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.
At a glance
What this is: Pixee argues that SAST false positives are now so severe that teams need exploitability analysis and runtime context to separate real risk from theoretical findings.
Why it matters: For AppSec, IAM-adjacent code governance, and engineering security teams, the issue is not just alert volume but whether tools can produce findings that developers will trust and act on.
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.
Context
SAST false positives are a governance problem as much as a tooling problem. Static analysis can identify insecure code patterns, but it cannot see whether those patterns are actually reachable, exploitable, or insulated by application context, which is why teams end up triaging noise instead of managing risk.
In application security programmes, this creates a credibility gap between finding defects and proving impact. Where code is generated faster, sanitisation varies, and frameworks change behaviour, pattern matching alone produces more alerts than teams can reasonably verify, which is typical at scale rather than an edge case.
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. A finding may be theoretically possible but not actually reachable or exploitable. That limitation becomes more visible as codebases grow, frameworks abstract logic, and AI-generated code increases pattern noise.
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. Validation matters most when the business impact could be large even if the vulnerability looks ordinary. In those cases, proof of exploitability is what separates noise from risk.
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. If alert counts keep rising but fix rates stay flat, the control is generating activity without improving risk reduction.
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.
Technical breakdown
Why static analysis overcalls exploitable defects
SAST inspects source code without executing it, so it infers risk from patterns rather than observed behaviour. That makes it useful for broad coverage, but weak on context such as framework behaviour, input sanitisation, routing, and data flow. A pattern can look dangerous while remaining unreachable in practice, or appear safe while becoming exploitable only in a specific runtime path. The result is a system that is intentionally conservative and therefore noisy. That is not a failure of implementation so much as a limitation of the method itself: static signals are not the same thing as exploitability.
Practical implication: treat SAST as an early-warning layer, not as proof of exploitability.
How exploitability analysis changes the security signal
Exploitability analysis adds reachability and security-context checks on top of static findings. Instead of asking only whether a pattern exists, it asks whether an attacker can actually reach the code path, influence the input, and trigger harmful behaviour under the application’s real conditions. That narrows the gap between theoretical weakness and actionable vulnerability. In practice, this changes the unit of work for AppSec teams: fewer findings, but each one has a stronger case for remediation. It also gives developers a better explanation for why a finding matters, which is critical when trust in the scanner has already eroded.
Practical implication: use exploitability as the filter that decides which findings deserve developer time.
Why AI-generated code makes the false positive problem worse
AI-generated code increases volume faster than teams can manually validate it, and it often arrives with inconsistent patterns, incomplete sanitisation, and duplicated logic. When that code is scanned by rule-based tools, the result is more alerts, not necessarily more useful signal. The benchmark data in the article points to a compounding effect: more code, more vulnerabilities, more scanner output, and less human capacity to sort the meaningful from the meaningless. That is why AppSec teams are moving from pure detection coverage to context-heavy verification models that can keep pace with development throughput.
Practical implication: pair code-generation governance with security validation that can keep up with release velocity.
Threat narrative
Attacker objective: The attacker objective is to exploit real application weaknesses that remain hidden inside a flood of low-value static alerts.
- Entry occurs when vulnerable code paths are introduced into repositories, either by developers or by AI-generated code with weak contextual safeguards.
- Credential access is not the core issue here; the main failure is that static tools flag patterns without proving whether those patterns are reachable or exploitable.
- Impact appears when teams ignore or deprioritise alerts because the signal-to-noise ratio has collapsed, allowing real defects to blend into routine noise.
Breaches seen in the wild
- Ultralytics PyPI compromise 2024: A GitHub Actions injection and a leftover PyPI token let attackers publish four Ultralytics releases that installed a cryptominer.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Alert credibility is now a governance issue: when teams stop trusting scanner output, the control has already failed even if the dashboard says coverage is high. This is not just triage fatigue, it is a signal governance failure where the programme cannot distinguish evidence from noise. The practical conclusion is that AppSec leaders need metrics tied to developer action, not just issue counts.
AI-generated code is amplifying security debt: faster code creation increases the burden on verification controls that were already strained by false positives. The problem is not simply more vulnerabilities, but more opportunities for low-confidence findings to drown out the real ones. AppSec teams should treat AI-assisted development as a reason to strengthen context-aware verification, not to assume existing scanning volume can scale unchanged.
Context-aware analysis is becoming the new baseline for AppSec operations: the market is shifting from theoretical detection toward decision-quality findings. That creates a sharper divide between tools that produce alerts and controls that help teams prioritise remediation. Practitioners should assume the next maturity step is not more findings, but better evidence for why a finding matters.
SAST false-positive debt: the accumulated cost of noisy static findings that steadily erode trust, inflate backlog, and weaken the practical value of AppSec tooling. Once this debt grows, organisations must pay it down with reachability, runtime verification, and stricter alert governance rather than more scanning alone.
What this signals
Context is becoming the decisive security variable: static findings without reachability proof behave more like hypotheses than controls, so AppSec programmes need a way to separate theoretical weakness from deployed risk. The organisations that survive alert inflation will be the ones that treat verification quality as part of the control stack, not as a reporting afterthought.
Runtime evidence is now the bridge between code scanning and governance: security leaders should expect static analysis to remain useful, but only as one input to a broader decision model that includes exploitability and application behaviour. That shift matters because teams cannot govern what they do not trust, and they will not trust what they cannot explain.
For practitioners
- 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.
- Prioritise exploitability analysis for noisy estates Use exploitability and security-context evaluation to collapse broad static outputs into a smaller set of findings that deserve remediation.
Key takeaways
- Traditional SAST can produce enough noise to weaken trust in the control itself, especially when findings are not tied to runtime reachability.
- Exploitability analysis reframes AppSec from counting possible flaws to identifying which flaws can actually be used in the deployed application.
- Teams that measure response quality and developer action will have a better view of risk than teams that only count findings.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | The article centres on code-level weakness detection and whether findings reflect exploitable design issues. |
| Recommendation — Use V15 to validate that code review focuses on exploitable design flaws, not only pattern matches. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | Runtime context and verification are needed before static findings can be treated as real control failures. |
| Recommendation — Align application verification with PR.DS-10 so security findings are judged against deployed behaviour. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about managing software-security findings in application code and reducing noisy triage. |
| Recommendation — Apply CIS-16 to govern application testing, validation, and remediation workflows around real risk. | ||
| MITRE ATT&CK | TA0009;TA0010 — Collection; Exfiltration | Exploitability analysis helps prioritise code paths that could support real attacker collection or exfiltration. |
| Recommendation — Map truly reachable findings to TA0009 and TA0010 before prioritising remediation effort. | ||
Key terms
- Exploitability Management: Exploitability management is the practice of prioritising vulnerabilities based on whether they can actually be used in a specific environment. It combines vulnerability intelligence, asset reachability, and compensating controls so teams focus on exposure that can lead to real operational impact.
- False Positive Rate: False positive rate is the share of alerts, detections, or test results that incorrectly indicate a problem when none exists. In security and identity operations, it measures how often a control flags benign activity as suspicious, usually expressed as a percentage of all negative cases. Lower rates reduce analyst noise and wasted response effort.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security practitioners connect identity control to wider assurance programmes without overextending into unrelated domains.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org