A reachability filter keeps findings where your code can actually call the vulnerable function. It can shrink a list by an order of magnitude. To trust it you need two numbers: how much noise it removes, and how many truly reachable issues it drops by mistake.
A worked example
Illustrative numbers. A dependency scan reports 1,000 findings. Suppose that, in truth, 80 of them are reachable from your code.
A reachability tool flags 90 findings. On review, 76 of them are the truly reachable ones, and 14 are not.
- Noise removed: the list falls from 1,000 to 90, a cut of 91 percent.
- Precision of the filtered list: 76 of 90, about 84 percent.
- Recall: 76 of 80, 95 percent. Four reachable findings were dropped.
The cut looks impressive. The four dropped items are the cost, and whether that is acceptable depends on what they are.
What can make the filter wrong
- Dynamic behaviour. Reflection, plugin loading, and code generated at runtime can create call paths static analysis does not see.
- Entry points. If the tool does not know about all of your entry points, such as a framework route table, it will miss paths from them.
- Configuration. A function may be unreachable today and reachable after a flag changes.
- Transitive depth. Long call chains through several packages are easy to lose.
Because of these, "not reachable" should read as "no known path", not as "safe forever".
How to check a filter on your own code
- Plant known reachable and unreachable cases and see how the tool classifies them. Our guide on validating a reachability tool with seeded tests shows the method.
- Sample the dropped findings, not just the kept ones. Review 30 or so of the unreachable group, and use the sample size guide for how many you need. Remember the rule of three if you find none that should have been kept.
- Track later events. If a dropped finding becomes the subject of a real exploit in your stack, record it.
What to do with the unreachable group
Do not delete it. Park it with a reason, and keep it visible. Two policies work well:
- Re-evaluate on dependency or code changes, since reachability can change when you add a call.
- Still upgrade when the fix is cheap, to reduce long term exposure.
Where it fits in a program
Reachability is one lens in ranking. Combine it with exploit evidence, exposure and the cost of the fix. Safeguard offers reachability analysis as part of dependency scanning, and the free scan at gold.safeguard.sh/scan lets you try it on a repository. Whatever tool you use, measure both what it removes and what it keeps.
Click through it at your own pace, or open it full screen.
Quick check
If a finding is marked unreachable, can I ignore it?
Treat it as lower priority, not as resolved. Record the reason and recheck when code or dependencies change.
What number should I ask a vendor for?
Ask for recall on reachable issues as well as the percent of noise removed. A filter that removes everything has perfect noise reduction and zero value.
Last reviewed: 19 October 2026.
