An unknown reachability result means the tool could not show a call path to the vulnerable code and could not rule one out. It is an honest answer, not a failure. Treat unknown as "not yet decided", send it to a short manual check, and never fold it silently into "not reachable".
Why a tool cannot always answer yes or no
Reachability analysis builds a call graph, a map of which functions can call which. Static call graphs are built without running the program, and computing an exact one is an undecidable problem, so practical tools produce approximations. The Wikipedia entry on call graphs states this directly: static algorithms are generally over-approximations, meaning they include every real call and sometimes extra ones.
That is the theory. In practice, a few code patterns push a tool toward unknown:
- Reflection, where code looks up methods by name at runtime.
- Dynamic loading of plugins or modules chosen by configuration.
- Generated code or macros that are not present at analysis time.
- Native extensions where the call crosses into compiled code the analysis cannot read.
The three outcomes you should expect
| Result | What it means | What to do |
|---|---|---|
| Reachable | A path from your code to the vulnerable function was found | Prioritise by fix effort and exposure |
| Not reachable | No path found under the tool's assumptions | Record the evidence, recheck on dependency change |
| Unknown | The tool hit a pattern it cannot resolve | Manual check or conservative treatment |
A tool that only ever reports the first two is hiding its uncertainty. Ask any vendor or open source tool how it reports the third.
How to resolve an unknown in 15 minutes
- Find the vulnerable function named in the advisory.
- Search your code and your direct dependencies for its name, including string forms such as a class name in a configuration file.
- Check whether the package is loaded dynamically or only imported.
- If you find a plausible path, treat it as reachable. If you find nothing and the loading is static, note that in the ticket.
- If you still cannot tell, fix it on your normal schedule rather than suppressing it.
The key habit is that unknown must never become a silent suppression. If your triage tooling lets someone mark unknown as ignored, add a required reason and an owner.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how findings are split by evidence, and notice which ones are not given a firm verdict.
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan to see the output on your own repository.
Quick check
Is unknown the same as not reachable?
No. Not reachable means the analysis looked and found no path. Unknown means it could not decide, so the risk is still open.
Should unknown findings block a release?
Usually not by default. Route them to a quick manual check, and block only if your policy treats the underlying vulnerability as severe and the package is exposed.
Sources
Last reviewed: 19 October 2026.
