VEX is a machine-readable statement about whether a product is affected by a vulnerability. It does not find vulnerabilities, it does not fix them, and it does not prove anything by itself. These six myths come up often, and each can be checked against the published specifications.
Myth 1: No VEX statement means not affected
Fact: CISA says VEX does not specify, assume or imply any default status that is not explicitly provided. VEX information may be incomplete. A missing statement is simply unknown.
Myth 2: Only the supplier can write VEX
Fact: CISA says VEX documents can be authored by the supplier of the software or by a third party. Consumers need to judge the author's credibility, but third party VEX is within the model.
Myth 3: VEX needs an SBOM
Fact: CISA says VEX is designed to integrate with SBOMs, vulnerability databases and advisories, but does not require any of them. In practice, matching is much easier with an SBOM, which is why most guidance pairs them.
Myth 4: A VEX file is always machine readable end to end
Fact: not quite. The OpenVEX spec says the impact statement is free-form text that is not intended to be machine readable. The machine-readable part is the status and justification.
Myth 5: CISA requires VEX
Fact: the minimum requirements document says it does not represent official CISA policy and does not impose or mandate compliance. It is a community drafted description of minimum elements.
Myth 6: One status can cover several unrelated cases
Fact: a statement conveys a single status for a single vulnerability across its listed products. If status differs for a subset of products, CISA says separate statements must be created for that subset.
A bonus fact: VEX is a claim
None of the myths above change this point. A VEX statement says what the author believes. The spec encourages signing so you can identify who is making the claim, but it does not certify correctness. Sample statements before trusting them in bulk. See how to judge a supplier's VEX.
How to use this list
When someone on your team makes one of these claims, ask for the page in the specification that says so. The CISA document is short and readable, and the OpenVEX spec is a single page. Ten minutes of reading usually settles the argument.
Also keep one more point in mind: VEX status is about a specific product and a specific vulnerability at a specific time. A statement that was true for last quarter's release says nothing about this quarter's. That is why versions and timestamps are required fields rather than decoration.
Quick check
Can VEX replace a vulnerability scanner?
No. A scanner finds what is present. VEX adds the author's view of whether each finding matters.
Can I write VEX for software I did not build?
CISA permits third party authors. Make the author and your evidence clear.
Sources
Last reviewed: 19 October 2026.
