OpenVEX is the lighter choice: a small JSON document with a handful of required fields, easy to generate from a triage record. The CSAF VEX profile is heavier, with a product tree and richer advisory structure, and suits vendors who already publish advisories in CSAF. Pick by what your customers' tools read.
The same job, two shapes
Both formats answer one question: is product X affected by vulnerability Y, and if not, why? They differ in structure and in how much surrounding advisory information they expect.
| Aspect | OpenVEX | CSAF VEX profile |
|---|---|---|
| Required at document level | Context, id, author, timestamp, version, statements | All CSAF Base elements, a product tree, vulnerabilities |
| Status values | not_affected, affected, fixed, under_investigation | known_not_affected, known_affected, fixed, under_investigation |
| Not affected needs | A justification or impact statement | A machine readable flag or an impact threat entry |
| Affected needs | An action statement | Remediation entries as an action statement |
| Typical size | Small | Larger, because of the product tree |
The field facts above come from the OpenVEX specification and from Profile 5 in the CSAF 2.0 specification.
Where each fits
OpenVEX suits a team that wants to generate VEX from a triage ticket with little ceremony. CSAF suits a vendor with a PSIRT, an advisory process, and customers who ingest CSAF feeds, because the same document can carry the advisory text, remediation and VEX status.
How to decide
- Ask your five largest customers what they ingest. Their answer outweighs any preference of yours.
- Check what your triage system can export.
- Count how many products and versions you must describe. A big product tree favours a generator that handles CSAF.
- Decide where the source of truth lives. One internal record, rendered to both formats, avoids drift.
- Run a test: have a customer's tooling read a sample and report what it understood.
Publishing both
Some vendors keep one internal record and render both formats. That works if the record is the source of truth and a build step produces the files. It fails if two people edit two files by hand. For the format question in more depth, see which VEX format should a vendor publish.
Rules that apply to both
- Say who the author is, in a machine readable way.
- Keep timestamps honest: OpenVEX defines a statement timestamp as the time the information was known to be true.
- Increase the version whenever content changes. OpenVEX says the document version must be incremented when any content changes.
- Do not mark a product not affected without a reason a reader can check.
Quick check
Is a CSAF VEX document just an OpenVEX document in another syntax?
No. They carry similar status information, but CSAF expects a product tree and ties into the wider advisory model.
Which one has a status for "fixed"?
Both do. In CSAF it sits under product status as fixed, and in OpenVEX it is a status value.
Safeguard supports SBOM and dependency scanning and compliance evidence automation, which give the inventory either format is matched against. A free scan is a quick way to see one.
Sources
Last reviewed: 19 October 2026.
