Sometimes. A VEX statement records whether a product is affected by a vulnerability and, if not, why. When a team can show that a vulnerable transitive code path is not reachable, a not_affected statement with a justification can close the dispute with evidence, but only if the claim is true and reviewed.
What VEX is
VEX stands for Vulnerability Exploitability eXchange. OpenVEX is an open specification for it. A VEX document carries statements that link a vulnerability to a product and give a status. OpenVEX defines these statuses:
| Status | Meaning in the spec |
|---|---|
| not_affected | No remediation is required regarding this vulnerability |
| affected | Actions are recommended to remediate or address it |
| fixed | These product versions contain a fix |
| under_investigation | It is not yet known whether these versions are affected |
Per the specification, a not_affected statement must include either a machine readable justification label or a free form impact statement. OpenVEX discourages the free text form for automated use, because it breaks interoperability, and recommends justification labels.
Where it helps in a dispute
Typical argument: security flags a vulnerable version of a library buried three levels deep. The product team replies that the vulnerable function is never called. Without a record, the claim is an assertion. With a VEX statement it becomes a dated, reviewable artifact that customers and auditors can read.
It also saves effort. A forced bump that would have cost days becomes a documented non-issue, plus a note to revisit when the code changes.
Steps to use it responsibly
- Confirm the package is in the shipped artifact. Check the SBOM for the build, not just the manifest.
- Check reachability. Determine whether the vulnerable code can be called from your application. Use analysis rather than a hunch.
- Pick the right label. Use one of the predefined justification labels in the spec that matches your reason.
- Write the statement for each affected product version, not for "the product" in general.
- Add an owner and a review trigger. A dependency update, a new feature using the library, or a new advisory should reopen the statement.
- Publish where consumers look. Share it with customers who ask, and attach it to the decision record.
Limits you should state
- A VEX statement is a claim by whoever issues it. It is only as good as the analysis behind it.
- Not reachable today is not not reachable forever. Code changes can make a path reachable.
- Some buyers will still want the fix, regardless of reachability. A VEX statement answers "are we affected," not "will you upgrade."
- Do not use it to avoid a fix that is cheap and safe. If an upgrade is a one line patch bump with passing tests, just do it.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the findings before and after reachability filtering, since that gap is what a not_affected claim rests on.
Where Safeguard fits
Safeguard's reachability analysis helps establish whether a vulnerable function is called, and its SBOM and dependency scanning shows what shipped. A person still has to review the result before it becomes a claim. Try a free scan at gold.safeguard.sh/scan.
Quick check
Does a VEX statement replace patching?
No. It documents that a product is not affected or what the status is. Where a safe fix is easy, patching is still the cleaner answer.
Who should sign off on a not_affected statement?
The owner of the product or service, with security review. Name the approver in the decision record.
Sources
Last reviewed: 19 October 2026.
