Notifications
Clear all
Topic starter
22/08/2026 12:01 pm
TL;DR: 2026 benchmark data shows that organisations average 865,398 security alerts each, while only 18% of critical findings remain critical once runtime context is applied, underscoring that AppSec noise is now a triage and exploitability problem, not a scanner problem, according to Pixee. The practical response is to rank findings by reachability and exploitability before human review.
NHIMG editorial — 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.
- Remediating just 7.3% of known CVEs covers most of the vulnerabilities attackers actually exploit.
Questions worth separating out
Q: How should security teams reduce AppSec noise without weakening control?
A: Start by gating only newly introduced risk and moving low-friction checks earlier in the developer workflow.
Q: Why do critical findings often fail to match real-world risk?
A: Because critical labels usually describe code properties, not exploit conditions.
Q: What do security teams get wrong about false positives in DAST?
A: Teams often treat false positives as a tuning nuisance, when they are really a trust problem.
Practitioner guidance
- Introduce exploitability gates before human triage Require reachability, runtime context, and deployment evidence before a finding can enter an engineer's remediation queue.
- Build a single prioritisation layer across scanners Normalise findings from SAST, SCA, and runtime tools into one ranked queue so duplicate or unexploitable issues are suppressed consistently.
- Prioritise the small CVE subset that drives real exploitation Use EPSS-informed thresholds to focus on the limited set of CVEs most likely to be abused in the wild, rather than treating all critical labels equally.
What's in the full article
Pixee's full article covers the benchmark detail this post intentionally leaves at the analysis layer:
- The full breakdown of 2026 alert-volume figures across SAST, SCA, and runtime tools
- The benchmark source list and methodology behind the 18% criticality figure
- Pixee's triage and remediation metrics, including false-positive reduction and merge-rate data
- The references to EPSS and reachability analysis that underpin the prioritisation model
👉 Read Pixee's analysis of 2026 SAST false-positive statistics and AppSec noise →
SAST false positives: what AppSec teams should do about noise?
Explore further
22/08/2026 12:02 pm
False-positive management has become a governance problem, not a tooling problem. The article shows that teams are not failing because they lack scanners, but because scanners emit more findings than human review can absorb. In identity-adjacent programmes, that creates a dangerous blind spot around code paths that touch secrets, tokens, and service accounts. The governance lesson is that triage quality now determines whether AppSec data is usable at all. Practitioners need a control model that filters for exploitability before ownership and SLA discussions begin.
A question worth separating out:
Q: How do you know if AppSec prioritisation is actually working?
A: Look for fewer high-exposure findings lingering across sprints, faster closure of issues tied to critical assets, and less duplicate triage across tools. If the backlog is shrinking only in total count but the most reachable problems remain open, the prioritisation model is not reducing real risk.
👉 Read our full editorial: SAST false positives are drowning AppSec teams in unusable noise
