Three years after Executive Order 14028 put SBOMs on the map for most organizations, the question is no longer "what is an SBOM?" but "what are you actually doing with yours?" The answer, depending on who you ask, ranges from "running automated policy enforcement on every build" to "we generate one for compliance and never look at it again."
That gap — between SBOM generation and SBOM utility — is the defining challenge of 2026.
The Numbers Paint an Incomplete Picture
Industry surveys consistently report high SBOM adoption rates. Gartner's latest research suggests 72% of organizations with more than 500 employees now generate SBOMs for at least some of their software. The Linux Foundation's 2025 SBOM readiness survey put the number even higher at 78%.
But dig into the methodology and the picture changes. Most surveys count "we can produce an SBOM if asked" as adoption. That is like counting "we have a fire extinguisher" as a fire safety program. Generation without consumption, enrichment, and policy enforcement is compliance theater.
When you filter for organizations that actively consume and act on SBOM data — using it to make deployment decisions, track vulnerability exposure, or assess vendor risk — the number drops to roughly 25-30%. That is the real adoption figure, and it is the one that matters.
Where Generation Stands
The tooling for SBOM generation has matured significantly. Syft, Trivy, cdxgen, and Microsoft's SBOM Tool all produce high-quality CycloneDX or SPDX documents with minimal configuration. Most CI/CD platforms now offer native or near-native SBOM generation.
The remaining generation challenges are at the edges:
Firmware and embedded systems still lack reliable tooling. Binary analysis is imprecise, and many embedded teams build from source trees that do not map cleanly to package manager manifests.
Multi-language monorepos create SBOM sprawl. A single repository might contain Go, Python, TypeScript, and Rust components, each with its own dependency resolution. Producing a unified, accurate SBOM for the entire artifact requires careful orchestration.
Build-time vs. runtime discrepancies remain common. An SBOM generated from a lockfile reflects declared dependencies. An SBOM generated from a running container reflects what actually shipped. These two documents should match, but frequently do not due to build system quirks, multi-stage Docker builds, or vendored dependencies.
The Consumption Gap
Generation is the easy part. Consumption — actually using SBOM data to make decisions — is where most organizations stall.
The typical failure mode looks like this: a security team mandates SBOM generation, stores the documents in an S3 bucket or artifact registry, and then... nothing. No automated analysis. No policy gates. No vulnerability correlation. The SBOMs exist, they satisfy an audit requirement, and they gather digital dust.
Why does this happen? Three reasons:
Lack of tooling integration. Many vulnerability management platforms still treat SBOMs as a secondary data source rather than a primary one. If your security scanner does not natively ingest and correlate SBOM data, you are stuck building custom pipelines.
Volume overwhelm. An organization with 500 services generating SBOMs on every build produces thousands of documents per week. Without automated enrichment and prioritization, the data is unusable by human analysts.
Unclear ownership. SBOMs sit at the intersection of development, security, and compliance. When nobody owns the consumption workflow, nobody builds it.
Format Wars Are Over (Mostly)
The CycloneDX vs. SPDX debate has largely resolved itself through market dynamics rather than technical merit. CycloneDX dominates in application security contexts — it is the default output for most modern generation tools and the preferred input for most consumption platforms. SPDX maintains a strong position in license compliance and firmware analysis, bolstered by its ISO standard status (ISO/IEC 5962:2021).
In practice, most mature organizations support both formats and convert between them as needed. The tooling for format conversion has improved to the point where this is a solved problem for standard use cases.
VEX (Vulnerability Exploitability eXchange) adoption remains nascent. The specification is solid, but the operational workflows for generating and consuming VEX documents are still being established. Expect 2026 to be the year VEX moves from early adopter to early majority.
Regulatory Pressure Is Working
Say what you will about government mandates — they move markets. The combination of EO 14028, CISA's SBOM minimum elements guidance, the EU Cyber Resilience Act, and NIST SP 800-218 (SSDF) has created a compliance forcing function that vendors cannot ignore.
Federal contractors were the first movers, driven by procurement requirements. Healthcare followed, pushed by FDA premarket cybersecurity guidance that explicitly requires SBOMs for medical devices. Financial services adopted voluntarily, recognizing that SBOM-driven supply chain visibility reduces operational risk.
The next wave is manufacturing and critical infrastructure, driven by CISA's sector-specific guidance and the growing recognition that operational technology (OT) supply chains are just as vulnerable as IT supply chains.
Maturity Model
Based on our work with hundreds of organizations, we see five distinct maturity levels:
Level 1 — Ad hoc. SBOMs are generated manually or on request. No automation, no consumption.
Level 2 — Automated generation. SBOMs are produced in CI/CD pipelines for every build. Storage is automated. Consumption is manual or nonexistent.
Level 3 — Enrichment and analysis. SBOMs are automatically correlated with vulnerability databases. Security teams receive alerts for new exposures.
Level 4 — Policy enforcement. SBOM data drives automated deployment decisions. Policy gates block non-compliant builds. Vendor SBOMs are required and validated.
Level 5 — Continuous risk management. SBOMs are a core input to enterprise risk models. Real-time dashboards track exposure across the entire software portfolio. Reachability analysis reduces false positives. VEX documents are produced and consumed operationally.
Most organizations are at Level 2. The leaders are at Level 4. Almost nobody has reached Level 5 at scale.
Predictions for 2026
VEX will hit its tipping point. Enough tooling now supports VEX generation and consumption that early majority adoption becomes feasible. Expect major vulnerability databases to start publishing VEX data alongside traditional advisories.
SBOM-as-a-service will consolidate. The number of startups offering SBOM generation, enrichment, and management has reached saturation. Expect acquisitions and consolidation as the market matures.
Reachability analysis will become table stakes. Static analysis that determines whether a vulnerable function is actually called in your code will move from "nice to have" to "required" in most policy gate configurations.
Regulatory enforcement will sharpen. CISA has signaled that 2026 is the year they move from guidance to enforcement on federal SBOM requirements. Organizations that treated compliance as optional will feel the pressure.
How Safeguard.sh Helps
Safeguard meets organizations at whatever maturity level they are at and helps them move to the next one. If you are generating SBOMs but not consuming them, our enrichment engine and policy gates turn static documents into actionable intelligence. If you are already enforcing policies, our reachability analysis and Griffin AI help you cut through false positives and focus on the vulnerabilities that actually matter. The platform is designed to make SBOM consumption as easy as SBOM generation — because that is where the real security value lives.