The False Positive Problem: Why an SCA Tool Reports 500 Vulnerabilities and Only 12 of Them Matter

An SCA scan runs against a mid-sized Java project. Let’s assume it reported 487 vulnerabilities. The security engineer opens the dashboard, sorts by CVSS, sees 23 criticals, 89 highs, and several hundred mediums. By the end of the week, 19 of the 23 criticals turn out to be in transitive dependencies whose vulnerable functions the application never calls. The actual exploitable count is 4.

This is how most SCA tools are designed to work: they match every component in the dependency tree against a vulnerability database and report every match. The problem is that matching is not the same as exploitability. Industry research cited by Pixee suggests false positive rates between 71 - 88% across typical scanning tools.

 

Why This Happens

Conventional SCA works through presence-based detection. The tool resolves the dependency tree, builds a list of components with their versions, and queries vulnerability databases for known CVEs affecting those versions. If package X at version Y has CVE-2024-12345 in its XML parsing module, and your application includes package X at version Y, the tool reports a finding — regardless of whether your code ever touches the XML parser.

From a database-query perspective, this is correct: the vulnerable code is present in the shipped binary. From an exploitability perspective, it is mostly noise. If an application only uses that library’s string formatting utilities and never invokes the XML parser, the CVE is technically there, but practically irrelevant.

The real cost is engineering attention. When a developer opens a report with 487 findings, the cognitive overload says “close it”. When the security team pushes to triage them all, the tool stops generating signal and starts generating friction. 

 

Reachability Analysis: What It Actually Means

Reachability analysis is the key. Instead of just matching components against CVEs, it traces the application’s call graph and determines whether the vulnerable method in the dependency is reachable from the application’s own code.

A library might expose a hundred public functions, and the application might call six of them. If the CVE affects one of the ninety-four that are not called, the vulnerability exists but is not exploitable from the codebase. And a reachability analysis in the SCA tool filters it out.

In practice, the real go-to implementation combines static analysis of the application’s call graph with SCA vulnerability data and treats the intersection as the real finding set.

 

A Theoretical CVE vs. an Exploitable Path

We take an application that uses Apache Commons Text for simple string substitution. A CVE is disclosed affecting the library’s StringSubstitutor class when used with variable interpolation from untrusted input. 

• A conventional SCA tool reports this as a critical finding in a dependency tree. 

• A reachability-aware tool asks a different question: does the code ever call StringSubstitutor with untrusted input?

If the answer is no, then the vulnerability is theoretical.

 

Fewer but Accurate Beats a Wall of Noise

The question security teams should ask of any SCA tool is not how many CVEs it finds. But how many of them a team can actually act on. DerScanner’s hybrid SAST+SCA analysis was built around this distinction. It combines static analysis of the application’s call graph with SCA vulnerability data to determine whether a vulnerable method in a dependency is actually invoked from the code. The result is a lower false positive rate — findings that represent actually exploitable risk. 

 

 

Alert fatigue is a predictable behaviour pattern when optimizing isn't considered for precision. The organizations that get SCA right are the ones that treat the number of findings for a fix as the primary metric. An accurate report is the only kind that survives contact with an engineering team.