Skip to main content
Cyber Risk Council
Category: Third-Party & Supply Chain Risk

Software Bill of Materials

Also known as: SBOM, software bill of materials, SBOM inventory
Simply put

A Software Bill of Materials (SBOM) is a detailed list of the components that make up a piece of software, much like a list of ingredients on a food label. It typically includes the open source and third-party libraries, packages, and other elements used to build an application, so organizations can understand what is inside the software they use or produce. This visibility helps teams manage security and supply chain risks associated with those components.

Formal definition

An SBOM is a formal, often nested inventory record documenting the components used to build software and the supply chain relationships among them. As defined in Section 10(j) of Executive Order 14028, it is a formal record containing the details and supply chain relationships of the various components used in building software. In practice, an SBOM enumerates third-party and open source libraries, artifacts, package versions, licenses, and scripts, supporting software supply chain risk management, vulnerability identification, and license compliance. An SBOM provides an inventory and does not by itself remediate vulnerabilities or guarantee compliance; its value depends on accuracy, completeness, and how it is maintained and consumed.

Why it matters

Modern software is rarely built from scratch. Applications are assembled from open source libraries, third-party packages, and reused components, which means an organization's risk exposure is inherited from code it did not write and may not fully understand. A Software Bill of Materials provides the visibility needed to answer a deceptively simple question: what is actually inside the software we use or produce? Without that inventory, teams cannot reliably determine whether a newly disclosed vulnerability affects them, nor can they respond quickly when it does.

The significance of SBOMs has been reinforced at the policy level. CISA describes the SBOM as a key building block in software supply chain risk management, and Executive Order 14028 formally defined it as a record of the components and supply chain relationships used in building software. This reflects a broader recognition that software supply chain risk is a governance and risk-management concern, not merely a technical one. For security leaders, an SBOM supports vulnerability identification and license compliance efforts, but it is an inventory rather than a remedy.

It is important to set expectations correctly. An SBOM does not by itself remediate vulnerabilities or guarantee compliance. Its value depends on accuracy, completeness, and how consistently it is maintained and consumed within existing processes. An SBOM that is generated once and never updated, or that is never actually used to drive decisions, provides limited protection. The document is only as useful as the organizational practices built around it.

Who it's relevant to

Security and risk leaders (including virtual and fractional CISOs)
For a virtual or fractional CISO, the SBOM is a governance and risk-management instrument rather than a hands-on operational tool. It supports the strategic work of understanding third-party and open source exposure across the software an organization uses or produces. A vCISO can advise on establishing SBOM practices, integrating them into vulnerability management, and setting policy, while accountability for acting on the resulting findings and for security decisions typically remains with the client organization and its officers. The value of any such advisory engagement depends on organizational maturity and on whether the SBOM is actually maintained and consumed.
Software producers and development teams
Organizations that build software are increasingly expected to produce SBOMs so that customers and downstream consumers can understand what components are inside a product. Development and application security teams generate and maintain the inventory as builds change, and use it to identify affected components when vulnerabilities are disclosed. The SBOM also supports license compliance by making third-party and open source components visible.
Software buyers and procurement functions
Organizations acquiring software can request an SBOM to gain visibility into the third-party and open source components they are inheriting. This supports supply chain risk assessment during procurement and helps determine exposure when new vulnerabilities emerge. Buyers should recognize that receiving an SBOM provides inventory visibility but does not guarantee that the software is free of vulnerabilities or fully compliant; the document is a starting point for informed risk decisions.
Compliance and governance stakeholders
SBOMs are relevant to teams responding to policy expectations such as those reflected in Executive Order 14028 and related NIST guidance on software supply chain security. These stakeholders should distinguish between supporting readiness and asserting compliance: an SBOM contributes to supply chain transparency but does not by itself satisfy any regulatory or certification requirement.

Inside SBOM

Component Inventory
A structured list of the software components, libraries, and dependencies that make up an application, including both direct and transitive dependencies.
Component Metadata
Identifying details for each component, such as supplier or author, component name, and version, which support traceability and matching against known vulnerability data.
Version Information
The specific version of each listed component, which is often essential for determining whether a component is affected by a disclosed vulnerability.
Dependency Relationships
Information describing how components relate to one another, including which components depend on others, so that the overall composition of the software can be understood.
License Information
Details about the licensing terms associated with components, which may support governance, legal review, and open-source compliance considerations.
Standardized Format
SBOMs are commonly expressed in machine-readable formats intended to support consistent generation, exchange, and automated analysis; the specific format may vary by tool and provider.

Common questions

Answers to the questions practitioners most commonly ask about SBOM.

