A VEX statement tells readers whether a specific product is affected by a specific vulnerability. It uses four statuses: not affected, affected, fixed, and under investigation. Support and sales can use them as a shared vocabulary, as long as each status carries the right evidence behind it.
What VEX is, in one paragraph
CISA describes VEX as an attestation, a form of a security advisory, about whether products are affected by known vulnerabilities (CISA). It pairs naturally with an SBOM. The SBOM lists what is inside the software, and VEX says which of the known issues in those parts actually matter for this product.
The four statuses in plain words
The values come from the OpenVEX specification.
| Status | Plain meaning | What the reader should do |
|---|---|---|
| not_affected | The vulnerability is in a component but does not apply to this product | Nothing. A reason must be attached |
| affected | The product is affected | Follow the recommended action |
| fixed | These versions contain a fix | Move to a fixed version |
| under_investigation | We have not decided yet | Wait for the next statement |
The specification says a not_affected statement must include either a status justification or an impact statement explaining why. It also says an affected statement must include an action statement describing how to remediate or mitigate. Those two rules are useful for non-technical teams: if you are given "not affected" with no reason, ask for the reason.
How support should use it
Support can quote the status and the reason, nothing more. If a customer asks why, the answer is the justification text, not a new explanation. If the status is under investigation, say so and give the time of the next statement.
How sales should use it
Sales can send a VEX statement along with an SBOM when a prospect asks about a specific vulnerability. It answers the question in a form the prospect's security team can read, which is often faster than a call. Sales should not edit it, summarise it in a way that changes its meaning, or promise a status change.
Common mistakes
- Treating under investigation as a polite way of saying no. It is a real status that will change.
- Reading not_affected as "has no vulnerabilities". It covers one product and one vulnerability.
- Sending a stale statement. Statuses change, so check the date.
- Using "fixed" without saying which versions.
Who writes the statement
Engineering or security produces it, with the evidence. Customer-facing teams distribute it. Keep a single owner so the statement does not drift between versions.
Try it yourself
Click through it at your own pace, or open it full screen. Click through to see how a vulnerability can be present in a component yet not exploitable in the product. That reasoning is what a not_affected justification records.
Where Safeguard fits
Safeguard provides SBOMs, dependency scanning and reachability analysis, which give the evidence behind a status. The free scan is at gold.safeguard.sh/scan.
Quick check
Is VEX a certification?
No. It is a statement about one product and one vulnerability, made by the supplier.
Can sales send a VEX statement before engineering approves it?
No. The supplier's security owner should approve each statement before it leaves.
Sources
Last reviewed: 19 October 2026.
