Usually yes for serious, reachable, fixable vulnerabilities, and no for the unreachable ones, with caveats. Reachability tells you whether your code can call the vulnerable function. Use it to prioritise and to decide between block and allow-with-plan, but keep fixed rules for malicious packages and for severe issues with an available fix.
What reachability means
Reachability analysis checks whether the vulnerable code in a dependency can be reached from your application's entry points. A vulnerability in a function you never call is much less urgent than one in a path that handles untrusted input. It is a way to cut noise, not a verdict that unreachable means safe forever.
Limits of reachability at intake
At intake, the candidate package is not used yet. So the analysis is about how you plan to use it, which is partly unknown.
- Your future code may call the vulnerable function later.
- Transitive paths can change when your own code changes.
- Static analysis can miss dynamic calls, so an unreachable result is a strong hint, not a guarantee.
A decision table
| Finding | Reachable | Fix available | Suggested decision |
|---|---|---|---|
| Malicious package | Not relevant | Not relevant | Block, no exception |
| Critical or known exploited vulnerability | Yes | Yes | Block, pick the fixed version |
| Critical vulnerability | Yes | No | Block, or allow only with a mitigation and expiry |
| High vulnerability | No | Yes | Allow, update soon, record the reason |
| High vulnerability | No | No | Allow with an owner and review date |
| Low severity | Any | Any | Allow, track |
Adjust the thresholds to your own risk appetite, and write them as policy.
Record what you decided
For each allow-with-plan decision, store the vulnerability identifier, the reachability result at the time, the reason, the owner and a review date. When the code changes, rerun the analysis. A reachable result tomorrow turns yesterday's allowance into a task.
Common mistakes
- Using unreachable as a permanent pass. Revisit on every significant change.
- Skipping the fixed version check. If the next patch release removes the issue, choosing it costs little.
- Applying reachability to malicious packages. A package built to steal credentials at install time does not need its functions called.
- Ignoring the exploitation context. A vulnerability known to be exploited in the wild deserves a harder line than its reachability suggests.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare how a finding looks before and after the exploitability question is asked, then think about what you would record as the decision.
Where Safeguard fits
Safeguard offers reachability analysis alongside SBOM and dependency scanning, and policies and gates that can turn your decision table into pull request checks. Try the free scan.
Quick check
Does unreachable mean the vulnerability can be ignored?
Not forever. It lowers urgency now, but you should recheck when the code or the dependency changes.
Should reachability override a malicious package flag?
No. Malicious packages are blocked regardless of whether their code is called.
Last reviewed: 19 October 2026.
