If you have read anything about software security in the last few years, you have run into the acronym SBOM. It sounds bureaucratic, and the surrounding regulation makes it sound complicated. The core idea is not. This is a plain-English guide to what a Software Bill of Materials is, what goes in one, and why it has become unavoidable.

The grocery-label analogy

A Software Bill of Materials is, quite literally, an ingredients list for a piece of software. Just as a food label tells you everything inside a packaged product — including the things you would never guess from looking at it — an SBOM tells you every component, library, and dependency inside an application.

The analogy holds further than you would expect. Most of what is in your software, like most of what is in processed food, was made by someone else. Modern applications are assembled far more than they are written: a typical service is 80 to 90 percent third-party open-source code by volume.

What actually goes in an SBOM

At minimum, for each component, an SBOM records:

Supplier — who produced the component.
Component name — what it is called.
Version — the exact version, because vulnerabilities live at the version level.
Unique identifier — a machine-readable ID such as a PURL (package URL) or CPE.
Dependency relationships — what depends on what, including transitive (indirect) dependencies.
Author of the SBOM data — who compiled the inventory.

Those items are the heart of the NTIA "minimum elements," the United States government baseline. Richer SBOMs add license information, cryptographic hashes for integrity, and known-vulnerability data.

Two formats, one idea

You will encounter two dominant SBOM formats: CycloneDX (from OWASP) and SPDX (from the Linux Foundation, and an ISO standard). They differ in structure and emphasis, but both capture the same essential inventory. A good platform reads and writes both; the format matters far less than the discipline of producing one at all.

Why now

SBOMs are not new as an idea — manufacturing has used bills of materials for a century. What changed is regulation and risk:

Executive Order 14028 (2021) required SBOMs from vendors selling software to the United States federal government.
The EU Cyber Resilience Act extends similar expectations to products sold in Europe.
The FDA now expects an SBOM with premarket submissions for connected medical devices.
Enterprise procurement has followed government's lead; "send us your SBOM" is now a routine line in security questionnaires.

Underneath the regulation is a simple risk argument. When the next Log4Shell-scale vulnerability drops, the only teams that can respond quickly are the ones who already know what they ship.

What an SBOM is not

It is worth clearing up two misconceptions:

An SBOM is not a vulnerability scan. It is the inventory you feed into vulnerability analysis. The two are complementary.
An SBOM is not a one-time document. Software changes with every release, so an SBOM is only useful if it is regenerated and kept current.

Getting started

You do not need a compliance program to produce your first SBOM. Point a tool at a Git repository or a lockfile and you will have a CycloneDX or SPDX file in seconds. The hard part is not generating one — it is generating one for every product, keeping it current, and being able to query across all of them when it matters. That is the problem worth solving, and it starts with understanding what the document is for.

What is an SBOM? A plain-English guide to the Software Bill of Materials