Category: Software Supply Chain
Software Bill of Materials
Also known as: SBOM, software BOM, software component inventory
Simply put
A Software Bill of Materials is a structured list of all the components, libraries, and dependencies that make up a software product, similar to an ingredients list for food. It gives developers, vendors, and security teams visibility into what is inside a given piece of software. This inventory is used to help identify known vulnerabilities, manage risk, and understand software supply chain relationships.
Formal definition
An SBOM is a formally structured artifact that enumerates the software components, open source and third-party dependencies, and their relationships within a parent software product or codebase. It functions as a nested inventory, capturing the hierarchical dependency graph of a software supply chain rather than a flat component list. SBOMs are designed to support vulnerability management, license compliance, and supply chain risk analysis by providing practitioners with the component-level data needed to assess exposure when new vulnerabilities are disclosed. The scope of an SBOM typically covers components identifiable through static analysis of source code, build manifests, or binary composition analysis, and may not reflect runtime-loaded components or dynamically resolved dependencies without additional instrumentation.
Why it matters
Modern software products rarely consist of code written entirely in-house. They typically incorporate dozens or hundreds of open source libraries, third-party components, and transitive dependencies, each of which may carry its own vulnerabilities or licensing obligations. Without a structured inventory of these components, security teams have no reliable way to determine whether a given piece of software is affected when a new vulnerability is disclosed, leaving organizations in a reactive posture as they scramble to audit codebases manually.
Who it's relevant to
Software Developers and Engineering Teams
Developers are the primary producers of SBOMs. Engineering teams integrate SBOM generation into build pipelines and CI/CD workflows to produce up-to-date component inventories as software is built and released. Developers also use SBOMs internally to understand their own dependency graphs, identify outdated or vulnerable components, and make informed decisions about dependency selection and maintenance.
Security and Vulnerability Management Teams
Security practitioners use SBOMs as the input for vulnerability management workflows. When a new vulnerability is disclosed, teams with current SBOMs can query their inventories to determine which products and versions contain the affected component, enabling rapid triage and prioritization of remediation efforts rather than manual codebase audits.
Software Vendors and Product Managers
Vendors who distribute software to customers are increasingly expected to provide SBOMs alongside their products. This allows customer security teams to independently assess whether vendor software introduces vulnerable or unlicensed components into their environments, and supports procurement and risk acceptance decisions.
Enterprise Procurement and Risk Teams
Organizations acquiring commercial or open source software use SBOMs as part of due diligence. By reviewing an SBOM before deployment, procurement and risk teams can assess the component-level risk profile of software they are considering adopting, including the presence of components with known vulnerabilities or restrictive license terms.
Compliance and Legal Teams
Legal and compliance functions use SBOMs to verify that software products adhere to open source license obligations. An SBOM that includes license metadata for each component allows teams to identify components whose license terms may conflict with distribution models or impose obligations such as source code disclosure.
Government and Regulatory Bodies
Regulators and government procurement agencies have incorporated SBOM requirements into cybersecurity policy frameworks. Agencies evaluating software for government use reference SBOM availability as an indicator of supply chain transparency and software assurance maturity, making SBOM generation relevant to any organization operating in regulated markets or seeking government contracts.
Inside SBOM
Component Inventory
A enumeration of software components included in the product, covering first-party code, third-party libraries, and open source dependencies, typically identified by name and version.
Unique Identifiers
Standardized identifiers such as CPE (Common Platform Enumeration) or Package URLs (purl) that allow components to be unambiguously referenced across tools, databases, and vulnerability feeds.
Dependency Relationships
The hierarchical or graph-based relationships between components, distinguishing direct dependencies from transitive ones, which affects exposure assessment and remediation scope.
Licensing Information
The license associated with each component, enabling organizations to assess legal obligations, identify license conflicts, and enforce open source policy compliance.
Version and Provenance Data
The specific version of each component along with its origin, such as the package registry or source repository it was obtained from, supporting integrity verification and supply chain traceability.
Known Vulnerability References
In enriched SBOMs, references to known vulnerabilities (such as CVE identifiers) associated with listed components, often populated by correlating component data against vulnerability databases.
Hash or Cryptographic Fingerprint
Checksums or cryptographic hashes for components or the SBOM document itself, used to verify that artifacts have not been tampered with after generation.
Supplier and Author Metadata
Information about the entity that created or distributed each component, which is relevant for assessing trust, evaluating support status, and tracing accountability in the supply chain.
SBOM Format and Specification Version
Metadata indicating which standard format (such as CycloneDX or SPDX) and which version of that format the SBOM conforms to, enabling consistent machine-readable consumption.
Common questions
Answers to the questions practitioners most commonly ask about SBOM.
Does having an SBOM mean my software is secure?
No. An SBOM is an inventory document that lists the components, libraries, and dependencies in a software artifact. It does not assess whether those components are configured securely, whether they are being exploited, or whether the overall application has vulnerabilities. Security requires acting on the information an SBOM provides, such as cross-referencing components against known vulnerability databases and remediating identified risks.
Does an SBOM capture all possible risks in my software supply chain?
Not entirely. An SBOM typically captures declared dependencies and, depending on the tooling and format used, may capture transitive dependencies. However, it generally does not capture runtime behavior, configuration-level risks, infrastructure dependencies, or risks introduced through the build and CI/CD pipeline itself. It should be treated as one input into a broader supply chain risk management program rather than a comprehensive risk assessment.
What SBOM format should I use, and does it matter which one I choose?
The two most widely adopted formats are CycloneDX and SPDX. The choice typically depends on your ecosystem, tooling support, and consumer requirements. CycloneDX is often favored in security-focused workflows and supports richer vulnerability and attestation data, while SPDX has strong roots in license compliance and is an ISO standard. In practice, many organizations support both. Confirm which formats your consumers, regulators, or customers require before committing to one.
How do I generate an SBOM, and when in the development lifecycle should I do it?
SBOMs can be generated using dedicated tools such as Syft, Trivy, or cdxgen, or through build system integrations. They may be produced at multiple stages: at build time from source, from a container image, or from a deployed artifact. Generating at build time from source typically captures the most accurate dependency information, while scanning a container image may surface additional runtime components. Many organizations generate SBOMs as part of their CI/CD pipeline to ensure the output reflects the actual shipped artifact.
How should I store and share SBOMs once they are generated?
SBOMs may be stored alongside release artifacts in artifact repositories, attached to container images using standards such as OCI attestations, or published to a centralized SBOM management platform. For sharing with customers or regulators, SBOMs are typically provided as machine-readable files in CycloneDX or SPDX format. Access controls should reflect the sensitivity of the component information disclosed, as SBOMs can reveal details about internal tooling and third-party dependencies.
How do I keep an SBOM accurate over time as dependencies change?
An SBOM reflects the state of a software artifact at a point in time, so it must be regenerated whenever dependencies are updated, packages are added or removed, or a new release is produced. Automating SBOM generation within the CI/CD pipeline is the most practical approach to keeping it current. Point-in-time SBOMs should be versioned and retained alongside corresponding release artifacts so that historical component data remains available for vulnerability retrospectives and incident response.
Common misconceptions
Generating an SBOM once at release provides ongoing security coverage.
An SBOM reflects the composition of a software artifact at a specific point in time. New vulnerabilities may be disclosed against listed components after generation, so SBOMs require regular updates and continuous correlation against current vulnerability intelligence to remain operationally useful.
Having an SBOM means all included components have been verified as secure.
An SBOM is an inventory document, not a security attestation. It records what components are present but does not itself indicate whether those components are free of vulnerabilities, properly configured, or safe to use. Vulnerability assessment is a separate process that consumes SBOM data as an input.
A single SBOM format works universally across all tools and regulatory requirements.
Multiple SBOM formats exist (including SPDX and CycloneDX), and different tools, consumers, and compliance frameworks may require or prefer specific formats. Organizations may need to produce or translate SBOMs into more than one format to satisfy all stakeholders.
Best practices
Automate SBOM generation as part of the CI/CD pipeline so that every build produces an up-to-date artifact inventory, reducing the risk of stale or manually maintained records.
Use standardized identifiers such as Package URLs (purl) and CPE for all components to ensure that SBOM data can be reliably correlated with external vulnerability databases and consumed by downstream tooling.
Capture both direct and transitive dependencies in the SBOM, since vulnerabilities in transitive dependencies represent a significant and often overlooked portion of actual exposure.
Store SBOMs alongside the artifacts they describe and apply cryptographic hashing or signing to both the SBOM and the components it references, enabling integrity verification throughout the supply chain.
Establish a process for continuously correlating SBOM component data against updated vulnerability feeds (such as NVD or OSV), rather than treating SBOM-based vulnerability analysis as a one-time activity at build time.
Define and enforce an organizational SBOM consumption policy that specifies minimum required fields, acceptable formats, and freshness thresholds for SBOMs received from third-party suppliers.