SBOM Is Not the Savior – Addressing the Deeper Problems in Supply Chain Security

This article was originally published on Scott’s Substack on June 3, 2025.

I hear a lot these days about SBOMs and how they are going to be the key to supply chain security accountability, to even include a Presidential Executive Order mandating SBOMs in the procurement process for federal agencies. There are multiple areas of research going on in this area, such as this Academic SBOM Repository. But before we get too far down the road, let’s get one thing straight: SBOM isn’t going to save us. It’s a transparency tool, not a solution. And treating it like a silver bullet for supply chain security is not just misguided: it’s dangerous.

In theory, SBOM (Software Bill of Materials) promises visibility into the components that make up your software, enabling faster response when vulnerabilities emerge. But in practice, it’s a Band-Aid on a broken process. We’re trying to standardize metadata while ignoring the operational chaos that happens downstream.

To put it plainly: the problem isn’t that we don’t know what’s in the software. It’s that we have no scalable, reliable process to do anything meaningful with that information.

Story 1: Risk Posture Reporting Fantasyland

In 2024, I sat in a room with federal policymakers and software industry leaders. The proposal on the table? A framework where vendors report the risk posture of all shipped software on a recurring basis.

The response from industry?

“We don’t even know what versions are running out there in the wild.”

“Instead, can we sign attestation letters that say it’s secure?”

Let that sink in. They couldn’t inventory deployed versions across environments but were perfectly fine checking a compliance box. This is what the SBOM ecosystem is becoming, compliance theater masking operational dysfunction. If CVE management is a mess, try tracking risk through firmware, dependency chains, and runtime variants. It’s chaos on a good day.

Story 2: Vulnerability Management Shouldn’t Exist?

Rewind to 2022. At a founder’s dinner in San Francisco, a bright-eyed startup founder asked about my company. I told her we build vulnerability management software.

Her reaction? A grimace, followed by:

“I don’t think vulnerability management should even exist.”

The idea? If we fix the software supply chain, bugs go away. In theory, maybe. In reality? Laughable. Software is human. Vulnerabilities are inevitable. And the notion that you can code your way out of the need for operational security is Silicon Valley magical thinking.

SBOM: Insight Without Action

The core issue isn’t with SBOM as a concept. It’s with how we’ve mythologized it. SBOM is a data format. That’s it. It doesn’t patch anything. It doesn’t assess risk. It doesn’t orchestrate remediation.

What SBOM Gets Wrong (or rather, what we get wrong about it)

• The Data Format Fallacy: Knowing what’s in your software is step zero. Not step 10.
• The Scale Blindspot: Try tracking thousands of versions, environments, and permutations without automation. Good luck.
• The Attestation Delusion: “Secure by default” becomes “secure by declaration” when the system lacks enforceability.

Where We Actually Need to Go

We don’t need another format. We need to operationalize vulnerability management in the supply chain. That means building systems that translate awareness into action—at scale, at speed.

Here’s what that looks like:

• Risk Prioritization at Scale: Move beyond CVSS and base scores. Leverage context: exploitability, business impact, asset sensitivity, to decide what actually matters.
• Automated Remediation: Manual patching is dead. Automation isn’t optional anymore; it’s survival.
• Embedded Security Posture Management: Bake risk assessment into development, procurement, and deployment pipelines.
• Cross-Functional Ownership: Security doesn’t belong to one team. It’s distributed. Vendors, devs, ops, product… all must align around shared accountability.

Recommendations

• For Policymakers: Incentivize operational excellence, not compliance paperwork. Invest in programs that reward integration, automation, and real-time visibility.
• For Vendors: Stop outsourcing security posture to your legal team. Replace attestation letters with actual risk data.
• For Cybersecurity Leaders: Push your stack to deliver outcomes, not optics. SBOM doesn’t reduce risk. Your processes do.

Final Thought

SBOM is necessary but wildly insufficient on its own. If we keep treating it like the holy grail, we’ll stay stuck in the same cycle: transparency without action, awareness without accountability.

To truly secure the supply chain, we need more than inventory. We need impact. That means embedding vulnerability management into the bloodstream of how software is built, deployed, and maintained.

Because until we can act at the speed of exploitation, we’re just spectators in our own security program.

Until next time.