An ingredients list for software
A software bill of materials, or SBOM, is a structured list of the components that make up a piece of software: the packages, their versions, their suppliers, their licences and how they relate to one another. It is the ingredients list on the side of the box.
The idea is not new, but it has become urgent. When a serious vulnerability is announced in a widely used library, the first question every organisation asks is whether it is affected. Without an SBOM, answering means searching repositories, asking teams and hoping. With one, it is a query. Customers and regulators increasingly expect suppliers to be able to answer that question quickly, and an SBOM is how you do it.
Two formats, both open
Two open formats dominate. SPDX, maintained under the Linux Foundation, began with a focus on licence information and is published as the international standard ISO/IEC 5962. It is particularly strong at describing licences, copyright and the relationships between files, packages and documents, which makes it a natural fit for compliance work.
CycloneDX, an OWASP project, began with a security focus. It is compact, widely supported by security tooling, and extends naturally to related information such as known vulnerabilities, services and the exploitability of a finding in context. It is often the format of choice in software supply-chain security pipelines.
In practice the two overlap a great deal, and converters exist between them. The more important decision is not which format you choose but whether you generate SBOMs consistently, automatically and accurately. Many organisations produce both, using each where its tooling is strongest.
Generating SBOMs well
An SBOM written by hand is out of date the moment it is saved. The only sustainable approach is to generate it as part of the build, from the same inputs that produce the software itself. A few habits make the difference between a useful SBOM and a decorative one:
- Generate at build time, from lock files and the built artefact, not from a developer's laptop.
- Include transitive dependencies, not only the packages you named directly.
- Record exact versions and package identifiers so vulnerability databases can match them.
- Store each SBOM alongside the release it describes, with the same version number.
- Sign or checksum the SBOM so recipients can trust that it has not been altered.
Using SBOMs, not just producing them
An SBOM sitting in a folder protects nobody. Its value comes from what you do with it. On the security side, SBOMs can be fed continuously into a vulnerability scanner, so that a newly disclosed issue is matched against everything you have shipped, not only what you are building today. On the compliance side, the licence data can be checked against your policy before release, catching a problem when it is cheap to fix.
SBOMs also help with conversations outside engineering. Procurement can request them from suppliers. Operations can use them to plan upgrades. And when a customer asks whether a particular component is in your product, you can answer with evidence rather than reassurance.
Honest limits
An SBOM is only as accurate as the tool that produced it, and tools differ in how well they detect components that were vendored, copied in or built from source. It describes what is present, not whether it is exploitable; that judgement still needs people and context. And an SBOM that includes everything can be overwhelming, so invest in filtering and prioritisation rather than simply generating more data.
None of this is a reason to wait. Start with your most important application, generate an SBOM in both formats, look at what it tells you, and fix the surprises. You will almost certainly find some. That is the point.