The Ingredient List for Software
A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component in a piece of software — every library, framework, and tool, along with its version, license, and origin. Think of it as the nutritional label on packaged food, but for software.
The analogy is precise: just as a food manufacturer must be able to trace every ingredient back to its supplier (so that a contaminated batch can be recalled quickly), a software producer must be able to identify every component (so that a vulnerable library like Log4j can be found and patched across all products within hours, not weeks).
Why SBOMs Matter Now
In May 2021, US Executive Order 14028 ("Improving the Nation's Cybersecurity") mandated that software sold to the US federal government must include an SBOM. This has driven rapid adoption of SBOM tooling across the industry, even for organizations not selling to the government.
When Log4Shell was disclosed, organizations without SBOMs spent days manually searching their codebases for Log4j usage. Organizations with SBOMs queried their inventory in minutes.
SBOM Formats
Two formats dominate:
- SPDX (Software Package Data Exchange): Originated at the Linux Foundation. Supported by GitHub's dependency graph export.
- CycloneDX: Originated at OWASP. Richer security-focused metadata. Widely supported by security tooling.
Generating an SBOM
Open source tools like Syft (by Anchore) can scan a directory or a container image and produce an SBOM in either format from what they find. A companion tool, Grype, then scans that generated SBOM file against vulnerability databases. This decouples SBOM generation from vulnerability scanning — the SBOM gets generated once, at build time, and can be scanned repeatedly against updated vulnerability databases without rebuilding anything.
Senior depth — SBOM attestation: Generating an SBOM is only useful if consumers can trust it. An attacker could generate a false SBOM that omits a vulnerable component. The emerging practice is to sign SBOMs using tools like cosign (from the Sigstore project), creating a cryptographically verifiable attestation that the SBOM was produced by a specific build pipeline at a specific time. This is the foundation of the SLSA (Supply-chain Levels for Software Artifacts) framework.