Topic starter
20/08/2026 5:34 pm
TL;DR: Traditional SAST is producing alert volumes that are too noisy to trust, with one benchmark showing 216 million findings across 250 organizations and only 795 critical issues after exploitability analysis, according to Pixee. The operational shift is toward runtime verification and exploitability analysis, because context, not pattern matching, now determines what is actually actionable.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “Why Your SAST Tool Cries Wolf — And What to Do About It”.
By the numbers:
- In one benchmark, 2,116 flagged vulnerabilities in public GitHub repositories produced only 180 real issues, a 91% false positive rate, according to Pixee.
- The OX Security 2026 Application Security Benchmark recorded 216 million findings across 250 organisations, according to Pixee.
- After exploitability and reachability analysis, only 795 findings were critical, or 0.092% of the total volume, according to Pixee.
Key questions
Q: Why do SAST tools produce so many false positives in modern codebases?
A: SAST produces false positives because it analyses code patterns without executing the application or seeing live data flow, framework behaviour, or runtime context.
Q: When should teams prioritise exploit validation over scanner alerts?
A: Teams should prioritise exploit validation whenever a scanner flags a public-facing path that can reach sensitive records, authentication logic, or database operations.
Q: What are the signs that AppSec alert quality is failing?
A: Common signs include large backlogs, repeated ‘won’t fix’ or ‘not applicable’ dispositions, developer disengagement, and security teams spending most of their time triaging rather than remediating.
Practitioner guidance
- Tighten scanner tuning before adding new tooling Review rule sets, framework-aware configuration, and sanitisation exceptions to see whether obvious noise can be removed without reducing coverage.
- Introduce reachability checks for high-volume findings Require evidence that a flagged code path is actually reachable in the deployed application before it enters developer triage.
- Measure developer response, not just finding count Track the percentage of findings that end in fix, verified false positive, or accepted risk so signal quality can be judged from outcomes.
Bottom line: Traditional SAST can produce enough noise to weaken trust in the control itself, especially when findings are not tied to runtime reachability.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:21 pm
Exploitability has become the real control objective: the industry has moved past asking whether a code pattern exists and toward whether it can actually be reached and abused. Static analysis without context produces volume, but not trust, and trust is what determines whether developers act. For application security programmes, the decisive question is no longer coverage alone, but which findings survive runtime and reachability scrutiny.
A question worth separating out:
Q: How should security teams respond when static findings no longer get trusted?
A: They should reset the workflow around evidence quality. That means tightening tuning, adding reachability or runtime validation, and prioritising only findings that can be explained in application context. If teams cannot show why a finding matters, the scanner’s volume will keep overwhelming decision-making.
👉 Read our full editorial: SAST false positives are driving a shift to exploitability analysis