Yes, many scanners can filter findings using VEX statements, for example one marked not affected, so a build can pass. Treat the statement as evidence that needs an author, a justification and a review date. A VEX file nobody checked is just an exemption in a different format.
What VEX is
VEX stands for Vulnerability Exploitability eXchange. It is a way to say whether a product is affected by a particular vulnerability. CISA has published minimum requirements for VEX documents. The idea is that a supplier can tell customers "this flaw is in a component we ship, but it cannot be exploited in our product", so customers do not waste time.
How a gate can use it
One open source scanner documents VEX filtering as a step in its pipeline of filters: severity first, then status, then suppression by finding ID, policy rules and VEX. Its example loads a VEX file and can show the suppressed results, which it exposes in JSON output so they are not lost.
That visibility is the safe design: the gate passes, and the suppressed findings remain in the record.
Where VEX comes from
| Source | Trust it when |
|---|---|
| Your own team, for your own services | Reviewed and dated, with a justification |
| A supplier, for a product you buy | You have a contract or a way to verify |
| An upstream maintainer, for a library | The statement names the version and component |
| An unknown file found online | Do not trust it |
Steps to use VEX in a gate
- Decide which statuses may suppress: usually only not affected.
- Require a justification text with each statement.
- Check that the statement names the exact product version.
- Load VEX files from a controlled repository, with code review.
- Show suppressed findings in reports.
- Expire or re-verify statements when the product changes.
Where VEX can mislead
A not affected claim can be wrong, or become wrong. A feature flag that was off gets turned on. A refactor makes a previously unused function reachable. If the VEX statement is not tied to a version and revisited, your gate will pass a build that is now affected.
Also remember that "under investigation" and "affected" statements should not pass anything.
Try it yourself
Open the exploitability demo and look at how the same vulnerability can be affecting or not affecting depending on usage.
Click through it at your own pace, or open it full screen.
Safeguard's reachability analysis can provide evidence for an exploitability decision, and policies let you decide what suppresses a finding. A free scan is at gold.safeguard.sh/scan.
Quick check
Is VEX a certification?
No. It is a statement from a supplier or team about one vulnerability and one product. Its value depends on who wrote it and how well it is checked.
Should the gate show what VEX suppressed?
Yes. Suppressed findings should stay visible in the report.
Sources
Last reviewed: 19 October 2026.
