The Conventional Wisdom
Your compliance team needs an SBOM. The EU Cyber Resilience Act demands it. Executive Order 14028 requires it. Every vendor pitch deck promises that generating and managing Software Bills of Materials will solve your supply chain security problems and keep you compliant.
The narrative is simple: create comprehensive SBOMs for all your software, maintain them continuously, and you'll meet regulatory requirements while gaining unprecedented visibility into your dependencies. Tools like Keysight's SBOM Manager promise to make this easy with unified SBOM generation and management.
Why It's Incomplete
Having an SBOM doesn't mean you're compliant. It means you have a list.
The EU CRA requires manufacturers to maintain SBOMs and report actively exploited vulnerabilities within 24 hours. Notice what that requirement actually says: you need the SBOM and you need to act on vulnerability intelligence within a tight timeframe. The SBOM is the input, not the output.
Most organizations treat SBOM generation as the finish line when it's actually the starting gate. You can generate perfect CycloneDX or SPDX documents for every application in your portfolio and still fail the intent of these regulations if you're not using that data to make security decisions.
Here's what compliance teams miss: the regulations care about your ability to respond to supply chain risk, not your ability to enumerate dependencies. An SBOM that sits in a repository while your application runs vulnerable Log4j versions doesn't satisfy the EU CRA's requirement to address actively exploited vulnerabilities. It just gives you something to show the auditor before they write up the finding.
The Evidence
Look at what the EU CRA actually requires. The 24-hour reporting window for actively exploited vulnerabilities assumes you can correlate your SBOM data with real-time threat intelligence. That means:
- You need vulnerability scanning integrated with your SBOM data.
- You need a process to triage and prioritize findings.
- You need deployment mechanisms fast enough to patch within hours, not weeks.
- You need evidence that you actually did these things.
Executive Order 14028 has similar implications. It requires federal agencies to obtain SBOMs from software vendors, but the goal is risk-based decision making about software procurement and deployment. The SBOM enables that decision making; it doesn't replace it.
I've seen compliance programs spend six months implementing SBOM generation tooling while their vulnerability management process still takes 45 days to patch critical findings. They have beautiful, standards-compliant SBOMs. They're still not meeting the regulatory intent.
The practical challenge isn't technical. Tools can generate SBOMs automatically during your build process. The challenge is operational: do you have the processes, ownership, and response capabilities to use SBOM data for actual risk reduction?
What to Do Instead
Start with your vulnerability response process, not your SBOM tooling.
First, map your current state. How long does it take your team to go from "CVE published" to "patch deployed in production"? If that number is measured in weeks, no SBOM tool will make you compliant with a 24-hour reporting requirement. Fix the deployment pipeline first.
Second, integrate SBOM generation into existing workflows rather than treating it as a separate compliance exercise. If you're already running dependency scanning in your CI/CD pipeline, extend those tools to output SBOM artifacts. Don't create a parallel process that generates SBOMs nobody uses.
Third, implement VEX (Vulnerability Exploitability eXchange) alongside your SBOMs. VEX documents let you communicate which vulnerabilities in your SBOM actually affect your application based on how you're using the component. This is the difference between "we have 47 high-severity findings" and "we have 3 exploitable vulnerabilities that require immediate action."
For example, if your SBOM shows you're using a vulnerable version of a library, but you're only calling functions that aren't affected by the vulnerability, VEX lets you document that analysis. This is what auditors and regulators actually want to see: evidence of informed risk decisions, not just dependency lists.
Fourth, establish clear ownership. Who reviews SBOM data when a new vulnerability drops? Who decides whether a finding requires emergency patching? Who communicates with customers or regulators? These process questions matter more than which SBOM format you choose.
Finally, treat SBOMs as living documents. The EU CRA doesn't just require you to generate an SBOM once; it requires you to maintain it as your software changes. That means your SBOM generation needs to be automated and triggered by every build, not manually created during compliance reviews.
When the Conventional Wisdom Is Right
SBOMs are genuinely valuable when you use them correctly.
If you're a software vendor subject to the EU CRA, you do need to generate and maintain SBOMs. The regulation is explicit about this requirement, and you won't be able to sell into EU markets without compliance. The conventional wisdom is right that SBOM tooling is necessary.
SBOMs also provide real security value when you integrate them with vulnerability intelligence and use them to drive prioritization decisions. If you're evaluating open-source components for a new project, checking the SBOM of potential dependencies against known vulnerabilities is faster and more reliable than manual research.
For organizations with complex supply chains, SBOMs enable transparency that wasn't previously possible. If you're assembling software from multiple vendors and internal teams, having machine-readable SBOMs for each component lets you understand your aggregate risk profile in ways that manual documentation never could.
The problem isn't that SBOMs are useless. It's that compliance teams treat SBOM generation as sufficient when regulations require SBOM-informed action. Generate the SBOMs, absolutely. But don't stop there and claim you're compliant.
Your SBOM is a map. Having the map doesn't mean you've made the journey.
