To read a VEX document, check four things in order: who authored it and whether it is signed, which products and versions it covers, what status and justification each statement carries, and whether it is current. Only then use it to change a finding in your scanner. The steps below take about ten minutes for a small file.
1. Check the author and the signature
CISA's minimum requirements say the author is responsible for the content and should be cryptographically associated with the document's signature or other exchange mechanism. Find the author field. Is it the supplier, or a third party? CISA allows both.
If the file is unsigned, note how you received it. CISA says exchange over HTTPS may be sufficient if you trust the certificate chain and the identity of the author.
2. Check what the document covers
Each statement names one vulnerability and one or more products. Compare those product identifiers with your SBOM. A statement about "the product" without a version tells you little. Look for package URLs, hashes or version ranges that you can match to what you deploy.
3. Read each statement's status
You will see affected, fixed, under_investigation or not_affected. Remember that there is no default status. A vulnerability that is not in the file has no VEX answer at all.
For not_affected, confirm a justification or an impact statement is present. For affected, confirm an action statement is present.
4. Check the dates and version
The document version must increase whenever anything changes, and timestamps record when it was first issued and last updated. If the last update is old and your scanner shows newer CVEs, the file may simply not cover them yet.
5. Decide what changes in your tracker
| Statement | Action in your tracker |
|---|---|
| not_affected with justification you accept | Mark as not affected, link the document |
| not_affected with weak reasoning | Keep open, ask for evidence |
| affected | Follow the action statement |
| fixed | Upgrade to a listed version |
| under_investigation | Keep open, set a follow up |
Keep the VEX document itself as the audit record. Reference its identifier and version in the ticket.
6. Sample before you trust at scale
Pick two or three not_affected statements and verify them yourself. If the claim is that code is not in the execute path, confirm with your own analysis or at least ask how the author decided. A small sample tells you how much weight the whole file deserves.
Quick check
Does a VEX file replace my scanner?
No. It adds supplier knowledge to scanner findings. Your scanner still finds what is present, and VEX tells you which findings the supplier says do not matter.
What if the product version in the file does not match mine?
Treat the statement as not applicable to you until the supplier confirms your version.
Sources
Last reviewed: 19 October 2026.
