SBOM and VEX: what they are and how they differ
An SBOM lists what a product is made of. A VEX says whether a known vulnerability actually affects it. They answer different questions.
Two documents, two questions
An SBOM (software bill of materials) lists the components a product is built from — libraries, their versions and how they relate. It answers “do we ship this component, and which version?”
A VEX (vulnerability exploitability exchange) document records whether a specific known vulnerability actually affects a specific product, and why. It answers “this CVE exists in a component we ship — does it matter here?”
The distinction matters because most vulnerabilities found in a dependency are not reachable in the product that includes it. Without VEX, every CVE in every component becomes a customer question. With VEX, the supplier states a position once, with reasoning, in a form a machine can read.
What an SBOM does and does not give you
The practical value is visibility: when a widely used library turns out to be vulnerable, an accurate SBOM answers “are we affected, and where” in minutes rather than days. That is the case that made SBOMs a requirement rather than a good idea.
What an SBOM does not tell you:
- Whether a listed component is actually reachable in the running product. Many are compiled in but never called on any path an attacker controls.
- Whether a vulnerability in a component is exploitable in your configuration.
- Whether the list is still true. An SBOM describes one build; the next build can differ.
- Anything about the components of services the product calls but does not ship.
The two common formats are SPDX (an ISO standard, ISO/IEC 5962) and CycloneDX (an OWASP project, also standardised through Ecma). Both are widely supported; the choice usually follows what your customers and tooling already consume. Generating an SBOM from the build is more reliable than generating one by scanning a finished artefact, because the build knows what it actually included.
What a VEX statement contains
A VEX statement ties a product version to a vulnerability and records a status. The four statuses are:
- Not affected — the vulnerability is present in a component but cannot be exploited in this product. This status requires a justification, such as the vulnerable code never being executed or being unreachable from any input.
- Affected — the vulnerability applies. The statement should say what to do about it.
- Fixed — this version contains the remediation.
- Under investigation — the supplier has not yet determined the answer.
The justification is the substance. “Not affected” with no reason is a claim; “not affected, because the vulnerable function is not present in the compiled binary” is evidence a customer can weigh. VEX can be expressed inside CycloneDX, alongside SPDX, or in CSAF, the OASIS advisory format used by many vendors and by CISA.
CISA published the working-group papers that define VEX and its statuses: CISA’s VEX resources ↗. The minimum-elements definition for SBOM comes from NTIA ↗.
How they work together
The pairing is what makes either useful at scale. The SBOM gives the inventory; the VEX filters it down to what deserves attention.
A CVE lands in a library you ship.
The SBOM shows which product versions include the affected library and at which version.
Engineering checks whether the vulnerable function is reachable from any input the product exposes.
A VEX statement records the conclusion and the reason, per affected product version.
The conclusion is re-checked when the product changes, because reachability can change without the component changing.
Illustrative workflow, not a completed client case.
Where the requirement comes from
For products sold in the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847) includes an SBOM requirement as part of vulnerability handling in Annex I, with the main obligations applying from 11 December 2027 and Article 14 reporting from 11 September 2026. In the United States, Executive Order 14028 drove SBOM requirements into federal software procurement.
Neither regime treats an SBOM as a certificate. It is one record among several, and producing one does not by itself demonstrate that a product is secure or that reporting duties have been met.
Common questions
Is a VEX a replacement for fixing the vulnerability?
No. VEX records an assessment. Where a vulnerability is exploitable, the status is "affected" and remediation still applies. VEX removes noise from the vulnerabilities that do not apply; it does not remove the ones that do.
Do we need to publish our SBOM publicly?
Not necessarily. Requirements generally concern producing and maintaining the record and making it available to the right parties, which for many products means supplying it to customers or to authorities on request rather than publishing it openly.
SPDX or CycloneDX?
Both are accepted. CycloneDX carries VEX natively, which is convenient if you intend to publish exploitability statements alongside the inventory. SPDX has broader use in licence compliance. Following what your customers already ingest avoids conversion work.
How often should an SBOM be regenerated?
Per build that you release. An SBOM describes one artefact; if the artefact changes, the previous record no longer describes what you shipped.
What about components in services we call rather than ship?
They are outside the product SBOM, and they still carry risk. Those belong in supplier and architecture review rather than in the bill of materials for the artefact.
You do not need to know the technical term.
Tell us what is happening, what it affects and when you need help. We’ll discuss whether we can help and what a useful first piece of work would be.