A not_affected VEX statement is only worth accepting if it carries a machine readable justification, the justification matches how the product really uses the component, and the seller can show how they know. A bare statement with no reason is a claim, not evidence.
What VEX is
VEX, the Vulnerability Exploitability eXchange, lets a supplier say whether a product is affected by a given vulnerability. OpenVEX is one format. A statement ties a product, a vulnerability and a status. The statuses include not_affected, affected, fixed and under_investigation.
The rule that helps reviewers
The OpenVEX specification states that a statement with not_affected status must include either a status justification or an impact statement explaining why. It also says the machine readable justification label is the recommended form, because free text breaks automation and interoperability.
That gives you a first test: no justification, no acceptance.
The justification labels worth knowing
| Label | Meaning (summarised from the specification) | What to verify |
|---|---|---|
| component_not_present | The component is not included in the product | Inspect the built artifact for it |
| vulnerable_code_not_in_execute_path | The vulnerable code cannot be executed as the product uses it | Ask for call path or reachability evidence |
The specification lists further labels. Read the current list rather than relying on a summary here.
Review steps
- Pick five not_affected statements for the highest severity items.
- For component_not_present, scan the artifact yourself. If the component appears, the statement is wrong.
- For vulnerable_code_not_in_execute_path, ask how it was determined. Acceptable answers include a reachability report, a test or a code review note with a name and date.
- Check the date. A statement written against an old version may not hold now.
- Check the product identifier. The statement must name the same product and version you are buying.
Red flags
- Many statements with identical wording and no labels.
- Statements that predate the version in the data room.
- Not affected claims for components the seller also lists as present and reachable.
- No path to update the statement when the code changes.
What a good answer looks like
The seller names who made the decision, when, on which version, and what evidence supports it. Even a short note is far better than a status column with nothing behind it.
If statements are missing
Not every seller publishes VEX. Absence is not a red flag by itself. In that case, ask for an exceptions list: known findings, who owns each, and why it is accepted or scheduled.
Safeguard's reachability analysis and exploitability checks can generate the supporting evidence for such a decision. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what evidence supports each exploitability verdict.
Quick check
Is a not affected claim a guarantee?
No. It is a statement at a point in time. Verify it and check its date.
Sources
Last reviewed: 19 October 2026.
