When a gate fails on a vulnerability with no fix, you have three options: replace or remove the component, apply a temporary mitigation, or accept the risk through a time-boxed waiver. Pick one on evidence of exploitability, record the reasoning, and set a date to look again.
Start with exploitability, not panic
First ask whether the vulnerable code can actually be reached in your release. A flaw in a function you never call is a different problem from one on a public request path. Check whether the component is loaded at all, whether the vulnerable feature is enabled, and whether an attacker can control the input.
Also check the exploitation signals: is it on the CISA KEV catalog, and what is its EPSS score? A known exploited, reachable flaw with no fix should usually stop a regulated release unless you can mitigate it.
The decision table
| Situation | Reasonable response | Record |
|---|---|---|
| Not reachable, not exploited | Waiver with expiry, plus VEX statement | Justification and review date |
| Reachable, mitigation exists | Apply mitigation, release, track | Mitigation evidence |
| Reachable, can swap component | Replace and re-scan | New SBOM and scan |
| Reachable, known exploited, no mitigation | Hold the release | Escalation note |
NIST SSDF practice RV.2.2 describes making a risk-based decision on whether each vulnerability will be remediated or addressed by other means such as risk acceptance. It also says that if a permanent mitigation is not yet available, you should determine how to temporarily mitigate it and add that to the plan.
Using VEX to say "not affected"
The OpenVEX specification defines four statuses: not_affected, affected, fixed and under_investigation. A not_affected statement must carry either a justification or an impact statement. The justification values include component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary and inline_mitigations_already_exist.
A VEX statement is a claim you must be able to defend. Pair it with the analysis that supports it, and bump the document version whenever a statement changes, as the spec requires.
Steps
- Confirm the finding is real for your version and configuration.
- Test reachability and attacker control.
- Check KEV and EPSS.
- Choose replace, mitigate or waive.
- Write the decision, owner and expiry in the release record.
- Subscribe to the upstream advisory so the fix triggers a ticket.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how exploitability changes the priority of the same finding.
Safeguard provides reachability analysis and policy gates, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Can we release with an unfixed critical vulnerability?
Sometimes, if it is not reachable or is mitigated and the risk is formally accepted with an owner and expiry. Document it.
Does a VEX statement make the finding disappear?
It changes the stated status for consumers of the document. It is only as good as the analysis behind it.
Sources
- NIST SP 800-218, SSDF v1.1 (PDF)
- OpenVEX specification
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS
Last reviewed: 19 October 2026.
