Why Your SBOM Does Not Protect You (and What Is Missing)

You have an SBOMSoftware Bill of MaterialsA machine-readable inventory of the components and dependencies included in a software product.. Your scanner runs nightly, your compliance team checks the box, and your next audit will go smoothly. Here is the part no one mentions: nine out of ten alerts that scanner fires are false positives, and the ones that survive come with no deployment context, no exploitability assessment, and no owner.

Your SBOM tells you what is inside your software. It says nothing about what is actually at risk.

Inventory is not security

I have sat in enough incident rooms to know the first question is never “what components do we have?” It is “is this thing running in production, and can an attacker reach the vulnerable code path?” An SBOM answers the first question. It is silent on the second.

The ENISAEuropean Union Agency for CybersecurityThe EU agency responsible for cybersecurity policy, incident response coordination, and security certification frameworks. 2026 adoption survey puts this in numbers. 78% of organizations have started generating SBOMs. Only 7% have closed the gap between generating them and actually using them for security decisions. 44% report a moderate gap. 39% never receive SBOMs from their commercial software suppliers. That is not a tooling problem. That is an industry treating inventory as the finish line.

When Log4Shell hit in December 2021, teams with SBOMs found pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1 in their inventory within hours. Good. But 60% of affected Java projects pulled Log4j as a transitive dependency — invisible in a direct dependency scan. And knowing you had Log4j did not tell you whether the JNDI lookup code path was reachable in your deployment, whether your WAF configuration blocked the exploit vector, or who was responsible for deciding what to do next.

Three years later, 13% of Log4j downloads still pull vulnerable versions (Sonatype, 2024). The SBOM did not fix that. Ownership did.

Nine out of ten alerts are noise

A 2026 study by Zhou, Dacier, and Konstantinou (ICSE 2026) analyzed 2,414 repositories across Python, Rust, Ruby, PHP, and Go. Their finding: SBOM-based vulnerability scanners produce a 92% false positive rate. Not an approximation. Measured.

The reason is structural. A scanner matches a component name and version against a CVECommon Vulnerabilities and ExposuresA standardized identifier for a publicly disclosed cybersecurity vulnerability. database. It cannot tell whether the vulnerable function is called in your code path. 95% of flagged vulnerabilities sit in transitive dependencies — libraries your direct dependencies pulled in, two or three levels deep. Your application may never invoke the affected code. But the alert fires anyway, and someone has to triage it.

I think the most damaging effect is not the wasted hours. It is the learned helplessness. When your team sees a hundred alerts a week and most of them are noise, they stop trusting the signal. The one real vulnerability that needs immediate action gets the same tired glance as the ninety-two false positives that came before it.

The same ICSE study showed that function call reachability analysis prunes 61.9% of those false alarms. In Go projects, 74.4%. The technology exists. Most organizations have not plugged it into their pipeline.

What sits between inventory and a decision

Four layers are missing between your SBOM and an actionable security decision. Each answers a question the SBOM cannot. When the artifact is an ML model rather than a container image, the same gap applies — CycloneDXCycloneDXAn OWASP standard for software bill of materials that supports component inventory, vulnerability reporting, and VEX. ML-BOMMachine Learning Bill of MaterialsAn extension of the software bill of materials concept that inventories ML models, training datasets, and inference dependencies. extends the concept to models, datasets, and inference dependencies (MLSecOps: Securing ML Models Beyond AppSec covers that extension).

