Integrating VEX (Vulnerability Exploitability eXchange) into SLA Countdown Timers

Integrating VEX Vulnerability Exploitability e Xchange into SLA Countdown Timers
Back to blog
What Is VEX and Why Is It Essential?
The Four VEX Statuses
The Open-Source VEX Implementation Landscape
Integrating VEX Status into SLA Countdown Timers
The Takeaway
Integrating VEX (Vulnerability Exploitability eXchange) into SLA Countdown Timers
In modern Application Security (AppSec), adopting a Software Bill of Materials (SBOM) provides critical visibility into software dependencies. But that transparency has a side effect: it triggers a massive influx of vulnerability alerts, many of which turn out to be false positives — the vulnerable component is present in the inventory, but the vulnerable code is never actually reachable or executable in the running product.

The scale of the problem is well documented. CISA recorded roughly 36,000 published CVEs in 2024, a 25% year-over-year increase, and the volume has kept climbing since. Yet a 2026 exploit-intelligence analysis from VulnCheck, based on more than two dozen vulnerability-intelligence sources, found that only about 1% of disclosed vulnerabilities were confirmed to have been exploited in the wild during 2025 — exploitation is concentrated in a small, fast-moving subset of CVEs rather than spread evenly across the disclosure firehose. Separately, research on software composition analysis has long noted that a large share of flagged dependencies are never referenced by the calling application at all — commercial SCA vendors have reported figures in the 70–80% range — and more recent reachability-analysis studies confirm the pattern: an automated call-graph analysis of Go projects cut false positives by 74%, rising to 90% on complex codebases like Prometheus, while a separate study of the Maven ecosystem found that fewer than 1% of flagged packages had an actual reachable call path to the vulnerable code.

For engineering managers and AppSec teams enforcing strict remediation deadlines, chasing down that noise drains enormous amounts of developer time. The fix is to pair SBOMs with Vulnerability Exploitability eXchange (VEX) data, and to wire that data directly into the tools that generate and enforce SLA deadlines.

What Is VEX and Why Is It Essential?
VEX is a machine-readable security advisory format that asserts whether a specific known vulnerability is actually exploitable in a specific software product or version. The concept grew out of the U.S. National Telecommunications and Information Administration's (NTIA) multistakeholder work on software transparency, which ran from 2018 to 2021; the effort — including the VEX working group — was subsequently taken over and is now coordinated by the Cybersecurity and Infrastructure Security Agency (CISA). CISA published the foundational "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)" document in April 2023.

CISA and the broader SBOM community frame VEX as a kind of negative security advisory: where a normal advisory says "this product is affected," VEX's most common use is the opposite — telling downstream consumers a flagged vulnerability does not apply to their deployment, and why. As the OpenVEX project puts it, SBOMs create the inventory that lets scanners find flagged components everywhere, and VEX is the mechanism suppliers use to cut through the resulting noise. The two are complementary: an SBOM without VEX just generates alerts, while VEX without an SBOM has no inventory to bind its statements to.

The Four VEX Statuses
A VEX statement assigns one of four statuses, defined by the CISA-coordinated VEX working group and implemented consistently across OpenVEX, CycloneDX, and Google's Artifact Analysis VEX tooling:

