What Is an SBOM? Software Bill of Materials Explained

A software bill of materials, or SBOM, is a structured, machine-readable inventory of every component that makes up a piece of software — every library, package, and dependency, down to their exact versions — the way a manufacturing bill of materials lists every physical part in a product. Its purpose is simple: when a vulnerability is disclosed in some widely used library, an SBOM lets a team answer “do we use this, and where?” in minutes instead of days of manual auditing.

Why this became necessary

Modern applications are assembled, not built from scratch. A single service might pull in hundreds of open-source packages directly, and each of those packages pulls in its own dependencies, and so on — a dependency tree that’s often impossible to reconstruct from memory or from a top-level package manifest alone. When a critical flaw is disclosed in a package buried three or four levels deep in that tree, the organizations that get hurt worst are the ones that don’t know they depend on it at all.

This is exactly the failure mode behind several major incidents in recent software history, where a vulnerability in a small, deeply nested dependency ended up affecting an enormous number of downstream applications that had no direct visibility into their own dependency graph. An SBOM exists to close that visibility gap before an incident forces it open.

What an SBOM actually contains

At minimum, an SBOM lists, for every component in a build:

• The component’s name and exact version
• Its supplier or origin (which registry or repository it came from)
• Its license
• A unique identifier that can be cross-referenced against vulnerability databases
• Its relationship to other components — what depends on it, and what it depends on

Two open, widely adopted formats dominate: SPDX, originally developed for tracking open-source license compliance and later extended to security use cases, and CycloneDX, designed from the outset around application security and dependency risk. Both are machine-readable — the value of an SBOM comes largely from being queryable by tooling, not just readable by a person.

How SBOMs get generated and used

SBOMs are typically generated automatically as part of a build, by scanning a project’s dependency manifests and lockfiles, or by inspecting a built artifact (like a container image) directly to catch anything a manifest alone might miss — pulled-in transitive dependencies, or components baked into a base image rather than declared explicitly. Generating one at build time, as part of the CI/CD pipeline, keeps it accurate as dependencies change from release to release, rather than relying on a document that goes stale the moment it’s written.

Once generated, an SBOM’s main job is being matched against vulnerability feeds. When a new CVE is published for a package, security tooling can check every stored SBOM across an organization’s software inventory and immediately flag which applications include the affected version — turning what used to be a manual, reactive scramble into an automated lookup.

SBOMs and the broader supply chain

An SBOM is one piece of a larger software supply chain security practice, not a complete solution by itself. Knowing exactly what’s in a build doesn’t automatically stop a malicious package from getting into it in the first place — that’s a separate concern closer to typosquatting defenses and dependency provenance verification. An SBOM also doesn’t replace scanning: SAST and DAST look for flaws in code and runtime behavior, while an SBOM tracks what components exist and where they came from. The three are complementary layers, not substitutes for each other.

For container-based deployments, an SBOM is often generated per image, since a container’s dependency surface includes everything baked into its layers, not just what an application’s own package manifest declares — see Docker image layers and caching for how that layered structure comes together and why it can hide dependencies that aren’t obvious from the top-level build file.

Who ends up consuming an SBOM

An SBOM usually has more than one audience. Security teams use it reactively, to check exposure the moment a new vulnerability is disclosed. Compliance and legal teams use it to verify license obligations are being met — an SBOM’s license field exists precisely because mixing incompatible open-source licenses into a single product can create real legal exposure, separate from any security concern. Increasingly, SBOMs are also requested contractually: a customer procuring software, particularly in regulated industries or government contracts, may require a vendor to provide one as a condition of the sale, so the customer’s own security team can assess risk before deployment rather than discovering it after an incident.

That shift — from an internal engineering artifact to something exchanged between organizations — is part of why the SPDX and CycloneDX formats matter as much as they do. A hand-maintained list of dependencies is fine for one team’s internal use; a format that other organizations’ tooling can parse automatically is what makes an SBOM useful as something handed across a vendor relationship.

The takeaway

An SBOM is a complete, structured inventory of everything a piece of software depends on, built specifically so that “are we affected by this vulnerability” can be answered by a query instead of an investigation. It doesn’t prevent vulnerabilities or malicious packages on its own, but it’s the visibility layer that makes every other supply-chain security practice faster and more reliable to act on — and increasingly, it’s table stakes for any organization shipping software that others depend on.