Each exception reason needs matching proof. "Not reachable" needs analysis output, "no fix" needs a vendor or maintainer statement, "compensating control" needs a test result, and "false positive" needs the version or code fact that shows the scanner is wrong. A bare sentence is not evidence.
Reason versus evidence
Auditors read the reason, then look for the thing that backs it. A strong record makes that one click. The table pairs the common reasons with what to attach.
| Reason | Evidence to attach |
|---|---|
| Vulnerable code not reachable | Call path or reachability analysis output, with date and code version |
| Component not actually present | SBOM or lockfile excerpt showing the resolved version |
| False positive from a version match | Advisory affected range compared with installed version |
| No fix available | Maintainer or vendor statement, issue link, date checked |
| Compensating control | Test results showing the control blocks the attack path |
| Not exploitable in this configuration | Config excerpt and the advisory's stated conditions |
| End of life | Support policy page and retirement plan |
| Business deferral | Approver's written risk decision and expiry |
Quality tests for evidence
- Dated. When was it produced?
- Specific. Does it name the exact component, version and asset?
- Reproducible. Could someone else rerun it?
- Retained. Will the link still work in two years?
- Independent. Was it produced by someone other than the requester, where risk is high?
Weak evidence to avoid
"Developer confirmed" without a method. Screenshots with no date. Links to a chat thread. A scanner dismissal with no comment. GitHub's documentation notes that a dismissal comment is added to the alert timeline and can be used as justification during auditing, which only helps if the comment says something real. For wording, see how to write a dismissal comment an auditor will accept.
Evidence by risk level
Scale effort to what is at stake. A low severity item in an internal tool may need a short statement. A critical one on an internet facing service needs analysis output and a second reviewer. Write these tiers into the process so requesters know what is expected.
Using reachability evidence carefully
Reachability results are strong support for "not reachable", but they describe code at a point in time. Attach the commit or version analysed and re-run the check on renewal. Related: can reachability analysis justify a risk acceptance.
Structured statements
If you share decisions with customers or downstream teams, a structured format helps. The OpenVEX specification defines fixed justification labels, including vulnerable code not present, vulnerable code not in the execute path and inline mitigations already exist, and requires either a justification or an impact statement for a not affected status.
A one-minute request check
Before submitting, ask: if the author vanished tomorrow, could a stranger verify this reason from the attachments alone? If not, add more.
Safeguard produces reachability analysis and SBOM output you can attach, and its compliance and evidence automation helps keep the proof next to the decision.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what the exploitability result shows, which is the sort of artefact an exception can cite.
Quick check
Is a screenshot acceptable evidence?
Only if dated and specific. Reproducible output is better.
Who should produce the evidence?
The requester can prepare it, but for higher risk an independent reviewer should confirm it.
Sources
Last reviewed: 19 October 2026.
