What is a software bill of materials

Definition

A software bill of materials is a complete, structured list of every component that makes up a piece of software, together with the details that identify each one. A typical SBOM records the name, version, supplier, and license of each component, and the relationships between them. Crucially, it captures not only the direct dependencies an engineer chose, but the transitive dependencies pulled in automatically several layers deep. The term borrows from manufacturing, where a bill of materials lists every part in a finished product. Applied to software, it answers a question many organizations cannot otherwise answer with confidence: what, exactly, is in what we ship.

What an SBOM contains

At minimum, a useful SBOM lists each component with a name, a version, the supplier or author, a unique identifier, and a license. The license field is what turns a security artifact into a license risk artifact. The two widely used machine readable formats are SPDX, maintained under the Linux Foundation, and CycloneDX, maintained under OWASP. Both can be produced and read by standard tooling, which means an SBOM created in one place can be exchanged with a customer, a regulator, or an acquirer without reformatting. The format matters less than the depth: an SBOM that stops at direct dependencies misses the layers where relicensed components tend to hide, a problem rooted in the nature of the transitive dependency tree.

Why a software bill of materials matters for license risk

For a buyer, a software bill of materials is the map that lets you find a relicensed component before it becomes a finding. When a project moves from an open license to source available terms, the change is invisible to you unless you hold a current inventory that records the license state of every dependency with a date. The relicensing wave makes this concrete. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License in August 2023. Redis moved to a source available model in 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. MongoDB moved to the Server Side Public License in 2018. An organization with a current SBOM can search its tree for these names and act. An organization without one learns about the exposure when a vendor or an auditor raises it. Source available is not open source, and only an inventory that is kept current will show you the difference as it happens.

SBOM versus software composition analysis

It is easy to confuse the inventory with the process that builds it. Software composition analysis is the tooling and method that scans code to discover its components, their versions, their licenses, and their known vulnerabilities. The SBOM is the output of that work, the list itself. Composition analysis is how the list is produced and refreshed; the SBOM is what you hold, share, and defend. A regulator may ask for the SBOM. An acquirer may ask for it during diligence. In both cases the same inventory that satisfies the request is the inventory that lets you find a relicensed component early. For the process side, see what is software composition analysis. An SBOM produced once and never updated loses its value quickly, which is why the most useful versions are regenerated continuously rather than assembled for a single audit.