No. CISA's minimum requirements say VEX does not require an author to list every product or component, that VEX information may be incomplete, and that it sets no default status. Whether you owe statements is a contract and relationship question, so prioritise the findings that drive customer decisions.
What the standard says
The CISA document states that VEX does not specify, assume or imply any default status that is not explicitly provided in a statement. It also says VEX does not require an author to provide a complete list of all products or components. And the document says it does not impose or mandate compliance. A missing statement therefore does not mean not affected. It means no statement.
Why silence is risky anyway
Customers who see no statement often assume the worst, and open tickets. A policy of answering selectively, with clear priorities, keeps the volume manageable.
A triage order
| Priority | Findings | Action |
|---|---|---|
| 1 | Known exploited or high severity in a reachable component | Affected or fixed statement with action |
| 2 | High severity where you believe the code is not reachable | Not affected statement with a justification label |
| 3 | Findings a customer asked about by name | Statement of any status |
| 4 | Low severity, bulk findings in dependencies | Batch statements, or a note that these are handled in routine updates |
Using a ranking like this is a process choice. It does not need a vendor tool, only a list and a rule.
Steps to implement
- Collect the findings from the customer scan or from your own.
- Remove duplicates and group by vulnerability.
- For each group, decide a status. Under investigation is a legitimate answer if you commit to follow up. CISA says it is expected to change when the investigation concludes.
- Write statements for priorities 1 to 3 first.
- For the rest, tell the customer how you handle them. A sentence in your security policy can do this.
- Track the open set so it shrinks over time.
Use evidence for not-affected
Not affected needs a justification label or impact statement. The five labels range from component not present to inline mitigations already exist. If you cannot show one, use under investigation rather than not affected.
Related: what VEX does and does not replace.
Try it yourself
Open the demo and look at how it separates findings that can be exploited from those that cannot. That separation is the basis for priorities 1 and 2.
Click through it at your own pace, or open it full screen.
Quick check
Does no statement mean we are not affected?
No. CISA says VEX sets no default status. The absence of a statement says nothing.
Can we use under investigation for everything?
Only briefly. It is meant to be temporary and customers will expect an update.
Safeguard's reachability analysis helps separate findings your code can reach from those it cannot, and the free scan gives a first view.
Sources
Last reviewed: 19 October 2026.
