To verify a reachability claim, ask what the tool analyses, which languages it covers, and how it labels uncertain cases. Then test it: take a vulnerable dependency you know you call and one you know you never call, and confirm the tool reports each correctly and explains why.
What reachability means
Reachability analysis asks whether your code can actually reach the vulnerable function inside a dependency. A package may contain a flaw in a feature you never use. If no path from your code leads to it, the finding is lower urgency than one on a function you call on every request. Done well, it removes much of the noise from a long list. Done poorly, it hides real exposure. For a longer primer, see do you need reachability analysis in SCA.
Questions that separate depth from marketing
| Question | Why it matters |
|---|---|
| Which languages does it cover? | Coverage is often narrower than SCA coverage |
| Is it function level or package level? | Package level is just presence |
| Does it include indirect calls and dynamic dispatch? | Common blind spots |
| What does it say when it cannot tell? | Should be "unknown", not "not reachable" |
| Does it show the call path? | Evidence you can inspect |
| How does it handle reflection or plugin loading? | Hard cases |
| Is the verdict stored with a date and version? | Code changes, so verdicts expire |
The fourth row is the one to press. A tool that turns every uncertain case into "not reachable" will produce a tidy dashboard and a false sense of safety.
A four step test
- Choose a vulnerable dependency where you know the affected function and call it directly in a test file.
- Choose another where you know the affected function is never called.
- Run the tool. The first should be marked reachable with a path. The second should be marked not reachable, ideally with an explanation.
- Add a case that calls the function through a wrapper or a callback, and see whether the path is still found.
Record the results. Then ask the vendor to explain any surprise. A clear explanation is a good sign.
Use reachability to rank, not to dismiss
Even a correct "not reachable" verdict can change when someone writes a new call. Treat it as a ranking signal rather than permission to ignore. Keep the findings visible, mark them as lower priority, and revisit on each scan. Pair it with exploit information, since a reachable flaw that is actively exploited outranks everything else.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the before and after view, then check whether the reduction in findings comes with an explanation per item.
Quick check
Can free tools provide reachability?
Some offer limited versions. Read can you get reachability analysis from free tools before assuming.
Does "not reachable" mean safe?
No. It means no path was found by that analysis at that time. Treat it as lower priority, not closed.
Safeguard offers reachability analysis as a GA capability, and you can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
