Two years after Executive Order 14028 put Software Bills of Materials into the mainstream security vocabulary, and with the EU Cyber Resilience Act codifying SBOM requirements into law, you might expect SBOM adoption to be a solved problem by now. It is not.
Industry surveys and practitioner reports from 2024 paint a more complicated picture. SBOM awareness is near universal among security professionals. SBOM generation is increasingly common. But SBOM operationalization, actually using SBOMs to make security decisions, remains the exception rather than the rule.
Where SBOM Adoption Actually Stands
Multiple industry surveys conducted in 2024 provide a reasonably consistent picture:
SBOM generation: Approximately 60-70% of large enterprises (5,000+ employees) report generating SBOMs for at least some of their software. This is up from roughly 40% in 2023. However, "generating SBOMs for at least some software" is a low bar. When you dig deeper:
- Only about 25-30% generate SBOMs for all production software.
- Even fewer generate SBOMs that include transitive dependencies (the dependencies of your dependencies, which are where most vulnerabilities actually live).
- SBOMs for infrastructure components (operating systems, middleware, network appliances) are generated by fewer than 15% of respondents.
SBOM quality: The SBOMs being generated vary wildly in quality and completeness:
- Many SBOMs are generated only at the application level, missing container base images, OS packages, and runtime dependencies.
- Version accuracy is a persistent problem. SBOMs generated from package manifests (package.json, requirements.txt) may not reflect what is actually deployed if the deployment includes additional dependencies or different versions.
- Fewer than 20% of organizations include VEX (Vulnerability Exploitability eXchange) information with their SBOMs, meaning consumers cannot tell which vulnerabilities are actually exploitable in a given deployment.
SBOM consumption: This is where the gap is widest. Organizations that generate SBOMs often do not have processes to consume and act on them:
- Only about 30% of organizations that generate SBOMs also have automated processes to correlate SBOM contents against vulnerability databases.
- Even fewer (roughly 15%) have automated policy enforcement based on SBOM contents (e.g., blocking deployments with known-vulnerable components).
- Most organizations that receive SBOMs from third-party vendors report that they do not have the tooling to ingest, analyze, or monitor those SBOMs.
The Maturity Spectrum
Based on the survey data and practitioner conversations, organizations fall into roughly four maturity levels:
Level 0 - Unaware (roughly 10%): No SBOM generation, no awareness of requirements. These are primarily smaller organizations or those in less regulated industries.
Level 1 - Compliant (roughly 40%): Generate SBOMs for compliance purposes (responding to customer questionnaires, meeting federal requirements). SBOMs may be incomplete, generated manually or semi-automatically, and stored as static documents. No operational use of SBOM data.
Level 2 - Integrated (roughly 35%): SBOM generation is integrated into CI/CD pipelines. SBOMs are generated automatically for each build and correlated against vulnerability databases. Alerts are generated for known-vulnerable components. However, policy enforcement and remediation workflows are still largely manual.
Level 3 - Operational (roughly 15%): Full SBOM lifecycle management. SBOMs are generated continuously, correlated against multiple vulnerability sources, enriched with VEX information, and used to drive automated policy decisions. SBOM data informs procurement decisions, deployment gates, and incident response.
What Is Blocking Progress
Several factors are slowing SBOM adoption and operationalization:
Tooling fragmentation: The SBOM ecosystem includes multiple formats (CycloneDX, SPDX), multiple generation tools (Syft, Trivy, FOSSA, Snyk), and inconsistent output quality. Organizations struggle to standardize on a toolchain.
Transitive dependency completeness: Generating an accurate, complete SBOM that includes all transitive dependencies is harder than it sounds. Build systems, package managers, and deployment pipelines all have nuances that affect dependency resolution. A package manifest lists what you asked for, not necessarily what got installed.
Infrastructure coverage gaps: Most SBOM tools focus on application dependencies. Coverage for operating system packages, container base images, firmware, and network appliances is less mature. Yet these are often where the most critical vulnerabilities live (CrowdStrike, OpenSSH regreSSHion, VPN appliance CVEs).
VEX adoption: Without VEX information, a raw SBOM vulnerability report generates massive amounts of noise. If your SBOM shows 200 vulnerable components but only 5 are actually reachable and exploitable, you need VEX to tell the difference. VEX tooling and processes are still immature.
Organizational silos: SBOM generation is often owned by engineering, while SBOM consumption is owned by security. Without cross-functional processes, the SBOM sits in a repository unused.
Third-party SBOM quality: Organizations that request SBOMs from their software vendors often receive documents that are incomplete, in non-standard formats, or clearly auto-generated without review. The lack of SBOM quality standards makes vendor SBOMs difficult to consume meaningfully.
Regulatory Pressure as a Catalyst
The regulatory environment is the primary driver of SBOM adoption:
US Federal: Executive Order 14028 and OMB M-22-18 require software suppliers to the federal government to provide SBOMs and self-attestation of secure development practices. Enforcement is tightening, with agencies beginning to include SBOM requirements in procurement evaluations.
EU Cyber Resilience Act: The CRA mandates SBOM provision for products with digital elements sold in the EU. While full enforcement is not expected until 2027, organizations need to begin building SBOM capabilities now to meet compliance deadlines.
Industry-specific requirements: Financial services (DORA), healthcare (FDA guidance on medical device SBOMs), and automotive (UNECE WP.29) all have emerging or established SBOM requirements.
The regulatory trajectory is clear: SBOMs will be mandatory for software in regulated markets. The question is not whether to adopt SBOMs but how to make them operationally useful rather than just compliance artifacts.
From Compliance to Value
The organizations at Level 3 maturity report tangible security benefits from their SBOM programs:
Faster incident response: When a new vulnerability is disclosed, they can identify affected systems in minutes rather than days. During the CrowdStrike outage, organizations with comprehensive SBOMs knew exactly which systems were running the Falcon sensor and could prioritize recovery.
Better procurement decisions: SBOM data informs vendor evaluations, identifying suppliers with excessive dependencies, outdated components, or poor vulnerability management practices.
Reduced vulnerability fatigue: VEX-enriched SBOMs filter vulnerability reports to show only actionable findings, reducing alert volume by 60-80%.
Regulatory readiness: When auditors ask about supply chain security, these organizations can produce comprehensive, current documentation instantly.
How Safeguard.sh Helps
Safeguard.sh is designed to take organizations from Level 1 compliance to Level 3 operational maturity.
- Automated SBOM generation integrates into your CI/CD pipeline, producing comprehensive SBOMs that include application dependencies, container base images, and infrastructure components.
- Continuous vulnerability correlation maps your SBOM contents against multiple vulnerability databases in real time, providing actionable alerts rather than static reports.
- VEX management enriches vulnerability findings with exploitability context, reducing noise and helping your team focus on the vulnerabilities that actually matter.
- Policy engine transforms your SBOM data into automated governance, blocking deployments with unacceptable risk and enforcing dependency management standards.
An SBOM that sits in a file share is a compliance artifact. An SBOM that drives security decisions is a force multiplier. Safeguard.sh makes the difference.