A tool should export at least one open VEX format that your customers can parse, and ideally two. OpenVEX is lightweight, CycloneDX VEX travels with a CycloneDX SBOM, and the CSAF VEX profile fits advisory workflows. Pick by who reads it, then test that statements round trip without losing justifications.
What VEX is
VEX stands for Vulnerability Exploitability eXchange. CycloneDX describes it as a way to convey the exploitability of vulnerable components in the context of the product in which they are used. In practice it is a statement from a supplier about a vulnerability and a product, with a status such as not affected, affected, fixed or under investigation.
The three formats
| Format | What it is | Strength | Watch for |
|---|---|---|---|
| OpenVEX | A minimal JSON-LD document of statements, with a required context URL, identifier, author, timestamp and version | Small, easy to write and sign | Newer tooling support varies |
| CycloneDX VEX | Vulnerability and analysis data in a CycloneDX document | Lives beside the SBOM that names the components | You need CycloneDX in your pipeline |
| CSAF VEX profile | Profile 5 of the OASIS CSAF 2.0 standard | Fits formal security advisory programmes | Heavier, with many validation tests |
The OpenVEX specification is explicit about a rule worth testing: a statement with not affected status must include either a status justification or an impact statement. It also says the impact statement is free text, not intended to be machine readable, and that its use is highly discouraged for automated systems. So prefer the fixed justification labels.
What a tool should do
- Let a human author a statement with status, product, vulnerability and justification.
- Export it with the correct identifiers for the product and components, so a reader can match it to their SBOM.
- Version the document and stamp it with a time. The OpenVEX specification treats VEX as a sequence of statements, each overriding but also enriching the previous ones.
- Never silently convert a justification to free text on export.
- Validate the output against the format's own rules before releasing it.
Test plan
- Create three statements: not affected with a justification, fixed with a version, and under investigation.
- Export in each supported format.
- Run each file through a parser or validator for that format.
- Import the OpenVEX or CycloneDX output into a second tool and see whether statuses and justifications survive.
- Change one statement and re-export. Check that the version or timestamp advances and the history is preserved.
Choosing for your audience
- Customers with a CycloneDX pipeline: CycloneDX VEX, or OpenVEX if they prefer standalone files.
- Customers with advisory processes or a CSAF based intake: the CSAF VEX profile.
- A broad audience with mixed tooling: publish OpenVEX and keep the statement content identical across formats.
Try it yourself
Click through it at your own pace, or open it full screen. Follow how an exploitability decision is reached, since that is the content a VEX statement records.
Where Safeguard fits
Safeguard's reachability analysis helps establish whether vulnerable code is called, which is evidence for an exploitability decision. Try the free scan at gold.safeguard.sh/scan. Confirm which VEX export formats are available in your plan before you promise them to customers.
Quick check
Is VEX a replacement for scanning?
No. Scanning finds candidates, and VEX records what you concluded about them.
Do I need all three formats?
Usually not. Start with the one your customers can read, and keep the content consistent if you add others.
Sources
Last reviewed: 19 October 2026.
