Static Application Security Testing (SAST) tools are notorious for their high false-positive rates, but an equally critical issue is what they miss. False negatives are particularly insidious: you don't discover what your SAST tool missed until an exploit hits production—or worse, makes headlines

In the last five years, academic and industrial research has shed light on how often SAST tools overlook complex security flaws and how the glut of false positives can obscure these gaps.

The sobering reality of what traditional SAST misses

Empirical studies show that static analysis tools miss between 47% to 80% of vulnerabilities under test conditions. This particular study looked at both open source and commercial products tested against 27 software projects containing a total of 1.15 million lines of code and 192 vulnerabilities (ground truth). They also found that combining multiple tools only reduced false negative rate to 30% to 69%, at the expense of an increase in false positives.

The problem becomes even clearer when we examine specific vulnerability classes. In controlled tests on buffer overflow vulnerabilities in C++, individual SAST tools missed between 56% and 68% of test cases. Even when combining results from all three scanners, over half—53%—of known overflow bugs remained undetected.

If laboratory conditions reveal such gaps, the question becomes: how does SAST perform against actual production code?

When theory meets practice

A 2024 study examining 815 real vulnerable code commits in C/C++ projects found that a single SAST tool would only alert on about half of them. More alarmingly, 22% of known-vulnerable commits triggered no SAST warning at all—the tools missed them entirely. Among the commits that did generate alerts, at least 76% of those alerts were irrelevant to the actual vulnerability.

This creates a perfect storm: roughly one-fifth of vulnerabilities (22%) go completely undetected by SAST tools, while the remaining alerts are so polluted with false positives that finding the legitimate issues becomes a needle-in-haystack exercise.

Why complex flaws evade detection

Understanding why SAST tools fail to catch certain vulnerabilities is critical for building effective security programs. The limitations are fundamental to how static analysis has traditionally worked.

Logic problems

SAST tools excel at pattern matching. But they struggle profoundly with business logic vulnerabilities because static analysis cannot truly understand developer intent or higher-level business logic. When security problems arise from logical oversights—like a missing authorization check in a particular workflow—rather than blatant API misuse, static tools often lack rules to detect them. Authentication flaws, authorization mistakes, and workflow abuses frequently go unnoticed by automated scanners.

Context problems

Modern applications are complex systems where vulnerabilities often emerge from interactions across multiple components. Research shows that inter-procedural vulnerabilities commonly span an average of three functions in a chain. Traditional SAST tools that analyze code function-by-function or file-by-file may miss the bigger picture. A 2024 study confirmed that machine-learning vulnerability detectors focused at the function level perform significantly worse on vulnerabilities spanning multiple functions.

When noise hides silence

When a tool floods developers with hundreds of alerts, it becomes harder to spot the critical true positives among them. As a result, teams ignore or turn off rules, potentially hiding the few real issues. Worse, developers become desensitized and assume if nothing was flagged that the code is safe. As some admitted in a survey study, if SAST doesn’t report a problem they “just overlook the issue…no one ever reports false negatives.”

This out of sight, out of mind effect means high false positive rates indirectly contribute to false negatives: teams miss or downplay the risk, especially if they have an implicit trust that the tool will warn them. In response, many practitioners supplement SAST with human processes: peer code review or security audits. In that same survey, developers expressed confidence that manual code reviews will catch what SAST overlooks, essentially using SAST as a first-pass filter.

This belief is unfortunately flawed, however, given the substantial research showing the limitations of manual code review. One study in particular found that it takes at least 15 human reviewers to reach a 95% confidence level that all security vulnerabilities have been resolved.

Uncomfortable tradeoffs

Here's an uncomfortable truth the industry rarely discusses: SAST vendors deliberately design their tools to miss some vulnerabilities. To avoid overwhelming developers with false positives, most SAST solutions use heuristics and rule scope limits that deliberately tolerate false negatives. Tool vendors have historically assumed developers would rather have fewer alerts than comprehensive coverage. They've optimized for low noise at the expense of detection, and security teams have paid the price in missed vulnerabilities while still struggling with noise from false positives.

Recent research shows that perspectives are shifting. Many security-conscious teams now recognize that missing a real vulnerability is far worse than a noisy report. An interview study found that nearly all participants preferred to minimize false negatives, accepting that this would generate more false positives. This mindset especially prevails in high-stakes domains like finance and automotive, where the cost of an undetected flaw can be catastrophic.

The bottom line

As one interview subject aptly stated: "False negatives—that one is going to kill you." The silent vulnerability is ultimately more dangerous than a noisy false alarm. We cannot let the cacophony of false positives lull us into missing the security flaws that matter.

The past five years of research has exposed the fundamental gap in traditional SAST: we're missing more than we're catching. But this clarity creates an opportunity. We now understand that effective static analysis must reason about business logic, track vulnerabilities across complex code paths, and adapt its sensitivity based on risk, not just match patterns against rules. 

The tools that bridge this gap won't just reduce noise. They'll finally catch what matters.