Reachability analysis checks whether your application can actually execute the vulnerable code inside a dependency. A scanner reports that a library has a flaw. Reachability asks the next question: does any path from your code lead to the flawed function? If not, the finding is lower priority.
Why it exists
Modern applications pull in many libraries, and most of each library goes unused. A vulnerability usually lives in one function or one feature. If you never call it, the risk to you is much smaller than the alert suggests.
Without this check, every finding looks equally urgent, teams burn time on alerts that cannot be triggered, and the real problems wait in the same queue.
How it works in outline
The tool builds a call graph, a map of which functions call which. It starts from your entry points, such as request handlers or the main function. It follows calls into dependencies. Then it checks whether the vulnerable function appears on any path.
Three results are common:
- reachable: a path exists
- not reachable: no path was found
- unknown: the analysis could not decide, often because of dynamic behavior
Where it falls short
Static call graphs struggle with reflection, dynamic loading, and code that builds function names at runtime. A "not reachable" result is strong evidence, not proof. Good tools label uncertainty instead of hiding it.
Reachability also depends on how you configure and deploy the software. A feature that is off in your setup can be on in someone else's, so keep the result tied to your context.
How to use the result
Do not delete unreachable findings. Sort them lower and record why. If your usage changes, for example you start calling that function, the finding should move back up automatically. Pair it with exploitation signals so a confirmed exploited flaw still gets attention even when the evidence is incomplete.
The same reasoning is what supports a VEX statement saying a product is not affected.
Click through it at your own pace, or open it full screen.
Safeguard includes reachability analysis alongside dependency scanning. A free scan is at gold.safeguard.sh/scan.
Quick check
If a finding is not reachable, can I ignore it?
Deprioritize, yes. Ignore, no. Code changes and analysis gaps can make it reachable later.
Is reachability the same as exploitability?
No. Reachable means your code can get to the flaw. Exploitable also depends on whether an attacker can control the input and bypass defenses.
Last reviewed: 19 October 2026.
