Maturity Levels

SBOM maturity isn't a simple yes-or-no proposition. Organizations progress through distinct capability levels, each characterized by different processes, automation levels, and business outcomes. Understanding these levels helps set realistic expectations, plan investments, and measure progress.

The framework defines two primary maturity levels aligned with the Content Requirements, extended here with operational characteristics that distinguish basic compliance from advanced operational capability.

Level 1: Basic (Compliance-Focused)

Level 1 represents the minimum viable implementation for regulatory compliance and basic customer transparency requirements. Organizations at this level can generate and share SBOMs but rely heavily on manual processes and human intervention.

Characteristics

Generation and Distribution: At Level 1, SBOM generation happens through a mix of automated scanning tools and manual enrichment. A software producer might use a tool like Syft or CycloneDX CLI to scan built artifacts, but then manually review and enhance the output with supplier information, license details, or dependency clarifications. Generation typically occurs at release milestones rather than continuously, and distribution happens through ad-hoc channels—email, customer portals, or shared folders—rather than systematic publication mechanisms.

The artifacts meet basic format requirements and contain essential fields like component names, versions, and supplier information, but may lack comprehensive metadata about tool provenance, build environments, or detailed pedigree information. Quality validation consists primarily of format checks ensuring the SBOM is valid JSON or XML that conforms to the CycloneDX or SPDX schema.

Vulnerability Management: VEX documents at Level 1 are created reactively—when customers ask about specific vulnerabilities or when regulatory deadlines demand disclosure. The analysis process is largely manual: security teams receive vulnerability notifications, manually check whether components exist in their products by searching SBOMs, and then write VEX statements documenting their findings. This reactive approach means time-to-disclosure for critical vulnerabilities can extend to days or weeks.

Organizations at this level struggle with the SBOM/VEX lifecycle coordination. They may regenerate SBOMs unnecessarily when vulnerabilities are discovered, or fail to update VEX documents after releasing patches because the connection between software releases and vulnerability status isn't systematically tracked.

Organizational Processes: Responsibility for SBOM generation often falls to a single team—usually either security or development—without clear handoffs or shared ownership. Documentation exists but may not be consistently followed, and there's no formal change management process for SBOM updates. When questions arise about SBOM accuracy or completeness, resolving them requires manual investigation and coordination across teams.

Typical Timeline

Organizations can reach Level 1 within 1-3 months if starting from scratch with basic development infrastructure. This timeline assumes existing version control, build processes, and some form of dependency management. Without these foundations, preparatory work extends the timeline to 3-6 months.

Business Outcomes at Level 1

Level 1 delivers fundamental transparency that enables:

• Meeting regulatory requirements like EU Cyber Resilience Act provisions for SBOM availability
• Responding to customer procurement requirements that mandate SBOM delivery
• Basic component inventory that supports manual vulnerability assessment
• Evidence for compliance audits demonstrating awareness of software composition

However, organizations at this level experience operational pain: high manual effort per SBOM generated, difficulty maintaining accuracy as software evolves, and limited integration with existing security workflows. The artifacts provide value but require significant human effort to produce and consume.

Level 2: Advanced (Operations-Focused)

Level 2 represents operational maturity where SBOM and VEX practices integrate seamlessly into development and security workflows. Organizations at this level treat software transparency as a continuous operational capability rather than a periodic compliance activity.

Characteristics

Generation and Distribution: At Level 2, SBOM generation is fully automated within CI/CD pipelines. Every build—not just releases—produces an SBOM, enabling continuous visibility into component changes. The automation extends beyond simple scanning to include systematic metadata enrichment: build environment details, tool versions, lifecycle phase indicators, and cross-references to related artifacts like container images or deployment manifests.

Quality gates enforce SBOM standards automatically. Pipeline checks validate not just format compliance but also completeness thresholds—ensuring required metadata is present, dependencies are fully enumerated, and component identifiers are correctly formatted. SBOMs failing quality checks block the pipeline, preventing releases with incomplete transparency artifacts.

Distribution happens through discoverable, versioned repositories with APIs enabling automated consumption. SBOMs are cryptographically signed as part of the build process, establishing provenance and integrity guarantees. Organizations maintain clear retention policies with automated archival after product EOL.

Vulnerability Management: VEX lifecycle management at Level 2 is policy-driven and largely automated. Monitoring systems detect new CVE publications, automatically query SBOM repositories to identify potentially affected products, and generate initial VEX documents with "under_investigation" status within hours of CVE disclosure. Security analysts receive alerts with draft VEX documents already populated with affected component details, allowing them to focus on impact analysis rather than artifact creation.

When patches are released, automated workflows update VEX documents to reflect "fixed" status, cross-referencing the specific software version containing the fix. The SBOM/VEX lifecycle is explicitly coordinated: release automation triggers both SBOM generation and VEX review to ensure vulnerability status remains synchronized with software versions.