Not affected — The vulnerability cannot be exploited in this product, in this configuration. A not_affected status is required by the specification to carry either a machine-readable justification or a free-text impact statement, so downstream consumers can audit the claim rather than take it on faith. The spec defines five standard justification labels, and practitioners are advised to work through them in order, from strongest/most verifiable to weakest:
component_not_present — the vulnerable component isn't included in the product at all.
vulnerable_code_not_present — the component is present, but the specific vulnerable code was removed or was never built in.
vulnerable_code_not_in_execute_path — the vulnerable code exists in the shipped artifact but is never called by the product.
vulnerable_code_cannot_be_controlled_by_adversary — the vulnerable code can run, but an attacker has no way to influence the inputs needed to trigger it.
inline_mitigations_already_exist — a compensating control in the product itself blocks exploitation, and the statement is expected to name the specific mitigation.
Affected — The product is exploitable in this configuration. A statement with this status is required to include an action statement describing what remediation or mitigation the vendor recommends.
Fixed — The vulnerability has been remediated as of a specified product version.
Under investigation — Analysis is still ongoing. Because this status is inherently temporary, several vendors and community guides (including tools like Anchore's vulnerability annotations) recommend attaching notes and a target re-assessment date so the finding doesn't stall indefinitely — though, unlike the not_affected justification requirement, this is a practitioner best practice rather than a strict field mandated by the specification.
One important nuance from CISA's own guidance: VEX statements describe a product in a specific configuration. A not_affected finding for a base container image can flip to affected the moment a downstream team builds on top of it and actually starts calling the vulnerable function — so VEX statements need to be re-verified as they're inherited down a supply chain, not treated as permanent.

The Open-Source VEX Implementation Landscape
AppSec teams have a few interoperable open formats to choose from:

CycloneDX VEX — OWASP's CycloneDX SBOM standard has native support for embedding exploitability data. Because vulnerability status changes far more often than the underlying component inventory, the CycloneDX project specifically recommends decoupling VEX statements from the SBOM itself — publishing them as a separate, updatable VEX document rather than baking them into a BOM that would otherwise need to be regenerated every time an assessment changes.
OpenVEX — A minimal, SBOM-agnostic JSON-LD format built specifically to satisfy the CISA VEX working group's minimum requirements. The project (hosted at github.com/openvex) ships a Go library, openvex/go-vex, for generating, transforming, and consuming OpenVEX documents, plus a companion CLI, vexctl, for creating, merging, and cryptographically attesting VEX statements.
CSAF (Common Security Advisory Framework) — An OASIS open standard (CSAF 2.0) for machine-readable security advisories, maintained by an OASIS technical committee with participation from Cisco, Red Hat, Germany's BSI, and others. CSAF includes an optional VEX profile, and CISA itself has published CSAF 2.0 advisories for industrial control systems, operational technology, and medical devices since September 2023 as part of its push to automate vulnerability disclosure.
CycloneDX documents can also reference CSAF advisories as an external source, so the formats are designed to interoperate rather than compete.

Integrating VEX Status into SLA Countdown Timers
Generic CVE-driven ticketing creates a backlog of rigid, ticking SLAs regardless of whether a finding is actually dangerous. GitLab's published vulnerability-management SLAs are a representative real-world example of what teams are up against: Critical- and High-severity findings carry a 30-day remediation SLA, Medium a 90-day SLA, and Low a 180-day SLA — with a formal "SLA exception" (what GitLab calls a Deviation Request in FedRAMP contexts) required any time a team can't hit the clock. That exception process is manual triage work, multiplied across every non-exploitable finding a scanner surfaces.

A VEX-driven vulnerability management strategy changes that by linking machine-readable exploitability data directly to the ticketing and SLA-enforcement layer, so the clock itself becomes conditional on exploitability rather than on CVE presence alone. This pattern is already implemented in real tooling, not just theory:

Dependency-Track exposes generateVex and uploadVex operations (via its API and companion plugins) specifically so a CI/CD pipeline can attach VEX suppression data to a project's findings automatically.
Anchore Enterprise lets teams record a status-plus-justification annotation on a given (vulnerability, package version) pair; a not_affected or fixed annotation removes that finding from the default vulnerability view so triage attention stays on genuinely open work, and every annotation is rolled up into a unified VEX document that downstream consumers — customers, auditors, deployment gates — can consume directly.
Google Cloud Artifact Analysis stores a VEX assessment per container image and lets security and policy teams filter vulnerabilities by VEX status when deciding what should block a deployment gate.
Applied to an SLA countdown timer, the mechanics look like this: when a scanner flags a CVE against an SBOM component, the pipeline checks for a matching VEX statement before starting or continuing the remediation clock. A not_affected statement with a valid justification pauses or cancels the SLA countdown automatically, with the justification retained as an audit trail. A fixed statement closes it. An affected statement leaves the SLA fully intact and visible. An under_investigation statement can hold the clock in a "pending" state tied to a review date rather than a hard deadline, until the assessment resolves one way or the other.

This isn't just an efficiency play — it's increasingly a compliance requirement. The EU's Cyber Resilience Act (Regulation (EU) 2024/2847), in force since December 10, 2024, requires that products with digital elements be delivered "without known exploitable vulnerabilities," and its mandatory reporting obligations for actively exploited vulnerabilities and severe incidents take effect on September 11, 2026 (full application follows on December 11, 2027). Manufacturers will need to report an actively exploited vulnerability to ENISA's Single Reporting Platform within 24 hours of becoming aware of it. Distinguishing "known" from "known and exploitable" at that speed is exactly the distinction VEX is built to make — and doing it manually, per CVE, per product configuration, is not realistic at the volumes AppSec teams are already dealing with.

The Takeaway
By binding VEX exploitability data to SLA timers, organizations turn a noisy, CVE-count-driven compliance exercise into a risk-based workflow: engineering time goes toward vulnerabilities that are actually reachable and exploitable, not_affected findings are suppressed with an auditable justification instead of an ad hoc exception request, and the resulting VEX trail doubles as evidence for regulatory reporting obligations like those arriving under the EU CRA. The open standards to do this — OpenVEX, CycloneDX VEX, and CSAF — are mature, interoperable, and already supported by mainstream SBOM and vulnerability-management tooling, which means the main remaining work for most teams is wiring existing scanners and ticketing systems together rather than inventing something new.

Sources

CISA — Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
OpenVEX specification (GitHub)
OpenVEX project
CycloneDX — VEX capability page / bom-examples
OASIS Common Security Advisory Framework (CSAF) 2.0
CISA adds OASIS CSAF 2.0 to ICS advisories (Sept. 2023)
European Commission — Cyber Resilience Act overview and timeline
ENISA — CRA Single Reporting Platform
VulnCheck 2026 Exploit Intelligence Report
GitLab — Vulnerability Resolution SLAs
GitLab — SLA exceptions
Anchore Enterprise — VEX annotations documentation
Dependency-Track companion plugin (VEX generation/upload)
Google Cloud Artifact Analysis — VEX status
"A Reality Check on SBOM-based Vulnerability Management" (arXiv, 2025)
"The Dynamics of Software Composition Analysis" (arXiv)
GitLab — reachability analysis and SCA prioritization (Jan. 2025)