VEX (Vulnerability Exploitability eXchange) is a machine readable statement from a software supplier saying whether a known vulnerability actually affects a product. It lets customers drop scanner findings that do not apply. Tools such as vexctl create VEX, and scanners such as Trivy and Grype can read it.
Safeguard publishes this guide and sells a competing product, so we describe other tools only from their own documentation, as of 19 October 2026.
Key takeaways
- An SBOM says what is in your software. VEX says which known vulnerabilities in it matter.
- A VEX statement has a status: not affected, affected, fixed or under investigation.
- Marking something not affected requires a reason, such as the vulnerable code not being present.
- There are three common formats: OpenVEX, CSAF VEX and CycloneDX VEX.
- Scanner support for consuming VEX is real but uneven, and some of it is marked experimental.
What is VEX and why does it exist?
VEX exists because SBOM scans produce false alarms. CycloneDX puts it this way: VEX "focuses on whether a vulnerability in a component can actually be exploited in its specific context." A library may be in your product, but if you never call the vulnerable function the CVE is not an issue for your customer.
Without VEX, every customer who scans your SBOM emails you a list of matches. With VEX, you publish the answers once.
Click through it at your own pace, or open it full screen.
How does VEX work step by step?
- You ship software with an SBOM that lists components.
- A customer or scanner matches components against CVEs.
- You review the matches and decide each one: affected, not affected, fixed, or still being investigated.
- You write those decisions as a VEX document tied to your product and version.
- You publish or attach it, and the customer's scanner filters its results using it.
- When your answer changes, you publish a new statement, and keep the history.
What does a VEX statement contain?
In the OpenVEX spec, each statement has a status and, for not affected, a justification. The four statuses are not_affected, affected, fixed and under_investigation. The spec defines these justifications for not_affected:
- component_not_present
- vulnerable_code_not_present
- vulnerable_code_not_in_execute_path
- vulnerable_code_cannot_be_controlled_by_adversary
- inline_mitigations_already_exist
A not affected statement must include either a justification or an impact statement. A document needs an id, author, timestamp, version and statements.
CSAF has equivalent groups. In its VEX validation rules, each vulnerability must have at least one of fixed, known_affected, known_not_affected or under_investigation in its product status.
Which VEX format should I use?
| Format | Who uses it (per docs) | Notes |
|---|---|---|
| OpenVEX | vexctl, Grype (OpenVEX filtering) | Small JSON spec with four statuses and five justifications |
| CSAF VEX | Advisory publishers, OASIS standard | Product status groups; justification flags such as component_not_present |
| CycloneDX VEX | CycloneDX users | Part of the CycloneDX capability set alongside SBOM and VDR |
Pick the one your consumers can read. If you do not know, OpenVEX is the lightest to produce. CISA has also published minimum elements for VEX documents, so check them if you sell to US government customers.
Which tools create or use VEX?
| Tool | Role | What the docs say |
|---|---|---|
| vexctl | Create, merge, attest, filter | Creates OpenVEX; merges documents while keeping status history; attests statements to container images; filters scanner results, with SARIF supported for now; Apache-2.0 |
| Trivy | Consume | Uses VEX to filter detected vulnerabilities with --vex; sources are a VEX repository, a local file, an OCI attestation or an SBOM reference; marked experimental |
| Grype | Consume | OpenVEX support for filtering and augmenting scan results |
| CycloneDX tooling | Format | CycloneDX lists VEX as a capability beside SBOM |
We could not confirm from the Dependency-Track pages we read how it imports VEX, so check its current docs before relying on it.
How do I choose a VEX tool?
- Which format do your customers or regulators accept?
- Can the tool sign the document or attach it to an image?
- Can your scanner read it, or must you filter by hand?
- Can it merge updates and keep history?
- Who approves a not affected claim, and where is the evidence kept?
- How will a document stay tied to the exact product version?
What should I be careful about with VEX?
Treat a not affected claim as a statement you can be held to. Back it with evidence, such as a reachability result or a code review. Reachability analysis helps here: Safeguard offers it alongside the free dependency scan at gold.safeguard.sh/scan, and the Gold registry at gold.safeguard.sh shows CVEs with CISA KEV status. Safeguard also supports SBOM generation and import.
Frequently asked questions
What is the difference between SBOM and VEX?
An SBOM lists components. VEX says whether specific vulnerabilities in those components affect the product.
Is VEX required?
Not by the sources we read. It is a way to cut false positives for your customers, and some buyers may ask for it.
Who writes a VEX document?
The supplier of the software, since they know how the component is used in their product.
Can I use VEX with Trivy or Grype?
Yes. Trivy has a --vex option, though marked experimental, and Grype supports OpenVEX filtering.
Is OpenVEX or CSAF better?
Neither is better by default. Use the format your consumers can parse.
Sources
- OpenVEX specification: https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md
- vexctl: https://github.com/openvex/vexctl
- Trivy VEX docs: https://trivy.dev/latest/docs/supply-chain/vex/
- Grype: https://github.com/anchore/grype
- CycloneDX VEX: https://cyclonedx.org/capabilities/vex/
- CSAF 2.0 standard: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html
- CISA VEX minimum requirements: https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex
- Free dependency scan: https://gold.safeguard.sh/scan
Last reviewed: 19 October 2026.
