Modern software is mostly other people’s code. A typical application pulls in dozens or hundreds of open source packages, each of which depends on more packages, several layers deep. That web of dependencies is what a software bill of materials, or SBOM, is meant to make visible.

An SBOM is essentially an inventory. For a given piece of software, it lists every component that went into building it: libraries, frameworks, transitive dependencies, their versions, and often their licenses and origins. Think of it like an ingredients label, except the “food” is a compiled binary or a container image, and the ingredients list can run into the thousands of entries once you account for nested dependencies.

Why This Suddenly Matters

For most of software history, nobody outside a security team cared much about dependency inventories. That changed as supply chain attacks became a recognized category of risk rather than a theoretical one. When a widely used open source library turns out to have a vulnerability, or worse, turns out to have been deliberately compromised, the organizations affected are often the ones who don’t know they’re using it. A vulnerability three dependencies deep, pulled in transitively by a package nobody on the team has directly interacted with, is easy to miss without a systematic way to track what’s actually in your software.

SBOMs address this by turning “what’s in our software” from a question that requires archaeology into something you can query directly. When a new vulnerability is disclosed in a specific library version, teams with SBOMs can search their inventory and get an answer in minutes: which applications are affected, and where. Without one, that same question can mean days of manually auditing build files and dependency trees across every product a company ships.

Standardization and Tooling

Two SBOM formats have become the de facto standards: SPDX, which originated in the license-compliance world, and CycloneDX, which grew out of application security tooling. Both are machine-readable, both are widely supported by build tools and package managers, and most organizations end up picking whichever one their existing toolchain generates most naturally rather than debating the merits in the abstract.

Generating an SBOM is increasingly a build-pipeline concern rather than a manual one. Many language ecosystems and CI/CD platforms can produce one automatically as an artifact of the build process, since the dependency graph is already known to the build tool. The harder problem isn’t generation, it’s what happens after: keeping the SBOM current as dependencies change, correlating it against vulnerability databases on an ongoing basis, and making that information visible to the people who need to act on it.

The Regulatory and Contractual Push

A lot of the momentum behind SBOM adoption isn’t purely technical, it’s procurement. Government agencies and large enterprises increasingly ask vendors to provide an SBOM as part of the buying process, treating it the way they’d treat a security questionnaire or compliance certification. Once a handful of major customers require it, it tends to become standard practice across a vendor’s entire product line, since maintaining two different levels of transparency for different customers is more overhead than just doing it uniformly.

What It Doesn’t Solve

An SBOM tells you what’s in your software. It doesn’t tell you whether any of it is safe, and it doesn’t fix a vulnerability once you find one. It’s an inventory, not a scanner and not a patch. The real value shows up when it’s paired with vulnerability monitoring and a process for actually acting on what that monitoring turns up. An SBOM nobody looks at is just a very detailed document sitting in a repository.

As software supply chains keep growing more layered, the organizations in the best position to respond to the next dependency-related incident will be the ones that already know, in detail, what they’re running. That’s the practical case for SBOMs: not compliance theater, but the ability to answer a basic question quickly when it suddenly matters.