A VEX status of "not affected" says that although a vulnerability is associated with a component in a product, no remediation is needed because the product is not affected. A good statement includes a machine readable justification. VEX has four statuses: not affected, affected, fixed and under investigation.
What VEX adds to an SCA report
An SCA report says a vulnerable component is present. VEX, the Vulnerability Exploitability eXchange, lets a supplier say what that means for a given product. The CISA minimum requirements document describes a VEX statement as covering a product, a vulnerability and a status, and notes a common use: conveying that a subcomponent is affected by a vulnerability while the product containing it is not.
The four statuses
| Status | Meaning in the CISA document | What you do |
|---|---|---|
| Not affected | No remediation or mitigation required; product not affected | Record, no action |
| Affected | Action statement describes how to remediate or mitigate | Follow the action |
| Fixed | Listed products contain fixes | Confirm the version |
| Under investigation | Final status not yet declared | Check back |
The document expects "under investigation" to change once the investigation concludes.
Justifications for "not affected"
For a not affected status, the statement should provide a justification, and if it does not, it must provide an impact statement explaining how or why. The justification values listed are:
- Component not present
- Vulnerable code not present
- Vulnerable code not in execute path
- Vulnerable code cannot be controlled by adversary
- Inline mitigations already exist
Each says something different. "Component not present" means the library is not in the product. "Vulnerable code not in execute path" is a reachability claim, and it is only as good as the analysis behind it.
How to read one in practice
- Who authored it? A supplier statement about its own product carries more weight than a guess by a third party.
- Which product and version? Statements apply to listed products. Check that yours is listed.
- Which justification? Treat "not in execute path" and "cannot be controlled" as claims to spot check for serious findings.
- When was it issued? A statement can go stale when the code changes.
- Does it contradict other evidence? If the finding is known exploited, ask for the basis.
Where it helps
VEX cuts down the noise customers see: a supplier can tell you which inherited findings need no action from you. It does not replace your own checks for components you build yourself.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an exploitability decision is recorded for a single finding.
Where Safeguard fits
Safeguard's reachability analysis and SBOM tooling give you evidence you can use when recording an exploitability decision for your own products.
Quick check
Is "not affected" the same as "fixed"?
No. Not affected means the product was never exploitable through that component. Fixed means a vulnerable version was patched.
Can I rely on a supplier's VEX statement blindly?
Treat it as a supplier claim. Check the product version, the justification and the date, and verify high risk items.
Sources
Last reviewed: 19 October 2026.
