“Most SBOMs are barely valid, few meet minimum government requirements, and almost none are useful.”
Harsh. But this is still a common sentiment by SBOM users on LinkedIn. Software bills of materials (SBOMs) often feel like glorified packing slips—technically present but practically worthless.
Yet Kate Stewart, one of the most respected figures in open source, has dedicated over a decade of her career to SBOMs. As co-founder of SPDX and a Linux Foundation Fellow, she’s guided this standard from its inception in 2010 through multiple evolutions. Why would someone of her caliber pour years into something supposedly “useless”?
Because Stewart, the Linux Foundation and the legion of SDPX contributors see something the critics don’t: today’s limitations aren’t a failure of vision—they’re a foundation for the growing complexity of the software supply chain of the future.
Because Stewart, the Linux Foundation and the legion of SDPX contributors see something the critics don’t: today’s limitations aren’t a failure of vision—they’re a deliberate strategy. They’re following the classic startup playbook: nail a minimal use-case first, achieve critical mass, then expand horizontally. The “uselessness” critics complain about? That’s a feature, not a bug.
Death by a Thousand Cuts
To understand where we’re headed, we need to start where it all began: back in 2009 with Kate and a few of her key software architects at Freescale Semiconductor spending their weekends manually scanning software packages for licenses before the launch of a new semiconductor chip.
Stewart and her team faced what seemed like a manageable challenge—tracking open source software (OSS) licenses for roughly 500 dependencies. But as she recalls, “It was death by a thousand cuts.” Every weekend, they’d pore over packages, hunting for license information, trying to avoid the legal landmines hidden in their newest chip’s software supply chain.
The real shock came from discovering how naive their assumptions were. “Everyone assumes the top-level license is all there is,” Stewart explains, “but surprise!” Buried deep in transitive dependencies—the dependencies of dependencies—were licenses that could torpedo entire projects. GPL code hidden three layers deep could force a proprietary product open source. MIT licenses with unusual clauses could create attribution nightmares.
This wasn’t just Freescale’s problem. Across the industry, companies were hemorrhaging engineering hours on manual license compliance.
The Counterintuitive Choice
Here’s where the story takes an unexpected turn. When the Linux Foundation’s FOSSBazaar working group came together to design a solution, they made a choice that still frustrates people today: they went minimal. Radically minimal.
The working group—including Stewart and other industry experts—envisioned SBOMs as “software metadata containers”—infinitely expandable vessels for any information about software components. The technology could support hashing, cryptographic attestations, vulnerability data, quality metrics, and more. But instead of trying to predict every potential use-case they chose to pare the original SPDX spec down to only its essentials.
Stewart knew that removing these features would make SBOMs “appear” almost useless for any purpose. So why did they proceed?
The answer lies in a philosophy that would define SBOM’s entire evolution:
“[We framed] SBOMs as simply an “ingredients list”…but there’s a lot more information and metadata that you can annotate and document to open up significant new use-cases. [The additional use-cases are] really powerful BUT we needed to start with the minimum viable definition.”
The goal wasn’t to solve every problem on day one—it was to get everyone speaking the same language. They chose adoption over the overwhelming complexity of a fully featured standard.
Why the ‘Useless’ Jab Persists
By launching SPDX with a minimal definition to encourage broad adoption and make the concept approachable, the industry began evaluating it equally as minimally—seeing SBOMs as simple ingredient lists rather than an extensible framework. The simplicity of the standard made it easier to grasp, but also easier to dismiss.
Today’s critics have valid points:
- Most SBOMs barely meet government minimums
- They’re treated as static documents, generated once and forgotten
- Organizations create them purely for compliance, extracting zero operational value
- The tools generating them produce inconsistent, often invalid outputs
But here’s what the critics miss: SBOMs aren’t truly static documents—at least, not in practice. They’re more like Git version-controlled files: static snapshots that form a dynamic record over time. Each one captures the meta state of an application at a given moment, but their value emerges from their evolution. As Stewart emphasizes, “Every time you apply a security fix you are revving your package. A new revision needs a new SBOM.” Just as Git commits accumulate to form a living history of a codebase, SBOMs should accumulate and evolve to reflect the ongoing lifecycle of an application.
The perception problem is real, but it’s also temporary.
The HTTP Playbook
To understand why the minimal SBOMs strategy is powerful, consider the evolution of HTTP.
In 1991, the original HTTP/0.9 protocol could only request a document using a GET method and receive raw HTML bytes in return. There were no status codes, no headers, and no extensibility. Critics at the time leveled familiar critiques against the fledgling protocol—”barely functional”, “useless”, etc. But that simplicity was its genius. It was a minimum viable definition that was easy to implement and rapidly adopted.
And because it was adopted, it grew and evolved.
Today, HTTP headers handle:
- Security policies (Content‑Security‑Policy, Strict‑Transport‑Security)
- Performance optimization (caching, compression)
- State management (cookies and session handling)
- Authentication and authorization
- Client hints and feature detection
Nobody in 1991 imagined we’d use HTTP headers to prevent cross‑site scripting attacks or optimize mobile performance. But the extensible design made it possible.
SBOMs are following the exact same playbook. The industry expected them to solve license management—the original Package Facts vision. Instead, the killer app turned out to be vulnerability management, driven by the explosion of software supply chain attacks like SolarWinds and Log4j.
“SPDX has grown use‑case by use‑case,” Stewart notes. And each new use-case doesn’t just add features—it enables entirely new categories of applications.
SBOMs today are where HTTP was in 1991—functionally limited but primed for explosion.
The Expansion Is Already Here
The evolution from SPDX 2.x to 3.0 proves this strategy is working. The changes aren’t incremental—they’re transformational:
From Documents to Graphs: SPDX 3.0 abandons the monolithic document model for knowledge graph model. Instead of one big file, you have interconnected metadata that can be queried, analyzed, and visualized as a network.
From Software to Systems: The new specification handles…
- Service profiles for cloud infrastructure
- AI model and dataset profiles (tracking what data trained your models)
- Hardware BOMs for IoT and embedded systems
- Build profiles that cryptographically link source to binary
- End-of-life metadata for dependency lifecycle management
Real-World Implementations: This isn’t theoretical. The Yocto project already generates build-native SBOMs. The Zephyr project produces three interlinked SBOMs:
- Source SBOM for the Zephyr RTOS itself
- Source SBOM for your application
- Build SBOM that cryptographically links everything together
These implementations show SBOMs evolving from compliance checkboxes to operational necessities.
The Endgame: Transparency at Scale
Kate Stewart summarizes the vision in seven words: “Transparency is the path to minimizing risk.”
But transparency alone isn’t valuable—it’s what transparency enables that matters. When every component in your software supply chain has rich, queryable metadata, you can:
- Instantly identify affected systems when a zero-day disclosure drops
- Prove compliance with regulations automatically
- Track technical debt and maintenance burden in real-time
- Make informed decisions about component selection
- Automate security policy enforcement
The platform effect is already kicking in. More adoption drives more use-cases. More use-cases drive better tooling. Better tooling drives more adoption. It’s the same virtuous cycle that turned HTTP from a simple network protocol into the nervous system of the web.
Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.
Playing the Long Game
The critiques of SBOMs as they are today suffer from a failure of imagination. Yes, they’re minimal. Yes, they’re often poorly implemented. Yes, they feel like “compliance theater”. All true.
The founders of SPDX made a calculated bet: it’s better to have adoption of a simple but potentially “useless” standard that can evolve than to have a perfect standard that nobody uses. By starting small, they avoided the fate of countless over-engineered standards that died in committee.
Now, with the cold start overcome and adoption growing, the real expansion begins. As software supply chains grow more complex—incorporating AI models, IoT devices, and cloud services—the metadata infrastructure to manage them must evolve as well.
The teams generating “barely valid” SBOMs today are building the muscle memory and tooling that will power tomorrow’s software transparency infrastructure. Every “useless” SBOM is a vote for an open, transparent, secure software ecosystem.
The paradox resolves itself: SBOMs are useless today precisely so they can become essential tomorrow.
Learn about SBOMs, how they came to be and how they are used to enable valuable use-cases for modern software.
