SBOM (Software Bill of Materials): What It Is and Why You Need One

If someone asked you to list every single ingredient in the software you shipped last week — every open-source library, every transitive dependency five levels deep, every version and license — could you produce that list in the next five minutes? For most teams the honest answer is no. A software bill of materials (SBOM) exists to change that answer to yes. An SBOM is a complete, structured inventory of the components that make up a piece of software: the direct dependencies you chose, the transitive ones they dragged in, the versions of each, the licenses attached, and the relationships that tie them together. Think of it as the nutrition label and ingredient list for your application, except it's machine-readable and built to be queried.

That definition sounds modest until you sit with the implications. Modern applications are assembled far more than they are written from scratch. The code your team authored is often a thin layer on top of hundreds or thousands of open-source packages. When you don't have an accurate inventory of that layer, every supply-chain question becomes an archaeology dig. An SBOM is the artifact that makes the invisible visible.

What an SBOM actually contains

At minimum, a useful SBOM records each component's name, its supplier or origin, a precise version, a unique identifier (such as a package URL or CPE), the license, and how components depend on one another. That last part — the dependency relationships — is what separates a real SBOM from a flat list of package names. Knowing that your service includes a logging library is helpful; knowing that the logging library is pulled in transitively through a web framework you can't easily swap out is what lets you plan a fix.

A strong SBOM is also cryptographically referenced to the exact build it describes. An inventory that doesn't correspond to a specific, immutable artifact is a guess. The value comes from being able to say: this SBOM describes this container image, built from this commit, at this moment.

Why the software bill of materials matters now

Three forces have pushed SBOMs from a nice-to-have into an operational necessity.

Supply-chain transparency. High-profile incidents over the past several years made it painfully clear that organizations often don't know what they're running. The OWASP Top 10 for 2025 reflects this reality: software supply chain failures are now called out prominently under A03, a broadening from the earlier "vulnerable and outdated components" framing. You cannot secure what you cannot enumerate, and an SBOM is the enumeration.

Fast impact analysis. This is the day-to-day payoff. When a serious vulnerability is disclosed in a widely used library, the clock starts immediately. Teams without SBOMs spend the first hours — sometimes days — just figuring out where the affected component lives. Teams with a current SBOM index run a query: which of our artifacts include this package at an affected version? The difference between those two experiences is the difference between a measured response and a fire drill.

License compliance. Every dependency carries license terms, and those terms have real obligations — attribution, source disclosure, restrictions on redistribution. An SBOM that captures license metadata lets legal and engineering see obligations across the whole portfolio rather than discovering a problematic license during due diligence for an acquisition. (For a deeper treatment, see our guide to open-source license compliance.)

Regulatory drivers. The policy landscape is moving toward SBOMs as an expectation. In the United States, Executive Order 14028 directed agencies and their software suppliers toward providing SBOMs, and NTIA published a set of minimum elements describing what a baseline SBOM should contain and how it should be delivered. In the European Union, the Cyber Resilience Act (CRA) is pushing manufacturers of digital products toward documenting components and managing vulnerabilities across a product's lifecycle. These frameworks differ in scope and timeline, and the details continue to evolve — the practical takeaway is directional rather than absolute: the expectation to know and disclose what's in your software is becoming a baseline, not a differentiator.

The standard formats: SPDX and CycloneDX

You don't have to invent a format. Two open standards dominate, and both are widely supported.

SPDX (Software Package Data Exchange) originated with a strong focus on license and compliance metadata and is an ISO-standardized format. It's expressive and rigorous, which makes it a natural fit when license clarity and formal provenance are the priority, and it's common in organizations that need to exchange component and licensing information across a broad ecosystem.

CycloneDX grew out of the application security community and was designed with security use cases front and center. It represents vulnerabilities, services, and dependency relationships cleanly, and it pairs naturally with VEX. Teams that think of the SBOM primarily as a security and vulnerability-management tool often gravitate toward it.

In practice the choice is less fraught than it looks. Most SBOM tooling can produce and consume both formats, and the two standards cover overlapping ground. Pick the one that matches your primary use case, but don't agonize — the important decision is to generate SBOMs at all, in a standard format, consistently.

How SBOMs are generated and kept current

The single most important principle: generate SBOMs automatically at build time, from the resolved dependency graph. Building the SBOM after the fact — by scanning a running system or hand-maintaining a spreadsheet — produces something that's out of date the moment it's written and incomplete besides. At build time, your tooling already knows the exact set of dependencies that were resolved and packaged, including the deep transitive ones, so that's the moment of ground truth.

