On this page
What Is a Software Bill of Materials (SBOM)?
An SBOM is a machine-readable inventory of every component in your software. Learn what it contains, its formats, and why it's increasingly required.
Quick answer
- An SBOM is a machine-readable list of every component in a piece of software — libraries, versions, and their relationships.
- It answers “what’s actually in this app?” so you can react when a component turns out to be vulnerable.
- The two dominant formats are CycloneDX and SPDX, and regulations are increasingly requiring SBOMs.
What is an SBOM?
A software bill of materials is a formal, machine-readable inventory of the components that make up a piece of software. Like a bill of materials in manufacturing, it lists what went into the product: the open-source libraries, their versions, their dependencies, and often their licenses. The point is that you can’t assess the security of software whose ingredients you can’t see.
What an SBOM contains
A typical SBOM records each component’s name, version, supplier, and unique identifier, plus the relationships between components. It also captures licenses and, ideally, known vulnerabilities when paired with a scanner. Standards like CycloneDX and SPDX define the exact format so tools can exchange SBOMs automatically.
Why it matters
When a vulnerability is disclosed in a library — like a high-profile logging library flaw — the first question every team asks is “are we affected?” An SBOM turns that from a manual code search into a query. This is why SBOMs have moved from niche practice to compliance requirement in the US and EU, and why they pair naturally with CVE data.
Where this bites vibecoders
AI-generated projects pull in dozens of transitive dependencies nobody reads, so “what’s in my app?” is genuinely unanswerable by hand. An SBOM generated automatically in CI gives you the ingredient list for free — and the moment a scanner flags a vulnerable transitive dependency, you have the exact component and version to fix. For a vibecoder, an SBOM is cheap insurance against a supply chain attack you can’t see.
Where AI coding assistants get this wrong
- Adding dependencies without awareness of their transitive tree.
- Never suggesting an SBOM or dependency inventory as part of a project.
- Pinning nothing, so “what version?” is answered only at install time.
Checklist
- Generate an SBOM as part of your build or CI.
- Use a standard format (CycloneDX or SPDX) so tools can consume it.
- Pair the SBOM with a vulnerability scanner.
- Re-generate on every release, not once.
- Review for unexpected or unlicensed components.
FAQ
What is the difference between CycloneDX and SPDX?
Both are SBOM standards. CycloneDX emphasizes security use cases and is common in application security tooling; SPDX, from the Linux Foundation, emphasizes license compliance and is an ISO standard. Many tools can output both.
Is an SBOM the same as a vulnerability scan?
No. An SBOM is an inventory of components; a vulnerability scan checks components against known vulnerabilities (like CVEs). They’re complementary — the SBOM says what you have, the scanner says what’s wrong with it.
Do I need an SBOM for a small project?
Legally, maybe not, but practically yes: it’s a one-command output that tells you your ingredients, and it’s trivial to automate. See How to Generate an SBOM for Your Project.