Topic starter
22/08/2026 12:01 pm
TL;DR: AppSec teams face 865,398 alerts on average, and only 18% of critical findings stay critical once runtime context is applied, according to Pixee. Reachability and exploitability need to guide review before severity labels consume human time.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “SAST False Positive Statistics 2026: 8 Numbers on the Noise Problem”.
By the numbers:
- Only 18% of vulnerabilities labeled critical stay critical once runtime context is applied.
- 87% of organizations are running software with known exploitable vulnerabilities.
- Remediating just 7.3% of known CVEs covers most of the vulnerabilities attackers actually exploit.
Key questions
Q: Why do SAST false positives create operational risk beyond wasted time?
A: Because noise changes what teams notice, what they defer, and what they believe is urgent.
Q: How do you know if exploitability-based triage is working?
A: You should see fewer findings reaching developers, a higher proportion of reviewed issues proving reachable, and shorter time spent on low-value review loops.
Q: What should AppSec teams do first when SAST findings overwhelm review capacity?
A: Start by filtering findings through reachability and runtime context before they reach a human.
Practitioner guidance
- Implement exploitability-first triage Rank findings by reachability and runtime exposure before they enter human review, so teams spend time on paths an attacker can actually hit.
- Measure scanner noise against live application context Compare static findings with runtime and deployment context to identify which buckets systematically overstate risk in your environment.
- Separate remediation queues by exploitability Create different lanes for exploitable findings, theoretical findings, and low-confidence alerts so developers are not forced into one undifferentiated backlog.
Bottom line: SAST noise becomes a governance problem when teams cannot distinguish exploitable findings from findings that are merely present in code.
Glossary terms: False Positive, Reachability analysis, Exploitability context, Runtime Context
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
22/08/2026 12:02 pm
Alert overrun is now an access-control problem for engineering attention. When a team cannot reliably separate exploitable findings from noise, the scarce resource is no longer scanner coverage but reviewer focus. That changes AppSec governance: the pipeline must decide what gets a human, not just what gets reported. Practitioners should treat triage as an enforced prioritisation control, not an optional workflow refinement.
A question worth separating out:
Q: How should teams balance SAST severity with runtime context?
A: Use severity as an input, not the decision. Runtime exposure, code reachability, and deployment path should override generic labels when they show that a finding is not realistically exploitable in the current environment. That is the difference between a scanner-generated alert and an operationally meaningful risk signal.
👉 Read our full editorial: SAST false positives are drowning AppSec teams in unusable noise