Notifications
Clear all
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.
NHIMG editorial — based on content published by Pixee: Why Your SAST Tool Cries Wolf And What to Do About It
By the numbers:
- The OX Security 2026 Application Security Benchmark reported 216 million findings across 250 organizations, while the average enterprise now faces 865,398 security alerts per year.
- After exploitability and reachability analysis, only 795 findings were critical, which represented 0.092% of the total volume.
- Ghost Security found that 180 of 2,116 SAST-flagged vulnerabilities were real, which meant a 91% false positive rate on open source code.
Questions worth separating out
Q: What breaks when SAST false positives are not controlled?
A: Triage credibility breaks first, then remediation throughput, and finally developer trust.
Q: Why do static scanners struggle with exploitable risk in modern codebases?
A: They inspect patterns without executing the application, so they cannot reliably see reachability, compensating controls, or deployment-specific context.
Q: How do security teams know if SAST is actually improving AppSec?
A: Look for shorter time to remediation, fewer repeated findings in the same code areas, and a higher percentage of findings resolved before merge or release.
Practitioner guidance
- Implement exploitability-based triage Require reachability and runtime-context checks before developer assignment so only findings that can be triggered in your environment enter the remediation queue.
- Measure developer response rate, not just false positive rate Track how often developers mark findings as won't fix or not applicable, because that ratio shows whether trust in the scanner has already collapsed.
- Add runtime verification to static findings Pair SAST with runtime testing or observation so scanner output is validated against real execution paths instead of theoretical code patterns.
What's in the full article
Pixee's full analysis covers the operational detail this post intentionally leaves for the source:
- Benchmark methodology behind the 216 million findings figure across 250 organizations
- The three-tier response model for tuning, runtime verification, and exploitability analysis
- Examples of how exploitability scoring changes developer triage queues in practice
- Pixee's own cohort data on false positive reduction and merge outcomes
👉 Read Pixee's analysis of why SAST tools produce so many false positives →
SAST false positives: are your AppSec controls keeping up?
Explore further
20/08/2026 6:21 pm
Alert quality is now a governance problem, not just an AppSec tuning problem. When security teams cannot separate exploitable findings from theoretical ones, remediation prioritisation becomes arbitrary and trust collapses. That affects developer behaviour, audit posture, and risk reporting at the same time. The practical conclusion is that security leadership should measure signal quality as a governance outcome, not a scanner setting.
A question worth separating out:
Q: How can teams reduce false positives without missing fraud?
A: Set different thresholds for different lifecycle stages and transaction types. A low-risk login, a new account, and a payout request should not trigger the same response. Good programmes use graduated controls, so only aligned evidence triggers the strongest friction.
👉 Read our full editorial: SAST false positives are driving a shift to exploitability analysis
