Use four status words: not affected, affected, fixed, and under investigation. These are the labels defined in the OpenVEX specification. Add a reason to every "not affected" and update the notice when your status changes. Customers can then decide quickly whether they need to act on a given vulnerability.
Why four words beat free text
A notice written as a paragraph forces every reader to guess. Fixed labels let a person skim and let a tool read the result. OpenVEX says scanners that consume its documents can key on status labels to change how they treat a detected vulnerable component, and dashboards can use them to show how impact evolved over time.
What each word means
| Status | Meaning in OpenVEX | What to tell customers |
|---|---|---|
not_affected | No remediation is required | Why, using a justification |
affected | Actions are recommended | What to do and by when |
fixed | These product versions contain a fix | Which versions, and how to upgrade |
under_investigation | Not yet known | That you are checking, and when to expect news |
The spec says an under investigation status should be followed by further documents as knowledge evolves, so do not leave it open without an update plan.
Give a reason for "not affected"
OpenVEX requires a not affected statement to include either a status justification or an impact statement. It lists fixed justification labels, including these four:
component_not_present: the component is not in the product.vulnerable_code_not_present: the component is included but the vulnerable code is not.vulnerable_code_not_in_execute_path: the vulnerable code cannot be executed as the product uses it.vulnerable_code_cannot_be_controlled_by_adversary: an attacker cannot control the vulnerable code.
Pick the label that matches your analysis, then add a sentence in plain words. "Not affected" with no reason reads as dismissal, and a careful customer will ask for the reason anyway.
A short notice template
- Vulnerability identifier and a one-line description.
- Products and versions in scope.
- Status, using one of the four words.
- Reason (for not affected) or action (for affected and fixed).
- Date published and date last updated.
- Contact for questions.
Keep each notice to one vulnerability. A table of many vulnerabilities can sit on an index page that links to each.
Handle changes honestly
When status changes, publish a new dated statement. Moving from under investigation to fixed is a normal path. Quietly editing an old notice makes the history unreadable. CISA's description of VEX is that it is an attestation, a form of security advisory showing whether a product is affected by a known vulnerability, so treat each statement as a claim you may be asked to support.
Try it yourself
Click through it at your own pace, or open it full screen.
Walk through how exploitability is judged. That judgment is what a not affected reason should summarize.
Where Safeguard fits
Safeguard's reachability analysis helps show whether vulnerable code is actually used, which supports the analysis behind a status. Try a free scan at gold.safeguard.sh/scan.
Quick check
Do I need a VEX file to publish a notice?
No. A plain page with the four status words and a reason is a start. A machine-readable VEX file helps customers who want to load the data into tools.
Can I say "not affected" because the code is unreachable?
Only if your analysis supports it. The matching justification label is the vulnerable code not being in the execute path, and you should keep the analysis on file.
Sources
Last reviewed: 19 October 2026.
