The software running in a typical cloud deployment is assembled, not written. An application image bundles the code an organization authored together with dozens or hundreds of open-source libraries, transitive dependencies, base-image packages, and build tooling — most of it sourced from public repositories and maintained by people the deploying organization has never met. The 2021 Log4Shell vulnerability made the consequences of that reality unavoidable: a critical flaw in a ubiquitous logging library left organizations scrambling to answer a deceptively simple question — do we even run this, and where? For many, answering took days. The software bill of materials, or SBOM, is the industry’s structured response to that question.

What an SBOM Is

A software bill of materials is a formal, machine-readable inventory of the components that make up a piece of software. By analogy with the bill of materials in manufacturing — the list of parts that go into a physical product — an SBOM enumerates the software components in a build: the libraries, their versions, their suppliers, their licenses, and ideally the dependency relationships between them.

Two standardized formats dominate. SPDX (Software Package Data Exchange), a Linux Foundation project and ISO standard, and CycloneDX, maintained under the OWASP umbrella, both express the same essential information in interoperable, tool-readable form. The choice between them is largely a matter of ecosystem fit; the important point is that the inventory is generated automatically as part of the build, not assembled by hand.

The value of an SBOM is realized at the moment a new vulnerability is disclosed. Instead of manually auditing every running system, an organization that maintains SBOMs for its deployments can query its inventory: which builds include the affected component, at which versions, in which services. The Log4Shell scramble was, fundamentally, the absence of that capability. An SBOM converts a frantic investigation into a database lookup.

The Policy Push

SBOMs moved from good practice to requirement largely through U.S. federal policy. Executive Order 14028, “Improving the Nation’s Cybersecurity,” issued in May 2021 in the wake of a string of high-profile supply-chain compromises, directed federal agencies and their software suppliers toward stronger supply-chain controls — including the provision of SBOMs for software sold to the government. The National Telecommunications and Information Administration and later CISA published guidance on the minimum elements an SBOM should contain.

The mechanism matters: by making SBOMs a procurement requirement for selling to the federal government, the policy created commercial pressure on software vendors to generate and supply them, which in turn pushed SBOM generation into mainstream build pipelines well beyond the immediate scope of federal contracts. Vendors that build SBOM generation into their products to satisfy government buyers make that capability available to all their customers.

SLSA and Build Provenance

An SBOM tells you what is in a build. It does not, by itself, tell you whether the build process can be trusted — whether the components came from where they claim to, or whether the build environment was tampered with. That is the gap the SLSA framework addresses.

SLSA (Supply-chain Levels for Software Artifacts), an OpenSSF project, defines a graduated set of requirements for build integrity and provenance. Its levels describe progressively stronger guarantees: that builds are scripted and reproducible, that the build platform generates verifiable provenance attesting to how an artifact was produced, and that the provenance is signed and tamper-evident. Where an SBOM answers “what is in this artifact,” SLSA provenance answers “how was this artifact built, and can I verify that claim.”

Together, SBOMs and build provenance form complementary halves of a supply-chain security posture. The SBOM supports vulnerability response and license compliance; the provenance supports trust in the integrity of the build itself. Cryptographic signing of both — using emerging tooling that makes signing artifacts and verifying signatures practical at scale — ties them to verifiable identities rather than to unattested assertions.

Why This Matters More in the Cloud

Cloud-native deployment patterns intensify the supply-chain problem in two ways.

First, container images are deep dependency stacks. A typical image layers an application on top of a base operating-system image, language runtimes, and system libraries — each contributing components that the application author never selected directly. The attack surface is the union of everything in the image, not just the code the organization wrote.

Second, the velocity of cloud deployment means images are rebuilt and redeployed continuously. A vulnerability disclosed today may be present in an image that was built last week and is running across a fleet. Without automated inventory, the question of exposure scales with the size and churn of the deployment — exactly the conditions under which manual auditing fails.

This is why SBOM generation belongs in the build pipeline rather than as a periodic audit. An SBOM produced automatically for every image, stored alongside the artifact, and queryable across the fleet turns a continuously changing deployment into something an organization can actually reason about.

A Distributed-Systems Framing

The supply-chain problem is, at heart, a trust-federation problem — and that framing connects it to long-standing distributed-systems concerns. In a federated system, components from many independently administered sources must interoperate, and the question of how much to trust each component, on what evidence, is central. The grid-computing research tradition spent considerable effort on exactly this: establishing verifiable identity and trust across resources owned by different parties. SBOMs and signed provenance are the modern, software-supply-chain expression of the same idea — replacing implicit trust (“it came from the registry, so it must be fine”) with verifiable, attestable claims about origin and composition.

Practical Steps for Cloud Teams

For teams operating cloud workloads, the path from awareness to capability is incremental:

  • Generate SBOMs in the build. Add SBOM generation (SPDX or CycloneDX) as a build step for every container image and deployable artifact. Store the SBOM as a build output alongside the artifact it describes.
  • Make the inventory queryable. An SBOM that sits unread in an artifact store provides little value. The payoff comes from being able to query across all SBOMs — “which deployments include component X below version Y” — when a vulnerability is disclosed.
  • Adopt build provenance incrementally. Begin moving toward verifiable, signed build provenance along the lines SLSA describes. Even the lower levels — scripted, reproducible builds with generated provenance — meaningfully raise the bar against tampering.
  • Treat third-party SBOMs as a procurement input. As SBOMs become standard, request them from software vendors. A vendor that can supply a current SBOM is one whose supply-chain posture you can actually assess.

Supply-chain security is not a problem that is solved once. New components enter the build continuously, and new vulnerabilities are disclosed daily. The SBOM does not eliminate that reality — it makes it manageable, by ensuring that when the next Log4Shell arrives, the question “do we run this, and where” has a fast, reliable answer.

Further Reading

Back to Blog