Verify reachability by running it on code where you already know the answer. Pick a few findings you have triaged by hand, include some that are truly exploitable, and see whether the tool keeps those and cuts the rest, with an explanation you can read.
Why a report cannot do this
A report can say a vendor offers reachability analysis. It cannot say how that analysis behaves on your frameworks, your dynamic calls or your build output. Reachability results depend on language, call graph depth and how generated code is treated, so two products with the same label can differ a lot.
Build a known answer set
- Pick five repositories across different languages and frameworks.
- For each, choose three to five vulnerable dependencies. Include at least one you know your code calls, one you know it does not, and one that is unclear.
- Write down the expected result for each before running any tool.
- Add one deliberate trap, such as a function called only through reflection or a plugin system.
Your own triage history is a good source. Past incidents tell you what was truly exploitable.
What to look for in results
- Kept the real ones. Missing a reachable finding is the worst failure, so count those first.
- Cut the unreachable ones. Fewer findings is good only if the cuts are right.
- Explained the call path. A result with a readable path lets a developer confirm it in minutes. A bare label forces trust.
- Said "unknown" honestly. A tool that labels uncertain cases as uncertain is easier to rely on than one that is always confident.
- Handled the trap. Note how it treated dynamic calls.
Score it
Create a small table: finding, expected, tool result, correct or not. Compute three counts: reachable findings kept, unreachable findings cut and unclear findings flagged. Share the table with the vendor and ask them to explain each miss.
Do not accept a percentage reduction as the headline. A product that cuts eighty percent of findings by also dropping real ones is worse than one that cuts fifty percent accurately.
Pair it with exploit signals
Reachability tells you whether your code can reach vulnerable code. Exploit signals tell you whether attackers are using it. CISA says organizations should use its Known Exploited Vulnerabilities catalog as an input to prioritization, and FIRST says EPSS estimates the probability of exploitation in the next 30 days. A reachable finding that is also on the exploited list is where to start.
Try it yourself
Open the demo and compare the list before and after reachability is applied. Think about which of your own findings would land in each group.
Click through it at your own pace, or open it full screen.
Safeguard provides reachability analysis and SBOM and dependency scanning, and the free scan at gold.safeguard.sh/scan can be pointed at one of your test repositories.
Quick check
How many findings do I need for a fair test?
Fifteen to twenty hand-triaged findings across several repositories gives a useful signal. More is better if you have them.
Is a lower finding count always better?
No. Count whether the cuts were correct. Wrong cuts hide real risk.
Sources
Last reviewed: 19 October 2026.
