What is an SBOM?

What does SBOM stand for?

SBOM stands for software bill of materials. The term comes from manufacturing, where a bill of materials lists the parts that go into a product. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components.

Most of the code in a modern application was written by someone else, and most of that arrives indirectly: you add one package, and it brings in dozens of transitive dependencies. An SBOM writes all of it down, so you can answer "are we affected?" without reading a single repository.

What does an SBOM contain?

A useful SBOM has two parts: data about the SBOM itself, and data about each component. The 2026 Minimum Elements, published by CISA, the NSA and the FBI with international partners on July 29, 2026, replace the 2021 NTIA list and set the baseline most buyers now refer to.

Part	Fields
About the SBOM	Author and author signature, timestamp, data format name and version, tool name and version, SBOM version, and the generation context
About each component	Name, version, producer, identifiers such as a package URL, hash value and algorithm, license, and dependency relationships

The generation context matters more than it looks. It says when the SBOM was made: before the build, during the build, from the finished artifact or after it. Two SBOMs of the same release can differ for exactly that reason. See SBOM examples for what these fields look like in a real file.

SBOM formats

Two formats cover almost all SBOMs in use. CycloneDX, from OWASP, started in security and also describes vulnerabilities and services. SPDX, from the Linux Foundation, started in license compliance. Both can carry the minimum elements, and most tools write both. See CycloneDX vs SPDX for how to choose.

Why SBOMs matter

• Faster incident response. When a vulnerability like Log4Shell lands, the question is which of your products contain it. With SBOMs that is a search. Without them it is a project.
• Vulnerability monitoring after release. Software that was clean when it shipped can be vulnerable tomorrow. Re-checking stored SBOMs against new advisories catches that without rebuilding anything.
• License risk. Each component's declared license shows copyleft or commercial terms before they reach the product.
• Customer and regulator questions. Buyers increasingly ask for an SBOM in procurement, and several frameworks expect a component inventory.

Who needs an SBOM?

Anyone who ships software, and anyone who has to answer for what is in it. The requirement usually arrives through one of these:

• Medical devices. FDA section 524B requires an SBOM for cyber devices in premarket submissions.
• Products sold in the EU. The Cyber Resilience Act asks manufacturers for an SBOM. See CRA SBOM requirements and tools.
• US federal procurement. The OMB memo M-26-05 of January 2026 lets each agency decide whether to require one, so expect it case by case.
• Payment software. PCI DSS 4.0 requirement 6.3.2 asks for an inventory of bespoke software and its third-party components. It does not prescribe an SBOM, but an SBOM meets the need.

How to generate an SBOM

There are three ways to make one, and the method decides what ends up in the file.

Method	What it reads	Typical gap
Scan the source	Manifests and lockfiles in the repository	Anything the build fetches that no lockfile lists
Scan the output	A finished container image or binary	Compiled code is ambiguous, and build tools leave no trace
Record the build	What the build actually fetched while it ran	Traffic that bypasses the recorder, which should be flagged

Open source generators such as Syft, Trivy and cdxgen use the first two methods. They disagree with each other on the same commit, because each has its own rules for what to read. For the options side by side, see the best SBOM tools.

SBOM vs SCA vs VEX

• An SBOM is an inventory. It says what is there, not whether it is safe.
• Software composition analysis is the analysis. It finds components and checks them for risk, and many SCA tools produce an SBOM along the way.
• VEX is a statement about impact. It says whether a known vulnerability actually affects your product, which cuts the noise an SBOM alone creates.

Generating an SBOM is the easy part

A file nobody reads changes nothing. The value comes from keeping one SBOM per release, monitoring them, and being able to find them when it counts. That work is SBOM management, and SBOM best practices covers how to run it.

How CRACI creates SBOMs

CRACI is a GitHub Actions runner that records every package each job fetches, at every depth of the tree and including packages restored from CI caches. The result is an SBOM of the build that produced the release, with a completeness state that says what the job could not see. It exports as CycloneDX or SPDX, and CRACI keeps re-evaluating it as new vulnerabilities are published. See build-time SBOM generation.

SBOM: frequently asked questions

What is an SBOM in simple terms?

An SBOM is an ingredients list for software. It names every component in a product, with its version, producer and license, in a format machines can read.

What does SBOM stand for?

SBOM stands for software bill of materials.

Why do you need an SBOM?

So you can tell quickly whether a newly published vulnerability affects what you ship, see license risk before release, and answer customers and regulators who ask what is in your product.

What are the two main SBOM formats?

CycloneDX and SPDX. CycloneDX comes from OWASP and started in security. SPDX comes from the Linux Foundation and started in license compliance. Both can carry the minimum elements.

Is an SBOM required by law?

It depends on the product and the market. FDA section 524B requires one for cyber devices, and the EU Cyber Resilience Act asks manufacturers for one. In US federal procurement it is now each agency's decision. For many other companies it is a customer requirement rather than a legal one.

How often should an SBOM be updated?

Generate a new SBOM for every release, because each build can pull in different versions. The SBOM of a release does not change afterward, but you should keep checking it against new vulnerabilities.

Who creates the SBOM?

Usually the team that builds the software, ideally in CI so that each release gets one automatically. Software you buy should come with an SBOM from its supplier.