A VEX statement covers exactly one vulnerability and exactly one status, for one or more products. If the answer differs for any product in the set, you must write more than one statement. This is the most common reason hand-written VEX files fail validation or mislead consumers.
The rule
CISA's minimum requirements say a VEX statement must convey a single status that applies to a single vulnerability for one or more product identifiers. A statement may reference more than one product as long as status, vulnerability and other information are correct for the complete set. If status or other information changes for a subset, additional statements must be created for that subset.
A document may contain many statements, or you may publish many documents.
A worked example
CVE-2026-0001 is a placeholder ID used for illustration only. Suppose a library has three releases in the field: 1.0, 1.1 and 1.2. The flaw exists in 1.0 and 1.1, and release 1.2 contains the fix.
Wrong: one statement listing all three releases as affected. Release 1.2 is not affected.
Right: two statements for the same vulnerability.
- Status affected for 1.0 and 1.1, with an action statement to upgrade to 1.2.
- Status fixed for 1.2.
If, in addition, 1.1 is built without the vulnerable module, you would split again, and give 1.1 a not_affected statement with the justification vulnerable_code_not_present.
Why consumers care
Tools match statements to your version. If a statement mixes statuses, the tool cannot tell which status applies to your build. Most will either reject the file or apply the wrong answer.
Product groups and ranges
CISA permits product identifiers that specify sets, such as a product line, a branch, or version ranges. It does not specify how to define those sets, leaving that to SBOM or VEX implementations. Use sets only when the status is identical for every member.
A practical authoring method
- List every shipped version of the product.
- For each vulnerability, decide the status per version.
- Group versions with identical status and reasoning.
- Write one statement per group.
- Check that every shipped version appears in exactly one statement per vulnerability, or in none if you have no answer.
Common slips
- Mixing fixed and affected versions in one statement.
- Listing a not_affected product alongside an affected one because the reason sounds similar.
- Copying an action statement into a not_affected statement.
Checking your file before you publish
Write a short script or checklist that confirms three things for each statement: it has exactly one vulnerability, all listed products share the status, and any action or impact text applies to every listed product. Then group statements by vulnerability and confirm no product appears twice with conflicting statuses.
A conflict means two statements disagree about the same product. Consumers cannot resolve that, so you must.
Quick check
Can one statement cover two CVEs?
No. A statement has exactly one vulnerability identifier. Write one statement per CVE.
Sources
Last reviewed: 19 October 2026.
