Software Bills of Materials
A software bill of materials is a machine-readable inventory of the components and relationships in a software product. It helps producers and users understand what a release contains so they can manage security, licensing, and operational risk.
itSoftware supply chain security | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Software Bills of Materials
A software bill of materials, or SBOM, is a formal record of the components in software and their supply chain relationships. Think of it as an inventory tied to a specific product or release. It names what is present and how the parts connect.
That inventory gives software producers, buyers, and operators a shared source of component data. A producer can document what it ships. A buyer can include transparency in acquisition. An operator can ask which products contain a component when new risk information appears.
An SBOM is data, not a security verdict. You gain value when a system consumes the data and connects it to vulnerability advisories, license information, end-of-support data, and internal asset records.
The mental model: a release inventory
Start with the subject. The subject is the product, artifact, or release described by the SBOM. Components sit beneath that subject. Relationships connect direct and transitive components into a dependency graph.
Each component needs stable identity data. Useful records include a component name and version, its supplier or producer, identifiers, hashes, and license information. The SBOM also records document metadata such as its author, creation time, and generation tool.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
Supports
- SBOM definition and value to software producers, choosers, and operators
- Component and document data, including names, versions, identifiers, hashes, licenses, authors, timestamps, tools, and generation context
- Automation, dependency relationships, coverage, known unknowns, updates, distribution, and delivery
- https://www.cisa.gov/sites/default/files/2025-09/joint-guidance-a-shared-vision-of-software-bill-of-materials-for-cybersecurity_508c.pdf
Supports
- Need to consume SBOM data and convert it into insights that drive action
- Correlation with vulnerability, advisory, project, supply chain risk, and end-of-support data
- Concurrent use of SBOM and VEX data
- https://www.cisa.gov/sites/default/files/2024-08/SECURING_THE_SOFTWARE_SUPPLY_CHAIN_RECOMMENDED_PRACTICES_FOR_SOFTWARE_BILL_OF_MATERIALS_CONSUMPTION-508.pdf
Supports
- Enterprise ingestion, correlation, risk analysis, and operational use of SBOM data
- VEX as an assertion about whether a product is affected by a known vulnerability
- An SBOM alone requires consumption capabilities to drive security actions
- https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf
Supports
- VEX as machine-readable product or component status with respect to a vulnerability
- VEX integration with SBOMs, vulnerability databases, and security advisories
- https://spdx.dev/use/specifications/
Supports
- SPDX as an international open standard under ISO/IEC 5962:2021
- Current SPDX specification index and supported historical versions
- https://cyclonedx.org/specification/overview/
Supports
- CycloneDX object model for components, services, dependencies, relationships, and metadata
- Supported JSON, XML, and Protocol Buffers serializations
- Direct and transitive dependency graph representation
- https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-SBOM-en.pdf
Supports
- CycloneDX SBOM production, validation, distribution, and consumption guidance
- Distinction between valid structure and useful, complete content
- Digital signatures as integrity and authenticity evidence rather than proof of inventory completeness
- https://github.com/sindresorhus/awesome
Supports
- Starting index used to discover relevant curated awesome lists
- https://github.com/bureado/awesome-software-supply-chain-security
Supports
- Discovery of the dedicated awesome-sbom list and SBOM ecosystem tools
- Discovery of Syft and Dependency-Track as relevant SBOM projects
- https://github.com/awesomeSBOM/awesome-sbom
Supports
- Curated discovery of Syft, Dependency-Track, Trivy, and OSV-Scanner
- Tool capability categories for SBOM production, analysis, viewing, and related operations
- https://oss.anchore.com/docs/reference/syft/cli/
Supports
- Syft generation from container images and filesystems
- CycloneDX and SPDX output formats
- https://dependencytrack.org/
Supports
- CycloneDX SBOM ingestion and component analysis
- Vulnerability, operational, and license risk evaluation
- https://trivy.dev/docs/latest/target/sbom/
Supports
- CycloneDX and SPDX SBOM input
- Vulnerability and license scanning
- Generator-specific metadata caveat
- https://google.github.io/osv-scanner/output/
Supports
- Package vulnerability output and source reporting
- SPDX and CycloneDX output options