runtime contextual security
prioritize SAST alerts
behavioral telemetry DevSecOps
reduce false positive security alerts
SAST false positives
runtime triage security
static scan noise reduction
unreachable code vulnerabilities
runtime exploitability analysis
AppSec alert prioritization
SAST alert overload
SCA alert noise
reachability analysis AppSec
application security triage
accepted risk audit trail
InstaSLA runtime security
contextual vulnerability management
behavioral security telemetry
runtime code reachability
production vulnerability triage
Why Most Critical Vulnerabilities Never Get Exploited Closing the Static to Runtime Context Gap
Back to blog
The Limitations of Purely Static Scanning
Reachability vs. Exploitability — Two Different Questions
A Better Signal: Layering EPSS on Top of CVSS
Prioritizing Alerts with Behavioral Telemetry
Managing Accepted Risk
The Bottom Line
Sources
Why Most "Critical" Vulnerabilities Never Get Exploited: Closing the Static-to-Runtime Context Gap
Modern AppSec teams are drowning in theoretical risk. Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools are excellent at finding vulnerable code and outdated packages — but without runtime context, they generate an overwhelming volume of alerts that rarely reflect real-world risk.
The data backs this up. A 2025 empirical study of 2,414 open-source repositories by researchers at KAUST measured a 92% false-positive rate in downstream vulnerability scanners, and traced it primarily to vulnerabilities sitting in code that never actually executes — pruning those out with function-call analysis eliminated 62% of the false alarms. Separately, Endor Labs' State of Dependency Management research found that 60–80% of flagged dependency vulnerabilities exist in code paths no application ever calls, and that reachability analysis can eliminate 60–95% of false-positive SCA alerts. Traditional SCA false-positive rates commonly run between 71% and 88%.
That gap is what drives alert fatigue, friction between security and engineering, and missed SLAs on the vulnerabilities that are actually exploitable. Closing it means moving from theoretical scanning to runtime-informed triage.
The Limitations of Purely Static Scanning
SAST and SCA tools analyze source code, bytecode, dependency manifests, or binaries without executing the application. That's essential for catching defects early, but it means they can't tell whether a flagged issue is a real, exploitable threat in a live environment.
High false-positive rates. Without knowledge of network configuration, load balancers, or runtime memory, static scanners flag every theoretical code path. Industry surveys back this up: 58% of AppSec teams report frequently encountering false positives, and 11% say it happens constantly.
The reachability gap. Static analysis checks whether vulnerable code is present — not whether it's actually invoked. A package can carry a critical CVE that your application logic never touches.
Wasted engineering time. Teams routinely burn hours triaging "critical" findings that turn out to be dead code or unreachable functions. One analysis found security teams spend as much as 70% of their time investigating alerts that turn out to be false positives; incident responders report spending 2.5–5 hours a day on alert investigation alone.
Reachability vs. Exploitability — Two Different Questions
These terms get used interchangeably, but they answer different questions:
Reachability asks whether a verifiable execution path exists between untrusted input and a vulnerable function or dependency — essentially, does your own code's call graph ever reach the flawed code? If it doesn't, the vulnerability is effectively dead code, unreachable by an attacker.
Exploitability asks whether an attacker can actually trigger that path in your live environment — factoring in network exposure, firewall rules, WAFs, access controls, and other runtime guardrails. A function can be technically reachable in code and still be unexploitable in production because of the infrastructure sitting in front of it.
Reachability is necessary but not sufficient for exploitability. A flaw only matters once it's both reachable and accessible to an attacker — which is why combining call-graph analysis with runtime and network context gives a far more accurate risk picture than either signal alone.
A Better Signal: Layering EPSS on Top of CVSS
Part of the noise problem is structural: somewhere between 50% and 60% of all published CVEs are rated "High" or "Critical" under CVSS. When most of the backlog is labeled critical, the label stops being useful for prioritization — and a CVSS score, once assigned, rarely gets revisited even as real-world exploitation data comes in.
The Exploit Prediction Scoring System (EPSS), maintained by FIRST.org (the same body behind CVSS), addresses this by estimating the probability that a given CVE will actually be exploited in the wild within the next 30 days. It's a machine-learning model trained on exploit availability, proof-of-concept code, and observed attacker activity, updated daily. Research behind the model suggests that combining EPSS with CVSS lets teams cover the large majority of vulnerabilities that are actually exploited while working through only 3–5% of the total CVE backlog — versus needing to remediate 60–70% of the backlog to get the same coverage using CVSS alone. That's because only a small fraction of all CVEs — well under 1% — are ever observed being exploited in practice.
EPSS doesn't replace CVSS, and it doesn't replace reachability analysis either. CVSS tells you how bad a flaw could be; EPSS tells you how likely it is to be targeted; reachability and exploitability tell you whether your specific application and environment are even exposed to it. Used together, they let teams triage by real risk instead of theoretical severity.
Prioritizing Alerts with Behavioral Telemetry
To meaningfully cut false positives, organizations need to validate static findings against actual application behavior rather than treating every CVE as equally urgent:
Contextual prioritization. Live runtime signals confirm whether flagged code is genuinely exploitable in your specific environment, cutting the triage burden down to real, fixable risk.
Call-graph and function-level analysis. Reachability tooling constructs call graphs tracing execution from your own code into third-party dependencies, pinpointing which CVEs can actually be triggered.
VEX documentation. When reachability analysis proves a CVE unreachable, it can be tagged in a Vulnerability Exploitability eXchange (VEX) document with a "Not Affected" status — giving compliance teams an auditable record rather than a silently ignored finding.
The scale of the underlying problem is significant: organizations running vulnerability scanners typically use 5.3 tools on average, which multiplies duplicate findings across dashboards. An estimated two-thirds of organizations carry vulnerability backlogs of 100,000 or more, and mean time to remediation has been measured at around 252 days industry-wide.
Managing Accepted Risk
Proving a critical vulnerability is unreachable is only half the job — the other half is formally documenting that decision without violating compliance frameworks or internal SLAs. Research suggests this is a real gap: a 2025 industry survey found only 60% of organizations measure vulnerability SLAs at all, and of those that do, 65% still track them manually in spreadsheets.
That's the operational case for pairing runtime/reachability tooling with a dedicated SLA-tracking workflow. Platforms like InstaSLA, built specifically to turn GitHub security alerts into owned, prioritized, SLA-tracked engineering work, give teams a way to route unreachable or low-risk alerts into a formal "Accepted Risk" queue backed by evidence, rather than leaving tickets open indefinitely or burying the decision in a spreadsheet. That produces the audit trail regulated industries need — documenting the specific runtime or reachability evidence behind each accepted-risk call — while still holding teams accountable for the vulnerabilities that are genuinely exploitable, tracked against real remediation-time metrics rather than static severity labels.
The Bottom Line
Static scanning will always be the foundation of AppSec — it's what catches issues early, before code ships. But treating every static finding as equally urgent guarantees alert fatigue and burns trust between security and engineering. The fix isn't more scanning; it's layering reachability, exploitability, and exploitation-probability data (EPSS) on top of what SAST and SCA already find, then formally tracking and documenting the risk decisions that result.
Sources
OX Security — Reachability Analysis: Eliminating Vulnerability Backlogs
Pixee — Reachability Analysis for SCA
Seemplicity — Vulnerability Exploitability: Is That Critical CVE Reachable?
Oligo Security — Reachability Analysis: 5 Techniques & 5 Critical Best Practices
Splunk — Exploit Prediction Scoring System (EPSS): How It Works and Why It Matters
ORDR — EPSS Glossary
Security Boulevard — Alert Fatigue and Talent Gaps Fuel AppSec Weaknesses
Snyk — Minimizing False Positives: Enhancing Security Efficiency
CriticalStart — Accuracy in AppSec Is Critical to Reducing False Positives
Mondoo — Setting MTTR Goals: How SLAs Improve Vulnerability Management
InstaSLAThe 82% Context Gap: Why CVSS Is Failing Prioritization in 2026
Top comments (0)