A reachable or vulnerable function column tells you whether your code can call the specific function that contains a vulnerability, not merely whether the vulnerable package is installed. Reachable means a call path exists. Not reachable lowers urgency but does not prove safety, because analysis has known blind spots.
Package present versus function called
A plain SCA match says: package X at version Y is in your project, and version Y has a known flaw. Reachability adds a second question: does anything in your code, directly or through other libraries, call the flawed function?
Most vulnerable packages expose many functions, and a flaw usually lives in one or a few. If your code uses other parts of the library, the finding may be present but inert. That difference is why reachability tends to shrink a long list into a short one.
A real tool shows the pattern
The Go team's govulncheck documentation describes it as using static analysis of source code or a binary's symbol table to narrow reports to vulnerabilities that could affect the application. Its tutorial output shows two findings for the same project. One is a vulnerability your code affects because it directly calls a vulnerable function. The other is labeled informational because the code never, directly or indirectly, calls the vulnerable function, and the output says you may not need to take action.
That split is the model for any reachability column: affected when a call path exists, informational when only the package is present.
How to read each value
| Value | Meaning | Suggested action |
|---|---|---|
| Reachable | A call path from your code was found | Treat as exposed, fix first |
| Not reachable | No call path found | Lower priority, upgrade in routine work |
| Unknown | Analysis could not decide | Treat as present until checked |
Limits you should know
The govulncheck documentation lists its own limitations, which are typical of static analysis in general:
- Function pointer and interface calls are analyzed conservatively, which may produce false positives or inaccurate call stacks.
- Calls made through reflection are not visible, so code reachable only that way may not be reported.
- Use of the unsafe package can cause false negatives.
- For binaries, call graphs are not available and results may include code that is in the binary but unreachable.
So treat "not reachable" as evidence, not a guarantee. If the flaw is known exploited, or the package sits at a trust boundary such as input parsing, upgrade anyway.
What to do with the column
- Use reachable findings to build the first queue.
- For not reachable findings, record the reason and schedule the upgrade with normal maintenance.
- Revisit when code changes, because a new call path can turn an inert finding into an exposed one.
- Never suppress based on this column alone for known exploited flaws.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the list before and after reachability is applied.
Where Safeguard fits
Safeguard includes reachability analysis in its dependency scanning, so each finding carries evidence about whether the vulnerable code is used.
Quick check
If a finding is not reachable, can I close it?
You can lower its priority and document why. Keep it tracked, since code changes can create a call path later.
Why might reachability be wrong?
Static analysis cannot see everything. Reflection, dynamic dispatch and unsafe code are common blind spots.
Sources
Last reviewed: 19 October 2026.
