A CSAF 2.0 document satisfies the VEX profile when it has a product tree, a vulnerabilities list, at least one product status, a CVE or other ID, notes, and the right supporting statements for each status. Its document category must be csaf_vex. This checklist walks through what the OASIS specification requires.
Where the profile comes from
CSAF 2.0 defines several profiles. Profile 5 is VEX. The spec says its main purpose is to state that and why a certain product is, or is not, affected by a vulnerability.
The checklist
A document must satisfy everything in the CSAF Base profile, plus:
- A product tree that lists all products referenced later in the document, regardless of their state.
- A vulnerabilities list covering all vulnerabilities.
- At least one of these product status groups per the vulnerability entries: fixed, known_affected, known_not_affected or under_investigation.
- At least one of a CVE field or an ids field for each vulnerability.
- Notes that provide details about the vulnerability.
- The document category set to csaf_vex.
Rules for known_not_affected
For each product in known_not_affected, an impact statement must exist. It can be machine readable, as a flag in the vulnerability's flags. Or it can be human readable, as a threat entry whose category is impact and whose details describe why the vulnerability cannot be exploited.
Compare this with OpenVEX and the CISA requirements, where the same idea appears as a justification or impact statement.
Rules for known_affected
For each product in known_affected, additional product specific information must be provided in remediations as an action statement. Notes and threats may add detail. The categories no_fix_planned and none_available are permitted for the action statement, which lets a publisher honestly say that no fix exists.
Using product groups
Product group IDs may be used in remediations and threats. The catch is that every product ID must still end up with the information its status requires. A group does not excuse a missing impact statement for any member.
Statuses in CSAF names
CSAF uses known_not_affected, known_affected, fixed and under_investigation. These align with the not_affected, affected, fixed and under_investigation of the CISA minimum requirements.
Why a publisher might choose CSAF
CISA notes that CSAF and CycloneDX provide information beyond what is required for VEX. CSAF suits vendors who already publish advisories, because the VEX profile reuses the same structure. Smaller teams may find OpenVEX lighter.
Validation tips
CSAF has tooling and a strict schema, so validate before you publish. Check these points by hand as well, since they are easy to miss:
- Every product in the product tree that appears in a status group has the supporting statement its status needs.
- The filename follows the CSAF rule: the tracking ID lower cased, with other characters replaced by underscores, and a .json extension.
- Notes exist for each vulnerability.
- The category field reads csaf_vex and not the category of a normal advisory.
A document that fails the profile can still be a valid CSAF advisory, so run the profile check separately.
Quick check
Is CSAF VEX different from a normal CSAF advisory?
It is a profile. A normal advisory has different requirements. The VEX profile fixes the category as csaf_vex and demands impact or action statements per product status.
Sources
Last reviewed: 19 October 2026.
