VEX vs SBOM: component inventory and exploitability context
An SBOM lists the components in a software product. VEX communicates whether a known vulnerability affects that specific product and why. They answer different questions and work together: inventory supports matching; VEX adds a reasoned product-level status for a finding.
By the Vellaci teamPublished Updated 4 min readOperational guidance, not legal advice
Key facts
- SBOM asks
- Which components and dependency relationships are in this product version?
- VEX asks
- Does this vulnerability affect this product, and what is the status and rationale?
- Relationship
- Use component and version matching to find candidate vulnerabilities; review product context before issuing a VEX statement.
- Formats
- CycloneDX can represent SBOM and VEX data; OpenVEX and CSAF also support VEX use cases.
- CRA caveat
- VEX can support vulnerability-handling evidence. It is not itself a CRA certificate or a substitute for the manufacturer's assessment.
What is the difference between VEX and an SBOM?
An SBOM is an inventory of software components and their relationships for a product or release. A VEX statement is an advisory about the impact of a known vulnerability on a particular product. An SBOM helps identify where a vulnerable package may be present; VEX records the manufacturer's product-specific status and reasoning after review.
| SBOM | VEX | |
|---|---|---|
| Primary question | What components are included? | Is this vulnerability exploitable or otherwise affecting this product? |
| Main subject | Components, versions, suppliers and dependency relationships | A vulnerability in a named product or product version |
| Typical inputs | Build, package manager, image or firmware inventory | A vulnerability finding plus product configuration, code and reachability context |
| Typical output | Machine-readable inventory | Status, justification, action and supporting detail in a supported VEX format |
| What it does not prove | That every listed component is vulnerable or exploitable | That all product risks are assessed or that the product conforms to law |
How they work together
A component matcher compares package identity and version information from an SBOM with vulnerability advisories. That produces candidate findings, not a final product-impact determination. A reviewer checks the affected version range, product configuration, vulnerable code presence or reachability, mitigations and available fixes. The reviewer then records the decision, evidence and any action. Where useful, the decision is expressed as a VEX statement for customers or downstream systems.
- Generate and preserve the SBOM for the exact product release.
- Match component identifiers and versions against vulnerability data.
- Verify the affected range and investigate the finding in product context.
- Record a human-reviewed status, rationale, evidence, owner and remediation action.
- Publish or share VEX in a supported format when it helps downstream users.
Worked example
A release SBOM identifies a specific version of a logging library. An advisory indicates that a version range may contain a vulnerability. The match creates a finding for review. The product team checks whether the affected code is present, reachable and configured in the shipped product, and whether a fixed version is available. The SBOM remains the component inventory; the resulting VEX statement records the product-specific status and the evidence behind it. A new product release or new evidence may require the VEX assessment to be revisited.
Status terms depend on the format
Common VEX vocabulary includes affected, not affected, fixed and under investigation. A serialization standard can use different terms or map a conceptual status to its own field values. CycloneDX 1.5 analysis states include affected, not_affected, resolved and in_triage. Consumers should validate against the selected format's schema and preserve the justification and update history they need.
How VEX relates to the Cyber Resilience Act
Annex I Part II of the CRA requires manufacturers to identify and document components and vulnerabilities and to operate vulnerability-handling processes. VEX can help communicate product-specific findings and preserve part of the decision evidence. The regulation does not turn a VEX document into proof of conformity: the manufacturer remains responsible for the applicable assessment, remediation and technical documentation.
Frequently asked questions
- Does an SBOM say whether my product is vulnerable?
- No. It records components and relationships. Vulnerability matching produces candidate findings; product configuration, affected versions and other context still need review.
- Does VEX replace an SBOM?
- No. VEX communicates vulnerability impact for a product. It does not provide the full component inventory that supports repeatable matching and traceability.
- Can VEX say a component is not affected?
- A VEX statement can record a product-specific not-affected status with a justification supported by evidence. Use the status terms and structure defined by the chosen VEX format.
- Does the CRA require a VEX file?
- The CRA requires vulnerability handling and component/vulnerability documentation, including an SBOM covering at least top-level dependencies. VEX is a useful communication and evidence format; the regulation does not prescribe a single VEX format as a conformity certificate.