Overview

Vulnerability Exploitability eXchange (VEX) is an emerging standard that enables software suppliers and security teams to communicate whether vulnerabilities in software components are actually exploitable in a specific product context. By integrating VEX documents into your CI/CD pipeline, you can automatically suppress false-positive CVE alerts and focus remediation efforts on vulnerabilities that pose genuine risk. This knowledge base article explains how to create, manage, and integrate VEX documents into your security scanning workflow to reduce vulnerability noise and improve triage efficiency.

The Problem: CVE Alert Fatigue

Modern applications contain hundreds or thousands of dependencies. When vulnerability scanners analyze a Software Bill of Materials (SBOM), they often flag numerous CVEs that, while technically present in a component, cannot actually be exploited in your specific deployment context. Common reasons include: Vulnerable code not loaded: The affected function or class is excluded during compilation or never invoked at runtime. Configuration prevents exploitation: The vulnerable feature is disabled in your deployment configuration. Mitigations already in place: Sandboxing, input validation, or other controls neutralize the attack vector. Component not deployed: Test or development dependencies are flagged but never ship to production. Without a mechanism to communicate this context, security teams waste significant time investigating non-exploitable vulnerabilities, and pipelines may fail unnecessarily on CVEs that pose no real risk.

What is VEX?

VEX was developed by the National Telecommunications and Information Administration (NTIA) in 2021 and further refined by CISA through a multi-stakeholder working group. It provides a machine-readable format for declaring the exploitability status of vulnerabilities, designed to complement SBOMs.

A VEX document asserts one of four statuses for each vulnerability-product combination:

VEX Format Options

VEX can be expressed in multiple formats. Choose based on your tooling ecosystem and interoperability requirements:

Integrating VEX into Your CI/CD Pipeline

The goal is to make VEX consumption a required step after vulnerability scanning, allowing your pipeline to automatically filter out non-exploitable CVEs before failing builds or creating tickets.

Pipeline Workflow

• Step 1 - SBOM Generation: Generate an SBOM using tools like Trivy, Syft, or your SCA solution. Output in CycloneDX or SPDX format.
• Step 2 - Vulnerability Scan: Scan the SBOM against vulnerability databases (NVD, OSV) to identify CVEs affecting your components.
• Step 3 - VEX Consumption: Query your VEX data source (local file, artifact repository, or API) to check each CVE's exploitability status.
• Step 4 - Policy Evaluation: Apply policy rules to determine build outcomes based on VEX-adjusted vulnerability data.
• Step 5 - Report and Act: Generate filtered reports showing only actionable vulnerabilities. Route findings appropriately.

Example: Using Trivy with VEX

Trivy natively supports VEX in OpenVEX and CSAF formats. To filter vulnerabilities using a VEX document:

trivy image myapp:latest --vex ./vex-statements.openvex.json

When a CVE listed in your VEX document has status “not_affected,” Trivy logs that it filtered out the vulnerability and excludes it from the final report.

Example: Using cve-bin-tool with VEX

The CVE Binary Tool supports VEX as a triage mechanism:

cve-bin-tool --sbom sbom.json --vex-file vex.json --filter-triage

The --filter-triage flag removes vulnerabilities marked as NotAffected or FalsePositive from the output.

Creating VEX Documents

Using vexctl (OpenVEX) The vexctl tool from the OpenVEX project creates and manages VEX documents:

# Create a VEX statement declaring a CVE as not affectedvexctl create \  --product="pkg:npm/myapp@1.0.0" \  --vuln="CVE-2024-12345" \  --status="not_affected" \  --justification="vulnerable_code_not_in_execute_path"

Sample OpenVEX Document

{  "@context": "https://openvex.dev/ns/v0.2.0",  "@id": "https://example.com/vex/myapp-v1",  "author": "security-team@example.com",  "timestamp": "2026-01-23T10:00:00Z",  "version": 1,  "statements": [{    "vulnerability": { "name": "CVE-2024-12345" },    "products": ["pkg:npm/myapp@1.0.0"],    "status": "not_affected",    "justification": "vulnerable_code_not_in_execute_path",    "impact_statement": "The affected function parseXML() is never called by our application."  }]}

Governance and Best Practices

Implementing VEX requires clear ownership and processes: Establish ownership: Define who can create and approve VEX statements. Security engineers should validate justifications before pipeline integration. Version control VEX documents: Store VEX files in Git alongside your code. This creates an auditable history of security decisions. Define evidence requirements: Document what constitutes sufficient evidence for each justification type. Code analysis, runtime verification, or architecture review may be required. Review periodically: VEX statements should be reviewed when new information emerges. A “not_affected” status may change if exploitation techniques evolve. Sign attestations: For high-assurance environments, cryptographically sign VEX documents using Sigstore or similar mechanisms.

Vendor VEX Sources

Major vendors now publish VEX data that you can consume in your pipeline: Red Hat: VEX files available at https://access.redhat.com/security/data/csaf/v2/vex/ covering all CVEs affecting the Red Hat portfolio. Microsoft: CSAF VEX advisories for Azure Linux and other products via https://msrc.microsoft.com/csaf/provider-metadata.json. Cisco: VEX documents available through the Cisco Vulnerability Repository (CVR) for supported products.