Reachability analysis checks whether your code actually calls the vulnerable part of a dependency. It does not delete findings, but it sorts them: reachable ones need near-term capacity, unreachable ones can be scheduled or monitored. A capacity plan built on it targets the code that runs, not every advisory.
What reachability analysis is
A vulnerability is usually in a specific function of a library. If your application never calls that function, directly or through other code, an attacker cannot use that path through your application. Reachability analysis traces calls to answer the question for each finding.
It is an input, not a verdict. Analysis can miss dynamic calls, and an unreachable flaw may become reachable after a code change. Plan for both.
The three buckets
Use reachability to sort the backlog into three buckets before you size the work.
| Bucket | Meaning | Planning treatment |
|---|---|---|
| Reachable | Called by your code | Fix on a service level, in the sprint plan |
| Not reachable now | Present but not called | Schedule with routine updates, recheck on change |
| Unknown | Analysis could not decide | Treat as reachable until reviewed |
Only the first bucket competes with features for sprint capacity. The other two go through routine updates and monitoring. Do not skip the unknown bucket, because it is where assumptions hide.
Change the capacity arithmetic
Suppose a backlog has many findings. Do not estimate hours for all of them. Estimate hours for the reachable bucket, add a small allowance for the unknown bucket, and put the rest on the update cadence in weekly update day or continuous updates. The forecast method in forecast when your backlog will clear should then count the reachable bucket separately from the whole.
This does not make the work vanish. It makes the plan honest about where the risk is, and it helps explain to leaders why the backlog count and the risk are different numbers.
Guard against the traps
- Stale results. Reachability changes with code. Re-run analysis on each release and when new code calls the library.
- Exploited anyway. A vulnerability on the CISA Known Exploited Vulnerabilities catalog deserves a second look even if marked unreachable, since an analysis gap costs more there.
- Quiet exceptions. If you use reachability to accept risk, record it with an owner and expiry. See can reachability analysis justify a risk acceptance.
- Overconfidence. Reachability reduces noise, but it is not a guarantee of safety.
Try it yourself
Open the demo and compare the list of findings before and after reachability is applied. Note which items move out of the urgent group, since those are the ones that leave your sprint plan.
Click through it at your own pace, or open it full screen.
Safeguard provides reachability analysis alongside SBOM and dependency scanning, with policies and gates to keep new reachable issues out. Its fix pull requests are off by default and every category starts on Manual. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Can I ignore findings marked not reachable?
Not forever. Schedule them with routine updates and recheck when code changes, since a new call can make them reachable.
Does reachability replace severity scores?
No. Use it with severity, exploitation signals and exposure. Each answers a different question about the same finding.
Sources
Last reviewed: 19 October 2026.
