The Conventional Wisdom
Your compliance team might believe that supply chain security is addressed by generating Software Bills of Materials (SBOMs). Create an SBOM for every release, submit it to the FDA if you build medical devices, and archive it for the European Cyber Resilience Act auditors. Check the box, move on.
Regulatory guidance appears clear: the FDA requires SBOMs for medical devices, the CRA imposes fines up to 2.5% of global turnover for non-compliance, and everyone from NIST to your auditors says you need "visibility into your dependencies." So you generate SBOMs, probably in SPDX or CycloneDX format, and consider the problem handled.
Why SBOMs Are Not Enough
SBOMs are documentation, not security controls. They tell you what's in your software—they don't tell you what to do about it.
Here's the reality: 97% of commercial applications contain open-source software, and 86% of those applications contain known vulnerabilities. You can generate a perfect SBOM that accurately lists every dependency, but you'll still ship vulnerable code if you don't act on that information.
Treating supply chain security as a compliance exercise misses the operational reality. When developers spend 3.5 hours per week manually reviewing security scan findings due to false positives, you haven't solved supply chain security. You've created a compliance theater that wastes engineering time while real vulnerabilities slip through.
The European Cyber Resilience Act doesn't penalize you for missing an SBOM. It penalizes you for shipping products with exploitable vulnerabilities. The SBOM is evidence you tried to track your components—it's not evidence you secured them.
The Evidence
Consider the Log4Shell incident. Organizations with SBOMs could quickly identify affected systems—that's valuable. But the SBOM didn't prevent the vulnerability from existing, nor did it indicate which instances were actually exploitable.
The 3.5 hours per week developers spend on false positives highlights the real bottleneck. Your team doesn't need more documentation about what's in your software. They need fewer, more accurate signals about what's actually wrong and what they should fix first.
When you frame supply chain security as "generate SBOMs and scan for CVEs," you end up with:
- SBOMs that are outdated the moment you merge a new dependency
- Vulnerability reports that flag every instance of a library, regardless of whether your code actually calls the vulnerable function
- Compliance teams who think they've addressed the risk because the SBOM exists
- Engineering teams who ignore security findings because 80% are false positives
PCI DSS v4.0.1 Requirement 6.3.2 requires you to manage vulnerabilities in bespoke and custom software, and Requirement 11.3.2 demands that you identify and address vulnerabilities in external-facing web applications. Notice what's missing: neither requirement says "maintain an SBOM." They say manage and address vulnerabilities.
What to Do Instead
Start with reachability analysis, not just presence detection. Your scanning tools should tell you whether your code actually calls the vulnerable function in that dependency. If you're using Log4j but never invoke the JNDI lookup feature, that's different from using it in a way that's exploitable. Some modern tools can trace execution paths—demand this capability.
Build your SBOM generation into CI/CD, but treat it as one input among many. When a new CVE drops, you need to answer three questions in order:
- Do we use this component? (SBOM answers this)
- Do we call the vulnerable code path? (Reachability analysis answers this)
- Is it exposed to untrusted input? (Architecture review answers this)
Only after you've answered all three can you accurately prioritize the fix.
For compliance: yes, generate SBOMs. The FDA requires them, the CRA expects them, and they're useful for incident response. But structure your security program around vulnerability management, not SBOM maintenance. Your auditors care that you can demonstrate you're finding and fixing vulnerabilities—the SBOM is just one piece of evidence.
Set clear thresholds with your security tools. If developers are spending 3.5 hours per week on false positives, your tool's signal-to-noise ratio is broken. You should be able to tell your scanning vendor: "We need a 90% true positive rate for high-severity findings, or we'll find a tool that can deliver that." This isn't a technical limitation—it's a tool selection problem.
Integrate your SBOM data with threat intelligence. When a new vulnerability is announced, you should be able to query your SBOM repository and get a list of affected services within minutes. If that takes hours or requires manual correlation, your SBOM process isn't operationalized—it's just generating files.
When SBOMs Are Necessary
SBOMs are necessary for certain use cases. If you're in a regulated industry—medical devices, critical infrastructure, government contracting—you need SBOMs to meet compliance requirements. The FDA won't accept "we use reachability analysis" as a substitute for the SBOM they explicitly require.
SBOMs are also invaluable during incident response. When the next Log4Shell drops, you need to know within an hour which products and services are affected. An accurate, queryable SBOM repository makes that possible. Without it, you're searching through repositories and hoping you find everything.
The conventional wisdom is also right that supply chain security has moved from a technical concern to a board-level issue. The CRA's 2.5% of global turnover penalty isn't a slap on the wrist—it's an existential threat for some companies. Your executive team should care about this, and SBOMs are part of how you demonstrate due diligence.
But here's the distinction: SBOMs are necessary but not sufficient. Generate them, maintain them, use them—but don't confuse having an SBOM with having supply chain security. The document doesn't protect you. The processes you build around vulnerability detection, prioritization, and remediation protect you. The SBOM just makes those processes faster and more accurate.
European Cyber Resilience Act
