When two VEX statements conflict, do not pick the newer one by default. Compare who wrote each, the date, the product and version scope, and the evidence given. Then record your own decision with reasons. VEX is a claim from an author, and you own the final risk call.
How conflicts arise
Your supplier might say a flaw is not affected, while a researcher, a downstream integrator or your own scan says it is. Or a supplier may publish an update that contradicts its earlier statement. Both are normal.
What the spec gives you
OpenVEX defines four statuses: not affected, affected, fixed and under investigation. A not affected statement must carry a justification or impact statement. Its timestamps and versions help ordering: the document has a required version that must increase when content changes, statements have their own optional version, and statements are ordered by timestamp. The spec describes VEX as a sequence of statements in which later ones override and enrich earlier ones, from the same author.
That last point matters. Ordering applies to one author's sequence. It does not say a third party's newer statement beats the maker's older one.
Decision procedure
- Check authorship. Who is the author, and are they in a position to know? A maker knows its code. An integrator knows its product.
- Check scope. Does each statement name the same product, version and component? A statement about version 3 does not settle version 4.
- Check dates. When was each true? Look at the statement timestamp, not only the document date.
- Check evidence. A justification such as the vulnerable code not being present is testable. A bare assertion is weak.
- Test it. Where possible, verify with a quick experiment or by reading the changelog.
- Decide and record. Write the decision, the reason, the reviewer and a review date.
- Tell both parties. Send your reasoning back and invite correction.
A table for common conflicts
| Conflict | Usual resolution |
|---|---|
| Supplier not affected, scan says affected | Ask supplier for justification, keep finding open until answered |
| Supplier under investigation then fixed | Accept after confirming the fixed version is the one you run |
| Third party affected, supplier not affected | Compare scope and evidence, escalate to both |
| Same author, newer statement reverses | Follow the later one, confirm the reason |
Keep a layered record
Store each statement with author, date and source. Never overwrite one with another. Your own decision sits on top as a separate layer, so an auditor can see the inputs.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how exploitability is determined, then ask which statement in a conflict has real evidence behind it.
Where Safeguard fits
Safeguard provides reachability analysis for code you scan, giving you independent evidence to weigh against statements. The free scan is a way to try it.
Quick check
Does the newest statement always win?
No. Ordering holds within one author's sequence. Across authors, weigh scope and evidence.
Who makes the final call?
You do. Record your decision and reasoning as its own layer.
Sources
- OpenVEX specification: statuses, justifications, versions and timestamps.
Last reviewed: 19 October 2026.
