A VEX statement is not a one time answer. A typical lifecycle starts at under_investigation, moves to affected once confirmed, then to fixed when a release ships. Or it ends at not_affected if analysis clears the product. At each move, versions and timestamps must change so consumers can see what happened.
Day zero: under_investigation
When a new CVE lands, the supplier often does not know yet. CISA says under_investigation means the author or relevant parties are investigating and have not declared a final status, and that the status is expected to change.
Publishing it early is useful. Customers know you have seen the CVE and have not forgotten it.
Path A: confirmed affected
If analysis shows the product is vulnerable, the status becomes affected, and an action statement is required. The action statement says what customers should do: apply a workaround, restrict a setting, or wait for a patch. OpenVEX allows an optional timestamp for the action statement.
Path B: cleared as not_affected
If analysis shows the product is safe, the status becomes not_affected with a justification, an impact statement, or both. Publish the reason, not just the verdict.
Path C: fixed
After a release ships with the patch, the status becomes fixed for the listed product identifiers. List the exact versions or build identifiers that contain the fix.
What must change on each update
CISA's rules, in short:
- The document version must increase when any content changes, including content inside statements.
- Each statement version must increase when its own content changes.
- The document's last updated time must be equal to or newer than the newest statement update.
- The statement's last updated time starts equal to its first issued time.
OpenVEX adds that when a document is updated, statements you did not touch should keep their original data, and if the document timestamp changes, existing statements should carry their original timestamp explicitly.
Common mistakes
- Editing a statement in place without bumping versions, so consumers cannot see a change.
- Replacing the whole document and resetting every first issued time.
- Moving to fixed without listing which versions are fixed.
For consumers
Track changes by version number. When a document version rises, diff the statements and re-open any finding whose status changed. A move from not_affected back to affected is rare, and it is the most important change to catch.
A suggested service level
The standards do not set response times, so each team picks its own. A reasonable internal target is to publish under_investigation quickly for CVEs that touch shipped components, then commit to a final status within a stated window. Publish the window to customers so they know when to expect an answer.
Track two numbers: how many statements sit in under_investigation, and how long the oldest has been there. A growing backlog of old investigations is an early sign that the VEX process is not resourced.
Quick check
Can a not_affected statement later become affected?
Yes. New analysis or a new exploit technique can change the answer. The author increments versions and updates timestamps so consumers notice.
Sources
Last reviewed: 19 October 2026.
