VEX in Practice: Cutting Vulnerability Noise and Feeding Compliance Reporting in 2026
| Interlynk
Most of the CVEs matched against your SBOM do not apply. VEX is how you say so, in a form machines and regulators can act on. Here is how to operationalize it in 2026.
Overview
An SBOM gives you an accurate list of what is in your software. Run that list against a vulnerability database and you get a second list, usually a much longer one, of every CVE ever associated with those components. Most of the entries on that second list do not apply to your product. The vulnerable function is never called. The affected code path is unreachable. A mitigation is already in place.
VEX, the Vulnerability Exploitability eXchange, is how you record that distinction in a form a machine can read and a regulator can accept. It is the layer that turns a raw match list into a defensible statement about which vulnerabilities actually matter.
The idea is not new, but 2026 is the year it stops being optional for a lot of teams. A January 2026 OpenSSF review of the field called VEX "a promise" rather than "a practice," and noted that adoption remains inconsistent. At the same time, the EU Cyber Resilience Act has made vulnerability handling a legal obligation, and large buyers such as Cisco now require VEX from their suppliers by contract. The gap between how useful VEX is and how little it is operationalized is the opportunity. This is a guide to closing it.
The Noise Problem
Start with the scale. Roughly 40,000 new CVEs are published each year. A single widely used library can account for hundreds of alerts that turn out to be harmless. The OpenSSF review cites Microsoft's experience with a common library, where vulnerabilities in a dependency like curl generated hundreds of unnecessary support tickets, none of which reflected a real exposure.
This is the daily reality of running vulnerability scans against an SBOM. The inventory is correct, the matching is correct, and the output is still mostly false positives, because a CVE attaches to a component, not to the way your product uses that component. A security team that triages every match by hand does not scale past a few products. A team that ignores the list entirely learns nothing from it.
VEX exists to break that trade-off. Instead of re-triaging the same non-issue on every scan, you assert its status once, in a machine-readable document, and every downstream tool and customer can apply that assertion automatically.
What VEX Asserts
A VEX statement answers one question for a given product and a given vulnerability: does this actually affect you? CISA defines four status values.
Not affected. No remediation is required, because the vulnerability does not impact the product as shipped.
Affected. The vulnerability does impact the product, and the author recommends action.
Fixed. The released product already contains the fix.
Under investigation. The author has not yet reached a conclusion.
The value of the format is in the first and last of those. "Not affected" is what suppresses the noise, and "under investigation" is an honest, trackable placeholder while an assessment is in progress. Both are far more useful to a downstream consumer than silence.
Justifications for "Not Affected"
A bare "not affected" is an assertion with no evidence behind it, and a serious consumer will not trust it. A credible VEX program backs the status with one of the five justifications CISA defines:
Component not present. The scanner matched something that is not actually in the build.
Vulnerable code not present. The component is included, but the specific vulnerable code is not.
Vulnerable code not in the execute path. The dependency is present, but the vulnerable function is never reached.
Vulnerable code cannot be controlled by an adversary. Input vectors cannot reach the vulnerability.
Inline mitigations already exist. The code is reachable, but something else stops the exploit.
Each one is a different kind of claim, and the discipline they impose is the point. They force the person writing the VEX to say, in a structured way, what they checked and what they concluded. That is also where VEX programs most often fall down, because the justification is only as good as the evidence underneath it, and the evidence has to come from somewhere.
The Format Landscape
VEX is a concept with several concrete encodings, and the choice between them has real consequences.
CSAF is the OASIS standard, widely used by major vendors and aligned with the direction of the EU CRA. It is powerful and expressive. It is also complex to generate and validate without specialized tooling, which is why the OpenSSF review recommends it as the target for high-fidelity production rather than the place most teams should start.
OpenVEX is the OpenSSF project built for simplicity. It favors reliability over advisory features, supports in-toto attestation, and has stable libraries in Go, Docker, and other ecosystems, which lowers the barrier for smaller teams. It is the pragmatic choice for getting started.
CycloneDX supports VEX and can embed vulnerability status inside an SBOM. That convenience comes with a catch worth understanding. An SBOM is a build-time snapshot, while VEX changes every time new status information appears, so embedding one in the other creates a lifecycle mismatch that the documentation does not fully resolve.
SPDX 3.0 now includes a full VEX implementation designed to round-trip with the other formats.
For most teams the practical path is to start in OpenVEX for its tooling, and move toward CSAF where a regulator or a large customer expects it. The important decision is not which format wins. It is to produce VEX in a format your consumers can actually ingest, and to keep the VEX documents separate from the SBOM so each can follow its own update cycle.
Who Writes VEX, and When
VEX is authored by whoever is best positioned to know whether a vulnerability is exploitable. Usually that is the supplier of the affected component or the vendor of the finished product.
In practice, the suppliers doing this well are a short list. Red Hat, OpenSUSE, and Microsoft publish CSAF VEX. Cisco exposes it through APIs and is moving toward CSAF exports. Chainguard maintains an OpenVEX feed. Most open-source maintainers publish nothing, because they see little incentive to, which means a consumer of open-source components often has to produce VEX for dependencies whose maintainers never will.
Timing is the other half. A vulnerability status is not a one-time declaration. It starts as "under investigation," becomes "affected" or "not affected" after analysis, and may become "fixed" after a release. A VEX program has to treat status as something that changes over a product's life, re-asserted as analysis concludes and releases ship. This is the lifecycle point that trips up the embed-in-SBOM approach, and it is why VEX is better managed as a living stream of assertions tied to products and versions.
VEX and Regulatory Reporting
The compliance case is what is pushing VEX from nice-to-have to necessary.
Under the EU Cyber Resilience Act, vulnerability handling is a legal requirement, and manufacturers have to report actively exploited vulnerabilities within tight deadlines. The question a regulator or a CSIRT is really asking in that moment is whether a given vulnerability is exploitable in your product and which products and versions are affected. That is precisely the question VEX is designed to answer. A maintained set of VEX assertions is how a manufacturer can state, with evidence, that a newly disclosed CVE in a bundled component is or is not exploitable in a shipped device, instead of scrambling to reconstruct that analysis under a 72-hour clock. CSAF's close alignment with the CRA is why major vendors are standardizing on it for this purpose.
The medical-device side runs in parallel. FDA expectations under Section 524B include an ability to assess and communicate the status of vulnerabilities in a marketed device over its lifecycle. VEX is the mechanism for that communication: a structured way to tell a hospital that a scary-looking CVE in the device's SBOM does not apply, and why.
In both regimes, the SBOM proves what is in the product and VEX proves what is exploitable. Regulators increasingly expect both, and the second is harder to fake.
Where VEX Breaks at Scale
Operationalizing VEX honestly means naming what still does not work, because the gaps determine how you build.
Discovery and distribution have no common standard. There is no universal lookup that, given a component, returns the VEX statements about it, so documents are scattered across vendor sites, APIs, and feeds. Trust is uneven, and in practice many teams trust a VEX file because of where it is hosted rather than because it is cryptographically signed. Signing standards are still maturing.
The deepest problem is identifier matching. VEX automation depends on reliably connecting a statement about a component to the component in your SBOM, and that connection runs on identifiers like PURL, CPE, and cryptographic hashes. Those identifier schemes lack shared conventions and trusted mapping authorities, so a VEX statement keyed to one identifier may never match the same component recorded under another. When the identifiers do not line up, the automation silently fails, and you are back to manual triage.
That last point has a direct consequence for how VEX should be built. VEX is only as automatable as the SBOM it attaches to. If the underlying SBOM carries vague or missing component identifiers, no amount of VEX tooling will match assertions to components correctly. Accurate identifiers in the SBOM are the precondition for VEX working at all.
Operationalizing VEX
Put the pieces together and an operational VEX program has a clear shape.
It starts with an accurate SBOM, because VEX assertions have to bind to real components with real identifiers. This is the part that breaks most often for embedded and firmware software, where components arrive as vendored source, static libraries, and SDKs without clean package identifiers. Interlynk's lynkctl generates build-aware SBOMs that capture those components with precise identifiers, which is what makes downstream VEX matching reliable rather than approximate.
From there, the Interlynk platform is where the vulnerability and VEX workflow lives. It ingests SBOMs and CBOMs, evaluates them, risk-assesses components against vulnerability data, and manages VEX assertions so that a "not affected" determination made once is applied consistently and suppresses the same CVE on every future scan. It tracks status across a product's lifecycle rather than freezing it at build time, and it notifies stakeholders when something that was quiet becomes exploitable. The platform does not scan or discover software itself. It operates on the SBOM and CBOM it is given, which keeps the generation and evaluation layers cleanly separated.
The shape of a working program, then, is: generate accurate SBOMs, match them against vulnerability data, record exploitability as VEX with real justifications, keep those assertions current, and feed them into the reports your regulators and customers ask for.
The Bottom Line
VEX is the difference between a vulnerability list that alarms people and one that informs them. The concept is settled, the formats exist, and the compliance pressure is now real enough that waiting is its own risk.
What is not yet settled is the operational layer: producing VEX from real evidence, keying it to accurate identifiers, keeping it current, and distributing it in a form consumers trust. That is the work worth doing in 2026. Standards define what a good exploitability statement looks like. Accurate SBOMs and a disciplined workflow are what let you produce one at scale.
Sources
OpenSSF, "Signal in the Noise: An Industry-Wide Perspective on the State of VEX," January 2026
CISA, "Vulnerability Exploitability eXchange (VEX)" overview and status justifications
CISA, "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)," April 2023
About Interlynk. Interlynk helps teams generate, manage, and operationalize SBOMs across the software supply chain. lynkctl produces build-aware SBOMs for embedded and firmware software, capturing vendored, static, and SDK components with precise identifiers. The Interlynk platform ingests SBOMs and CBOMs, evaluates them for completeness and quality, risk-assesses components, manages VEX assertions, and notifies teams when exposure changes.
This article is informational and does not constitute legal or compliance advice. Regulatory obligations and standards evolve; confirm current requirements against the primary sources and your own counsel.