In December 2021, a logging library quietly became the most important software in the world. The Log4Shell vulnerability in the Apache Log4j library gave remote attackers a way to execute code on countless servers — and revealed, in real time, that almost no organization actually knew what was running in its own environments. Weeks of emergency patching followed, and the single most common answer to the question "are we affected?" was a shrug. The Software Bill of Materials, or SBOM, was supposed to end that shrug forever.
The SBOM is a simple concept with an honest history. It borrows the idea from manufacturing, where every physical product lists its constituent parts. For software, a Bill of Materials is a machine-readable inventory of the components that make up an application — the libraries, frameworks, containers, and tools it was built from, complete with version numbers and licensing. Regulators and industry bodies have embraced it. And yet, years later, the typical SBOM is generated once, saved somewhere, and read by nobody until the next emergency.
Why the Inventory Keeps Not Getting Read
The failure of the SBOM is not a failure of the format. It is a failure of the assumption that an inventory changes what people do. Knowing you have a vulnerable component is only useful if you also have a way to patch it, an owner responsible for it, and a process that is triggered by the knowledge. Most SBOMs stop at the first step — the list — and leave the rest as an unsolved problem.
There are four reasons an SBOM typically becomes a document rather than a control:
- It's generated post-hoc. Most SBOMs are produced after the build, by scanning the final artifact and asking "what do we think is in here?" They reflect a best-effort reconstruction, not a statement of provenance.
- It's static. Software changes daily. An SBOM is a photograph of a moving target, and photographs don't trigger alerts.
- It has no owner. Security generates the document; engineering never sees it; nobody is accountable for acting on it.
- It describes, it doesn't decide. An SBOM lists components. It cannot tell you which of those components are reachable, which are exploitable, or which ones matter to the business.
What an SBOM Actually Captures
Modern SBOMs come in two main machine-readable formats: SPDX and CycloneDX. Both can represent a nested graph of dependencies, not just a flat list, and both are increasingly built directly into the toolchains that produce software. A well-formed SBOM answers questions like:
| Question | SBOM field |
|---|---|
| Which library is this? | Component name and version |
| Where did it come from? | Supplier, download URL, provenance hash |
| What does it depend on? | Dependency graph, including transitive dependencies |
| Who is responsible for it? | Supplier identity and license metadata |
| What known weaknesses might it carry? | Linked vulnerability references (VEX and CVE identifiers) |
The difference between a good SBOM and a decorative one is whether those fields are trustworthy. A generated-from-recollection SBOM carries the same errors as the person who guessed. A generated-during-build SBOM, produced from the actual resolved dependency graph, is a record of what really shipped — and that distinction is the entire point.
The Formats and the Flow
The two dominant formats, SPDX and CycloneDX, are more similar than their acronyms suggest, and both are converging on the same idea: a graph, not a list. A flat list tells you what packages were resolved; a graph tells you how they relate — which components are direct dependencies, which are transitive, and which path an attacker would need to travel to reach a given component. The graph matters because a vulnerability in a transitive dependency is a different problem than a vulnerability in a direct one, and the graph is what lets you tell the difference.
The flow matters more than the format. The single biggest predictor of whether an SBOM is useful is where in the pipeline it was generated. An SBOM generated from a lockfile at build time is a record of what actually got resolved — the versions, hashes, and suppliers that were genuinely used. An SBOM reconstructed later by scanning an artifact is an educated guess about the same thing. Both are called SBOMs, and only one of them is worth alerting on.
The Vulnerability Exploitability Exchange
The SBOM became far more useful when it acquired a companion concept: the Vulnerability Exploitability Exchange, or VEX. A VEX document is a machine-readable statement that pairs each component in an SBOM with the current status of every known vulnerability affecting it — "affected," "not affected," "fixed," or "under investigation." The value of VEX is not the data. It is the discipline: someone has to actually assess each component and say, out loud, what its risk status is.
Without VEX, an SBOM hands your security team a list of a thousand components and a vulnerability feed, and leaves the hard work of deciding which combinations matter to humans under pressure. With VEX, the assessment is produced at a sane moment and consumed by automation at the moment of need. The difference is the difference between reading a phone book and having a call router.
The Thought Experiment: The Day the SBOM Earned Its Keep
Thought experiment — a vulnerability in a library you've never heard of
An advisory drops: a critical remote code execution flaw in xmltree-utils version 3.2.1, a small XML parsing helper that appears in hundreds of products. The advisory gives an attacker a full remote shell on any service using the library. Your team's first question: do we run xmltree-utils?
Organization A has no SBOM. The answer requires searching Git history, grepping lock files, and asking engineers who left the company. Somewhere between twelve hours and two weeks later, they conclude — tentatively — that one forgotten microservice, deployed by a team that no longer exists, includes the library as a transitive dependency of a dependency.
Organization B has SBOMs generated at every build, stored alongside every artifact, and cross-referenced by a tool that queries the advisory feed. The moment the advisory publishes, the SBOM matcher flags exactly two services, both owned, both with a patch path already negotiated with the maintainer. Organization B patches in an afternoon. Both organizations are the same size. The difference is not skill. It is that one of them decided, in advance, to know what it was running.
The Gap Between Knowing and Doing
Even the perfect SBOM does not close the loop. Knowledge still has to become action, and that is where supply chain security gets genuinely hard:
- Remediation requires leverage. Knowing a component is vulnerable only matters if a patched version exists, is compatible, and can be deployed without breaking something else. In practice, the patching queue is often blocked by a component that hasn't been updated by its maintainer in years.
- Transitive dependencies multiply the work. Your app depends on library A, which depends on library B, which depends on the vulnerable library C. You did not choose C, and you cannot update it without A and B shipping new versions. This is the single most common reason SBOM data doesn't translate into fixes.
- Inventory is not exposure. A component in the SBOM that is never loaded, never reaches the network, or is compiled out is a low-risk entry. SBOMs list everything; security has to decide what matters. Without reachability analysis, teams burn their alert budget on components that were never exploitable.
- Generated once is not generated always. An SBOM built at the wrong point in the pipeline — before dependency resolution, or after the artifact has been modified in a later step — is fiction wearing an official format.
Making the SBOM Earn Its Keep
The practices that turn an SBOM from a compliance checkbox into an operational control are not glamorous:
| Practice | Why it matters |
|---|---|
| Generate SBOMs at build time, from the resolved dependency graph | Captures what actually shipped, not what was assumed |
| Publish SBOMs with every artifact, signed like the artifact itself | Makes the inventory part of the release, not a separate report |
| Feed SBOMs into a continuously running matcher against advisory feeds | Turns a static list into a living alert |
| Require suppliers to provide SBOMs for everything you buy | Extends the inventory to code you never built at all |
| Pair each SBOM with VEX assessments and reachability data | Converts "is it in the list" into "does it matter" |
Key Takeaways
- An SBOM is a photograph of a moving target; its value is in the tooling that keeps it current, not the file itself.
- Most SBOMs fail because they are generated post-hoc, owned by nobody, and disconnected from remediation.
- VEX turns a list into a decision, and reachability analysis turns a decision into prioritization.
- Transitive dependencies are the real supply chain — you inherit components you never chose, and patching them is not always possible.
- The organizations that survive the next Log4j are the ones that treat the SBOM as a control with an owner, not as a deliverable.
Log4Shell did not teach us that logging libraries can be dangerous. It taught us that organizations cannot defend software they do not know they are running. The SBOM is the answer to the knowing half of that sentence. The doing half is the harder problem — but you cannot do what you do not know, and the organizations that learned to read their own inventories were the ones that got to choose how to react, instead of discovering they were affected in the comments section of a blog post.