SBOM (Software Bill of Materials) adoption remains critically incomplete: only a limited fraction of real-world SBOMs contain the minimum required information, despite regulatory mandates from the US and EU

Despite US Executive Order 14028 (May 2021) requiring SBOMs for federal software procurement, CISA's updated 2025 minimum elements expanding required metadata, and the EU Cyber Resilience Act making SBOMs legally mandatory for the EU market by December 2027, a 2025 academic study found that only a limited fraction of real-world SBOMs contain minimum or recommended information, and many are non-compliant with existing standards (SPDX, CycloneDX). Why it matters: incomplete SBOMs give organizations a false sense of security about their software composition, so when a vulnerability like Log4Shell is disclosed, companies cannot quickly determine if they are affected, so incident response takes weeks instead of hours (the average Log4Shell incident response cost was $90,000+), so regulators imposing SBOM requirements receive unusable data that does not actually improve supply chain security, so the entire SBOM ecosystem becomes a compliance checkbox exercise rather than a functional security tool. The structural root cause is that SBOM generation tooling cannot reliably detect all transitive dependencies across polyglot codebases (JavaScript, Python, Java, C/C++ mixed in one project), two competing standards (SPDX and CycloneDX) fragment the ecosystem, and open source projects themselves have no incentive or capacity to produce SBOMs because the mandate falls on commercial manufacturers who merely consume their code without funding SBOM creation upstream.