To test reachability analysis, pick vulnerable dependencies in your own code where you already know the answer, some called and some never called, then see whether the tool agrees. Also ask what languages it supports, how it treats dynamic calls, and how it explains each verdict.
What reachability claims to do
Many findings sit in dependencies whose vulnerable function your code never calls. Reachability analysis tries to tell which findings are called from your code and which are not, so teams can fix the first group first. The idea is sound. The accuracy varies by language, by how the analysis works and by how dynamic your code is.
Build a ground truth set
Pick ten findings. Have a developer who knows the code mark each as reachable, not reachable or unclear, with a short reason. Include at least two that look unreachable but are called through reflection or a framework hook, since these are where analysis can be wrong. Do this before the vendor demo so nobody is anchored.
Score the tool
Compare verdicts to your set. The costly error is calling something unreachable that is reachable, because a real risk gets deprioritized. A less costly error is the reverse, which only adds work. Ask how the tool shows its evidence: a call path you can read is much more useful than a bare label. Ask what it does for languages or frameworks it cannot analyze, and whether it says so clearly.
Use it as a prioritization aid
Treat reachability as a way to order work, not to dismiss risk. A not reachable verdict can change when code changes, so ask whether the tool re-evaluates automatically. Keep the original finding visible with its reasoning so a reviewer can disagree. Teams that do this get the benefit of fewer interrupts without trusting a single label blindly.
Ask the vendor for a limitations page and read it closely. Mature products state what they do not cover, such as certain languages, generated code or runtime plugin loading. Vague limitations are a reason to test harder. Also ask whether the analysis runs on your infrastructure or the vendor's, because source code handling may matter to your security team. Reachability is a useful signal, and an honest vendor will say where it stops.
Try it yourself
Click through the demo and watch how the results change as you move through each step.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and a free scan lets you try it on a repository.
Quick check
What is the worst error to watch for?
Marking a reachable vulnerability as unreachable. Make sure your test set includes cases likely to trigger it.
Last reviewed: 19 October 2026.
