Ask the demo to show the call path: the chain of functions from your code to the vulnerable function. If it says "not reachable", ask what it checked. A label without evidence is a guess, and a wrong "not reachable" can hide a real exposure.
What reachability analysis is
A vulnerability usually lives in one function inside a library. If your code never calls that function, directly or through other code, the flaw is much less likely to be exploitable in your application. Reachability analysis tries to work this out by tracing calls.
It is a prioritization aid. It does not make a vulnerable package safe, and it is not perfect. Reflection, dynamic loading and framework magic can hide real calls from any static analysis.
A four step verification
- Pick a "reachable" finding. Ask to see the path. Open the first function in your own code and confirm it exists and is used.
- Pick a "not reachable" finding. Ask what the tool concluded and on what basis. Search your code for the vulnerable function name yourself.
- Pick one with unknown status. A tool that never says "unknown" may be overconfident.
- Change something. If time allows, add a call to the vulnerable function in a throwaway branch and rescan. The label should change.
Step four is the strongest test. It turns a claim into an experiment.
What good evidence looks like
- A path with named functions and file locations you can open.
- A statement of what the analysis covers, such as which languages and which kinds of calls.
- A clear label for "could not determine".
- A way to override the label with a reason when you disagree.
What weak evidence looks like
| Claim | Why it is weak |
|---|---|
| "Not reachable" with no detail | You cannot check it |
| 100 percent of findings labeled | Real analysis has gaps |
| No mention of language support | Coverage varies by language |
| No way to override | You are stuck with the tool's view |
Using the result responsibly
Treat "not reachable" as a reason to lower urgency, not as a reason to ignore. Keep the finding tracked, because code changes. A function that is unused today may be called after next month's feature.
Treat "reachable" as a reason to raise urgency, and pair it with exploit data, such as whether the vulnerability appears in CISA's Known Exploited Vulnerabilities Catalog, which CISA recommends as an input to prioritization (see Sources).
Where Safeguard fits
Safeguard includes reachability analysis as a GA capability, designed to cut the noise from findings that your code never calls. The demo below shows the effect on a list of findings.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the list before and after reachability is applied, and ask yourself what evidence you would want for each removed item.
Quick check
Can reachability analysis be wrong?
Yes. Dynamic behavior and reflection can hide calls. Use it to prioritize, and keep not reachable findings visible.
Does reachable mean exploitable?
No. It means your code can reach the vulnerable function. Exploitability also depends on inputs, configuration and exposure.
Sources
Last reviewed: 19 October 2026.
