In December 2021, a single Java logging library turned into the software industry's most expensive fire drill in a decade. Log4Shell (CVE-2021-44228) scored a 10.0 on CVSS, sat in an estimated 3 billion devices, and triggered mass patch-everything mandates. But most organizations quickly discovered their real problem wasn't Log4j itself — it was that their vulnerability scanners flagged the library everywhere it existed in a dependency tree, whether or not the vulnerable JNDI lookup code path was ever actually invoked. Security teams spent weeks triaging alerts for code that could never be exploited in their environment.
That gap — between "this vulnerable package is present" and "this vulnerable code actually runs" — is the problem reachability analysis exists to solve. As CVE volume climbs past 40,000 disclosures a year, the industry is converging on a simple idea: you can't fix everything, so you'd better know what's actually reachable before you decide what's urgent.
What Is Reachability Analysis, and Why Does It Matter Now?
Reachability analysis determines whether the vulnerable function inside a dependency is actually called, directly or transitively, by your application's code paths, rather than just sitting unused in a JAR, wheel, or node_modules folder. A typical enterprise application pulls in 150-500 open-source dependencies, and each of those brings its own sub-dependencies — Maven and npm trees routinely run four or five levels deep. A CVE in a transitive dependency doesn't automatically mean your application is exposed; it means the vulnerable package is present somewhere in that tree.
This matters now because the volume of disclosed vulnerabilities has outpaced any team's ability to manually triage them. NVD publishing crossed roughly 29,000 CVEs in 2023 and jumped past 40,000 in 2024 — a growth curve that has held steady even as NVD itself struggled with enrichment backlogs for much of 2024. Meanwhile, application security teams haven't grown headcount at anywhere near that rate. Reachability analysis is the mechanism that lets a fixed-size team keep pace with an exponentially growing disclosure pipeline by narrowing "vulnerabilities present" down to "vulnerabilities that matter."
How Much Vulnerability Noise Are Security Teams Actually Dealing With?
Most of it is noise: independent research from application security vendors studying real customer codebases has repeatedly found that somewhere between 60% and 85% of vulnerabilities flagged by traditional software composition analysis (SCA) tools sit in code that is never executed by the application. A mid-size fintech scanning a typical microservices estate of 40-60 services might see 3,000-5,000 open CVE findings from an SCA scan in a given quarter. Studies applying reachability analysis to comparable dependency sets have found that only 10-25% of those findings trace back to an actually-called function.
The practical effect shows up in metrics security leaders care about directly. Mean time to remediate (MTTR) for critical vulnerabilities frequently stretches past 60-90 days at organizations relying on CVSS-only triage, largely because engineering teams are asked to patch dependencies with no clear justification for urgency and deprioritize the requests. When reachability data narrows a 4,000-item backlog to the 400-600 items that are provably exploitable in production, remediation velocity on the items that matter improves because engineers can see the actual call path that makes a fix urgent, not just a score.
What's the Difference Between Static and Runtime Reachability Analysis?
Static reachability analysis builds a call graph from source code or bytecode without executing anything, while runtime reachability analysis observes what code paths actually execute in a live or running-equivalent environment — and the two produce materially different answers. Static analysis, built through techniques like control-flow graph construction and points-to analysis, can tell you whether a vulnerable function is theoretically callable from your entry points. It's fast, works pre-deployment, and integrates cleanly into CI pipelines. But it struggles with dynamic language features — reflection in Java, eval and dynamic imports in JavaScript, duck-typed dispatch in Python — and tends to over-approximate reachability to stay safe, which reintroduces some of the noise it was meant to remove.
Runtime reachability analysis instead instruments the application (via language-level agents, eBPF probes, or sidecar observation in Kubernetes environments) and records which functions actually execute during real traffic or representative test suites. This produces far higher-confidence results because it reflects what genuinely happens in production, including code paths triggered by configuration, feature flags, or request routing that static analysis can't see. The tradeoff is coverage: runtime analysis only sees what actually ran, so a rarely-triggered admin code path exercised once a quarter might not show up in a week of observation. The strongest programs combine both — static analysis for pre-merge, always-on coverage, and runtime confirmation for production-grade confidence on the highest-severity findings.
Why Do CVSS Scores Alone Fail to Prioritize Real Risk?
CVSS alone fails because it scores a vulnerability's theoretical worst-case severity in isolation, with no knowledge of whether your specific application ever calls the vulnerable code, exposes it to untrusted input, or runs it with elevated privileges. A CVSS 9.8 finding in a logging utility's obscure configuration parser and a CVSS 9.8 finding in a JSON deserializer sitting directly behind your public API gateway are scored identically, but they represent wildly different real-world risk. This is precisely the pattern that made Log4Shell so disruptive: the vulnerable JNDI lookup functionality was reachable in some deployments (any app logging attacker-controlled strings) and completely inert in others (apps that never passed user input through the vulnerable log formatting call), yet CVSS gave every instance the same 10.0.
CISA's Known Exploited Vulnerabilities (KEV) catalog and EPSS (Exploit Prediction Scoring System) both emerged as partial answers to this gap, adding real-world exploitation signal on top of CVSS. They're valuable, but they still describe the vulnerability, not your application. EPSS might tell you a CVE has a 12% probability of exploitation in the next 30 days across the internet; it can't tell you whether that vulnerable function is even present in your call graph. Reachability analysis is the layer that answers the application-specific question CVSS, KEV, and EPSS were never designed to answer.
What Does Effective Reachability-Based Prioritization Look Like in Practice?
In practice, it looks like a scoring pipeline that starts with every CVE affecting your dependency tree and progressively filters by reachability, exploit maturity, and exposure before anything reaches an engineer's queue. Take a hypothetical but representative case: a security team ingests 1,200 open CVE findings from their SCA tool across 80 services. Reachability analysis (static, cross-checked with runtime traces from staging traffic) confirms that 180 of those findings sit on an actually-called path. Of those 180, cross-referencing against CISA KEV shows 6 are under active exploitation in the wild, and EPSS scoring flags another 14 with elevated near-term exploitation probability. That 20-item list — not the original 1,200 — becomes the team's real, evidence-backed priority queue for the week.
This is also where reachability analysis pays for itself in developer trust. When a vulnerability ticket includes the actual call stack showing how untrusted input flows into the vulnerable function, engineers stop treating security tickets as bureaucratic noise and start treating them as the concrete bug reports they actually are. Teams that have adopted reachability-informed triage commonly report cutting their "must-patch-now" queue by 70-90% relative to CVSS-only lists, freeing engineering time to actually close out the vulnerabilities that carry real exploitation risk instead of chasing theoretical ones.
Does Reachability Analysis Replace Software Composition Analysis?
No — reachability analysis is a prioritization layer on top of SCA, not a replacement for it, because you still need SCA to build the complete inventory of what's in your software supply chain in the first place. SCA answers "what open-source components, and which versions, are in my build?" Reachability analysis answers the follow-up question: "of the vulnerabilities in those components, which ones can actually be triggered by an attacker interacting with my application?" Skipping SCA and going straight to reachability would mean flying blind on your dependency inventory — which matters for SBOM compliance obligations (including the ones tied to Executive Order 14028 and increasingly to procurement requirements) independent of exploitability. The right model treats SCA as the census and reachability analysis as the triage nurse deciding who goes into the operating room first.
How Safeguard Helps
Safeguard builds reachability analysis directly into the software supply chain security workflow, so vulnerability data never arrives at an engineer's desk without exploitability context attached. Instead of treating SCA output as the finish line, Safeguard traces each CVE against your actual call graphs — combining static analysis across your CI pipeline with runtime signal from production and staging environments — to determine whether the vulnerable function sits on a path your application genuinely executes.
That reachability verdict then feeds a unified risk score alongside CISA KEV status, EPSS probability, and exposure context (is the service internet-facing, does it handle untrusted input, does it run with elevated permissions), so security teams get a single prioritized queue instead of five disconnected data sources to reconcile manually. Findings routed to engineering teams include the actual call path from entry point to vulnerable function, turning abstract CVE IDs into concrete, actionable bug reports.
For teams under SOC 2 or similar compliance pressure, Safeguard maintains full SCA-based inventory and SBOM generation as the foundation, so reachability-based triage never comes at the cost of audit-ready component visibility. The result is a workflow where a scan surfacing thousands of theoretical findings resolves down to the handful that represent genuine, exploitable risk in your specific environment — cutting remediation backlogs down to a size your engineering org can actually keep pace with.