Modern application security testing is a layered set of checks, not one scanner. It covers threat modeling at design time, static code analysis, dependency and secrets checks, and tests against the running application, all automated in the build so results arrive while the author still remembers the change.
Why is one tool never enough?
Each technique sees a different slice. Static analysis reads source and finds patterns such as injection sinks. It cannot see how the deployed app behaves behind a gateway. Testing a running app finds configuration and runtime flaws, but it cannot point to the line of code. Dependency checks find known flaws in code you did not write, which in most modern apps is the majority of the code.
NIST published a short list of minimum verification techniques after Executive Order 14028. NIST IR 8397 names threat modeling, automated testing, static code scanning, heuristic tools for hardcoded secrets, built-in language checks, black box test cases, code-based structural test cases, historical test cases, fuzzing, web application scanners and checks of included software. That list is a useful baseline because it is vendor neutral and it is short.
What does each layer catch?
Think of it as questions you ask at different times.
- Design: Where does untrusted data enter, and what can it reach? A threat model answers this before any code exists.
- Code: Does this change introduce a known bad pattern? Static scanning answers it on every pull request.
- Dependencies: Is any component we ship affected by a published vulnerability, and is the vulnerable function actually called?
- Secrets: Did a key or token land in the repository? Heuristic scanning catches most of these.
- Running app: Does the deployed system behave safely when probed from outside, including authentication and error handling?
A constructed example
Imagine a small team shipping an invoice API. Their threat model notes that invoice notes are rendered in a PDF. Static scanning flags a string concatenation in the PDF template code. The dependency check reports a flaw in a font library, but call graph analysis shows the vulnerable parsing routine is never reached, so it drops to the back of the queue. A web scan against staging then finds that an older v1 endpoint skips an authorization check. No single tool found all three problems. Each layer found the one it was built to find.
How should results be handled?
Volume is the common failure. A scanner that returns hundreds of findings with no ranking trains people to ignore it. Rank by whether the code is reachable, whether the flaw is exploited in the wild, and how exposed the service is. Fail the build only on a short list of conditions the team agreed on, and send everything else to a backlog with an owner.
Also keep the tests in the same place developers already work: the pull request and the IDE. NIST's Secure Software Development Framework (SP 800-218) groups this under practices for reviewing and testing code and for configuring the build to produce secure output, which is a reminder that the pipeline itself is part of what you test.
Safeguard covers several of these layers in one place: dependency and SBOM scanning, reachability analysis to separate reachable flaws from noise, secrets scanning, and policies and gates on pull requests. You can try the dependency view for free at gold.safeguard.sh/scan, which checks up to 100 dependencies in the browser.
What to do
- Write down the five layers above and mark which ones you run today.
- Add the cheapest missing one first. For most teams that is secrets scanning or dependency checks.
- Run checks on every pull request, not nightly.
- Rank findings by reachability and exposure before assigning work.
- Define two or three build failing conditions and publish them.
- Re-test after fixes, and keep a historical test for each past bug.
Quick check
Is a web application scanner enough on its own?
No. It sees the running app from outside and misses code level flaws and vulnerable dependencies that are not reachable through the paths it tries.
Should every finding fail the build?
No. Fail on a short agreed list, such as exposed secrets or reachable critical flaws, and track the rest in a backlog with owners.
Sources
- NIST IR 8397, Guidelines on Minimum Standards for Developer Verification of Software
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
