Knowledge base
What is an SBOM?
A Software Bill of Materials is a complete, machine-readable inventory of everything your software is built from. Here is what that means, what goes in one, and why it has become a requirement rather than a nice-to-have.
6 min read · Updated June 26, 2026
What an SBOM actually is
SBOM stands for Software Bill of Materials. The clearest analogy is the ingredients label on packaged food: a Bill of Materials in manufacturing lists every part that goes into a product, and an SBOM does the same for software. It is a formal, machine-readable list of the components your application is assembled from, especially the open-source packages you did not write yourself.
The important word is complete. A modern application has a handful of dependencies you chose directly, and each of those pulls in its own dependencies, which pull in more. These indirect packages are called transitive dependencies, and they are where most surprises live. An SBOM follows that whole graph, not just the top layer.
In practice
A static marketing-style website can declare four or five direct dependencies and still resolve to several hundred packages once the transitive graph is included. The SBOM of this very site lists 512.
What goes inside one
An SBOM is more than a list of names. For each component it records the metadata you need to reason about risk. In 2021 the US Department of Commerce (NTIA) published a baseline set of minimum elements every SBOM should carry:
- Supplier name (who produced the component)
- Component name
- Version of the component
- Other unique identifiers (such as a Package URL or CPE)
- Dependency relationship (what depends on what)
- Author of the SBOM data
- Timestamp (when the SBOM was created)
On top of those, a good SBOM usually carries each component’s license and a cryptographic hash so the exact artifact can be verified. The dependency relationships matter as much as the list itself: knowing that a vulnerable package is buried six levels deep, pulled in by something you do trust, is the difference between a five-minute answer and a week of archaeology.
Worth knowing
The 2021 NTIA seven are the foundation, not the ceiling. CISA published a revised, expanded set of minimum elements in 2025, so the baseline is still moving.
The two standard formats
You do not invent your own SBOM format. Two open standards dominate, and most tools can emit either:
- SPDX: stewarded by the Linux Foundation and an international standard (ISO/IEC 5962:2021). Originally built around licensing and compliance.
- CycloneDX: stewarded by OWASP and ratified as an Ecma standard (ECMA-424). Security-first, with strong support for vulnerabilities and services.
For a practical comparison of the two, see SPDX vs CycloneDX. The short version: pick one, generate it automatically, and be able to produce the other when a customer or regulator asks.
How an SBOM is generated
You do not write an SBOM by hand. Tools generate it by reading your project: your lockfiles and manifests, the built artifact, or a container image. Open-source generators like Syft and cdxgen produce one in seconds, and many build systems can emit an SBOM as a normal build output.
The best place to generate it is in your CI pipeline, on every build, so the SBOM always matches what actually shipped. A document generated once by hand and saved to a wiki is stale the moment the next dependency updates.
The SBOM behind the scan of this site was produced with cdxgen in a single command, with no account required. Generating the document is genuinely the easy part.
Why it matters
An SBOM turns three otherwise painful questions into fast lookups:
- Are we exposed to this vulnerability? When a serious flaw lands (think Log4Shell in late 2021), the first question every security team asks is “do we use the affected package, and where?” An SBOM answers that across every application in minutes instead of days.
- Are we allowed to use this code? Open-source licenses carry obligations. An SBOM surfaces the copyleft components hiding in your tree so legal can see them before a release, not after a dispute.
- Can we prove it? Government buyers, the EU, and the FDA increasingly require an SBOM, and acquirers ask for one during due diligence. Having it ready is the difference between a smooth process and a stalled deal.
Generating one is the easy part
A generator gives you one SBOM, once. The harder, ongoing work is operational: ingesting SBOMs from many tools into one normalized view, keeping them current on every release, turning policy (“no AGPL in shipped code”, “no critical vulnerabilities”) into an automated gate, and prioritizing the findings that actually reach production. That continuous layer, often built on software composition analysis, is what platforms such as FOSSA provide on top of the raw document.
Frequently asked questions
What does SBOM stand for?
SBOM stands for Software Bill of Materials: a machine-readable inventory of every component, especially open-source dependencies, that a piece of software is built from.
Is an SBOM just a list of dependencies?
No. It includes transitive (indirect) dependencies and records metadata for each component such as version, supplier, license, unique identifiers, and how the components depend on one another.
What formats can an SBOM use?
The two dominant open standards are SPDX (an ISO standard stewarded by the Linux Foundation) and CycloneDX (an Ecma standard stewarded by OWASP). Most tooling can produce either.
How is an SBOM generated?
Tools generate it automatically by analyzing your manifests, build, or container image. Open-source options include Syft and cdxgen, and the best practice is to generate it in CI on every build so it stays accurate.
Who needs an SBOM?
Anyone managing open-source risk benefits, and it is increasingly mandatory: software sold to the US government, products under the EU Cyber Resilience Act, and medical devices reviewed by the FDA all require one.
Keep reading
Sources
Part of the software supply-chain field notes on this site. Written by Antoni K Pestka.