What is reachability analysis? Separating exposure from presence
Reachability analysis asks whether the vulnerable part of a dependency can actually be reached by your application's execution. A vulnerable function in a library you never call is present but not exposed. By demoting unreachable findings, reachability turns a queue of every-vulnerability-in-every-dependency into the far smaller set that is actually a path to your system - as long as unknown reachability is treated as unknown, not as safe.
Reachability analysis answers a question that sits underneath vulnerability management: not do we contain this vulnerable component, but can the vulnerable code actually run in our application. The distinction sounds academic until you see what it does to a queue. Most dependencies are imported for a handful of functions, and a vulnerability usually lives in one specific function. If you never call that function, the vulnerability is present in your inventory but not a path into your system.
Presence versus exposure
A software composition analysis scan matches your components against vulnerability data and reports every match. That is correct and necessary - but it over-reports exposure, because it answers presence, not reachability. A mature program layers reachability on top: of the vulnerabilities present, which ones can actually be executed?
The payoff is prioritization. Reachability is one of the signals - alongside severity, exploitation likelihood, and confirmed exploitation - that turns a wall of matches into an ordered worklist. A reachable, known-exploited, high-severity vulnerability is unambiguous top-priority; an unreachable one of the same CVSS can wait behind it.
The direction of error is everything
Reachability analysis can be wrong, and its two error directions are not symmetric:
- Falsely reachable: the tool says a vulnerability is reachable when it is not. Cost: some wasted triage time.
- Falsely unreachable: the tool says a vulnerability cannot be reached when it can. Cost: a real exposure hidden, silently.
The second is far worse, which dictates the only honest design: demote only what can be proven unreachable, and mark everything else unknown - never assumed-safe. Reachability is a tool for ranking work down, not for making findings disappear. Any product that treats unknown reachability as a green light has turned a prioritization aid into a suppression mechanism, and a dangerous one.
Depth matters
Reachability comes at different depths, and the depth determines how much its verdicts are worth:
- Import-presence - is the vulnerable package imported anywhere in the code? A coarse, cheap signal: useful, but “imported” is not “the vulnerable function is called.”
- Call-graph reachability - is there an actual path of function calls from your code to the vulnerable function? Precise, and much harder to compute, especially across dynamic dispatch and language boundaries.
A tool that performs import-presence should say so rather than imply call-graph precision, because the two support very different confidence in an “unreachable” verdict.
In the SecuNexa platform
Reachability is a correlation property, and it lives where the findings come together. The engines contribute the raw signals - which components are present, which are imported, and where call-graph information is available - and the dashboard combines them into the reachable / unreachable / unknown verdict that feeds prioritization. Consistent with the principle throughout the platform, unknown stays unknown: reachability sharpens the queue without ever quietly hiding a real path.
Frequently asked questions
How is reachability different from just having a vulnerable dependency?
Containing a vulnerable version and being exploitable through it are different facts. Most dependencies are pulled in for a few functions; if the vulnerable function is not among the ones you call, the vulnerability is present but not reachable. Reachability analysis makes that distinction, which is what separates a real exposure from an inventory match.
Can reachability be wrong, and which way should it err?
It can, and the direction matters enormously. Wrongly calling something reachable wastes triage time; wrongly calling something unreachable hides a real exposure. So honest reachability demotes only what it can prove unreachable and marks everything else unknown - never assumed-safe. Reachability is a prioritization aid, not a suppression mechanism.
What are the levels of reachability analysis?
From shallow to deep: import-presence (is the package imported anywhere), which is a coarse signal; and call-graph reachability (does a path of calls actually reach the vulnerable function), which is precise but harder. Knowing which level a tool performs tells you how much to trust its reachable-versus-unreachable verdicts.