Integration with security tools enables automated vulnerability correlation. When ingesting an SBOM, security platforms automatically query for associated VEX documents, presenting a complete picture of both component inventory and known vulnerability status. This integration accelerates incident response—during events like Log4j, organizations can identify affected systems within minutes rather than days.

Organizational Processes: Responsibility for SBOM/VEX practices is distributed across teams with clear ownership boundaries. Development owns SBOM generation quality, security owns VEX content accuracy, and operations manage distribution infrastructure. Regular reviews assess coverage metrics (percentage of products with automated SBOM generation), quality metrics (validation pass rates), and operational metrics (time from CVE disclosure to VEX publication).

Change management processes govern updates to SBOM generation tooling or VEX policies, ensuring changes don't compromise quality or introduce gaps. Documentation is maintained as code alongside implementation, enabling version control and systematic updates.

Typical Timeline

Progressing from Level 1 to Level 2 typically requires 6-12 months, depending on organization size and existing automation maturity. Smaller organizations with modern CI/CD infrastructure can achieve this faster, while larger enterprises with diverse technology stacks and legacy systems require longer transformation periods.

Business Outcomes at Level 2

Level 2 unlocks strategic value beyond compliance:

• Operational efficiency: Automated generation reduces per-SBOM effort from hours to minutes, enabling portfolio-wide coverage
• Accelerated incident response: Automated vulnerability correlation enables rapid impact assessment during security events
• Proactive security posture: Continuous SBOM generation reveals dependency changes before they reach production
• Supplier differentiation: Demonstrable transparency maturity provides competitive advantage in security-conscious markets
• Reduced audit burden: Comprehensive audit trails and automated evidence collection streamline compliance demonstration

Organizations at Level 2 experience SBOM and VEX as enablers rather than burdens, with transparency practices enhancing rather than hindering development velocity.

Progressive Improvement Strategy

Most organizations should target Level 1 initially, then systematically build toward Level 2. Attempting to achieve Level 2 immediately often fails due to missing foundations or underestimated complexity.

Phase 1 (Months 1-3): Achieve Level 1 Focus on demonstrating capability with pilot products. Select 1-3 representative applications, implement basic generation processes, and establish distribution channels. Accept manual processes initially while proving value and identifying automation opportunities. Use this phase to build organizational understanding and executive support for broader investment.

Phase 2 (Months 4-6): Expand Coverage Scale Level 1 practices across the product portfolio. Standardize tooling choices, document repeatable processes, and identify patterns that apply broadly versus edge cases requiring special handling. Build the business case for automation investment based on demonstrated manual effort and identified pain points.

Phase 3 (Months 7-12): Build Automation Systematically automate generation, validation, and distribution. Implement CI/CD integration for high-frequency release products first, then extend to slower-moving applications. Build VEX automation incrementally—start with detection and alerting, add draft generation, then enable policy-driven auto-publication for low-risk determinations.

Phase 4 (Months 13+): Optimize and Extend Refine quality thresholds based on operational data, extend coverage to complex scenarios like multi-repository systems, and integrate with advanced use cases like supply chain risk scoring or architecture optimization.

Measuring Progress

Track these indicators to assess maturity progression:

Coverage Metrics: Percentage of products with automated SBOM generation, percentage of SBOMs meeting Level 2 content requirements, percentage of known vulnerabilities with published VEX.

Quality Metrics: SBOM validation pass rate, component identification accuracy (validated through sampling), time from code commit to SBOM availability.

Operational Metrics: Time from CVE disclosure to VEX publication, manual effort hours per SBOM produced, percentage of SBOM generation failures requiring human intervention.

Business Metrics: Incident response time for vulnerability events, customer satisfaction with transparency practices, procurement cycle time for security-conscious buyers.

For detailed capability assessment, use the Assessment Tool which provides structured evaluation across all operational dimensions.

Common Maturity Mistakes

Mistake 1: Skipping Level 1 to jump directly to full automation

Organizations sometimes invest heavily in automation before understanding their requirements or proving basic capability. This leads to complex systems that automate incorrect processes, requiring expensive rework. Better to start simple, learn what works, then automate proven practices.

Mistake 2: Declaring Level 2 achievement based on technology alone

Having automated SBOM generation doesn't equal Level 2 if quality validation is absent, VEX lifecycle isn't coordinated, or organizational processes remain ad-hoc. True maturity encompasses technology, process, and organization—not just tools.

Mistake 3: Optimizing individual components without systemic thinking

Achieving perfect SBOMs while VEX practices remain immature, or vice versa, creates capability gaps. Progress toward Level 2 requires balanced advancement across generation, validation, distribution, and vulnerability management.

Mistake 4: Treating maturity as a destination rather than continuous improvement

Level 2 isn't the end state. As threats evolve, regulations expand, and technologies change, SBOM practices must adapt. Mature organizations continuously refine their capabilities rather than declaring victory at any particular level.

Next Steps

• Assess your current state using the Assessment Tool
• Review Choosing Your Starting Point to select appropriate initial workflows
• Understand investment requirements in Resource Planning
• Explore progression strategies in Maturity Progression Pathways