To defend a reachability based decision, show the evidence, not just the label. Provide the finding, the analysis date and commit, the call path or the absence of one, the reason you set it aside, an owner and a review date. Word it as no call path found in this build, never as this cannot be exploited.
Why this question comes up
A customer sends a scan of your product with a long list of findings. Or an auditor samples your vulnerability records and asks why a high severity item is still open. Saying our tool called it unreachable will not satisfy either of them. They want to see how you decided.
The evidence pack
For each set aside finding, keep:
- Identity. The package, version and advisory.
- Scope. The product and version or commit analyzed.
- Method. The tool, version and analysis type, static or dynamic.
- Result. The path found, or a statement that none was found.
- Reasoning. For example, function present but never called, or input not attacker controlled.
- Ownership. Who made the decision.
- Review date. When it will be checked again.
Use a standard format where you can
VEX exists to communicate this. The OpenVEX specification defines status values and justification labels for not affected claims, and requires either a label or an impact statement. CISA also published baseline elements for VEX in April 2023. Sharing a VEX statement lets a customer filter their scan with your reasoning attached. See using VEX justifications for unreachable code.
Wording that holds up
Safer phrasing:
- No call path to the affected function was found in version 2.4 as of the analysis date.
- The function is present in the package but not called by our code.
- We will re-check at the next release.
Phrasing to avoid:
- This vulnerability does not affect us.
- Not exploitable.
- Fixed by design.
The first set describes evidence. The second set makes a claim you may not be able to support later.
Do not overclaim compliance
Reachability evidence supports a vulnerability management process. It does not by itself satisfy any framework, and you should not tell a customer it does. Check what the specific contract or framework asks for.
Keep the record findable
Store decisions where audits look: in the ticket system or compliance tool linked to the finding, not in chat messages. A decision that cannot be found did not happen as far as an auditor is concerned.
Quick check
Is a tool report enough evidence by itself?
Usually not. Add scope, date, reasoning and an owner so the decision can be understood without the tool.
Should I share VEX with customers?
If they can use it, yes. It lets them match your decisions to their scans. Make sure each statement is accurate for the version they run.
Safeguard offers compliance and evidence automation alongside dependency scanning and reachability analysis. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
