Software Bill of Materials (SBOM)

A software bill of materials (SBOM) is a complete inventory of the components that make up an application, much like an ingredients list on food packaging. It records every library, framework, and dependency, including transitive dependencies, with versions, suppliers, and licenses.

How It Works

An SBOM is generated automatically by tools that scan source code, package manifests, or built artifacts and container images. It is expressed in standardized, machine-readable formats, chiefly SPDX and CycloneDX, so it can be shared and processed by other tools.

A typical entry lists a component's name, version, supplier, license, and cryptographic hash, plus its relationships to other components. Once produced, an SBOM can be matched against vulnerability databases to flag known issues identified by CVE, scored using CVSS, and checked against license policies.

SBOMs are most useful when generated as part of CI/CD for every build and stored alongside the released artifact, sometimes with a signed attestation proving provenance.

Why It Matters

Modern software is mostly assembled from open-source and third-party components, so most risk lives in dependencies rather than first-party code. When a critical vulnerability like Log4Shell emerges, organizations with SBOMs can answer "are we affected, and where" in minutes instead of weeks.

SBOMs are central to software supply-chain security and are increasingly required by regulation, including U.S. Executive Order 14028 for software sold to the federal government. They also support license compliance and faster incident response.

An SBOM is only valuable if kept current; a stale inventory gives false confidence.

Related Terms

SBOMs are a foundation of supply-chain security, are cross-referenced with CVE entries and CVSS scores, and feed vulnerability and license management.