Reachability analysis checks whether your application can actually call the vulnerable code inside a dependency. If it cannot, the finding is usually lower priority. You need it when your scanner output is too long to act on. If you have a handful of findings, you may not.
How it works in plain terms
A scanner says package X version 2 has a flaw in function f. Reachability analysis builds a call graph of your code and asks whether any path leads from your entry points to f. If yes, the finding is marked reachable. If no path exists, it is marked unreachable.
What it is good for
Cutting noise. Many projects pull in large libraries and use a small part of them. A flaw in a part you never call is real but rarely urgent.
It also helps in conversations with auditors and customers, because you can state why a specific finding was deprioritised.
What it cannot do
- Guarantee safety. Dynamic features such as reflection, plugin loading and generated code can hide paths from static analysis.
- Cover every language equally. Support depth varies by ecosystem. Ask which languages and what depth.
- Replace fixing. Unreachable today can become reachable after a refactor. Treat it as a ranking signal, not a dismissal.
Questions to ask
- Which languages are supported at function level, and which only at package level?
- What happens when the tool cannot decide? Good tools say unknown rather than guess.
- Can I see the path it found?
- Can I override it with a reason?
Do you need it?
You probably do if you have hundreds of findings, several teams, or developers who have started ignoring the scanner. You probably do not if you maintain one small project and fix everything promptly anyway.
Using the results well
Treat reachable findings as the first queue and unreachable ones as a second queue with a longer deadline. Revisit the second queue when a major refactor lands, since new code paths can make old findings reachable. Reviewers should also spot check a handful of unreachable verdicts each quarter by reading the code. Doing so builds or breaks your confidence in the analysis, using evidence from your own system.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the list changes when unreachable findings are separated out.
Where Safeguard fits
Safeguard includes reachability analysis alongside dependency scanning. A free scan is a way to see your inventory first.
Quick check
Is unreachable the same as safe?
No. It means lower priority for now. Keep tracking it and fix it on a normal schedule.
Last reviewed: 19 October 2026.
