A scanner flags a package you do not use for one of three reasons. It is a transitive dependency of something you do use, the match was made by name and picked the wrong product, or the package is present but your code never calls the vulnerable function. Each has a different fix.
Definitions
Transitive dependency. A package pulled in by another package.
Name based match. Identifying a component by a product style name, such as a CPE, rather than exact ecosystem coordinates.
Reachability. Whether your code can call the vulnerable function.
Cause 1: it is transitive
Run your tree command and look for the package. If it shows up under a direct dependency, you use it, indirectly. Upgrade the closest parent. See the companion post on tracing which package pulls it in.
Cause 2: the match is wrong
OWASP Dependency-Check works by collecting evidence about a dependency to infer a CPE, then listing CVEs for it. When evidence is thin, the guess can point to the wrong product or version. Check the advisory text against the artifact: same vendor, same module, same version range?
If it is wrong, suppress the finding with a written reason, scoped to that component, so it does not return every scan.
Cause 3: present but not called
The Go tutorial shows this split well. govulncheck reports an affected section where call stacks show your code reaching the flawed function, and an informational section where the module is imported but no call stack reaches the vulnerability, noting you may not need to take action.
Other ecosystems rely on separate reachability analysis to make the same call.
Decision table
| Evidence | Likely cause | Action |
|---|---|---|
| Package appears in the tree under a parent | Transitive | Upgrade the parent |
| Advisory names a different product | Wrong match | Suppress with reason |
| No code path to the flawed function | Not reachable | Lower priority, schedule the upgrade |
| Code path exists | Real exposure | Fix now |
Steps
- Find the package in the dependency tree.
- Read the advisory for the affected component and version range.
- Check whether your code calls the affected function or feature.
- Decide: fix, suppress with reason, or defer with a review date.
- Record the decision so the next person does not repeat the work.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the findings before and after reachability filtering.
Quick check
Can I just ignore findings in code I never call?
You can lower their priority, but still plan the upgrade. Code paths change, and the next developer may call that function.
Is suppressing a finding risky?
Just if you do it without a reason or a review date. Document both.
Safeguard includes reachability analysis, so findings that your code reaches can be ranked above those it does not. A free scan will show the split.
Sources
- OWASP Dependency-Check project page
- Go tutorial, Find and fix vulnerable dependencies with govulncheck
Last reviewed: 19 October 2026.
