Reachability analysis can support a decision to accept or defer a vulnerability, because it shows whether your code calls the vulnerable function. It is evidence, not proof. Record the method and version, note its limits, and re-run it when the code changes.
What reachability tells you
A dependency can have a known flaw in a function your application never calls. Reachability analysis traces call paths from your code into the dependency and reports whether the vulnerable code can execute. If it cannot, the practical risk is much lower than the score suggests.
That fits the way scoring bodies describe their own numbers. The CVSS v4.0 FAQ says Base scores "are not risk" and that applying environmental data is the consumer's responsibility. Reachability is one such piece of local context.
Two outcomes, two records
| Result | Best record |
|---|---|
| Vulnerable code cannot run, and you can show why | VEX not_affected, with the justification vulnerable_code_not_in_execute_path |
| Reachability is unclear or partial | Risk acceptance, with a short term and a re-check |
The OpenVEX specification includes vulnerable_code_not_in_execute_path as a not_affected justification. If your evidence is strong, prefer that. See risk acceptance vs VEX not_affected.
Limits to write down
- Dynamic behavior. Reflection, plugins and dynamic loading can hide call paths from static analysis.
- Configuration. A flag may enable the vulnerable path in another deployment.
- Time. The result is true for this commit. New code can change it.
- Transitive depth. Some tools trace deeper than others.
- Not every flaw is a function call. Some risks sit in how data is parsed or in install-time behavior.
State the limits in the record. An approver who knows them can set a fair expiry.
What to attach as evidence
- Tool name and version, and the commit analyzed.
- The vulnerable function or entry point.
- The result, as saved output.
- The date and who reviewed it.
- The trigger to re-run: any release, or any change to the calling module.
A sensible policy
Let reachability lower priority and extend deadlines, but do not let it erase the finding. Keep the record visible, re-run it on every release, and revoke the exception if the call path appears. That keeps the benefit, which is less noise, without the main danger, which is false comfort.
Where Safeguard fits
Safeguard offers reachability analysis for dependency findings, and its policies can use reachability results when deciding whether a gate should block.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop in priority once call paths are checked.
Quick check
If the function is unreachable, can I just ignore the finding?
Record it, as a VEX not_affected statement with evidence where possible, and re-check on each release. Ignoring it without a record leaves nothing to show a customer or auditor.
Does reachability replace compensating controls?
No. It addresses whether the flaw can run. Compensating controls reduce risk when it can.
Sources
Last reviewed: 19 October 2026.
