By October 2022, virtually every enterprise security leader had heard of SBOMs. Executive Order 14028 mandated them. NIST published guidance on them. The OpenSSL pre-announcement proved you need them. But hearing about SBOMs and actually implementing an effective SBOM program are very different things.
The reality: most organizations were still at what I'd call Level 0 — no SBOMs for any software, whether produced or consumed. To help organizations chart a practical path forward, here's a maturity model based on patterns we've observed across dozens of enterprise SBOM implementations.
Level 0: No SBOMs
Characteristics:
- No systematic software composition analysis
- Vulnerability management relies on scanner output without dependency context
- "What's in our software?" is answered with guesswork or manual investigation
- Response to incidents like Log4Shell takes weeks or months
- No ability to comply with SBOM requirements from customers or regulators
This is where approximately 70% of organizations sat in late 2022. The risk isn't theoretical — it's the reason organizations spent weeks scrambling during Log4Shell while those with SBOMs had their answers in hours.
Level 1: Ad Hoc SBOM Generation
Characteristics:
- SBOMs generated for some projects, usually manually or semi-automated
- No consistent format (mix of SPDX, CycloneDX, or custom formats)
- SBOMs created at a point in time, not continuously updated
- No centralized storage or management of SBOMs
- Generated primarily in response to specific customer requests
How to get here:
- Choose an SBOM standard (CycloneDX or SPDX)
- Install basic SCA tooling (Syft, Trivy, cdxgen, or similar)
- Generate SBOMs for your most critical applications
- Begin responding to customer SBOM requests
Common pitfalls:
- Generating SBOMs but never using them for vulnerability management
- Using tools that miss transitive dependencies
- Treating SBOM generation as a one-time activity
Level 2: Systematic SBOM Generation
Characteristics:
- SBOM generation integrated into CI/CD pipelines for all software products
- Consistent format and tooling across the organization
- SBOMs generated automatically with every build
- Basic vulnerability matching against SBOM contents
- SBOMs stored in a central repository
How to get here:
- Standardize on a single SBOM format and tooling
- Integrate SBOM generation into every CI/CD pipeline
- Implement a central SBOM repository
- Set up automated vulnerability matching against generated SBOMs
- Establish a process for including SBOMs in software deliveries
Key metrics at this level:
- Percentage of products with automated SBOM generation
- SBOM completeness (are transitive dependencies captured?)
- Time from vulnerability disclosure to impact assessment
Level 3: SBOM-Driven Vulnerability Management
Characteristics:
- Vulnerability management process is driven by SBOM data
- Continuous monitoring of SBOM contents against vulnerability databases
- VEX integration to filter noise and prioritize genuine risks
- SBOM data used in incident response (rapid impact assessment)
- Both produced and consumed software have SBOMs
How to get here:
- Implement continuous vulnerability monitoring across all SBOMs
- Begin generating VEX documents for your software products
- Ingest SBOMs from third-party software vendors
- Integrate SBOM data into your incident response playbooks
- Train security analysts to use SBOM data for triage and assessment
This is the level where SBOMs start delivering measurable security value. Before Level 3, SBOMs are primarily a compliance artifact. At Level 3, they become an operational security tool.
Level 4: Supply Chain Risk Management
Characteristics:
- SBOM data integrated into supply chain risk assessment
- Policy-based governance of dependencies (allowed/blocked components, license compliance)
- SBOM-driven risk scoring for software products and suppliers
- Provenance verification for consumed components (Sigstore, SLSA)
- Regular reporting to leadership on supply chain risk posture
How to get here:
- Define policies for acceptable dependencies (security, licensing, maintenance status)
- Implement automated policy enforcement in CI/CD pipelines
- Begin verifying build provenance for critical dependencies
- Establish supply chain risk metrics and reporting
- Integrate SBOM data into vendor risk assessments
What changes at this level: Dependencies are no longer just technical choices — they're risk decisions. Adding a new dependency triggers a risk assessment. Using a dependency with a known-bad license or an unmaintained project requires explicit justification.
Level 5: Full Supply Chain Transparency
Characteristics:
- End-to-end visibility from source code to deployed artifact
- Multi-level SBOMs capturing the full dependency graph including build tools and infrastructure
- Real-time supply chain risk dashboard
- Automated response to supply chain threats (automatic dependency updates, automated rollbacks)
- Active participation in ecosystem security (publishing VEX, contributing to upstream projects)
How to get here:
- Extend SBOMs to capture build environment and toolchain
- Implement automated remediation workflows
- Publish VEX documents and SBOMs for all software products
- Contribute to the security of upstream projects you depend on
- Establish threat intelligence feeds focused on supply chain threats
Few organizations reach Level 5. It requires significant investment in tooling, process, and culture. But it represents the state of the art in supply chain security.
Practical Considerations
Start with Produced Software
Most organizations find it easier to start by generating SBOMs for their own software products rather than demanding SBOMs from vendors. You control your build process, so you can instrument it. Getting SBOMs from third-party vendors requires contractual and relationship work.
Quality Over Coverage
A high-quality SBOM for your most critical application is more valuable than low-quality SBOMs for everything. Ensure your SBOM tooling captures transitive dependencies, accurately identifies component versions, and includes license information.
Automate From Day One
Manual SBOM generation doesn't scale and quickly becomes outdated. Even at Level 1, invest in automation. SBOM generation should be a CI/CD step, not a manual process run before release.
Don't Forget Containers and Infrastructure
Your application's SBOM should include the operating system packages in its container image, the base image lineage, and ideally the build tools used to compile it. An SBOM that only covers application-level dependencies misses a significant attack surface.
Plan for SBOM Consumption
Generating SBOMs is half the equation. You also need to consume SBOMs from your suppliers and process them through your vulnerability management pipeline. Build the consuming infrastructure early, even if you have few vendor SBOMs initially.
The Business Case
For security leaders building the business case for SBOM investment, the arguments are straightforward:
- Regulatory compliance: EO 14028, OMB M-22-18, EU CRA all require SBOM capability
- Incident response speed: Organizations with SBOMs resolved Log4Shell exposure in hours; those without took weeks
- Customer requirements: An increasing number of enterprise buyers are requesting SBOMs as part of procurement
- Cyber insurance: Insurers are beginning to factor software supply chain security into underwriting decisions
- Competitive advantage: In regulated industries, SBOM maturity is becoming a differentiator
How Safeguard.sh Helps
Safeguard.sh accelerates your journey through the SBOM maturity model regardless of your starting point. Our platform automates SBOM generation across languages and ecosystems, provides centralized SBOM management, integrates continuous vulnerability monitoring with VEX support, and enforces supply chain policies. Whether you're at Level 0 looking to generate your first SBOM or at Level 3 looking to implement policy-driven supply chain risk management, Safeguard.sh provides the tooling and intelligence to move up the maturity curve efficiently.