Does having an SBOM mean my software is secure or free of vulnerabilities?
No. An SBOM is an inventory of the components, libraries, and dependencies within a piece of software; it does not by itself remediate, patch, or eliminate vulnerabilities. Its value lies in visibility, knowing what is in your software so you can identify when a component becomes vulnerable. Security depends on how the organization acts on that information through vulnerability management, patching, and risk decisions. Treating an SBOM as evidence of a secure product rather than as an input to ongoing risk management is a common mistake an experienced security leader would correct.
Is producing an SBOM a purely technical, one-time task the engineering team can check off?
Not typically. While generating an SBOM often involves technical tooling within the build or development pipeline, its ongoing usefulness depends on governance, defining who maintains it, how often it is regenerated, and how it feeds into vulnerability response and procurement decisions. Software components change with each release, so an SBOM is generally treated as a living artifact rather than a one-time deliverable. Framing it solely as an engineering task, rather than as part of a broader risk and supply chain governance function, tends to limit its value.
How can a virtual CISO help an organization establish an SBOM practice?
A virtual CISO typically provides strategy and governance guidance rather than hands-on implementation. This may include helping define the objectives for SBOM adoption, advising on where it fits within existing risk and vulnerability management programs, recommending policy and process, and helping prioritize based on organizational maturity. Actual generation of SBOMs, tool configuration, and pipeline integration generally remain with the engineering or security operations teams unless explicitly contracted. The value of this guidance often depends on client cooperation and access to relevant technical stakeholders.
What formats are commonly used for SBOMs, and does the choice matter?
Several standardized, machine-readable formats are commonly used to represent SBOM data. The choice can matter for interoperability, particularly when sharing SBOMs with customers, vendors, or tooling that expects a specific format. In many engagements, a security leader will advise selecting a format that aligns with the organization's toolchain and the expectations of partners or regulators it works with. Because format support and requirements may vary by provider and context, this is often a decision worth validating against your specific downstream uses rather than assuming one universal standard.
How often should an SBOM be updated?
Because software components change over time, an SBOM is generally regenerated when the software itself changes, such as with new builds, releases, or dependency updates. The appropriate cadence often varies by the organization's release frequency, risk tolerance, and any contractual or regulatory expectations it operates under. A practical approach many security leaders recommend is tying SBOM generation to the build or release process so the inventory stays current, rather than treating it as a periodic manual exercise that risks drifting out of date.
How does an SBOM support compliance or customer requirements?
An SBOM can support transparency and readiness efforts by providing documented visibility into software components, which may help satisfy certain customer, contractual, or regulatory expectations around supply chain transparency. However, an SBOM on its own does not guarantee compliance or certification against any framework; it is typically one input among many. The specific requirements vary by industry, customer, and applicable regulation, so organizations should confirm what is actually expected of them rather than assuming an SBOM alone satisfies a given obligation.

Common misconceptions

An SBOM is a technical artifact that a virtual CISO produces and maintains directly as a hands-on operational task.
SBOM generation and maintenance are typically operational activities performed by development, engineering, or tooling teams. A virtual CISO generally advises on governance, policy, and how SBOMs fit into third-party and vulnerability risk management rather than executing the hands-on generation, unless such work is explicitly contracted.
Having an SBOM guarantees that software is secure or free of vulnerabilities.
An SBOM provides visibility into components but does not by itself remediate risk or ensure security. Its value depends on how the inventory is used, kept current, and cross-referenced against vulnerability information, and outcomes such as breach prevention cannot be guaranteed.
An SBOM is a one-time deliverable that stays accurate over time.
Software composition changes as dependencies are updated, added, or removed, so an SBOM can become outdated quickly. Its usefulness typically depends on regular regeneration and integration into ongoing development and risk processes.

Best practices

Treat SBOM adoption as a governance and risk management initiative, defining clear ownership, policy, and scope rather than assuming it is purely a technical exercise.
Integrate SBOM generation into development and build processes so the inventory is refreshed as software components change, rather than produced as a one-time artifact.
Use consistent, machine-readable formats where practical to support automated analysis and exchange with customers, suppliers, or partners.
Cross-reference SBOM contents against known vulnerability information to prioritize review and remediation, recognizing that this depends on accurate and current version data.
Clarify in any engagement scope whether SBOM-related work is advisory, such as guiding policy and integration into third-party risk management, or hands-on, since operational tasks are typically out of scope for a virtual CISO unless explicitly contracted.
Recognize that legal and organizational accountability for acting on SBOM findings, including remediation decisions, generally remains with the client organization and its officers.