SBOM vs VEX: when you need the inventory, the exploitability statement, or both
An SBOM lists the components inside a product, while a VEX statement says whether a known vulnerability actually affects that product. If you are a buyer holding a vulnerability report, or a supplier answering a Cyber Resilience Act or NTIA request, the SBOM tells you what is there and the VEX tells you what matters. The two answer different questions, so the first decision is which question your request has to settle. CISA's Minimum Requirements for VEX describe VEX as a way to state that software is or is not affected by a vulnerability, and CISA designs VEX to integrate with SBOMs, vulnerability databases and advisories without requiring any of them.
Ask for the SBOM as the primary deliverable when you need an inventory for asset tracking, license review, or a CRA Annex I Part II point (1) style record of top-level dependencies. Regulation (EU) 2024/2847 requires an SBOM in a commonly used, machine-readable format, so an SBOM is the baseline for many suppliers. Ask for a VEX as the primary deliverable when your team already holds an SBOM and needs to triage a specific advisory quickly. A VEX must give one status (not affected, affected, fixed or under investigation), so it gives you an answer per vulnerability without re-deriving it from the component list.
Require both when the supplier will be asked to justify exploitability claims over time. A VEX should reference the same product and subcomponent identifiers that appear in the SBOM, which is how you trace a "not affected" claim back to a specific version of a component. Check that each "not affected" statement carries a justification or an impact statement, and that each "affected" statement carries an action statement. Confirm with the supplier which VEX format they publish and whether they update statements after new advisories, because a VEX that is never revised goes stale quickly.
SBOM vs VEX side by side on scope, authorship, format and buyer use
This table compares an SBOM and a VEX statement on purpose, contents, authorship, required fields, identifier linkage, formats and the buyer question each answers. Read it as two documents that answer different questions, so a buyer usually needs both: the SBOM to see what is inside a product, and the VEX to see which known vulnerabilities actually affect it.
| Dimension | SBOM | VEX |
|---|---|---|
| Question it answers | What components does this product contain? | Does a known vulnerability affect this product, and what is being done about it? |
| Core content | An inventory of components, including top-level dependencies and their identifiers | Status statements about specific vulnerabilities for a product or subcomponent |
| Who authors it | Usually the software supplier, since it describes the supplier's build | The supplier or a third party, as CISA's VEX requirements allow |
| Required fields or justification | Data fields defined by NTIA's 2021 minimum elements, such as component name, version and supplier | One status per statement: not affected, affected, fixed or under investigation, with a justification or impact statement for not affected and an action statement for affected |
| Identifier linkage | Provides the component identifiers that VEX statements should reference | Should reference existing SBOM identifiers for products and subcomponents |
| Dependency on other inputs | Stands alone as an inventory | Designed to work with SBOMs, vulnerability databases and advisories, but CISA does not require any of them |
| CRA anchor | Annex I Part II point (1) requires an SBOM in a commonly used, machine-readable format covering at least top-level dependencies | Not named in the CRA text supplied here, so confirm with counsel how it maps to the CRA's vulnerability handling duties |
| Common formats | CycloneDX (Ecma standard ECMA-424, version 1.7 released 21 October 2025) or SPDX (ISO/IEC 5962:2021) | Confirm which VEX format your supplier or tool emits and whether it imports into your scanner |
| What a buyer should ask for | A current SBOM per product version in a machine-readable format, with supplier and version fields filled | VEX statements for known vulnerabilities in that SBOM, with justifications for every not affected claim |
Which artifact to ask for by situation
A US federal or NTIA-aligned buyer usually starts with an SBOM because the minimum elements describe what the buyer needs to know about each component. NTIA published *The Minimum Elements for a Software Bill of Materials* on 12 July 2021 under Executive Order 14028, grouping them into data fields, automation support, and practices and processes. The SBOM answers the question of what is inside the product. A VEX statement becomes the follow-up when the buyer needs to know whether a specific published vulnerability affects the product as shipped.
- Minimum artifact: a machine-readable SBOM that covers the delivered product, with the data fields named in the NTIA minimum elements.
- Follow-up artifact: a VEX document for vulnerabilities the buyer is tracking, with one status per statement.
- Supplier provision: the SBOM generation practice, how it is kept current across releases, and the identifiers used for each component.
- Automation support: confirm the supplier can produce the SBOM in a format your scanning tools import, such as CycloneDX or SPDX.
- Practices and processes: ask how the supplier documents its SBOM generation, updates and distribution to customers.
Confirm with the contracting office which SBOM format and delivery method the solicitation requires, since requirements can differ by agency and program. Ask the supplier for a sample SBOM for your product version before award.
A manufacturer placing a product with digital elements on the EU market has a direct legal duty. CRA Annex I Part II point (1) requires identifying and documenting vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies (Regulation (EU) 2024/2847). The SBOM is therefore the minimum artifact. VEX is not named in that requirement, so a manufacturer uses it as a supporting record that explains how known vulnerabilities were assessed, not as a substitute for the SBOM.
- Minimum artifact: an SBOM in a commonly used machine-readable format, covering at least the top-level dependencies.
- Follow-up artifact: VEX statements for known vulnerabilities in components the product ships, with identifiers that match the SBOM.
- Supplier provision: documented vulnerability handling records that show how each finding was assessed and what action was taken.
- Format choice: CycloneDX is published as ECMA-424 and SPDX is recognized as ISO/IEC 5962:2021, so document which format you use and why.
- Compliance proof: the CRA does not create a certificate for the SBOM, so confirm the conformity route and documentation with legal counsel and any notified body involved.
Check that the SBOM is generated from the build that actually ships, not only from source manifests, and that the VEX identifiers reference the same component entries.
An operator running many products has a different question when a new CVE is published: which of our products contain the affected component, and of those, which are actually affected. The SBOM answers the first question because it lets the team search inventories across suppliers. A VEX statement answers the second, because it states whether a vulnerability is not affected, affected, fixed or under investigation for a given product. Without a VEX statement, every match becomes a manual investigation.
- Minimum artifact: a current SBOM from each supplier, so the component search covers every product.
- Follow-up artifact: VEX statements from suppliers for the CVEs that match, which reduce the investigation queue.
- Supplier provision: a VEX statement with one status, plus a justification for not affected statements or an impact statement if the justification is missing.
- Action statements: for affected statements, ask for the remediation or mitigation the supplier recommends and its timing.
- Identifier alignment: check that product and subcomponent identifiers in the VEX reference the SBOM identifiers, so statements can be matched automatically.
Illustrative example: a supplier's SBOM shows a library version present in three products, and the VEX for one product states not affected with a justification. The operator then focuses on the other two. Confirm how each supplier publishes VEX, since CISA notes that documents can come from the supplier or a third party.
A team that consumes open-source components usually does not receive an SBOM or VEX from the project maintainers. It builds its own inventory from the dependencies it pulls in, then decides which known vulnerabilities matter for its deployment. The SBOM is the minimum starting point because it records which versions are in the product. A VEX statement is the follow-up if a project publishes one, or if the consumer writes its own to record a reasoned decision for an internal audit.
- Minimum artifact: an SBOM generated from your own build output, covering the versions you actually run.
- Follow-up artifact: any VEX published by the project, or an internal VEX that records why a vulnerability is not affected in your configuration.
- Supplier provision: for an open-source project, check whether it publishes SBOMs or VEX documents with releases, and which identifiers it uses.
- Justification quality: an internal not affected statement should state the reason, such as a code path that is never reached, so an auditor can check it.
- Ownership: a VEX authored by you does not replace the project's own statement, so keep both and note the source of each.
Confirm with the project's security contact whether it publishes VEX documents, because CISA's minimum requirements do not require any particular publication pattern from open-source projects.
What an SBOM finds and misses, and what a VEX statement finds and misses
An SBOM tells you what components a product contains, and a VEX statement tells you whether a known vulnerability affects those components. Neither answers the question alone, so the cards below cover the gaps each one leaves and the checks that keep them honest.
SBOM shows presence, not reachability
An SBOM lists that a component is in the product, such as a vulnerable logging library nested three dependencies deep. It does not show whether the vulnerable code path is ever called in the shipped configuration. Treat an SBOM hit as a reason to investigate, and ask the supplier whether they have analyzed reachability before anyone opens an incident.
Not affected needs justification
A VEX statement marked not affected must carry a justification, or an impact statement explaining why the vulnerability does not apply. Without one, the status is a claim you cannot check. Ask suppliers which justification they used for each not affected entry, and whether it reflects your deployment rather than a generic default.
Affected needs an action statement
An affected status must include an action statement describing how the supplier is remediating or mitigating the issue. A VEX entry that says affected with no action leaves your team with a known exposure and no path forward. Check that each affected entry names a fix version, a workaround, or a documented mitigation before you accept it into your risk register.
Accurate SBOM identifiers
VEX statements are only useful when their product and subcomponent identifiers match identifiers in the SBOM. A statement that points at a component name the SBOM does not contain cannot be matched to anything you run. Before relying on a VEX feed, confirm that the identifiers resolve against the SBOM version you received, and log any mismatches as supplier defects.
VEX covers only what suppliers issue
VEX is a supplier choice in practice. A supplier can publish statements for the vulnerabilities it has assessed and leave others unaddressed, and silence is not a not affected verdict. Ask which vulnerabilities the supplier covers, how often statements are updated, and whether third-party components receive statements at all, then keep your own scanning running in parallel.
SBOM alone is not proof of exposure
Treating an SBOM as proof that a product is exposed leads to false alarms, and treating it as proof of safety leads to missed fixes. Neither conclusion follows from the inventory alone. Pair the SBOM with vulnerability data, VEX statements where available, and your own deployment facts, so each finding carries a documented reason for its status.
What you receive from each artifact and from a combined engagement
An SBOM and a VEX document answer different questions, so each deliverable needs its own checks. The cards below connect them through shared identifiers and show what a buyer should confirm against the CISA and NTIA requirements before accepting either one.
The SBOM file
The SBOM is the inventory of components in a product, including the top-level dependencies the CRA requires at minimum. Check that it names the supplier, component names, versions and unique identifiers, and that it is delivered in a machine-readable format such as CycloneDX or SPDX. Confirm the NTIA data fields are present, because an SBOM missing component versions cannot be matched against vulnerability data.
The VEX document
A VEX document states the status of a known vulnerability against a product or component. Each statement must carry exactly one status: not affected, affected, fixed or under investigation. Confirm the author is named, since the supplier or a third party may write it, and that the statement covers the specific product version you run.
The identifier mapping
VEX statements should reference the same product and subcomponent identifiers used in the SBOM, so each status attaches to a component you can find in the inventory. Test this directly: pick three components from the VEX file and confirm each identifier appears in the SBOM. Mismatched identifiers are the most common reason a VEX file cannot be used in an automated scan.
The justification and action text
A not affected statement must include a justification, or an impact statement if no justification is given. An affected statement must include an action statement describing remediation or mitigation. Read these texts for specifics such as the vulnerable code path or the fixed version, not generic wording. Vague text in either field leaves your team to repeat the analysis.
The update cadence
An SBOM describes one build, so it changes whenever a dependency changes, and a VEX status can change whenever new vulnerability information appears. Ask the supplier how often each artifact is reissued and how a changed status is communicated. Confirm that a new SBOM version and its matching VEX update reach you together, or you may be reading a status against the wrong inventory.
The combined engagement
A combined engagement delivers the SBOM, the VEX document and the supporting analysis as one package, so the inventory and the exploitability statements stay linked. Ask for the scope in writing, the file formats, the identifier scheme and who signs off on each status. Because DeployOpen does not issue audit reports or attestations, confirm with any independent assessor which artifacts they will accept as evidence.
How suppliers combine SBOM and VEX in a release cycle
The sequence turns an inventory of what a product contains into a dated, machine-readable record of which known vulnerabilities actually affect it, so customers can act on the answer instead of a raw scanner list. Each step names who does the work and what proves it is finished.
Generate the SBOM for each release
The supplier's build or release engineering team generates a software bill of materials for the exact artifact being shipped, covering at least the top-level dependencies the Cyber Resilience Act requires. The output is a machine-readable file in a common format such as CycloneDX or SPDX, with the data fields the NTIA minimum elements call for, such as supplier name, component name, version, and unique identifiers. It is done when the SBOM is generated from the release build rather than from a stale manifest, and when someone can confirm it matches the shipped version. Confirm with the supplier which format they use and whether transitive dependencies are included.
Link VEX identifiers to SBOM entries
The team confirms that every product and subcomponent identifier it will use in a VEX document matches an identifier already present in the SBOM. CISA's minimum requirements say VEX identifiers should reference existing SBOM identifiers, so a mismatch here breaks the link a customer relies on. The output is a reconciled identifier list where each vulnerable component can be traced to one SBOM entry. Ask the supplier how identifiers are assigned and whether they stay stable across releases.
Match components against vulnerability advisories
Security or product security staff compare the SBOM component list against vulnerability databases and security advisories for the same release. CISA designs VEX to sit alongside these sources without requiring them, so the supplier chooses its own feeds and must document them. The output is a list of advisories that touch components in the release, each awaiting an analysis decision. Confirm which feeds the supplier monitors, how often they are checked, and how matches are triaged.
Author one status per VEX statement
For each advisory, an analyst records exactly one status: not affected, affected, fixed or under investigation. A not affected statement must carry a justification, or an impact statement if no justification fits, and an affected statement must include an action statement describing remediation or mitigation. The output is a set of VEX statements, each tied to a SBOM identifier and a specific release. Ask the supplier who signs off on these statements and whether they are authored internally or by a third party.
Publish the SBOM and VEX with the release
Release engineering publishes the SBOM and the VEX document together with the product version so that a customer can read both against the same build. The VEX document may be authored by the supplier or a third party, but the publication should state who issued it. The output is a published pair of artifacts with a stable location and version reference. Confirm with the supplier where these files are delivered, how customers receive notice of them, and whether they are signed or otherwise protected against tampering.
Reissue VEX when status changes
When new information changes a status, such as a component being found exploitable or a fix becoming available, the analyst issues an updated VEX statement and records the change against the affected release. The earlier statement remains part of the history so customers can see when a conclusion moved. The output is a revised VEX document with a traceable change. Ask the supplier how customers are notified of revisions and how long superseded statements are retained.
What drives the effort and cost of producing SBOMs and VEX
Producing an SBOM and the VEX statements that sit beside it is mostly an effort problem, and the effort scales with how many components, products and advisories a supplier carries. The cards below cover the drivers that change the work, and what to confirm before asking for a quote. No fee figures are given here, because a quote follows from written scope.
Component count and depth
Every component listed in an SBOM has to be identified, versioned and linked to its parents, and deeper transitive dependencies multiply that work. The CRA requirement covers at least top-level dependencies, while a broader inventory reaches into nested packages. Ask the supplier which depth the SBOM must reach, and how many components a typical release contains.
Tooling and automation support
Generating SBOMs from build pipelines and package manifests costs far less per release than assembling them by hand from spreadsheets. The NTIA minimum elements also treat automation support as a category of its own. Confirm which build systems, package managers and container tooling the team already runs, and whether SBOM output can be produced on every build.
Identifier hygiene
VEX statements should reference the same product and subcomponent identifiers that appear in the SBOM, so mismatched or missing identifiers force manual reconciliation. Naming conventions, version pinning and stable package identifiers reduce that rework. Check whether the team uses one identifier scheme across all products before estimating the effort of linking the two documents.
Number of products and variants
Each product line, configuration, deployment option and regional build can need its own SBOM and its own set of VEX statements. Work grows with the product matrix, not only with the number of code repositories. Ask the supplier to list every shipped variant in scope, since a variant left out of the scope often becomes an unplanned cost later.
Volume of advisories
A VEX statement is written against a specific vulnerability, so the number of advisories that touch a product drives how many statements must be reviewed, updated and republished. Advisories tied to shared libraries can affect many products at once. Ask how often the supplier expects to publish updates, and how it will handle a new advisory that arrives between releases.
Staff needed to write justifications
A not affected statement needs a justification and, where one is missing, an impact statement, and an affected statement needs an action statement on remediation or mitigation. Those statements require someone who understands the product's code paths and configuration, not only the scanner output. Confirm who on the supplier side will sign off each justification and how many hours of that expertise the scope includes.
Common questions buyers and engineers ask about SBOM and VEX
Is a VEX statement required if we already publish an SBOM?
No single rule makes a VEX mandatory because an SBOM exists, and CISA's Minimum Requirements for VEX say VEX is designed to work with an SBOM but does not require one. The two answer different questions. An SBOM tells a reader what components a product contains, while a VEX statement says whether a known vulnerability in one of those components actually affects the product. Without VEX, every scanner hit against a listed component becomes a support ticket. Whether your customers or regulators expect VEX depends on their contracts and sector, so confirm that with each buyer before you decide to skip it.
Who pays for and writes an SBOM versus a VEX document?
The software supplier usually pays for and writes the SBOM for its own product, since the CRA places the duty on manufacturers. A VEX document can be authored by the supplier or by a third party, as CISA notes, so a supplier may pay an analyst or a tool vendor to write statements for components it does not maintain. Cost falls on the supplier's engineering and security teams in both cases, and buyers pay indirectly through their own review effort. Ask each vendor who authors its VEX, how often statements are updated, and whether statements are published alongside the SBOM.
What drives the time it takes to produce an SBOM and VEX?
The main drivers are the number of components, how much of the build is already automated, and how many vulnerability findings need a reasoned status. An SBOM is faster when the build system can emit it on every release and slower when teams must reconstruct dependencies by hand. A VEX takes longer than the SBOM because each affected or not affected statement needs evidence, a justification or impact statement, and an action statement where the product is affected. Ask any supplier for its own process timeline in writing, since no supplied source gives a standard duration.
Can our engineering team produce SBOM and VEX artifacts in-house?
Yes, many teams can, provided the build pipeline can generate a machine-readable SBOM and someone owns the triage of vulnerability findings. The NTIA minimum elements cover data fields, automation support, and practices and processes, so an in-house program must address all three, not just run a generator. Ownership gaps usually appear in VEX, where a team must judge exploitability, document justification, and keep statements aligned with SBOM identifiers. If internal staff lack the time or threat analysis skills, a fixed-scope implementation engagement can help set up the pipeline, though DeployOpen does not issue attestations or certifications.
What do engineering and procurement each need to provide?
Engineering needs build access, a stable inventory of direct and transitive dependencies, and a named owner for vulnerability triage. Procurement needs to write SBOM and VEX expectations into contracts, including the format, the update frequency, the identifiers used, and who receives the artifacts. Both teams should agree on what a not affected statement must justify and how affected statements get remediation or mitigation actions. Put these items in the statement of work or supplier questionnaire so responsibilities are visible before a vulnerability disclosure forces the conversation.
Which SBOM format should we require, CycloneDX or SPDX?
Both are established formats, and the choice depends on what your tools and counterparties read. CycloneDX is published as Ecma standard ECMA-424, with version 1.7 released on 21 October 2025, and it is widely used for vulnerability and VEX workflows. SPDX is recognized as the international standard ISO/IEC 5962:2021 and is strong on license data. Confirm with each customer, regulator or supplier which format they accept, and whether they require a specific version, because the CRA requires a commonly used machine-readable format without naming one.
What should we confirm about CRA timing and formats with the regulator or supplier?
Confirm the dates from the official text of Regulation (EU) 2024/2847 and from the competent market surveillance or national authority guidance, because this page does not state application dates. Ask the regulator which format and minimum content it expects for the top-level dependency SBOM, and whether it accepts a VEX as supporting evidence. Ask suppliers which SBOM version they publish, whether it matches the identifiers used in their VEX, and how they will provide evidence during a market surveillance request. Record each answer in writing, since guidance can change before enforcement.
When one artifact is enough and when you need both
An SBOM alone is enough when the question is inventory: which components, and which versions, ship in a product or sit in a deployed environment. Procurement teams asking for component visibility, and compliance reviews asking whether a supplier can produce a machine-readable list of top-level dependencies, are answered by the SBOM. The Cyber Resilience Act expects manufacturers to draw up an SBOM covering at the very least the top-level dependencies, and the NTIA minimum elements describe the data fields that make that list usable. An SBOM does not tell you whether a known vulnerability in one of those components is exploitable in the product as shipped, so it cannot close an incident question by itself. Ask the supplier which SBOM format and version they produce, whether nested dependencies are included, and how often the list is regenerated after a release.
A VEX adds value during an incident, when a new advisory names a component you already know is in the product and you need a supplier's answer on whether the product is affected. CISA's minimum requirements allow a VEX to state one of four statuses: not affected, affected, fixed or under investigation, with a justification or impact statement for not affected and an action statement for affected. The VEX is only as good as its links to the SBOM, because CISA recommends that product and subcomponent identifiers reference existing SBOM identifiers. Ask the supplier whether VEX documents are published, who authors them, and whether they are updated when new advisories appear. A VEX also does not replace the SBOM: it does not say what is inside the product. Confirm in the supplier's own environment that the identifiers match before you rely on a status.
How DeployOpen scopes SBOM and VEX work for self-hosted platforms
DeployOpen plans, implements, documents and supports SBOM and VEX work inside the client's own infrastructure, for self-hosted open-source platforms the client already runs. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which self-hosted platforms, versions and build pipelines the SBOM must cover before any tooling is chosen
- Agree in writing which VEX statuses the team will issue and who in the client organization approves them
- Confirm which customers, regulators or procurement teams will receive SBOM and VEX outputs, and in what format
How we build
- Set up SBOM generation in the client's pipeline using a machine-readable format the client selects and documents
- Link SBOM component identifiers to the VEX statements so product and subcomponent references resolve consistently
- Test generated documents against the client's chosen field requirements before they are released to anyone outside the team
How we hand over
- Document the SBOM generation steps, VEX authoring rules and review roles so the client's own staff can repeat them
- Provide the justification and action statement templates the client's assessors and customers will read
- Walk the client team through the outputs and record open questions the client must answer with its suppliers
How we support
- Offer ongoing support, upgrades and continuous review of SBOM and VEX outputs as a retainer, scoped in writing
- Refresh SBOM and VEX documents when platform versions change, under the terms of the retainer agreed in writing
- Ask the client to confirm final regulatory and customer obligations with its own counsel, assessor or the relevant authority
