Reachability affects priority and review effort, not whether a fix is ever worth doing. If your code never calls the vulnerable function, an AI proposed bump can wait for the normal update cycle, as long as you record the reason and recheck when usage changes.
What reachability tells you
A vulnerability in a dependency is only exploitable through the code paths that use the affected function. Reachability analysis asks whether your application can actually call that code. If the answer is no, the finding is still real in the sense that the package is vulnerable, but the risk to you is lower than the alert implies.
This is not the same as saying the finding is false. Usage changes, other services may share the library, and attackers sometimes find indirect routes. Treat unreachable as a lower priority with evidence, not as a dismissal.
A decision table
| Situation | Suggested action |
|---|---|
| Reachable, internet facing path | Review the fix with full care and merge promptly |
| Reachable, internal path | Normal priority and normal review |
| Not reachable, patch bump of a direct dependency | Merge through the routine cycle, light review |
| Not reachable, major version change or code rewrite | Defer. The review cost and regression risk outweigh the benefit |
| Reachability unknown | Treat as reachable until shown otherwise |
These are starting rules for a team to adjust, not a standard.
Why this matters for AI fixes
An AI suggestion has the same review cost whether or not the flaw is reachable. For an unreachable finding, an ambitious AI rewrite is rarely a good trade. The risk of a regression from a large change may exceed the risk of the flaw you never call. A small patch bump is different, since it is cheap to review and keeps you off the list of known vulnerable components.
OWASP's guidance on secure coding with AI also advises running dependency auditing on every AI generated dependency list regardless of origin. An unreachable finding still shows up in those audits, so decide in advance how you will record and handle it.
What to record
- The finding and the affected version range.
- How you determined it is not reachable (tool output, search for the call sites).
- The date, the owner, and a trigger to recheck, for example when the code that imports the package changes.
- A target date for the routine upgrade.
This record turns a silent dismissal into a defensible decision. See vulnerability exceptions and upgrades for how exceptions behave over time.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the list shrinks once reachable findings are separated from the rest, and how that changes which fixes you would review first.
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and its fix pull requests are off by default with every category on Manual.
Quick check
If a vulnerability is unreachable, can I ignore it forever?
No. Record the reason and set a recheck trigger. Code changes can make it reachable later.
Does unreachable mean the scanner was wrong?
No. The package is still vulnerable. Reachability describes your exposure, not the scanner's accuracy.
Sources
Last reviewed: 19 October 2026.
