According to Dark Reading, software bill of materials (SBOMs) have moved from theory to a practical expectation in most enterprise and regulated software buying cycles, driven by mandates like the US Executive Order 14028 in 2021 and the EU’s new Cyber Resilience Act. Companies like Docker have fully embraced them, building complete SBOMs into their Docker Hardened Images with SLSA Level 3 provenance. Yet, experts like Joseph Saunders of RunSafe Security and Dan Lorenc of Chainguard argue most SBOMs are generated too late, are inaccurate, and serve more as a compliance checkbox than a real security tool. The US Cybersecurity and Infrastructure Security Agency (CISA) updated its SBOM guidance earlier this year to require machine-readable formats, but doubts about operationalization remain high. The focus is now shifting from simply having an SBOM to demanding they be accurate and actionable.
The Compliance Checkbox Problem
Here’s the thing: mandating a document doesn’t magically create security. The article nails the core issue. Companies are being “dragged into a future” where they have to provide SBOMs, so they do the minimum. They generate them as the very last step of the build, just to check that box. But what good is an ingredient list if it’s written after the meal is cooked and doesn’t match what’s actually on the plate? For compiled and embedded software—think firmware in devices or specialized industrial systems—this gets even messier. The tools often can’t fully capture the mix of components, leading to manual processes and guesswork. So you get a nice, compliant PDF that might bear little resemblance to the software actually running on a server, or more critically, on an industrial panel PC on a factory floor. And if you’re sourcing critical hardware, you’d want that bill of materials to be rock-solid, not just a paperwork exercise.
SBOM vs. SCA: The Independent Auditor
This is where Dan Lorenc’s point gets really interesting. He suggests that in some cases, a Software Composition Analysis (SCA) tool—a black-box scanner that examines the final product—might be better than a self-reported SBOM. Why? Because it’s independent. Think about it. An SBOM is generated by the same build system that might be compromised. If an attacker infiltrates your pipeline, they can make the SBOM lie for them. An external SCA tool is doing its best to guess what’s in the binary, but at least it’s a separate set of eyes. It’s the difference between a company self-reporting its finances and bringing in an external auditor. The auditor might miss some details, but you trust it more because it has no incentive to hide the bad stuff. This skepticism is healthy. It means the industry is maturing past the “just give me any SBOM” phase.
The Future is Salsa (and AI BOMs)
So if SBOMs are flawed, what’s next? The conversation is already moving upstream to the build process itself with frameworks like SLSA (Supply-chain Levels for Software Artifacts). The goal here isn’t just a list of ingredients, but a verifiable, tamper-proof record of how the software was made—securing the “kitchen,” not just the recipe. Docker’s Michael Donovan notes that demand for SLSA is growing as organizations realize they need to secure build pipelines as rigorously as production environments. The Linux Foundation’s recent SLSA 1.2 update shows this is a living, evolving standard. And then, of course, there’s the new kid on the block: the AI Bill of Materials (AI BOM). As outlined by Wiz, this tries to capture the chaotic, evolving nature of AI systems—datasets, model parameters, training methods. If you think tracking open-source libraries is hard, try tracking the provenance of a 2TB training dataset that’s been tweaked weekly.
A Foundation, Not a Finish Line
Look, SBOMs aren’t useless. As Joseph Saunders said, an accurate SBOM is the foundation for vulnerability identification and prioritization. The push for them, especially from regulations like the EU CRA, has forced the entire software industry to at least start thinking about its supply chain. That’s a huge win. But 2026 seems to be the year we collectively admit they’re a starting point, not a solution. The real work is in verifiable builds (SLSA), independent verification (SCA), and now managing the AI wild west. The mandate got everyone to the table. Now the hard part begins: moving beyond the checkbox to build systems you can actually trust. Because in the end, a false sense of security might be more dangerous than knowing you’re in the dark.
