SAST false positives are driving a shift to exploitability analysis

At a glance

What this is: This is an analysis of why SAST generates so many false positives and why exploitability analysis is becoming the practical response.

Why it matters: It matters because identity and access teams increasingly depend on code-security signals that are precise enough to protect secrets, credentials, and privileged workflows without overwhelming remediation capacity.

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.
• AI-generated code contains 2.74x more vulnerabilities than human-written code, according to CodeRabbit's 2026 analysis.

👉 Read Pixee's analysis of why SAST tools produce so many false positives

Context

Static application security testing is designed to find patterns in source code, not to prove whether a weakness is reachable in a running system. That gap matters because modern codebases are larger, faster-moving, and increasingly generated with AI, which means the volume of findings is rising faster than most teams can triage.

For identity-heavy applications, the concern is not just application noise. False positives can obscure genuine risks around secrets, tokens, service accounts, and privilege paths embedded in code. The article's central point is that teams need stronger context, not simply more findings, and that position is increasingly typical across AppSec programmes.

Pixee's analysis is strongest when it treats alert quality as an operational control issue rather than a tooling complaint. The underlying problem is now familiar to security and identity practitioners alike: if the signal cannot separate theoretical exposure from real exploitability, governance breaks down at the point of triage.

Key questions

Q: What breaks when SAST false positives are not controlled?

A: Triage credibility breaks first, then remediation throughput, and finally developer trust. Once most findings are ignored, the tool stops shaping behaviour, which means genuine weaknesses in code and identity-sensitive flows can remain open for far longer than intended.

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. In modern frameworks, that gap produces many valid-looking warnings that are not practically exploitable.

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. If developers are ignoring alerts, the tool may be generating noise rather than risk insight. Good programmes measure both adoption and defect reduction.

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.

Technical breakdown

Why static analysis produces false positives

Static analysis inspects source code without executing it, so it cannot observe runtime context, data flow through live services, or whether a vulnerable pattern is actually reachable. That limitation becomes acute in frameworks with custom sanitisation, layered abstractions, and environment-specific controls. The result is a flood of theoretically valid findings that may never become exploitable. In practice, the tool is not failing its design, but the design is mismatched to the decision teams need to make.

Practical implication: use static findings as a screening layer, not as a final decision on remediation priority.

Why exploitability and reachability analysis change the signal

Exploitability analysis narrows the gap between code that looks risky and code that can actually be triggered in a given environment. Reachability asks whether the path from input to sink exists. Security-context evaluation then checks whether compensating controls, sanitisation, authentication boundaries, or deployment conditions block the issue in practice. This is a different question from detection coverage. It moves AppSec from pattern recognition toward operational evidence, which is why it reduces noise so sharply.

Practical implication: prioritize tooling and workflows that prove reachability before assigning developer work.

Why AI-generated code makes alert fatigue worse

AI-generated code often increases both code volume and vulnerability density at the same time, which means SAST has more material to inspect and more opportunities to misclassify harmless patterns. When teams do not comprehensively review AI-generated code for security, IP, and quality issues, the signal degradation compounds. This is especially relevant when generated code touches authentication flows, secret handling, or API integrations, where false confidence can hide real exposure.

Practical implication: add AI-code review gates that include exploitability checks for any path handling secrets or privileged access.

Threat narrative

Attacker objective: The objective is to keep real exploitable weaknesses buried inside an alert system that no longer commands attention.

1. Entry occurs when vulnerable or suspicious code patterns are introduced into the codebase through human development or AI-generated output.
2. Escalation happens when static scanners produce large volumes of low-confidence alerts that overwhelm triage and hide the few reachable issues.
3. Impact follows when genuine vulnerabilities remain unresolved because teams have lost trust in the alert stream and stop acting on it.

NHI Mgmt Group analysis

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.

Exploitability analysis defines a new named concept for AppSec maturity: context-intelligent triage. This is the point at which a finding is evaluated against runtime reachability, compensating controls, and deployment context before it reaches a developer queue. The model aligns with NIST-CSF and NIST-800-53 thinking because it treats control effectiveness as evidence, not assumption. Practitioners should adopt it where code volume and alert volume are both rising.

AI-generated code widens the gap between detection capacity and human review capacity. More code does not merely create more vulnerabilities, it creates more places for pattern-based scanners to generate noise. That means AppSec programmes need stronger review boundaries around generated code, especially where secrets, credentials, or identity flows are involved. The conclusion for practitioners is clear: scanning alone cannot keep pace with machine-assisted development.

For identity security, false positives are dangerous because they obscure the code paths that govern secrets and privilege. Service account handling, token propagation, and API authentication logic are often embedded in application code and dependencies. If teams lose trust in scanner output, those identity-sensitive paths are exactly where real issues can hide. The practical takeaway is to align AppSec triage with IAM and PAM risk, not just vulnerability counts.

Signal collapse is the named failure mode this article exposes. Once a security queue crosses the point where most findings are ignored, the control no longer functions as a control. That pattern is visible in both AppSec and identity governance programmes, where volume without prioritisation erodes actionability. Practitioners should treat sustained high false positive rates as an operational risk signal.

What this signals

Context-intelligent triage is becoming the practical response to AppSec overload, especially where code security overlaps with IAM, secrets, and service-account governance. When scanners cannot distinguish exploitable paths from theoretical ones, security teams need runtime evidence before they spend developer time. The same logic applies to identity programmes that are already overloaded by low-quality alerts.

This shift also changes how teams should think about application risk reporting. A queue full of non-actionable findings can look busy while doing very little to reduce exposure, which means governance metrics need to move closer to fixability and reachability. Where code protects privileged workflows, teams should align scanner output with Ultimate Guide to NHIs , 2025 Outlook and Predictions and the live control thinking in NIST AI Risk Management Framework when AI-generated code or assistants are part of the development path.

For practitioners

• 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.
• Review AI-generated code for identity-sensitive paths first Prioritise authentication, secrets handling, service account logic, and API integration code produced by AI systems because those paths carry the highest governance risk.

Key takeaways

• SAST noise becomes a control failure when teams can no longer tell which findings are actually exploitable.
• Exploitability analysis and runtime verification reduce queue volume by restoring context that static analysis cannot see.
• Identity-sensitive code paths such as secrets handling and service-account logic deserve the earliest contextual review.

Key terms

• False positive closure rate: The share of alerts that are automatically identified as benign and closed with supporting evidence before reaching analyst queues. It is a useful SOC metric because it shows whether automation is reducing noise without hiding real threats.
• Exploitability Benchmark: An exploitability benchmark tests whether a model can progress from a weak signal to a working proof of concept against planted or known vulnerabilities. It is closer to real offensive validation than generic model scoring because it measures practical attacker outcomes.
• 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.
• Context-Intelligent Triage: A security review process that ranks findings using runtime evidence, deployment context, and control state rather than scanner output alone. It is especially useful where code volume is high and identity-sensitive logic, such as secrets and privileges, is embedded in applications.

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

👉 Pixee's full post covers the benchmark data, triage model, and exploitability analysis approach.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in practical terms. It gives security practitioners a stronger basis for connecting application findings to identity risk across modern delivery pipelines.