Reachability analysis checks whether your application can actually call the vulnerable code inside a dependency. A library may contain a flaw, but if your code never reaches it, the practical risk is lower. For a product manager, it turns a long finding list into a shorter, ordered work list.
An analogy that holds up
Think of a large building with a faulty door in a wing that has no corridor leading to it. The fault is real, and you should still note it. But it matters less than a faulty front door. Reachability analysis draws the corridors: it follows calls from your code into the library and asks whether any path ends at the faulty part.
Why it matters for planning
Without it, a scanner reports every known issue in every dependency. Teams see hundreds of findings, most of which they cannot act on at once. Planning suffers in three ways:
- Sprints fill with upgrades that change nothing in practice.
- Genuinely urgent items are buried.
- Developers learn to ignore the tool.
With it, the team can say: these items are reachable and go first, these are not reachable and go on a scheduled list.
What it is not
Be honest about limits when you explain it.
| Claim | Reality |
|---|---|
| Not reachable means safe forever | It means not reachable today. Code changes can create a path later |
| It finds every path | Dynamic calls and reflection can hide paths, so treat the answer as strong evidence, not proof |
| It replaces patching | It orders the work. Unreachable issues still get fixed on a schedule |
Reachability is also not the same as exploitability. A reachable flaw may still need specific input or conditions to be attacked.
How a product manager can use it
- Ask for the reachable subset when a scan report arrives, not the full list.
- Put reachable high-impact items in the current sprint as bugs, with the same standing as customer-reported ones.
- Put the rest on a dated backlog with an owner, so they do not vanish.
- Ask for a recheck when a major feature changes how a library is used.
A short script for the planning meeting
"The scanner found 140 issues. Reachability says 9 are called by our code. We fix those 9 now, schedule the rest by risk, and re-run the analysis after the checkout rewrite."
That script is short, factual and ties security work to the roadmap.
Try it yourself
Click through it at your own pace, or open it full screen. Click through to see a long finding list reduced to the findings your code can actually reach, and notice what remains on the scheduled list.
Where Safeguard fits
Safeguard includes reachability analysis alongside dependency scanning, and the free scan at gold.safeguard.sh/scan is a way to see the dependency side on your own project.
Quick check
Does reachability mean we can ignore unreachable findings?
No. It changes their priority and timing, not their existence. Keep them on a dated list.
Who should own the reachable items?
The team that owns the service, with the same sprint standing as customer-reported bugs.
Last reviewed: 19 October 2026.
