When a VEX statement says affected, it must also carry an action statement. CISA says the action statement should describe actions to remediate or mitigate the vulnerability. A good one names the fixed version or workaround, who must act, and by when, in plain words a customer can follow without a call.
What the specs require
CISA: for status affected, a statement must include one action statement, which should describe how to remediate or mitigate. It may carry a timestamp for when the action statement was issued.
OpenVEX: affected statements require an action statement, with an optional action statement timestamp.
CSAF: for each product in known_affected, product specific information must be provided in remediations. The categories no_fix_planned and none_available are allowed.
What a customer needs from it
- Is there a fix, and which exact version contains it?
- If not, is there a workaround, and what does it cost?
- Is there a deadline or a known exploit that changes urgency?
- Where do I get more detail?
Weak versus strong
Weak: "Update to the latest version."
"Latest" changes tomorrow. It also gives no way to check.
Strong: "Upgrade to release 4.2.7 or later. Until then, disable the import endpoint in the admin settings. This blocks the vulnerable code path. A patched build for the 3.x line is planned, and this statement will be updated when it ships."
It names a version, offers a mitigation, and signals that more is coming.
When there is no fix
Be honest. CSAF explicitly allows none_available and no_fix_planned. CycloneDX has can_not_fix and will_not_fix responses. A clear "no fix is planned for this branch, migrate to 4.x" is more useful than silence, because customers can plan.
Keep the action current
Update the action statement when facts change: the fix ships, a better workaround appears, or the decision not to fix is reversed. Each update bumps the statement version and the document version. Record the action statement time if your format supports it.
Pair it with a status move
When the fix ships, move the statement to fixed and list the fixed versions. Leaving an old affected statement in place with a dated action creates confusion.
For consumers
Copy the action statement into your ticket along with the document version. If the action is a workaround, add a review date so the workaround does not become permanent by accident.
A template to start from
Use four short parts: what is affected, what to do, what to do if you cannot, and when the statement will next be reviewed. For example, naming the affected releases first lets a consumer confirm relevance in one glance. The review date sets expectations and keeps the statement from going stale.
Avoid internal jargon and ticket numbers that customers cannot open. Write for the person who has to act on it at short notice.
Quick check
Can an affected statement omit the action?
No under CISA and OpenVEX. If nothing can be done, say so explicitly.
Sources
- CISA, Minimum Requirements for VEX
- OpenVEX specification
- OASIS CSAF 2.0 specification
- CycloneDX 1.6 JSON schema
Last reviewed: 19 October 2026.
