You probably need reachability analysis if your dependency alert lists are too long to work through and most findings turn out not to apply. You probably do not if you have few dependencies, update often and clear alerts quickly. Reachability reduces noise, but it adds a dependence on language support and a new kind of error.
What it buys you
Plain SCA matches package versions to advisories. It reports every match, whether or not your code uses the affected function. Reachability adds a question: can your code get to the vulnerable part? Findings that cannot be reached are ranked lower.
The benefit is time. In applications with large dependency trees, many advisories concern functions the application never calls. Skipping them in triage lets people spend effort on findings that can matter.
What it costs
- Language coverage. It works well for some languages and less for others. Where it is unsupported, you fall back to plain matching and must know that.
- Analysis time. Deeper analysis takes longer than reading a lockfile.
- A new error type. Static analysis may call something unreachable when it is reached through reflection, configuration or plugins. A wrong answer here hides a real finding.
- False comfort. Teams may start treating unreachable as safe forever, though code changes.
- Price. It may be an add-on.
When it is worth it
Reachability tends to pay off when:
- You have many services and thousands of open findings
- Your triage queue grows faster than it shrinks
- Developers have started ignoring alerts
- You are in languages the tool analyzes well
- You need to justify deprioritizing a finding to an auditor or customer with evidence
When plain matching is enough
- A handful of repositories and a short alert list
- Strict policy that every advisory above a threshold must be fixed, regardless of use
- Languages where the feature is not supported
- Teams that can upgrade dependencies routinely, which solves the problem differently
Frequent updating is a legitimate alternative strategy. If you can keep dependencies current, many findings disappear without analysis.
How to use it safely
Treat unreachable as lower priority, not closed. Keep the finding visible with the evidence. Re-run analysis when code or the dependency changes. Record the reasoning so it survives personnel changes. And always ask what the tool reports when it cannot decide.
Try it yourself
Open the demo and compare the full list with the reachable view. Notice how the count changes and what evidence supports each label.
Click through it at your own pace, or open it full screen.
Where Safeguard fits: Safeguard includes reachability analysis with its SBOM and dependency scanning. You can see how it affects your own list with the free scan at gold.safeguard.sh/scan.
Quick check
Does reachability remove the need to update dependencies?
No. It helps you order the work. Keeping dependencies current still lowers risk and reduces future noise.
Last reviewed: 19 October 2026.
