Reachability Analysis

SCA · DevSecOps
Definition

Reachability analysis is a technique for determining whether a vulnerable code path in a dependency is actually reachable from your application's code. A library might have a Critical CVE, but if your application never calls the vulnerable function, you're not actually exposed. Reachability analysis filters out those false positives.

Why it matters in practice

Most dependency scanners flag every CVE in every package you install. A typical scan on a medium-sized application can return 50-200 vulnerabilities. The vast majority are in code paths your application never touches. Reachability analysis cuts through the noise by tracing your actual call graph.

For example: a popular HTTP library might have a CVE in its WebSocket implementation. If your application uses the library only for plain HTTP requests and never uses WebSockets, the CVE is technically present but not reachable. A reachability-aware scanner won't flag it — or will flag it with lower priority.

How it works

Reachability analysis tools construct a call graph — a map of which functions call which other functions across your codebase and its dependencies. They then check whether any path from your application's entry points reaches the vulnerable function identified in the CVE.

This requires static analysis of your actual source code, not just your manifest file. It's why reachability analysis is typically a feature of enterprise SCA platforms (Snyk Code, Endor Labs, Aikido) rather than quick browser-based tools.

The trade-off

Reachability analysis reduces false positives significantly — some studies show it eliminates 70-80% of flagged CVEs as unreachable. The downside is it requires more setup: you need to give the tool access to your source code, and analysis takes longer than a simple manifest scan.

Practical advice

For most teams: start with manifest scanning (PackageFix, npm audit, OSV Scanner) to fix the clear issues. Add reachability analysis when alert fatigue becomes a problem — when you're drowning in Medium CVEs that are hard to prioritize.

Paste your manifest — see your exact versions against the full CVE history.

Scan with PackageFix →

Free · No signup · No CLI · Runs in your browser

Common questions

Does PackageFix do reachability analysis?
No — PackageFix is a manifest-based scanner. It checks your package versions against OSV and CISA KEV but doesn't analyse your source code call graph. For reachability analysis, look at Endor Labs, Snyk Code, or Aikido's reachability features.
Is a CVE less urgent if the vulnerable code is unreachable?
Generally yes — but there are caveats. Code paths can change as your application evolves. A function that's unreachable today might be reachable after a refactor. Reachability is a prioritization tool, not a reason to never fix a CVE.
Which tools offer reachability analysis?
Endor Labs, Snyk Code (paid), Aikido, and CodeQL (GitHub Advanced Security) all offer varying degrees of reachability analysis. They require source code access and more setup than manifest-based tools.
What is the difference between reachability and exploitability?
Reachability means the vulnerable code path can be called by your application. Exploitability means an attacker can actually trigger it with crafted input. A vulnerability can be reachable but not exploitable if there's no way to control the inputs that reach the vulnerable function. CISA KEV represents confirmed exploitability in real environments.

Related