Reachability analysis tries to tell whether your code can actually call the vulnerable part of a dependency. It can cut the list of urgent findings sharply, but the term covers very different techniques. Ask the vendor what is analysed, for which languages, with what accuracy, and how you can check a result by hand.
What reachability can and cannot say
If a vulnerable function is never called by your code or by anything your code calls, the finding is lower priority than one that sits on a live path. That is useful. It does not mean the issue is harmless forever: a code change tomorrow may call it. It is a prioritisation signal, not a clearance.
Questions that separate claims
- Which languages and frameworks are supported? Support often varies by language. Ask for your exact stack.
- Is the analysis static, dynamic or both? Static analysis sees code paths without running them. Dynamic analysis sees what actually runs but depends on test coverage.
- How does it treat reflection, dynamic loading and plugins? Every analyser has blind spots. A good vendor will name them.
- What does it report when it cannot decide? A tool that labels unknown as "not reachable" is dangerous. Look for a third state.
- Is it function level or package level? Package level only says the library is imported, which is much weaker.
- Can I see the call path? A traceable path lets an engineer verify the claim in minutes.
- How is it kept current with new advisories? The vulnerable function must be mapped for each advisory.
How to verify yourself
Take ten findings marked unreachable and ten marked reachable. Ask an engineer to check each by reading the code or writing a small test. Count disagreements. A handful in the unreachable group is a red flag that matters more than any marketing number.
Policy implications
Decide before rollout how reachability will change your actions. A common rule is: reachable and exploited issues block a release, reachable ones get a short deadline, and unreachable ones are tracked and reviewed on a slower cycle. Do not drop the unreachable list entirely.
Trade-offs
Reachability adds scan time and adds a layer you need to trust. For a small codebase with few dependencies, plain severity plus exploit data may be enough.
Try it yourself
Open the reachability demo and compare the list before and after the filter. Look for the call path on one finding and ask whether you could check it by hand.
Click through it at your own pace, or open it full screen.
Where Safeguard fits: reachability analysis is a generally available capability alongside SBOM and dependency scanning; the free scan at https://gold.safeguard.sh/scan is a way to look at output on your own code.
Quick check
Does unreachable mean safe?
No. It means lower priority today. Code changes can make it reachable, so keep tracking it.
Is reachability worth it for small projects?
Often not at first. It earns its place when finding volume outgrows the team's ability to triage.
Last reviewed: 19 October 2026.