Produce an SBOM per artifact: one for each deployable unit, one for each container image, one for each release. A single monolithic SBOM for "the whole company" is neither accurate nor useful. Fine-grained, artifact-scoped SBOMs are what let you answer precise questions later.

Keeping SBOMs current is then a matter of never treating them as a one-time deliverable. Regenerate on every build. Store each SBOM alongside the artifact it describes and version it the same way. Because a fresh SBOM is produced whenever the artifact changes, currency stops being a discipline you have to enforce and becomes a property of the pipeline. This is the same philosophy behind good open-source vulnerability management: make the safe path the automatic path.

Consuming and managing SBOMs at scale

Generating SBOMs is the easy half. The harder, more valuable half is doing something with them across hundreds of services and thousands of builds. A pile of SBOM files sitting in an artifact store is inventory you can't act on.

At scale you want SBOMs ingested into a central index that you can query across every artifact and environment: show me every image running in production that contains this package below this version. You want continuous matching of that inventory against newly disclosed vulnerabilities, so that a component which was clean when you shipped it gets flagged the day a new CVE affects it. And you want the results routed to the teams who own the affected code, with enough context to prioritize. An SBOM program that stops at generation delivers a fraction of the value; the payoff is in the querying and the continuous re-evaluation.

VEX: saying which vulnerabilities actually matter

Here's a problem SBOMs create by being thorough: a complete inventory, matched against vulnerability databases, surfaces a lot of findings — and many of them don't matter. A vulnerable function may never be called. A component may be present but disabled. A flaw may require a configuration you don't use. Drowning teams in findings that don't apply is how security data becomes noise, and noise is how real issues get missed.

VEX (Vulnerability Exploitability eXchange) is the answer. A VEX document is a companion to the SBOM that communicates the exploitability status of specific vulnerabilities in the context of your product. For each listed vulnerability it can assert a status such as "not affected," "affected," "fixed," or "under investigation," along with a justification. In other words, the SBOM says what's in here and VEX says and here's which of those known issues actually reach you.

This matters enormously for consumers of your software, too. When you ship an SBOM to a customer and a scary CVE appears in one of your listed components, a VEX statement lets you proactively tell them "we're not affected, and here's why" — instead of fielding a wave of anxious support tickets. VEX turns the SBOM from a liability that invites questions into an asset that answers them.

SBOMs for containers and images

Containers are where SBOMs earn their keep, because a container image is a layered stack of things you didn't write: a base image, OS packages, language runtimes, and your application's dependencies on top. An image's real contents are frequently a surprise to the team that built it.

Generate an SBOM for each image as part of the image build, capturing both the OS-level packages and the application-level dependencies, and attach it to the image so it travels with the artifact. That lets you re-scan images already sitting in your registry when a new vulnerability drops, without rebuilding them, and it makes the base-image layer — often the most overlooked source of risk — fully visible. This dovetails with broader Kubernetes image security practices, where knowing exactly what's in each image is the foundation everything else builds on.

Common pitfalls

The SBOM idea is simple; the failure modes are predictable.

Stale SBOMs. An SBOM generated once and never refreshed describes a version of your software that no longer exists. It gives false confidence, which is worse than no SBOM at all. Regenerate on every build.

Incomplete SBOMs. An SBOM that captures direct dependencies but misses transitive ones, or that covers application libraries but ignores OS packages in the container, leaves exactly the blind spots attackers exploit. Depth and coverage are the whole point.

Shelfware. The most common failure isn't technical — it's organizational. Teams generate SBOMs to satisfy a checkbox, file them away, and never query them. An SBOM that no one consults during an incident is a document, not a control. The value lives entirely in operationalizing it.

How SCA produces and operationalizes SBOMs

This is where software composition analysis comes in, and it's why SBOMs and software composition analysis are best understood together. SCA is the practice — and the tooling — that resolves your dependency graph, identifies every component and version, maps licenses, matches everything against vulnerability data, and does it continuously. Generating an accurate SBOM is a natural output of doing SCA well, because the SCA engine already has to build the exact inventory an SBOM describes.

A modern SCA capability closes the whole loop: it generates standards-based SBOMs (SPDX or CycloneDX) automatically at build time for each artifact and image, ingests them into a queryable inventory, continuously re-evaluates that inventory against new vulnerabilities, incorporates VEX so teams see the findings that actually matter, and routes prioritized, actionable results to the people who can fix them. That's the difference between having SBOMs and having an SBOM program.

Rainforest brings SBOM generation and operationalization together in one place, so the inventory you produce at build time becomes a living control you can query the day the next big CVE lands — not a file you have to go hunting for. If you want to see what that looks like across your own repositories and images, explore our software composition analysis platform or book a demo and we'll walk through it with your stack.