Static application security testing (SAST): what it catches, what it misses
SAST tools scan source code for security flaws before it runs. OWASP's own assessment is that they catch a useful slice of problems, and miss a lot.
Static application security testing, or SAST, analyzes an application's source code, without running it, to find security weaknesses. It is usually one of the first security checks a development team adds, because it can run automatically on every code change.
What SAST does well
According to OWASP, the open security community behind the OWASP Top 10, source code analysis tools have three main strengths. They scale, running on every build or nightly without extra effort. They find well-known flaw types such as SQL injection and buffer overflows with confidence. And they point developers to the exact file and line, which makes fixes quick.
What it misses
OWASP is equally direct about the limits. In its words, "Current SAST tools are limited." Among the weaknesses it lists:
- Many types of flaw are hard to find automatically, including authentication problems, access control issues and insecure use of cryptography.
- The tools find only a small share of an application's security flaws.
- They produce many false positives, which take time to triage.
- They usually can't see configuration problems, because configuration isn't in the code.
- Many can't analyze code that doesn't compile.
That is why SAST is one layer, not a security program. Teams pair it with dependency scanning for vulnerable open-source libraries, dynamic testing of the running application, and human code review.
Choosing a tool
OWASP's selection criteria, in order of how often they decide a purchase:
| Criterion | Why it matters |
|---|---|
| Language and framework support | A tool that doesn't understand your frameworks misses their flaws |
| Accuracy | False positives waste developer time; false negatives give false comfort |
| CI/CD integration | It has to run automatically on every change |
| IDE plugins | Developers fix issues faster when they see them while writing code |
| Source or binary analysis | Some tools need buildable source code |
| License cost | Pricing models vary widely |
OWASP also points to the OWASP Benchmark project as a way to compare tool accuracy.
Rolling it out without stalling developers
Start in report-only mode, so findings are visible without blocking merges. Fix or suppress the backlog in the most critical applications first. Then block only high-confidence, high-severity findings on new code. Teams that turn on blocking for every finding on day one usually end up turning the tool off.
What IT teams should do
- Check that every production application has some form of automated code scanning.
- Add dependency scanning alongside SAST, since vulnerable libraries are a common entry point.
- Start new SAST tools in report-only mode, then block high-severity findings on new code.