VEX: How Vulnerability Exploitability eXchange Reduces Alert Fatigue in SBOM Security Programs

One of the most frustrating aspects of SBOM-driven security is alert fatigue. When your SBOM is cross-referenced against vulnerability databases, you may receive hundreds of vulnerability findings for a single application. Many of these are technically accurate — the vulnerable component is present — but the vulnerability is not actually exploitable in your specific product's use of that library. VEX was developed to solve this problem.

The Alert Fatigue Problem

Consider a Java application that uses a popular framework. That framework has twenty transitive dependencies. Three of those dependencies have known CVEs. But in two of the three cases, the vulnerable function in the library is never called by the framework in the way your application uses it. Your SBOM scanner reports all three CVEs as findings, your security team triages all three, and two of them turn out to be not exploitable in practice. This is alert fatigue — and at scale, it causes security teams to stop trusting their scanners.

What VEX Provides

VEX (Vulnerability Exploitability eXchange) is a document format — supported natively in CycloneDX and available as a standalone format via CISA — that allows the software vendor to attach statements to their SBOM asserting the exploitability status of specific CVEs in their specific product. The four VEX status values are: not affected (the product is not affected by this vulnerability); affected (the vulnerability is present and exploitable); fixed (the vulnerability was present but has been remediated in this version); and under investigation (the vendor is still assessing exploitability).

VEX in Practice

A software vendor publishing their product's SBOM with accompanying VEX statements dramatically reduces the burden on their customers' security teams. Instead of triaging every CVE that appears in any component of the SBOM, the customer can trust the vendor's VEX assertions for components where the vendor has the best contextual knowledge — and focus their attention on CVEs where the vendor has not yet issued a statement or where the vendor's statement indicates the product is affected.

CISA's VEX Guidance

CISA has published implementation guidance for VEX and has positioned it as a key complementary capability to SBOM for reducing downstream consumer burden. CISA recommends that software vendors include VEX statements with SBOMs provided to federal agencies, and that agencies develop the tooling to consume VEX data as part of their SBOM intake process. This positions VEX as an expected component of mature SBOM programs in the federal ecosystem.

How to Start Using VEX

CycloneDX supports VEX natively — you can include vulnerability components with exploitability status directly in your CycloneDX SBOM. Alternatively, VEX documents can be published separately and linked to SBOMs. The CISA VEX working group has published a minimum requirements document specifying what a valid VEX statement must include. Tools like Fossity can assist in generating and managing VEX statements alongside SBOMs.

// Recommended Tool

Fossity Supports VEX for Complete SBOM Programs

Fossity — Fossity helps you generate and manage VEX statements alongside your SBOMs — reducing alert fatigue for your customers and downstream security consumers while maintaining full vulnerability transparency. Build a mature SBOM program that goes beyond simple inventory.

Visit Fossity.com →
// Author: Esteban C.