Reachability analysis is a way to produce evidence. VEX is a way to communicate a conclusion. When analysis shows that vulnerable code in a dependency is never called by your application, the matching VEX claim is not_affected with the justification vulnerable_code_not_in_execute_path.
Two different jobs
Reachability analysis looks at how your code uses a dependency and asks whether a path exists from your entry points to the vulnerable function. It produces a result for a finding.
VEX is a document format. OpenVEX defines the justification as: the vulnerable code, likely in a subcomponent, cannot be executed because the product does not call it. CISA's wording is nearly identical.
So reachability is the method, and the justification is the label.
What the evidence should include
If you publish the claim, a consumer will want to know how you decided. Useful details:
- The vulnerable function or module, by name.
- The product version analysed.
- The method: static call graph, tests, runtime traces, or a mix.
- The date of the analysis.
Put a short version into the impact statement, and keep the full result in your records.
Limits to state honestly
Static analysis can miss dynamic calls, reflection or plugins. A runtime trace only covers the paths exercised. If the product loads code by configuration, the claim may hold only for one configuration.
State the configuration. If the answer changes when an optional module is enabled, the safer statement is a narrower one, or an impact statement that names the condition.
When not to use this justification
If the vulnerable code is not even built, the better value is vulnerable_code_not_present. If the component is not shipped at all, use component_not_present. Those claims are stronger because they can be checked from the artifact. Use the execute path value only when the code is present and the argument is about calls.
Re-check on change
A reachability result belongs to a code version. When your code adds a call, or a dependency update changes its internals, the earlier claim may no longer hold. Re-run the analysis on release, and bump the VEX statement version if the answer changes.
A workflow
- Scan and list findings.
- Run reachability on each.
- For unreachable findings, draft not_affected statements with the execute path justification and a short impact note.
- Review a sample by hand.
- Publish or store the VEX, with versions.
You can see the effect on a finding list in the reachability demo. Safeguard offers reachability analysis for dependency findings, and a free scan is at https://gold.safeguard.sh/scan.
What a consumer should ask for
When a supplier cites the execute path justification, ask two questions. Which method produced the result, and for which configuration? If the answer is a call graph for the default configuration, you can check whether your deployment changes it. If you cannot get an answer, treat the claim as under investigation on your side until you have run your own analysis.
Quick check
Is reachability proof that a vulnerability is not exploitable?
No. It is evidence that the vulnerable code is not called in the analysed configuration. State the limits in the statement.
Sources
Last reviewed: 19 October 2026.
