VEX: The Document That Tells You Which CVEs Actually Matter

VEX (Vulnerability Exploitability Exchange) answers the question your SBOM can't: "This dependency has a CVE, but does it actually affect my product?" VEX is a machine-readable document that states whether a known vulnerability is exploitable, under investigation, not affected, or fixed in your specific product. Think of it as your SBOM's companion — the SBOM lists what you use, VEX says which vulnerabilities in those components actually matter.

For teams drowning in scanner alerts, VEX is the difference between "you have 200 CVEs" and "you have 12 CVEs that actually affect your product."

What We'll Cover

• The problem VEX solves
• VEX status categories
• VEX formats compared (CSAF, OpenVEX, CycloneDX)
• How VEX works with EPSS and CISA KEV
• Creating your first VEX statement
• FAQ

The Problem VEX Solves

You've generated an SBOM for your application. Good. Your vulnerability scanner cross-references it against the CVE database and reports 200 findings. Now what?

Here's the problem: most of those CVEs don't affect your product. A vulnerability in a function you never call. A flaw in a module you don't import. A bug that requires a configuration you don't use. The CVE exists in the component, but it's not exploitable in your specific context.

Without VEX, your options are limited:

Scanner reports CVE-2026-1234 in lodash 4.17.21
├── Option A: Patch immediately (wastes time if not affected)
├── Option B: Ignore it (risky if actually affected)
└── Option C: Manually investigate (doesn't scale)

Every CVE in your SBOM triggers the same alert with the same urgency. Your team spends sprint after sprint patching vulnerabilities that pose zero actual risk — while the few percent of CVEs that are actually exploited sit in the backlog waiting for attention.

VEX eliminates this ambiguity. Instead of "this component has a CVE," VEX says "this CVE does not affect this product because the vulnerable function is not reachable." It's a formal, machine-readable document that your downstream consumers, auditors, and automated tools can all process.

VEX Status Categories

Every VEX statement assigns one of four statuses to a vulnerability in a specific product:

┌─────────────────────────────────────────────────────────────────┐
│                    VEX Status Decision Tree                     │
│                                                                 │
│  CVE exists in a component you ship                             │
│  │                                                              │
│  ├── Do you know the impact yet?                                │
│  │   └── No  ──────────────────────  🟡 UNDER INVESTIGATION    │
│  │                                                              │
│  ├── Does it affect your product?                               │
│  │   └── No  ──────────────────────  🟢 NOT AFFECTED           │
│  │       (justification required)     │                         │
│  │                                    ├── component_not_present │
│  │                                    ├── vulnerable_code_not   │
│  │                                    │   _in_execute_path      │
│  │                                    ├── inline_mitigations    │
│  │                                    │   _already_exist        │
│  │                                    └── vulnerable_code_      │
│  │                                        cannot_be_controlled  │
│  │                                        _by_adversary         │
│  │                                                              │
│  ├── Does it affect your product?                               │
│  │   └── Yes ──────────────────────  🔴 AFFECTED               │
│  │       (action required)            Action: patch, upgrade,   │
│  │                                    or apply workaround       │
│  │                                                              │
│  └── Was it affected but now fixed?                             │
│      └── Yes ──────────────────────  🔵 FIXED                  │
│          (version where remediated)                             │
└─────────────────────────────────────────────────────────────────┘

The key innovation: "Not Affected" requires a justification. You can't just say "we're fine" — you must explain why. The standard justification categories are:

• Component not present: The vulnerable component isn't actually included in your build
• Vulnerable code not in execute path: The component is included, but the vulnerable function/method is never called
• Inline mitigations already exist: Your code already implements protections (input validation, sandboxing) that prevent exploitation
• Vulnerable code cannot be controlled by adversary: The vulnerable code path exists but can't be reached by external input

This justification requirement is what makes VEX useful. It forces a documented analysis instead of a gut feeling.

VEX Formats Compared

Three formats dominate the VEX landscape. Each takes a different approach:

CSAF VEX is the most comprehensive. It's a profile of the Common Security Advisory Framework (CSAF) from OASIS — the same standard used by major vendors like Cisco, Red Hat, and Siemens for security advisories. If you're producing advisories for government or enterprise customers, CSAF is likely required.

OpenVEX is the simplest. Created to pair directly with SBOMs, it strips VEX down to the essentials: product, vulnerability, status, justification. If you're a development team creating your first VEX document, start here.

CycloneDX VEX embeds vulnerability exploitability data directly into a CycloneDX SBOM. If your organization already produces CycloneDX SBOMs, this avoids managing a separate document.

VEX, EPSS, and KEV: The Full Picture

VEX answers a different question than EPSS and CISA KEV. Together, they form a complete vulnerability triage pipeline:

┌──────────────────────────────────────────────────────────────┐
│                    Vulnerability Triage Pipeline              │
│                                                              │
│  Step 1: SBOM identifies components                          │
│  ──────────────────────────────────────                      │
│  "You ship lodash 4.17.21, express 4.18.2, ..."             │
│                        │                                     │
│                        ▼                                     │
│  Step 2: CVE databases flag known vulnerabilities            │
│  ──────────────────────────────────────                      │
│  "lodash 4.17.21 has CVE-2026-XXXX"                         │
│                        │                                     │
│                        ▼                                     │
│  Step 3: VEX filters false positives                         │
│  ──────────────────────────────────────                      │
│  "CVE-2026-XXXX: NOT AFFECTED — vulnerable code path         │
│   not reachable in this product"                             │
│                        │                                     │
│          ┌─────────────┴──────────────┐                      │
│          │ Only AFFECTED CVEs remain  │                      │
│          └─────────────┬──────────────┘                      │
│                        ▼                                     │
│  Step 4: EPSS + KEV prioritize what's left                   │
│  ──────────────────────────────────────                      │
│  EPSS: "How likely is this to be exploited in 30 days?"      │
│  KEV:  "Is this already being exploited in the wild?"        │
│                        │                                     │
│                        ▼                                     │
│  Step 5: Prioritized action list                             │
│  ──────────────────────────────────────                      │
│  "3 CVEs need immediate patching. 8 can wait. 189 filtered." │
└──────────────────────────────────────────────────────────────┘

This is the approach behind the 3-Signal Triage Method: use multiple signals instead of relying on CVSS severity alone. VEX adds a fourth dimension — product-specific context — that transforms generic vulnerability data into actionable intelligence.

GeekWala enriches your dependency scan results with EPSS scores and CISA KEV status, giving you two of these signals automatically. The VEX assessment — whether a CVE is exploitable in your specific product — is still a judgment you make, but the enrichment data gives you the context to make that judgment faster.

Creating Your First VEX Statement

When a customer, partner, or regulator asks "Are you affected by CVE-2026-XXXX?", a VEX document is your formal answer. Here's a minimal OpenVEX example:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-03-24-001",
  "author": "Example Corp Security Team",
  "timestamp": "2026-03-24T12:00:00Z",
  "statements": [
    {
      "vulnerability": {
        "@id": "https://nvd.nist.gov/vuln/detail/CVE-2026-12345"
      },
      "products": [
        {
          "@id": "pkg:npm/your-app@2.1.0"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "The vulnerable parseXML() function in libxml2 is included as a transitive dependency but is never called. Our application uses JSON exclusively for data interchange."
    }
  ]
}

Key elements:

1. Vulnerability identifier — the specific CVE being addressed
2. Product identifier — what product this statement applies to (using Package URL format)
3. Status — one of the four categories (affected, not_affected, under_investigation, fixed)
4. Justification — required for "not_affected" status; explains why
5. Impact statement — human-readable explanation for auditors and customers

Generating VEX at scale: Manual VEX authoring doesn't scale beyond a handful of products. Tools like vexctl (for OpenVEX) and csaf-writer (for CSAF) can generate VEX documents from structured input. Some organizations integrate VEX generation into their CI/CD pipeline — when a scan completes and a developer marks a CVE as "not affected," the pipeline produces the VEX document automatically.

FAQ

Is VEX required by the EU Cyber Resilience Act?

The EU CRA doesn't explicitly mandate VEX documents by name — the term "VEX" does not appear anywhere in the regulation's text. Its vulnerability-handling rules (Regulation (EU) 2024/2847, Annex I, Part II) require manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials" (point 1), and, once a security update is available, to "share and publicly disclose information about fixed vulnerabilities" together with a description, affected-product identification, impact, and severity (point 4) — separately from the requirement to "address and remediate vulnerabilities without delay, including by providing security updates" (point 2).

These Annex I obligations apply from 11 December 2027. Only the narrower Article 14 duty — reporting actively exploited vulnerabilities and severe incidents — takes effect earlier, from 11 September 2026. VEX is the most practical machine-readable format for meeting these disclosure requirements, and organizations preparing for CRA compliance are adopting it as the standard way to communicate vulnerability status to downstream users.

How is VEX different from EPSS?

VEX and EPSS answer fundamentally different questions. VEX is a product-specific assessment you create: "This CVE does not affect our product because we don't call the vulnerable function." EPSS is a global statistical prediction from FIRST.org: "This CVE has a 73% chance of being exploited somewhere in the next 30 days." You might have a CVE with a high EPSS score (likely to be exploited in the wild) but a VEX status of "not affected" (not exploitable in your specific product). Both signals are valuable — VEX eliminates false positives from your queue, and EPSS prioritizes whatever remains.

Does GeekWala generate VEX documents?

Not yet. GeekWala scans your dependencies, cross-references them against the OSV vulnerability database, and enriches findings with EPSS scores and CISA KEV status. This enrichment data — exploitation probability, confirmed exploitation status, severity context — gives you the information you need to make VEX assessments faster. When you see a CVE in your scan results with an EPSS score of 0.02 and no KEV listing, you can confidently investigate whether it's worth a "not affected" VEX statement rather than an emergency patch.

---

VEX turns vulnerability noise into actionable signal. Start by scanning your dependencies with GeekWala to see which CVEs actually affect your stack — enriched with the EPSS and KEV data you need to make informed VEX assessments.