Test a reachability claim by picking findings you can verify by hand: some where the vulnerable function is clearly called, some where it clearly is not, and some in between. A sound tool agrees with your manual answers, shows the call path, and says when it cannot decide.
What the claim actually means
Reachability analysis asks whether your code can call the vulnerable function in a dependency. If not, the finding is less urgent, though not necessarily irrelevant. Marketing often shortens that to noise reduction. Ask for the definition in writing.
Build a ground truth set
Pick ten findings. For each, read the advisory, find the affected function, and search your code for a path to it. Label each reachable, not reachable or unclear. This takes an afternoon and is the only way to measure anything.
Check the evidence, not the label
For every reachable verdict, ask to see the call path from your entry point to the vulnerable function. Our guide on reading a call path shows what to look for. An unreachable verdict should say what was analysed and what was not.
Probe the edges
Reflection, dynamic dispatch, plugins and generated code defeat static analysis. Include one such case. A tool that admits uncertainty is safer than one that marks everything confident.
Check language support
Reachability depth varies widely by language. Confirm each language you use is supported for the analysis, not just for dependency listing.
Decide what you do with unreachable
Set the policy before the trial: deprioritize, schedule, or ignore. Never hide unreachable findings entirely, because code changes can make them reachable later, and a good tool should re-evaluate on each scan.
Finally, repeat the test after a code change. Reachability depends on the current code, so refactor a call path in a test branch and check that the verdict updates on the next scan. A tool that caches an old answer will mislead you quietly.
Where Safeguard fits
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and fix pull requests that stay off until you turn them on. You can try a free scan on a repository before you commit to anything.
Try it yourself
Click through to see the same list before and after reachability, and note which findings drop and why.
Click through it at your own pace, or open it full screen.
Quick check
Should unreachable findings be closed?
Deprioritize them, but keep them visible and re-checked.
What is a fair accuracy target?
Set it from your ground truth set and require explained misses.
Last reviewed: 19 October 2026.
