Software bills of materials (SBOM): the inventory of your own supply chain

What it is

A software bill of materials (SBOM) is the parts list of a software product: packages, versions, suppliers, licenses, checksums, and the relationships between them ("contains", "depends on"). Two formats have become established. According to the project's site, SPDX from the Linux Foundation is a freely available international standard as ISO/IEC 5962:2021; its roots lie in license management. CycloneDX is an OWASP project, standardized as ECMA-424 according to its project site. Besides the SBOM, it also describes bills of materials for services, hardware, and cryptography, as well as the Vulnerability Exploitability eXchange (VEX), a document with which a vendor states whether a reported vulnerability is actually exploitable in its product. In addition, the SLSA framework defines levels for provenance: a statement about which build, from which source, produced the artifact.

Why it matters

When a vulnerability in a widely used library becomes known, the first question is: where does this version run? Without an SBOM, the answer is "rebuild all projects and search them"; with an SBOM, it is a query over stored files. The same inventory answers license questions (attribution, copyleft) and, according to common reports, is increasingly required as a deliverable. However, an SBOM alone does not say whether a component is unmodified and comes from the expected source; that requires provenance.

How to apply

• Generate the SBOM in the release run, from the built artifact (container image, wheel, JAR) and not only from the manifest file: only then do base images, system packages, and bundled components that the manifest does not know about appear.
• Choose one format internally and export the other when needed; both projects maintain tool lists and converters.
• Store the file next to the artifact, with the same version identifier, and sign it if artifacts are signed.
• Regularly check the SBOMs of all shipped versions against vulnerability databases; record matches that turn out not to be exploitable after review as a VEX statement, so that the same match is not re-evaluated every week.
• Formulate license rules as an automated check over the SBOM (permitted, to be reviewed, prohibited licenses).
• Keep lockfiles and hash-verified installations; the SBOM documents, it enforces nothing.

Pitfalls

An SBOM generated from the source manifest differs from the contents of the image. SBOMs age: they apply to exactly one build, not to "the application". Tools often fail to detect copied-in or renamed libraries. A match in a check is a question, not a diagnosis: only checking whether the vulnerable path is reachable in your own product determines urgency, and that is exactly what VEX is for.