Yes. If most of your backlog is vulnerable dependencies, reachability analysis belongs in an ASPM evaluation, because it shows whether your code can actually call the vulnerable function. It narrows the list, but you should test it on your own code and treat its output as evidence, not proof.
What reachability analysis is
A dependency can contain a flaw in a function your application never calls. Reachability analysis examines how your code uses a library and reports whether a path exists from your code to the vulnerable part. If no path exists, the finding is real but less urgent.
It is a form of context, like exposure or exploitation data, added on top of a severity score.
What it can and cannot tell you
| Question | Reachability helps? |
|---|---|
| Does my code call the vulnerable function? | Yes |
| Is the service reachable from the internet? | No, that is exposure |
| Is exploitation happening in the wild? | No, use sources like the CISA KEV catalog |
| Could my usage change next release? | Not until it is rescanned |
| Does dynamic loading hide a call? | Sometimes missed, so check the limits |
Static analysis has known limits with reflection, dynamic loading and generated code. Ask any vendor which languages are supported and what happens in those cases.
How to test it fairly
- Pick a repository with a long list of dependency findings.
- Choose ten findings marked unreachable. Ask a developer to confirm by reading the code.
- Choose ten marked reachable. Confirm that a real call path exists.
- Note any disagreement and ask the vendor to explain it.
- Check that a finding marked unreachable stays visible, with a reason, rather than vanishing.
The second part of step five is a trust issue. You want to be able to reverse a decision when code changes.
Pairing it with other signals
Reachability is strongest alongside other signals. A reachable flaw in a component that appears in the CISA KEV catalog is a strong candidate for immediate work. FIRST's EPSS adds a probability of exploitation in the next 30 days. An unreachable flaw with a low probability can be scheduled with routine updates.
Recording the decision
When a team sets a finding aside because it is unreachable, record that, with the analysis date and the person who reviewed it. Revisit when the dependency or the code changes. Treat it as a time limited statement about the code as it was.
Questions for your evaluation
Which languages and package managers does reachability cover? Does it run on every scan or only on request? Can I see the call path? Can I override it? Does it handle transitive dependencies?
A worked example: one dependency finding
Suppose a service depends on a large utility library. An advisory affects a function that handles a rarely used file format. The scanner flags the library as high severity.
| Question | Answer in the example |
|---|---|
| Does the code import the library? | Yes |
| Does the code call the affected function directly? | No |
| Does any other library in the tree call it? | Reachability analysis reports no call path |
| Is the service internet facing? | Yes |
| Is the advisory in a known exploited list? | No |
| Decision | Schedule with the next routine upgrade, record the reason and review date |
The finding stays in the system. The analysis changed its priority, and the reason is recorded. If the code later starts handling that file format, a rescan should surface the change.
Step by step: designing the evaluation test
- Select two or three repositories with different languages.
- Pull a list of dependency findings from your current scanner.
- Run the platform's reachability analysis over the same repositories.
- Pick ten findings the platform marks unreachable. Ask developers to verify by reading code.
- Pick ten marked reachable and verify the call paths.
- Count disagreements and ask the vendor about each.
- Check what happens after you change code to add or remove a call.
Step seven shows whether analysis keeps up with change, which matters as much as the first result.
Questions about coverage
Reachability support differs by language and framework. Ask for a written list of supported languages and package managers, and for known limitations such as reflection, dynamic loading, code generation and native extensions. Make sure the list matches the languages you run, not only the ones in the demo.
How to use the output
Treat reachable findings as the first queue. Treat unreachable findings as scheduled work with a review date. Treat findings where analysis cannot decide as reachable until proven otherwise. That conservative default avoids dismissing a real problem because a tool lacked support.
What to tell developers
Explain that unreachable does not mean unimportant forever. It means the risk today is lower than the score suggests, and the work can be batched. Developers tend to welcome that message because it respects their time while keeping the list honest.
Where Safeguard fits
Safeguard provides reachability analysis along with SBOM and dependency scanning. You can see the effect on your own repositories with the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how many findings remain once call paths are checked.
Quick check
Is an unreachable finding safe to ignore forever?
No. Code changes, so revisit it when the dependency or your usage changes.
Does reachability replace severity scoring?
No. It adds context. Use it with severity, exploitation data and exposure.
What if the platform says a finding is not reachable but we are unsure?
Treat it as reachable until a developer confirms. Record the review so the decision is not repeated, and ask the vendor to explain the analysis.
Sources
Last reviewed: 19 October 2026.
