94.9% of Vulnerable Components Have a Fix Available. Most Organizations Never Apply It.

Your Software Bill of Materials (SBOM) told you what's vulnerable. The question is what happened next.

The Compliance Checkbox That Doesn't Protect You

Regulations told you to generate SBOMs. You did. Executive Order 14028 set the expectation. Your team integrated SBOM generation into the CI/CD pipeline. The inventory exists. The compliance checkbox is checked.

Your risk profile hasn't changed.

Data from Sonatype's 2024 State of the Software Supply Chain report found that 94.9% of vulnerable components downloaded had a fixed, non-vulnerable version available. The patches exist. Organizations aren't applying them. More than four years after its discovery, 13% of Log4j downloads are still for known vulnerable versions.

Security researcher Dan Lorenc captured the frustration directly: the industry is producing "SBOM theater" where "actual security has not been brought about." The inventory is comprehensive. The remediation is not.

This isn't an argument against SBOMs. They're foundational. But understanding SBOM limitations means recognizing that confusing transparency with protection is a mistake regulators are no longer willing to accept.

What Do SBOM Tools Actually Do Well?

SBOMs solve a specific problem, and the value is real.

Transparency. Before SBOMs, most organizations couldn't answer a basic question: what software components are running in production? SBOMs provide a machine-readable answer. When the next Log4Shell drops, organizations with comprehensive SBOMs can identify affected systems in minutes rather than weeks.

Compliance documentation. EO 14028 requires federal software suppliers to provide SBOMs. The EU Cyber Resilience Act mandates component documentation. PCI DSS 4.0 requires software inventories. For regulated industries, SBOMs are table stakes for market access.

