Software Bill of Materials (SBOM) | The Complete Guide
Continue Reading
November 10, 2026
Cyber insurance requirements: is it required? Learn the controls insurers demand, how underwriting works, and what voids a claim, plus a readiness checklist.
November 6, 2026
Learn how business email compromise protection works: how BEC attacks happen, warning signs, and the technical and payment controls that stop them.
November 4, 2026
A privileged access management system controls, records, and limits admin access. See how PAM works, where it fits with IAM, and how to roll it out.
A software bill of materials (SBOM) is a nested, machine-readable inventory of every component, library, and dependency inside a piece of software. It shows what your code is made of, so security teams can quickly trace a new vulnerability to affected products. This guide explains what an SBOM must include, which formats to use, and how to create one.
SBOMs are also becoming a regulatory expectation. The EU Cyber Resilience Act requires manufacturers of products with digital elements to document their components, including with an SBOM, and applies in full from December 11, 2027. In the US, the FDA expects an SBOM in premarket submissions for connected medical devices. CISA's 2026 minimum elements, which replaced the 2021 NTIA baseline, add fields such as component hash, license, tool name, and generation context.
A software bill of materials (SBOM) is formal, machine-readable list of the components that make up a software product, including open-source libraries, third-party packages, and the dependencies they pull in. It records what is inside the software, who supplied each piece, and which version is in use. When a new vulnerability is disclosed, an SBOM lets a team check quickly whether the affected component is in their products.
Think of an SBOM as an ingredient label for software. Modern applications are rarely written from scratch. A typical product combines first-party code with open-source libraries, which in turn depend on other libraries, so the real component list is much longer than most teams expect. An SBOM captures that full tree in a structured file that tools can read, rather than in a spreadsheet someone updates by hand.
Each entry normally names the component, its version, its supplier, and how it relates to other components. Newer guidance goes further. CISA's 2026 minimum elements add fields such as a cryptographic hash and license information, so that each component can be identified precisely.
The term "bill of materials" also describes something different in manufacturing. A manufacturing BOM lists the physical parts, quantities, and sub-assemblies needed to build a product, and it feeds purchasing, inventory, and production planning. A software bill of materials lists digital components for security and risk management, and it has no role in procurement or production scheduling. The two share a name and a nested structure but serve different purposes. For connected hardware, such as a medical device or a router, both can exist for the same product.
An SBOM tells you what is in your software. That is the first question you must answer in a supply chain incident, and it is why regulators ask for it. The EU Cyber Resilience Act, for example, requires manufacturers to document product components in a commonly used, machine-readable format, covering at least the top-level dependencies. Manufacturers are not required to make the SBOM public.
An SBOM does not tell you whether a component is vulnerable, exploitable, or actually reachable in your code. It is an inventory, not a risk assessment. To act on it, you have to match its entries against vulnerability databases and add exploitability context, which a Vulnerability Exploitability eXchange (VEX) document can supply. An SBOM is also only accurate for the build it describes, so a stale file can mislead you. Treat it as an input to your vulnerability management process, not a replacement for it.
An SBOM matters for security because it tells you which components sit inside your software, which is the first thing you need to know when a vulnerability or supply chain compromise is announced. Without that inventory, teams spend days searching repositories and asking vendors. With it, they can check affected products in minutes and decide what to patch first.
When a critical flaw is disclosed in a widely used library, the first question is whether you ship it. An SBOM answers that by letting you search your component inventory for the affected package and version. The search can cover every product at once. Without it, you often have to inspect build files by hand, and the library may be buried several layers down as a dependency of a dependency.
The speed matters because attackers move quickly. Teams that already hold current SBOMs can match a new advisory against their inventory, identify the affected products, and send fix requests to the right owners without a manual hunt.
A software supply chain attack targets something you depend on instead of your own code, such as a compromised library, a poisoned build tool, or a vendor's product. An SBOM makes that dependency visible. It shows which suppliers' components run in your products, so you can judge where your exposure sits.
The data suggests this exposure is growing. Verizon's 2026 Data Breach Investigations Report found that a third party was involved in 48% of breaches, up from 30% the year before. Verizon counts several kinds of third-party involvement, including a vulnerability in a vendor's software used to get into a customer's environment. An SBOM won't stop that kind of breach, but it helps you see which vendors' code you are trusting.
An SBOM and software composition analysis solve related but different problems. An SBOM is a record: a structured inventory of what a product contains. SCA is an activity: a tool that scans code and dependencies to identify open-source components, flag known vulnerabilities, and check license compliance. Many SCA tools can generate an SBOM as an output.
In practice they work together. SCA finds and analyzes components during development, the SBOM captures the result in a standard format that can be shared with customers and regulators, and the vulnerability data is checked against that record over time. Having an SCA tool doesn't mean you have an SBOM program, and an SBOM file without ongoing analysis quickly goes stale.
An SBOM tells you what is present, not whether it can be attacked. A component can have a known vulnerability that is unreachable in your product, because the vulnerable function is never called or a configuration blocks it. Matching an SBOM against vulnerability databases without that context produces a long list of alerts, many of which won't matter.
A Vulnerability Exploitability eXchange (VEX) document addresses this. It is a companion statement in which a supplier says whether a specific vulnerability actually affects a specific product, for example "not affected" or "fixed." Paired with an SBOM, VEX lets customers focus on the findings that carry real risk. Neither replaces vulnerability management, patching, or testing.
An SBOM must contain, at minimum, the data fields and practices set out in CISA's 2026 Minimum Elements for a Software Bill of Materials. That guidance replaced the 2021 NTIA baseline. It covers the identity of each component and its producer, plus details about the SBOM itself, such as who made it, which tool was used, and when.
The National Telecommunications and Information Administration (NTIA) published the first federal baseline in July 2021, responding to Executive Order 14028. It defined seven data fields: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. It also asked for automation support, meaning SBOMs in a machine-readable format such as SPDX or CycloneDX. It added practices around how often to update an SBOM, how deep to go, how to flag unknown dependencies, and how to share the file. The depth requirement was modest: it asked for top-level dependencies with enough detail to trace the rest. For several years this was the reference point for procurement rules, tooling, and regulator guidance.
CISA released the updated baseline on July 29, 2026, jointly with the NSA, the FBI, and international partners. It builds on the 2021 document and incorporates feedback from the 2025 public comment period on CISA's August 2025 draft.
The guidance now splits its data fields into two groups. SBOM metadata describes the SBOM document, and component data describes each piece of software. CISA's announcement names four headline additions: a cryptographic hash for each component, license information, the name of the tool that generated the SBOM, and the generation context. Generation context records whether the SBOM was produced before the build, during it, or after it from the finished binary.
That matters because an SBOM built from source can see different components than one built from the shipped artifact. One analysis counts ten new required fields in total, adding an author signature, data format name and version, tool version, and an SBOM version.
The practices changed too. Coverage replaces depth: an SBOM should list all components, including transitive dependencies, with no minimum depth. Authors must separate information they don't know from information they chose to withhold. Access control is no longer a standalone element and now sits within distribution and delivery. The guidance applies to all software, including open source, AI, and SaaS.
These are baseline expectations, not law. Their practical force comes through procurement requirements and regulations that point to them.
Element | 2021 NTIA | 2026 CISA |
|---|---|---|
Producer of the component | Supplier Name | Renamed to a producer field; unknown provenance must be stated |
Component name | Required | Kept; alternate names allowed |
Component version | Version of the Component | Renamed Component Version |
Identifiers | Other Unique Identifiers | Renamed; at least one machine-processable identifier required |
Dependency relationship | Required | Kept and clarified |
SBOM author | Author of SBOM Data | Renamed SBOM Author |
Timestamp | Required | Kept; format standardized |
Component hash | Not a minimum element | New, with hash algorithm |
License | Not a minimum element | New |
SBOM tool name | Not a minimum element | New, with tool version |
Generation context | Not a minimum element | New |
SBOM author signature | Not a minimum element | New |
Data format name and version | Not a minimum element | New |
SBOM version | Not a minimum element | New |
Depth / coverage | Top-level dependencies | Coverage of all components, including transitive |
Access control | Separate element | Folded into distribution and delivery |
SBOMs are exchanged in two widely used machine-readable formats, SPDX and CycloneDX. Both are named in CISA's 2026 minimum elements guidance, which asks organizations to accept any widely used, interoperable format. NIST doesn't define a format. It provides broader supply chain security guidance that explains why and how organizations should use SBOMs.
The Software Package Data Exchange (SPDX) is an open standard maintained by the Linux Foundation. It began as a way to communicate component and license information, so open-source license compliance has been a core use case since the start. Version 2.2.1 was published as ISO/IEC 5962:2021, making SPDX an international standard and a key reason some procurement and regulatory teams prefer it.
SPDX 3.0, released in April 2024, restructured the specification around a linked-data model and introduced profiles. Profiles are subsets of fields tailored to specific needs, such as security, build attestation, licensing, and AI or dataset documentation. The Linux Foundation has also described the name as now standing for System Package Data Exchange, reflecting its wider scope beyond software. The 3.0.1 patch followed in December 2024. Older 2.x documents remain common, so many tools still read and write both generations.
CycloneDX is an open standard from the OWASP Foundation, designed with application security and supply chain risk analysis in mind. It is typically lightweight to produce and parse, and vulnerability scanners and software composition analysis tools widely support it. It is also commonly used to carry vulnerability and exploitability information alongside the component list.
CycloneDX is standardized by Ecma International (ECMA-424), giving it formal standing alongside SPDX. Teams often choose it when the main goal is to feed an SBOM straight into vulnerability management.
The two formats overlap heavily, and most modern tools can export either. The practical choice usually comes down to what your consumers or regulators ask for and what your tooling supports best.
Comparison | SPDX | CycloneDX |
|---|---|---|
Steward | Linux Foundation | OWASP Foundation |
Origin | License and component compliance | Application security and supply chain risk |
Formal standard | ISO/IEC 5962:2021 (v2.2.1) | Ecma ECMA-424 |
Current major version | 3.0 (April 2024), 3.0.1 (December 2024) | Check the CycloneDX site for the current release |
Strengths | License expressions, broad scope, profiles for AI, data, and build use cases | Security-oriented tooling and straightforward use in vulnerability workflows |
Typical use | Compliance-heavy and regulated environments, license audits | DevSecOps pipelines and vulnerability management |
Named in CISA's 2026 guidance | Yes | Yes |
If you must pick one and nobody has asked for a specific format, choose the one your build and scanning tools support natively, and generate the other only when a customer requires it.
NIST's role is to set the practices around SBOMs, not their file format. Executive Order 14028 defined an SBOM as a formal record of the components and supply chain relationships used in building software, and NIST's glossary cites that definition. NIST's software supply chain guidance then places SBOMs within broader risk management.
Two publications matter most. SP 800-218, the Secure Software Development Framework (SSDF), covers secure development practices, including keeping provenance data for the components in your software. SP 800-161 Rev. 1 covers cybersecurity supply chain risk management for systems and organizations. NIST states that federal acquirers should keep using the risk-based approaches in these two documents to guide SBOM implementation.
Taken together, the layers fit like this. NIST provides the security practices, CISA's minimum elements say what an SBOM should contain, and SPDX or CycloneDX provide the file format.
A software bill of materials example is easiest to understand at two levels: a single component entry and a full document for a small application. The examples below use real npm package data (versions, licenses, and hashes pulled from the npm registry), in CycloneDX JSON, one of the two formats CISA's guidance names.
Each component in an SBOM is a short record. This is the entry for the Express web framework, version 4.21.2:
{
"$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
"version": 1,
"metadata": {
"timestamp": "2026-11-12T11:15:00Z",
"tools": {
"components": [
{
"type": "application",
"name": "cyclonedx-node-npm",
"version": "2.0.0"
}
]
},
"component": {
"type": "application",
"bom-ref": "pkg:npm/[email protected]",
"name": "acme-express-api",
"version": "1.0.0",
"purl": "pkg:npm/[email protected]",
"licenses": [
{
"license": {
"id": "Apache-2.0"
}
}
]
}
},
"components": [
{
"type": "library",
"bom-ref": "pkg:npm/[email protected]",
"name": "express",
"version": "4.21.2",
"purl": "pkg:npm/[email protected]",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
"hashes": [
{
"alg": "SHA-512",
"content": "dbc1ea...bad79c"
}
]
},
{
"type": "library",
"bom-ref": "pkg:npm/[email protected]",
"name": "qs",
"version": "6.13.0",
"purl": "pkg:npm/[email protected]",
"licenses": [
{
"license": {
"id": "BSD-3-Clause"
}
}
]
}
],
"dependencies": [
{
"ref": "pkg:npm/[email protected]",
"dependsOn": [
"pkg:npm/[email protected]"
]
},
{
"ref": "pkg:npm/[email protected]",
"dependsOn": [
"pkg:npm/[email protected]"
]
}
],
"vulnerabilities": [
{
"id": "CVE-2026-4867",
"source": {
"name": "NVD",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4867"
},
"ratings": [
{
"severity": "high",
"method": "CVSSv31"
}
],
"description": "Denial of Service vulnerability in transitive query-string parsing dependency.",
"analysis": {
"state": "not_affected",
"justification": "code_not_reachable",
"detail": "Extended query parser is explicitly disabled at the Express gateway (app.set('query parser', 'simple'))."
},
"affects": [
{
"ref": "pkg:npm/[email protected]"
}
]
}
]
}The hash is shortened here for readability. In a real file it is the full 128-character value.
Here is what each field does:
type says what kind of component this is. Here it is a library, not an application, container, or firmware.
bom-ref is a unique label inside this document. Other parts of the file use it to point at this component, most importantly the dependency graph.
name and version identify the exact release. Vulnerability matching depends on the version, because a flaw usually affects some versions and not others.
purl is a package URL, a standardized identifier that includes the ecosystem (npm), name, and version. Scanners use it to look the component up in vulnerability databases.
licenses records the license by its SPDX identifier, so legal and procurement teams can check obligations automatically.
hashes is a cryptographic fingerprint of the package file. It lets a recipient confirm that the component they have is the one the SBOM describes.
One field is missing on purpose. The entry has no supplier or producer, because the registry data I used didn't state one reliably. A real SBOM should either fill that field or mark the producer as unknown. Silent omission is the pattern CISA's guidance moves away from.
Consider a small order-tracking web app, called acme-orders here (a placeholder name), that declares one dependency: Express. The SBOM below is abridged to show how the document fits together. The component entries follow the pattern above, so they are omitted.
{
"$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
"version": 1,
"metadata": {
"timestamp": "2026-11-11T09:30:00Z",
"lifecycles": [
{
"phase": "build"
}
],
"tools": {
"components": [
{
"type": "application",
"name": "example-sbom-generator",
"version": "1.0.0"
}
]
},
"authors": [
{
"name": "Example Co. Platform Team"
}
],
"component": {
"type": "application",
"bom-ref": "pkg:npm/[email protected]",
"name": "acme-orders",
"version": "2.4.0",
"purl": "pkg:npm/[email protected]",
"licenses": [
{
"license": {
"id": "Apache-2.0"
}
}
]
}
},
"components": [
{
"type": "library",
"bom-ref": "pkg:npm/[email protected]",
"name": "express",
"version": "4.21.2",
"purl": "pkg:npm/[email protected]",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
"hashes": [
{
"alg": "SHA-512",
"content": "dbc1ea...bad79c"
}
]
},
{
"type": "library",
"bom-ref": "pkg:npm/[email protected]",
"name": "debug",
"version": "2.6.9",
"purl": "pkg:npm/[email protected]",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
"hashes": [
{
"alg": "SHA-512",
"content": "a1b2c3d4...e5f6a"
}
]
},
{
"type": "library",
"bom-ref": "pkg:npm/[email protected]",
"name": "ms",
"version": "2.0.0",
"purl": "pkg:npm/[email protected]",
"licenses": [
{
"license": {
"id": "MIT"
}
}
],
"hashes": [
{
"alg": "SHA-512",
"content": "f7e8d9c...1a2c"
}
]
}
],
"dependencies": [
{
"ref": "pkg:npm/[email protected]",
"dependsOn": [
"pkg:npm/[email protected]"
]
},
{
"ref": "pkg:npm/[email protected]",
"dependsOn": [
"pkg:npm/[email protected]"
]
},
{
"ref": "pkg:npm/[email protected]",
"dependsOn": [
"pkg:npm/[email protected]"
]
},
{
"ref": "pkg:npm/[email protected]",
"dependsOn": []
}
],
"compositions": [
{
"aggregate": "incomplete",
"assemblies": [
"pkg:npm/[email protected]"
]
}
]
}Reading it from the top down shows what each block is for. The metadata block describes the SBOM itself: when it was generated, by which tool, by whom, and for which application. The lifecycles entry records that it was produced at build time, which tells a recipient how complete to expect it to be. The dependencies block is the graph. The app declares one dependency, but Express depends on debug, which depends on ms, so one line in the manifest becomes three components, and that is only one branch of Express's tree. The compositions block states honestly that this record is incomplete for Express. That is the "known unknowns" idea in practice: a consumer shouldn't assume a missing dependency means no dependency.
Use this as a working checklist for the document and for every component. The field names follow CISA's 2026 minimum elements, which split data into SBOM-level and component-level fields.
For the SBOM document
SBOM author
Author signature
Data format name and version (for example, CycloneDX 1.6)
Generation context (before build, during build, or after build)
Tool name and tool version
SBOM version
Timestamp
For each component
Producer, or an explicit "unknown provenance" marker
Component name and version
At least one machine-processable identifier (a purl or CPE)
Cryptographic hash value and the algorithm used
License, ideally as an SPDX identifier
Dependency relationship to other components
For the whole SBOM
Transitive dependencies included, with unknowns labeled
A new SBOM generated for each release, and corrected when new details emerge
A defined route for sharing it with the people who need it
To create an SBOM, decide what you are documenting, generate the file automatically from your build, include transitive dependencies, validate it, and then store a new version with every release. The process is largely a pipeline task. A file produced by hand is usually out of date by the next release.
Start by choosing the point in the software lifecycle where you will generate the SBOM, because that determines what it can see. CISA's 2026 minimum elements call this the generation context, with three options: before build, during build, and after build.
A source-based SBOM is generated from repositories and dependency manifests. It shows what the project intends to use, but it can miss what actually ships, such as components pulled in at build time. A build-time SBOM is generated as the releasable artifact is assembled and records the components that went into it, which generally makes it the highest-fidelity option. A post-build SBOM is produced by analyzing the finished binary or container image. It is the fallback when you don't control the build, for example when assessing software from a supplier, but static analysis has limits.
For software you build yourself, generate at build time. If you need a check on the result, or you receive software from others, use post-build analysis as a second source. Whatever you choose, record it in the SBOM, so recipients know how much to trust it.
Generate the SBOM with a tool wired into your build or CI pipeline, and let it run on every build. Manual spreadsheets drift almost immediately, because dependencies change with every update, and a stale inventory is worse than none when you are responding to a new vulnerability.
In practice this means adding a generation step after dependency resolution, so the tool reads the exact versions that were resolved rather than the loose version ranges in a manifest. Output it in SPDX or CycloneDX, and have the tool record its own name and version in the file, which are fields in CISA's 2026 baseline. Treat the SBOM as a build artifact, stored next to the package or image it describes.
Most of the components in a typical application are not ones your team chose. They are dependencies of dependencies. In the example from the previous section, an app declares one package, Express, and its SBOM already contains a chain of three components, with Express itself pulling in more than were shown.
The 2021 NTIA baseline asked only for top-level dependencies, with enough detail to trace the rest. CISA's 2026 guidance says an SBOM should include information for all components, including transitive dependencies, and sets no minimum depth. The reasoning is practical. If a newly reported vulnerable component isn't listed, a consumer should be able to conclude they aren't affected, and that only works if the list is complete.
To capture transitive dependencies, generate from a lockfile or from the resolved dependency tree, not from the top-level manifest. Where you cannot see all the way down, say so. The guidance asks authors to mark information they don't know separately from information they are deliberately withholding, so an incomplete list is not mistaken for a complete one.
Check every generated SBOM before you share it. Validation has three layers.
First, check that the file is valid against the format's schema, so other tools can parse it. Second, check completeness against the minimum elements: every component should have a name, version, identifier, hash, and license, or an explicit "unknown" where the data isn't available, and the document should carry its author, tool, generation context, and timestamp. Third, spot-check accuracy. Compare the component count with your lockfile or build output, and confirm that a few hashes match the real artifacts. CISA's guidance suggests that consumers can verify coverage by checking open-source repositories or running binary analysis to find components the SBOM doesn't list, and you can run the same checks on your own output.
Watch for fields filled with placeholders such as "unknown" on a large share of components. It usually means the generator couldn't resolve the data, and the fix belongs in the tooling, not in the file. If your SBOM is meant for customers or regulators, sign it so recipients can confirm it hasn't been altered.
Produce one SBOM for each software version, and generate a new one whenever you issue a new build or release. CISA's guidance also asks for a revised SBOM when you discover new details about the components or need to correct an error. The new file should replace the old one's status, not silently overwrite it, so keep an SBOM version identifier and the previous files.
Store each SBOM next to the release it describes, and decide how people will get it. Common patterns include shipping it with the product, serving it from a version-specific URL, exposing it through an API, or publishing it in a repository. Restrict access where needed, but make sure the teams that use it for vulnerability management can reach it quickly.
Finally, feed the stored SBOMs into your vulnerability process. An SBOM that nobody searches for when an advisory arrives has not done its job.
Generators fall into a few categories, and most teams use more than one. The choice matters less than where the tool sits in your pipeline.
Package-manager and build-system plugins read your resolved dependencies directly during the build. They are usually free, accurate for the ecosystem they support, and the simplest route to build-time SBOMs.
Software composition analysis scanners inspect source trees and dependency files across several languages, and typically add vulnerability and license data. They are the most common starting point for mixed-language projects.
Container and image scanners produce an SBOM from a built image, covering operating-system packages as well as application libraries.
Binary analysis tools examine compiled software when no source or build access exists. They help with supplier software and legacy components, but are limited by static analysis.
Commercial SBOM management platforms wrap generation, storage, validation, sharing, and monitoring in one product. They suit larger programs with many applications and customer-facing requirements, at the cost of licensing and some lock-in.
Open-source tools typically cover generation well, and commercial platforms mostly add management, workflow, and reporting. Test any candidate by generating an SBOM for a project you know well and checking it against the validation steps above.
SBOM management means treating each SBOM as a living record: give it an owner, regenerate it with every release, check it against new vulnerability data, and share it with customers deliberately. An SBOM that is created once and filed away stops describing your software the next time a dependency changes.
Assign a named owner for the SBOM program, and make the generation step part of the build so it doesn't depend on anyone remembering. In most organizations the owner sits in product security or engineering, with the build or platform team responsible for the pipeline and security responsible for what happens to the data. The point is that someone is accountable when an SBOM is wrong, late, or missing.
The cadence has two parts. The first is per release. CISA's guidance asks for an SBOM for each software version or update, and for a revised SBOM when you discover new details about the components or need to correct an error. That means a new file with every build that changes the component list, plus corrections when you find mistakes. The second part is ongoing: re-check existing SBOMs against new vulnerability information on a regular schedule, because a component that was clean at release can be flagged months later. CISA's guidance sets the release cadence. The monitoring frequency is a judgment call. Many teams run it daily or continuously through automated tooling, and the right interval depends on how fast you can act on what it finds.
Keep the history. Retain earlier SBOM versions and record an SBOM version identifier so you can answer what was in a specific release, including ones customers are still running.
An SBOM tells you what is in your software, and a scanner tells you which of those components have known vulnerabilities. You need both. The scanner matches component identifiers, such as package URLs or CPEs, against vulnerability databases, and it re-runs as new advisories appear. The SBOM is what makes that matching possible across every product at once.
The pace of exploitation is the reason this matters.
Verizon's 2026 Data Breach Investigations Report found vulnerability exploitation was the leading initial access vector, at 31% of breaches with a known entry point, the first time it has led in the report's history. When new flaws are exploited that quickly, being able to search your inventory the same day is a real advantage.
Scanning produces a long list, and many findings won't be exploitable in your product. That is where a Vulnerability Exploitability eXchange (VEX) document helps. VEX is a supplier's statement about whether a specific vulnerability actually affects a specific product.
Typical statuses are not affected, affected, fixed, and under investigation, and a "not affected" claim should include a reason, such as the vulnerable code not being present or reachable. CISA's guidance describes VEX and the Common Security Advisory Framework (CSAF) as ways to narrow the set of at-risk components and avoid unnecessary effort when a trusted source has judged that potential risk isn't real.
In practice: generate the SBOM, scan it, triage the findings, and record your conclusions as VEX statements. Publish those statements to customers alongside the SBOM, so they don't have to repeat your analysis. Update them as the facts change, since a vulnerability marked "under investigation" today will need a different status once you've decided.
Share an SBOM when a customer, regulator, or contract needs it, and decide the delivery method in advance. Whether you must share it at all varies. The EU Cyber Resilience Act, for example, requires manufacturers to document their components but doesn't oblige them to make the SBOM public. Contracts and procurement rules are often what drive sharing in practice.
For timing, the simplest approach is to provide the SBOM with each release, so customers always have the version that matches what they are running. On request, provide the SBOM for a version they already have. CISA's guidance says SBOMs should be available promptly to those who need them.
For delivery, CISA's draft lists several workable patterns: ship the SBOM with the installation, host it at a version-specific URL, expose it through an API, or publish it in a repository. Access controls can limit who outside your organization can see it, but they shouldn't get in the way of customers who need it for their own security tooling. Sign the file, so recipients can check that it came from you and wasn't altered.
Be careful with redaction. If you withhold component information, say that you withheld it and why, rather than leaving a silent gap. CISA's guidance distinguishes information you don't have from information you chose not to share, and asks authors to give recipients a way to ask about redacted security-relevant data. Recipients may treat an SBOM with essential dependencies redacted as incomplete.
SBOM requirements depend on where and what you sell. In the US, federal agencies now decide for themselves whether to require SBOMs. In the EU, the Cyber Resilience Act makes an SBOM mandatory for products with digital elements, with full application from December 11, 2027. In the US medical device market, the FDA requires one in premarket submissions for connected devices.
Executive Order 14028 (2021) started the federal SBOM push, and OMB memos M-22-18 and M-23-16 turned it into procurement rules, including a common secure-software attestation form. On January 23, 2026, OMB's memo M-26-05 rescinded both memos and replaced them with a risk-based approach that leaves the details to each agency.
SBOMs survived that change, though as an option rather than a universal rule. Under M-26-05, agencies must still keep a complete inventory of their software and hardware, and they may write contract terms that require a producer to provide a current SBOM on request. For cloud platforms, the memo says that term should call for an SBOM of the runtime production environment. Use of the attestation form and of the SBOM terms is optional. The memo points agencies to CISA's minimum elements, which CISA finalized in July 2026. For vendors, the practical result is that SBOM requests now come from individual agencies and contracts, not a single government-wide rule.
The Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers of products with digital elements to identify and document the components in their products. Annex I, Part II, point (1) specifies that this includes an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. Annex VII places the SBOM in the product's technical documentation, which authorities can request when checking compliance.
Two dates matter. The manufacturer reporting duties in Article 14, which cover actively exploited vulnerabilities and severe incidents with a 24-hour early warning, a 72-hour notification, and a final report, apply from September 11, 2026, including for products already on the market. The regulation as a whole, including the Annex I requirements, applies from December 11, 2027. You can't report on a component you haven't listed, so the SBOM underpins the reporting duty even before full application.
Manufacturers aren't required to publish the SBOM. If a manufacturer decides to make it available to users, Annex II requires them to tell users where to find it. Fines for breaching the essential requirements reach €15 million or 2.5% of worldwide annual turnover, whichever is higher.
Section 524B of the Federal Food, Drug, and Cosmetic Act requires manufacturers of "cyber devices" to include an SBOM in their premarket submissions. A cyber device includes software, can connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. The requirement applies to 510(k), PMA, PDP, De Novo, and HDE submissions, as well as modifications that must meet section 524B.
The SBOM must cover commercial, open-source, and off-the-shelf software components. The FDA's final guidance, issued June 27, 2025 and replacing the September 2023 version, says the SBOM should be machine-readable and contain the baseline attributes from the NTIA's 2021 SBOM framework. It also asks for each component's support status and end-of-support date. If you can't provide some SBOM information, the guidance expects you to justify the omission in the submission. Note that the guidance predates CISA's 2026 update and still points to the NTIA baseline.
These rules follow the market, not your headquarters. If you place products with digital elements on the EU market, the CRA applies to you. If you sell to US federal agencies, your contracts may require an SBOM. If you export a connected medical device to the US, the FDA's requirement applies to your submission. The EU framework also allows non-EU manufacturers to appoint an authorized representative, though importers carry the EU verification duties either way. Local obligations, such as the UAE cybersecurity regulations, apply in addition to these regimes, and none of the three replaces them.
For most vendors, the efficient route is to build to the strictest standard once. Generate an SBOM at build time in SPDX or CycloneDX, include transitive dependencies, capture the CISA 2026 data fields, produce a new one for every release, and keep it in your technical file. That one process satisfies the CRA's minimum, supports agency requests, and adds the support-status fields the FDA asks for on top. With the reporting duties already live and full application about a year away, the useful time to start is before a customer asks.
The most common SBOM mistakes are generating it once and never updating it, listing only direct dependencies, leaving version and supplier fields empty, and never connecting the file to vulnerability management. Each one produces an SBOM that looks compliant but fails when you need it, which is usually the day a new vulnerability is announced.
An SBOM describes one specific build. Dependencies change with every update, so a file generated at launch and left in a folder stops matching the software within weeks. A stale SBOM is risky because it still looks authoritative. A team searching it during an incident may conclude a vulnerable library isn't present when it was added two releases ago.
CISA's guidance expects each software version or update to have its own SBOM, and it asks authors to issue a revised one when they discover new details about the components or find an error. The fix is to automate generation in the build pipeline, so every release produces a new file without anyone having to remember to run it. Keep the earlier versions, so you can still answer what shipped in a release a customer is running.
Direct dependencies are the packages your team chose. Most of the risk sits in the packages those packages pull in. In the example from earlier in this article, an application declaring a single dependency, Express, already reaches a chain of three components, and Express itself has more branches than that example shows. An SBOM that stops at the first layer misses most of what your software contains.
The gap between standards shows how much this matters. The EU Cyber Resilience Act sets its legal floor at the top-level dependencies, and the 2021 NTIA baseline asked for the same depth. CISA's 2026 guidance goes further: an SBOM should cover all components, including transitive dependencies, with no minimum depth. The reason is practical. If a newly reported vulnerable component isn't listed, a recipient should be able to conclude they aren't affected, and that conclusion is only safe when the list is complete. So meet the higher bar even where the law asks for less, generate from a lockfile or the resolved dependency tree, and where you can't see the full depth, label the gap as a known unknown instead of leaving readers to assume completeness.
An SBOM entry without a version can't be matched reliably to a vulnerability, because most advisories apply to specific version ranges. An entry without a machine-processable identifier, such as a package URL, is nearly as bad, since scanners use the identifier to look up the component. Missing producer information leaves the next question unanswered: who do you contact when this component has a flaw?
These gaps often appear because the generator couldn't resolve the data, and the file is then filled with blanks or placeholders. A high share of "unknown" values across a file is a signal to fix the tooling or the source data, not something to ship as is. Where information genuinely isn't available, say so explicitly. CISA's guidance asks authors to mark a component of unknown origin as unknown provenance instead of omitting the field, and it asks them to distinguish information they don't have from information they chose to withhold. A labeled gap tells the reader what to do next. A silent one looks like completeness.
An inventory that nobody searches doesn't reduce risk. The value of an SBOM comes from what you do with it: match its components against vulnerability databases, re-check them as new advisories appear, and route the findings to the people who can fix them. CISA's guidance makes the same point, describing the SBOM alone as data about software components and saying that analysis turns it into insight about risk.
Connect the pipeline end to end. Generate the SBOM at build, load it into a scanner or vulnerability management tool, and set a schedule for re-checking stored SBOMs against fresh vulnerability data. Then record what you decide about each finding, using VEX statements when a vulnerability doesn't actually affect the product, so every customer doesn't repeat the same analysis. If your SBOM program ends with a file in storage, you have documentation, not a security control.
An SBOM fits into a security program as the inventory layer: it tells your other controls what to examine. It doesn't find flaws on its own. CISA's guidance says an SBOM won't resolve every software security and supply chain concern, but it is a necessary step toward risk-informed decisions.
In development, the SBOM is generated as part of the build, which makes it a natural output of a DevSecOps pipeline. The same pipeline can scan the component list on every build and block releases that carry serious known issues.
For existing systems, the SBOM tells your assessors where to look. A vulnerability assessment can use the component inventory to prioritize which applications and libraries carry the most exposure. A component list shows what is present, though.
Source code review examines how your own code handles data and logic, which no inventory can show, and penetration testing tests whether a flaw in a listed component can actually be exploited in your environment.
Newer kinds of software need more than the baseline. CISA notes that AI systems and SaaS may require more than the minimum elements, so for model and data dependencies, see how AI supply chain security extends the same inventory idea.
The practical rule is simple. Use the SBOM to know what you have, then use scanning, review, and testing to find out what is wrong with it.
Start with one product you ship. Generate its SBOM from the build, and make sure it includes transitive dependencies, hashes, and licenses. Connect the file to your vulnerability scanning before you share it with anyone, so the first time you search it isn't during an incident. Once that works, repeat it across your other products, and treat any customer or regulator request as a check on whether your SBOMs are ready to hand over.
It depends on where and what you sell. The EU Cyber Resilience Act requires an SBOM for products with digital elements, with full application from December 11, 2027. The FDA requires one in premarket submissions for connected medical devices. In the US, federal agencies decide individually whether to require SBOMs in contracts.
An SBOM is an inventory of the components in your software. A vulnerability scan checks those components, or the running system, against databases of known flaws. The SBOM says what is present, and the scan says which parts have known problems. A scan is only as complete as the inventory it reads, so the two work best together.
Either is acceptable, because CISA's 2026 guidance names both and asks organizations to accept any widely used, interoperable format. Choose the one your build and scanning tools support natively, or the one a customer or regulator requests. SPDX is an ISO standard with roots in license compliance, while CycloneDX is security-oriented.
Not as a general rule. The EU Cyber Resilience Act doesn't oblige manufacturers to publish an SBOM, and CISA's guidance says access controls may limit sharing with outside parties. Customers who need it for their own security work should still be able to get it promptly. If you decide to share it, say where users can find it.
Generate a new SBOM for every software release or update, because each version has its own component list. Also issue a revised one when you find errors or learn new details about the components. Between releases, re-check stored SBOMs against fresh vulnerability data on a regular schedule, since flaws are disclosed after software ships.
An SBOM lists what is inside a product. A Vulnerability Exploitability eXchange (VEX) document is a supplier's statement about whether a specific vulnerability actually affects that product, such as not affected, affected, fixed, or under investigation. Together they let customers focus on findings that carry real risk instead of every flagged component.