Reachability analysis tells you whether a call path to a vulnerable function was found. It does not tell you the path is impossible, that the issue is unexploitable, that the code will stay unreachable, or that the advisory data was complete. Treat the label as strong evidence for prioritizing, not as proof of safety.
1. It cannot see calls decided at runtime
Reflection, dynamic loading and similar features create calls that static analysis may never see. The Go vulnerability checker states this about its own results: calls through the reflect package are not visible and the unsafe package may cause false negatives. See reflection and reachability.
2. It depends on the advisory data
If an advisory lists no function, the tool cannot name a target. Some tools then fall back to package level. A not reachable result is only as good as the symbol data behind it. See how scanners link a CVE to a function.
3. It does not measure exposure
A reachable function inside an internal batch job is less urgent than one on an internet facing endpoint. Reachability says nothing about who can send input. CVSS guidance makes a similar point about its own scores: severity should not be used alone to assess risk, and exposure and threat fall outside the score.
4. It describes today's code
You scan a commit. The next pull request can add an import that makes a dormant function live. A result has a date. Re-check after changes, which is why re-running reachability on a cadence matters.
5. It does not know about exploitation in the wild
A flaw can be reachable and never attacked, or unreachable in your code while being mass exploited elsewhere. That is a different signal. See reachability vs EPSS vs KEV.
6. It does not cover what is not in the graph
Code that is not analyzed, such as an unscanned service, a vendored copy or a binary blob, is outside the result. The result covers the inputs you gave the tool and nothing else.
How to use the label well
- Prefer reachable findings first, but keep the others on a list with a reason.
- Read the call path of any finding you plan to dismiss if the severity is high.
- Record the date and the commit you analyzed.
- Combine with exposure and exploitation data.
Quick check
If a tool says not reachable, can I close the ticket?
You can lower its priority. For high severity items, read the analyzed paths first and note a re-check date instead of closing for good.
Does a limit mean the method is bad?
No. Every triage signal has limits. Knowing them tells you how much weight to give each one.
Safeguard's reachability analysis is part of its dependency scanning, and the free scan lets you inspect results on your own project.
Sources
Last reviewed: 19 October 2026.
