It should inform the decision, not make it alone. Reachability analysis estimates whether your code can actually call the vulnerable function. Using it to rank and gate automated fix proposals reduces noise and unnecessary change, but an unreachable finding still deserves a recorded decision, not silence.
Definitions
Reachability analysis is a way of checking whether the vulnerable part of a dependency is on a path your application can execute. A vulnerable package that your code never calls is present but not necessarily exploitable through your use.
Automated fix proposal is a change, usually a pull request, generated to remove a finding.
Why connect the two
Every fix is a change, and every change carries risk. If a finding is not reachable, the risk reduction from fixing it now is small, while the change risk is the same. Sending only reachable findings through the automated path concentrates effort and review attention where exposure is real.
It also reduces volume. Fewer low value pull requests means reviewers keep the habit of reading them closely.
A simple gating table
| Reachability | Exposure | Suggested handling |
|---|---|---|
| Reachable | Internet facing | Prioritize, propose now, fast review |
| Reachable | Internal | Propose on normal schedule |
| Not reachable | Any | Hold, record decision, revisit on change |
| Unknown | Any | Treat as reachable until analyzed |
The last row matters. Do not read lack of data as safety.
Limits of reachability
- It depends on analysis quality and language support, and static analysis can miss dynamic behavior such as reflection or plugin loading.
- Reachable today is not reachable forever. A refactor can create a path.
- Exploitability depends on more than a call path: input control, configuration and environment all matter.
- Some compliance and customer commitments set remediation windows by severity, not by reachability, so check what you promised.
So treat reachability as a prioritization input and a justification for deferral, not as a reason to delete findings.
How to use it as a gate
- Tag each finding with a reachability state at creation.
- Let the automated path consider reachable and unknown findings first.
- For unreachable findings, require a short note and an expiry, for example revisit in ninety days or on the next major dependency change.
- Re-run analysis after significant code changes and move findings between states.
- Keep unreachable findings visible in reports, labeled, so reviewers see them.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop out of the urgent queue once reachability is applied.
Combine with the other guardrails
Reachability chooses what to fix. Size caps, path allowlists, required checks and human review decide how a fix lands. They do different jobs, so keep all of them. For the review side, see fix PR reviewer checklist.
Safeguard offers reachability analysis and autonomous remediation with fix PRs. The fix PRs are off by default with every category on Manual, so reachability can guide your review queue before any automation changes. You can run a free scan to see findings.
Quick check
If a finding is unreachable, can we ignore it?
Not silently. Record the decision with an owner and an expiry, and recheck when code or dependencies change.
Does reachable mean exploitable?
No. It means a call path exists. Exploitability also depends on input control, configuration and environment.
Last reviewed: 19 October 2026.
