Pick the VEX format that matches how you already exchange SBOMs. If your inventory is CycloneDX, keep decisions in its vulnerability analysis block. If you want a small standalone document that travels separately, OpenVEX is simpler. Both can express "not affected" with a reason, which is the decision most worth preserving.
What VEX is, in one paragraph
VEX stands for Vulnerability Exploitability eXchange. It is a statement that says whether a product is affected by a specific vulnerability, and why. For a migration, that makes it a portable record of triage: the decision outlives the tool that produced it.
How the two formats differ
OpenVEX is a dedicated, minimal specification. A document holds statements, and each statement names a vulnerability, the products it covers, and a status. The four status labels are not_affected, affected, fixed and under_investigation. For not_affected, the spec requires either a machine readable justification label or a free text impact statement. The justification labels include component_not_present, vulnerable_code_not_present and vulnerable_code_not_in_execute_path.
CycloneDX handles the same idea inside the BOM. The 1.6 schema defines an analysis object on each vulnerability with a state, a justification, a response, a detail text, and firstIssued and lastUpdated timestamps. States include resolved, exploitable, in_triage, false_positive and not_affected.
| Question | OpenVEX | CycloneDX analysis |
|---|---|---|
| Lives where | Separate document | Inside the BOM |
| Status values | 4 | 6 |
| Has a false positive state | No, use not_affected | Yes |
| Has an in progress state | under_investigation | in_triage |
| Timestamps | Per statement | firstIssued and lastUpdated |
| Free text field | impact_statement | detail |
How to choose
Choose CycloneDX analysis when your pipeline already produces CycloneDX BOMs and you want one artifact per release. The decision travels next to the component list, and the first issued date can serve as your age anchor.
Choose OpenVEX when decisions are made by a different team than the one producing the BOM, when you need to publish decisions to customers without publishing a full component list, or when you do not use CycloneDX at all.
Do not choose by feature count. Choose by who will read the file and what tool will ingest it. Ask the new scanner which format it reads, and test one file before committing.
Gaps to plan for
Neither format carries a reviewer name in a standard field, so keep decider and approval date in your own sidecar table. Neither tracks ticket links natively. And neither replaces an audit log: a VEX file is a snapshot, not a history of who changed what.
Also note the vocabulary mismatch. OpenVEX has no separate false positive state, so a wrong alert and a harmless alert both become not_affected. If your reporting distinguishes them, record the distinction in the impact statement.
Try it yourself
Open the demo and look at how an exploitability decision is presented next to a finding. Imagine that panel as a single VEX statement, with a status and a reason.
Click through it at your own pace, or open it full screen.
Quick check
Can one scanner export both formats?
Some can. Check the export options of your current tool before assuming, and test the output with a small project.
Is VEX a replacement for ticket history?
No. VEX records a conclusion about exploitability. Ticket history records the discussion and the work. Keep both.
Sources
Last reviewed: 19 October 2026.
