Reachability analysis is a technique for determining whether a known vulnerability can actually be triggered from within your specific application — that is, whether there's an executable path from your code to the vulnerable function in a dependency. It reframes the core question of vulnerability management from "does my project contain a vulnerable component?" to the far more useful "can that vulnerability actually be reached and exploited given how my code uses the component?" Because a large share of the vulnerabilities in a typical dependency graph sit in code the application never calls, reachability analysis is one of the most effective tools available for cutting false-positive noise.
The Problem: Most Findings Don't Matter
Anyone who has run a dependency scanner knows the feeling: hundreds or thousands of findings, each labeled "critical" or "high," with no realistic way to fix them all. The uncomfortable truth is that most of them don't matter to your application.
Here's why. A single open source package might expose hundreds of functions, but your code typically uses only a handful. When a vulnerability is disclosed in that package, traditional software composition analysis flags your project as vulnerable simply because the package is present — regardless of whether the specific vulnerable function is ever called. If the flaw lives in a feature you don't use, the vulnerability is present but unreachable: it can't be triggered through your application, so exploiting it is not possible via your code paths.
This distinction is enormous in practice. Studies and vendor data across the industry have repeatedly shown that a substantial majority of dependency vulnerabilities are unreachable in any given application. Treating all of them as equally urgent is what produces alert fatigue — and alert fatigue is what causes teams to ignore the reachable vulnerabilities that genuinely threaten them. For the broader context, see our concepts library.
How Reachability Analysis Works
Reachability analysis builds a model of how code actually executes and checks whether the vulnerable code sits on any path your application can follow. There are two broad approaches, often combined:
- Static reachability analyzes source code and dependencies without running them. It constructs a call graph — a map of which functions call which — starting from your application's entry points, and traces whether any path leads to the known-vulnerable function. If no path exists, the vulnerability is unreachable.
- Runtime (dynamic) reachability observes an application while it runs, recording which functions and packages are actually loaded and invoked. A vulnerability in code that never loads at runtime is deprioritized with high confidence.
The heart of static reachability is the call graph. Starting from entry points (an API handler, a main function, a request route), the analyzer follows function calls outward, through your code and into dependencies, marking everything it can reach. A vulnerable function that never appears in that reachable set is, by definition, unreachable from your application.
Reachable vs. Present: A Worked Distinction
| Scenario | Component present? | Vulnerable function called? | Reachable? | Priority |
|---|---|---|---|---|
| You call the exact vulnerable function | Yes | Yes | Yes | Fix now |
| You use the package, but not the flawed feature | Yes | No | No | Deprioritize |
| Transitive dep, never invoked at runtime | Yes | No | No | Deprioritize |
| Vulnerable code behind a config flag you enable | Yes | Conditionally | Potentially | Investigate |
The middle rows are where reachability earns its keep: those are the findings that would otherwise consume triage time for no security benefit.
The Limits and Nuances
Reachability analysis is powerful, but it must be applied honestly:
- Unreachable is not "safe forever." A vulnerability that's unreachable today can become reachable tomorrow if a developer starts using the affected function. Reachability is a point-in-time property that must be re-evaluated on every change.
- Dynamic code is hard. Reflection, dynamic dispatch, plugin systems, and heavy metaprogramming can obscure call paths, so good tools err toward caution when they can't prove unreachability.
- It's for prioritization, not dismissal. Best practice is to rank unreachable findings lower, not delete them — you still want them tracked, patched during normal maintenance, and re-checked as code evolves.
Used correctly, reachability doesn't mean ignoring vulnerabilities; it means spending your limited remediation effort where it actually reduces risk.
Best Practices
- Prioritize, don't discard. Fix reachable vulnerabilities first, then address unreachable ones during routine dependency upkeep.
- Re-run on every change. Reachability shifts as your code changes, so it belongs in CI, not a one-time audit.
- Combine static and runtime signals for the highest confidence — static for breadth, runtime for proof of actual use.
- Pair reachability with exploitability data (like whether an exploit is known to exist in the wild) for the sharpest prioritization.
- Keep the full inventory. Even deprioritized findings should live in your SBOM for incident response and compliance.
How Safeguard Helps
Reachability analysis is central to how Safeguard fights alert fatigue. Our Software Composition Analysis doesn't stop at detecting that a vulnerable package is present — it builds a call graph from your application's entry points to determine whether the specific vulnerable function is actually reachable, so your team sees a short list of genuinely exploitable issues instead of a wall of "criticals" that can never be triggered.
The Griffin AI engine layers additional context on top — exploitability, exposure, and business criticality — to rank the reachable findings that remain, and generates fix recommendations so prioritization turns into action. Because Safeguard keeps the complete inventory in SBOM Studio, the unreachable findings aren't lost; they're tracked and automatically re-evaluated as your code changes, so a vulnerability that becomes reachable later doesn't slip through.
Create a free account to see how much of your backlog is actually reachable, or read the documentation to learn how the analysis works.
Frequently Asked Questions
What does "reachable" mean for a vulnerability? A vulnerability is reachable when there's an executable path from your application's code to the specific vulnerable function in a dependency — meaning it can actually be triggered as your software runs. If your code never calls the flawed function, the vulnerability is present but unreachable and can't be exploited through your application.
Does reachability analysis eliminate false positives entirely? It dramatically reduces them, but no technique is perfect. Dynamic language features like reflection and plugin loading can obscure call paths, so responsible tools stay cautious when they can't prove a path doesn't exist. Reachability is best used to prioritize findings rather than silently delete them.
Is an unreachable vulnerability safe to ignore forever? No. Unreachable is a point-in-time property. A future code change could start calling the vulnerable function, making it reachable. Best practice is to deprioritize unreachable findings for immediate action but keep tracking them, patch during routine maintenance, and re-evaluate reachability on every change.
What is the difference between static and runtime reachability? Static reachability analyzes code without executing it, building a call graph to see if a path to the vulnerable function exists. Runtime reachability observes the running application to record which code actually loads and executes. Static offers breadth and works pre-deployment; runtime offers high-confidence proof of real usage. Combining both is most effective.