Exploitability context (VEXVulnerability Exploitability eXchangeA security advisory that communicates whether vulnerabilities affect a specific product and why.). A Vulnerability Exploitability eXchange statement is the supplier telling you: “yes, this CVE affects our product” or “no, we use Log4j but the vulnerable code path is not exercised.” Microsoft started publishing machine-readable VEX for Azure Linux in October 2025. The OpenSSFOpen Source Security FoundationA Linux Foundation project that coordinates cross-industry efforts to improve open-source software security.’s January 2026 cross-vendor assessment describes VEX adoption as “more like a promise than a practice.” Four competing formats exist (CSAFCommon Security Advisory FrameworkAn OASIS standard for machine-readable security advisories, used as one of the formats for publishing VEX statements., OpenVEXOpenVEXAn open specification for creating and distributing Vulnerability Exploitability eXchange documents in a minimal, interoperable format., CycloneDX, SPDXSoftware Package Data ExchangeAn ISO standard (ISO/IEC 5962:2021) for communicating software bill of materials information, including component identities and licenses. 3.0). No standard discovery protocol. But the principle is sound: the producer knows whether their product exercises the vulnerable path. Without VEX, every consumer repeats that analysis independently. I examine VEX justification flags and their limits in VEX: Documenting “Not Exploitable”.

Reachability analysis. Static or dynamic analysis that determines whether the vulnerable function is called in your specific build. The ICSE 2026 data shows it works. The question is whether you are using it. If you are not, you are triaging alerts that a five-minute call graph traversal would have dismissed. The evidence chain connecting these layers is the subject of Building a DevSecOps Evidence Chain.

Build provenance. An SBOM lists components. It does not tell you whether the binary you are running was built from the source code you reviewed. The XZ Utils backdoor (CVE-2024-3094) proved this in March 2024: an attacker spent two years building trust as a co-maintainer, then injected malicious code during the build process. The SBOM correctly listed XZ Utils. The binary was compromised. SLSASupply-chain Levels for Software ArtifactsA security framework that defines levels of assurance for how software artifacts are built, from source to binary.-level build provenance — cryptographic attestation of how an artifact was built — is the layer that catches this. Without it, your SBOM is a menu. You have no guarantee the kitchen served what is on it.

Deployment context. The 3CX supply chain attack in March 2023 distributed trojanized updates through the official signed update channel. The SBOM was technically accurate. It listed every legitimate dependency. The malicious payload was injected after the inventory was generated. Knowing what is in the build means nothing if you cannot verify what is running in production and whether the deployed artifact matches the build record.

Regulation demands the full chain

If your argument for stopping at the SBOM is compliance, that argument already fails.

The EU Cyber Resilience Act (Regulation 2024/2847) mandates SBOMs in technical documentation. But it also mandates a vulnerability handling process, 24-hour initial notification to ENISA for actively exploited vulnerabilities (starting September 11, 2026), and security updates throughout the product lifecycle. An SBOM without those capabilities does not meet CRACyber Resilience ActEuropean Union legislation establishing cybersecurity requirements for products with digital elements. requirements. It meets one line item. I break down the operational requirements in What the Cyber Resilience Act Changes for Software Vulnerability Management.

CISACybersecurity and Infrastructure Security AgencyThe United States federal agency responsible for cybersecurity guidance, vulnerability coordination, and critical infrastructure protection.’s own July 2026 guidance on minimum SBOM elements states it plainly: SBOMs “will not resolve all software security and supply chain concerns.” The agency that wrote the standard is telling you the standard is not enough.

I have seen organizations treat “we have an SBOM” as the end of the conversation with their board. That works until an auditor asks a follow-up question: “Show me the decision record for CVE-2024-3094. Who assessed exploitability? What was the deployment status? When was the decision made, and by whom?” If the only answer is a component list, the conversation gets uncomfortable fast.

What to do next

Pick the next vulnerability alert that lands in your queue. One alert, one service.

Trace it from inventory to deployment. From SBOM to Actionable Signal walks through this exercise step by step. Does your SBOM identify the component? Good. Is the vulnerable function reachable in your code path? Does a VEX statement from the supplier exist? Is the affected artifact actually running in production, and can you prove it with a deployment record? Who decides what to do, and by when?

Document the answer. Every step, with the raw evidence. If a second reviewer cannot reconstruct your decision from that record alone, the process is not done.

That single traced finding will show you every gap between your SBOM and an actual security posture. It will also show you it is closable. Not with a platform purchase. With a decision record, an owner, and the discipline to stop treating inventory as security.