Dependency mapping. Modern applications average over 1,200 dependencies (per OpenSSF's 2025 analysis), a 30% increase from the prior year. Of those, 64% are transitive dependencies that your developers never explicitly chose. SBOMs reveal this hidden attack surface, showing where risk lives three or four layers deep in your dependency graph.

Zero-day response. CISA describes SBOMs as a "roadmap for the defender," providing "machine-readable decision support" to instantly scope impact when a new vulnerability disclosure drops. This is operational value that justifies SBOM investment on its own.

Getting More from the SBOMs You Already Generate

If you're generating SBOMs but not using them operationally, three changes make a difference:

The Regulatory Shift You May Have Missed

Early SBOM mandates focused on transparency. Newer ones explicitly require remediation. The direction is accelerating.

EO 14028 (May 2021) started the conversation by mandating that federal agencies obtain SBOMs for critical software. The primary requirement centered on producing and sharing SBOMs, with NIST and NTIA defining minimum elements. It urged "quick identification and remediation of vulnerabilities," but the enforcement focus was on inventory creation.

FDA 2023 Omnibus Bill (effective March 2023) marked a turning point. For medical devices, it mandates not just providing an SBOM but also a "plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits." Manufacturers must "make available postmarket updates and patches." This is explicit: inventory alone doesn't satisfy the requirement.

EU Cyber Resilience Act (in force December 2024, most requirements by December 2027) goes further. Manufacturers must "identify and document vulnerabilities and components" and "handle vulnerabilities, and deliver patches in a timely manner," including providing free security updates. SBOMs are the foundation for identifying vulnerabilities under CRA, but compliance requires demonstrating that you're fixing them.

PCI DSS 4.0 (mandatory March 2025) states that software inventory is "used to identify and address vulnerabilities." Requirement 11.3.1.1 mandates managing all vulnerabilities found during scans. The inventory is the input. Remediation is the expected output.

DoD SBOM requirements (Army mandate by February 2025) tie SBOMs to the Pentagon's Software Fast Track initiative, using them as inputs for risk evaluation to determine digital Authority to Operate (ATO) status. No mitigation, no authorization.

The regulatory trajectory is clear. "Show us what's inside your software" is becoming "show us you're fixing what's inside your software."

What SBOM Limitations Prevent Risk Reduction?

Three structural problems explain why comprehensive SBOMs don't translate to reduced vulnerability counts.

The noise problem is massive. A 2023 study by Imtiaz et al. documented a 97.5% false positive rate in SBOM-based vulnerability management pipelines. Vulnerabilities flagged in unreachable code are the primary driver. Your SBOM correctly identifies a component. The vulnerability database correctly flags a CVE. But your application never calls the vulnerable function.

Call-graph-based reachability analysis can eliminate approximately 63% of these false alarms, but most organizations aren't running that analysis. They're triaging every match manually, or worse, ignoring the results entirely because the signal-to-noise ratio destroyed their team's trust in the process.

Remediation timelines are measured in quarters, not days. Even when vulnerabilities are identified and confirmed as exploitable, the mean time to remediate for some projects exceeds 400 days. Critical vulnerabilities in 2024 took over 500 days to fix in certain open source projects (per Sonatype's analysis). Your SBOM surfaced the finding. The fix took a year and a half.

Dependency complexity makes fixes non-trivial. SCA remediation at scale is where most automation breaks down. A 2024 Synopsys report found that 77% of code in commercial codebases is open source. With most components being transitive dependencies that your developers never explicitly chose, and transitive dependencies accounting for nearly half of high-risk vulnerabilities, the fix path is rarely "upgrade component X." It's "upgrade component X, verify compatibility across 47 downstream consumers, test for breaking changes in components Y and Z that depend on the old API, and hope the maintainer has actually published a patched version."

Your SBOM provides excellent visibility into what's vulnerable. Your remediation process can't keep pace with what it reveals.

When Are SBOMs Enough on Their Own?

For certain functions, SBOMs without a downstream remediation layer serve their purpose well.

Audit and compliance documentation. If your auditor asks "what open source components are in this application?" the SBOM is the complete answer. For SOC 2, ISO 27001, and regulatory examinations, SBOM generation satisfies the inventory requirement.

Zero-day scoping. When a new critical vulnerability is disclosed, the SBOM lets you answer "are we affected?" in minutes. This incident response value is real and doesn't require automated remediation.

Vendor risk assessment. Requiring SBOMs from third-party software suppliers lets your procurement team evaluate supply chain risk before purchase. The SBOM is a due diligence input, not a remediation trigger.

Low-volume environments. If your team manages a small number of applications with manageable dependency counts, manual remediation may scale adequately. Not every organization needs automated fix tools.

As with ASPM, the real question is whether your SBOM is the final piece of your supply chain security program or the foundation for one.

Where Do Fix Tools Fall Short?

Automated remediation tools — sometimes called resolution platforms — are a relatively new category, and they carry their own limitations. Legacy codebases with no test coverage make automated fixes risky to merge. Monorepo architectures create cascading dependency conflicts that most tools can't resolve cleanly. Custom frameworks and proprietary libraries sit outside the coverage of any automated fix engine. And zero-day vulnerabilities with no published patch are unfixable regardless of tooling.

The evaluation criteria below are designed to help you navigate these trade-offs honestly.

How Do You Evaluate Fix Tools?

If you've decided your SBOM workflow needs a remediation layer, here are seven questions to evaluate any tool claiming to close that gap. These apply whether you're looking at SCA platforms with fix capabilities, specialized remediation tools, or SBOM-first platforms adding automated patching.

1. Does it resolve vulnerabilities or just flag them?

The spectrum runs from "generates a report" to "generates a pull request." Flagging tools add value if your team has capacity to act on findings. But if your backlog is growing despite having comprehensive vulnerability data, flagging isn't the constraint. Fixing is.

2. Can it handle transitive dependency chains?

Most components in a modern application are transitive, meaning the upgrade path for most vulnerabilities involves multiple layers of your dependency graph. A tool that bumps a direct dependency but can't navigate transitive chains will solve the straightforward minority and leave the dangerous majority untouched. Ask how the tool resolves conflicts when upgrading a transitive dependency requires changes to intermediate packages.

3. Does it filter by reachability or exploitability before suggesting fixes?

If the tool fixes every CVE match without reachability analysis, you're automating the noise problem at industrial scale. Look for tools that determine whether the vulnerable function is actually called in your code path before generating a fix. This is the difference between fixing 2,000 findings and fixing the 50 that matter.

4. What's the merge rate on generated fixes?

Developer trust is the ultimate validation. A tool that generates fixes nobody merges is an expensive alert generator. Ask for merge rate data across real production codebases. Ask about the denominator. Ask what happens when a generated fix fails a test suite.

5. Does it support your language ecosystems and SCM platform?

A tool that handles Java and JavaScript but not your Go or Rust services creates coverage gaps you'll need to fill manually. Similarly, verify support for your specific source control platform (GitHub, GitLab, Bitbucket) and your package manager lock file formats. Ecosystem breadth matters more than demo polish.

6. What types of vulnerabilities does it NOT fix?

Every automated fix tool has blind spots. Dependency bumps are the easiest; SAST code-level fixes are harder; architectural vulnerabilities (broken authentication, insecure data flows) are beyond any current automation. Ask explicitly about coverage boundaries. A tool that's honest about what it can't do is more trustworthy than one that claims universal coverage.

7. Does it integrate with your SBOM workflow or replace it?

The strongest architecture builds on your existing SBOM investment, not around it. Look for tools that consume SBOM data as an input, layer reachability and exploitability analysis on top, and produce fixes for the findings that survive filtering. A mature stack looks like this:

Each layer adds intelligence. Skipping layers, especially reachability analysis, means you're either fixing everything (wasteful) or fixing nothing (risky).

The Compliance Math That Matters

Here's a two-minute exercise for your next executive review.

Pull two numbers:

That ratio tells you whether your SBOM program is a security program or a documentation program.

Regulators are increasingly asking the same question. The FDA doesn't ask "do you have an SBOM?" It asks "what's your plan to address what the SBOM reveals?" The EU CRA doesn't accept inventory without timely patches. PCI DSS 4.0 explicitly connects inventory to remediation.

Your SBOM answered the transparency question. Most organizations are treating that answer as the finish line. The regulators aren't. Neither should you.

If your remediation ratio is below 50%, your SBOM program is a documentation program — not a security program. The inventory was never the hard part. Fixing what the inventory reveals is.

Related reading: