SBOM

How it works

An SBOM (Software Bill of Materials) is a machine-readable inventory of every component inside a piece of software: direct dependencies, transitive dependencies, versions, and licenses. Two formats dominate, SPDX (an ISO standard) and CycloneDX (OWASP). It is produced at build time, either by the build system or by an SCA tool reading lockfiles, and it travels with the artifact so a consumer can answer "is the vulnerable version of this library in here" without rebuilding anything.

When it matters

It matters the moment a widely-used library is disclosed and the question becomes organizational rather than technical: which of our hundreds of deployed artifacts contain it. Without an SBOM that is an archaeology project. It also matters commercially, because US federal procurement and a growing set of enterprise contracts now ask for one. Note the boundary with build provenance: an SBOM inventories what is inside the artifact, while a SLSA attestation records how the artifact was assembled. See Verified Builds with SLSA and Sigstore.

Common misconceptions

• "An SBOM is a security control." It is an inventory. It tells you where to look; it neither blocks nor fixes anything.
• "SBOM and SCA are the same thing." SCA is the analysis that scans dependencies and flags known CVEs. The SBOM is the document describing what is there. One is the process, the other is the artifact.
• "Generating it is the work." Generation is a build flag on most toolchains. Storing SBOMs where they can be queried across every deployed artifact is the part teams skip and then need under time pressure.