Ask ten security leaders about their software supply chain security posture, and you will get ten different answers -- most of them vague. "We use Dependabot." "We scan containers." "We are working on SBOMs." These are activities, not a posture assessment. They tell you what tools are running but nothing about coverage, consistency, or whether any of it would withstand a determined attacker.
The problem is that software supply chain security spans so many domains -- dependency management, build integrity, artifact provenance, vulnerability management, license compliance, vendor risk -- that organizations struggle to see the complete picture. They excel in one area and have blind spots in others.
This article presents a maturity framework organized around six capability domains. It is not theoretical. It is based on patterns observed across organizations ranging from startups to Fortune 500 enterprises, and it maps to existing standards like SLSA, SSDF, and the CISA SBOM guidance.
The Six Capability Domains
1. Software Bill of Materials (SBOM)
Level 1 -- Ad Hoc: SBOMs are generated manually or not at all. No standardized format. SBOMs exist for some projects but not others.
Level 2 -- Repeatable: SBOMs are generated automatically for most applications using CycloneDX or SPDX. Generation is part of the build process, but SBOMs may not be stored or shared consistently.
Level 3 -- Defined: SBOM generation is mandatory for all production software. SBOMs are stored in a central repository, versioned alongside releases, and shared with customers or partners on request. SBOMs include dependency trees, licenses, and component hashes.
Level 4 -- Managed: SBOMs are continuously monitored against vulnerability databases. New CVEs are automatically correlated with deployed SBOMs to identify affected products. VEX documents are generated to communicate exploitability status to consumers.
Level 5 -- Optimizing: SBOM data drives strategic decisions. Dependency risk scores influence component selection. Historical SBOM data reveals trends in dependency health. SBOM quality metrics (completeness, accuracy, freshness) are tracked and improved.
2. Build Integrity and Provenance
Level 1 -- Ad Hoc: Builds run on developer laptops or shared CI servers with no access controls. Build scripts are not version-controlled. No attestation of build provenance.
Level 2 -- Repeatable: Builds run in CI/CD pipelines with version-controlled build scripts. Build environments are somewhat controlled but not fully isolated. No cryptographic provenance.
Level 3 -- Defined: Builds run in ephemeral, isolated environments. Build inputs and outputs are logged. SLSA Level 2 provenance attestations are generated and distributed alongside artifacts.
Level 4 -- Managed: Hermetic builds with fully declared dependencies. SLSA Level 3 provenance with non-falsifiable attestations from a hardened build platform. Build policies are enforced automatically.
Level 5 -- Optimizing: SLSA Level 4 or equivalent. Two-party review of all build configuration changes. Build provenance is verified at every deployment point. Anomalous build behavior triggers automated investigation.
3. Dependency Management
Level 1 -- Ad Hoc: Dependencies are added without review. No inventory of direct or transitive dependencies. No process for evaluating dependency health or maintainer trustworthiness.
Level 2 -- Repeatable: Direct dependencies are tracked. Automated tools (Dependabot, Renovate) create update PRs. Some awareness of transitive dependencies but no systematic management.
Level 3 -- Defined: Complete dependency inventory including transitive dependencies. Dependency health metrics (maintainer activity, security history, bus factor) are evaluated before adoption. Private registries or proxies provide a controlled dependency source.
Level 4 -- Managed: Dependency updates are risk-assessed before merging. Malicious package detection is in place. Dependency pinning and lock files are enforced. Critical dependencies are mirrored or vendored to protect against upstream removal.
Level 5 -- Optimizing: Proactive dependency risk management. Dependencies approaching end-of-life are identified and migration-planned before they become problems. The organization contributes security improvements back to critical dependencies.
4. Vulnerability Management
Level 1 -- Ad Hoc: Vulnerability scanning is sporadic or absent. Findings are triaged manually based on CVSS scores. No SLAs for remediation.
Level 2 -- Repeatable: Automated scanning runs in CI/CD. CVSS-based prioritization with defined SLAs. Some vulnerabilities are tracked to resolution, but coverage is incomplete.
Level 3 -- Defined: Comprehensive scanning across source code, dependencies, containers, and infrastructure. EPSS scores supplement CVSS for prioritization. Vulnerability status is tracked across the full lifecycle from discovery to remediation.
Level 4 -- Managed: Reachability analysis filters false positives. VEX documents communicate exploitability status. Remediation is partially automated (auto-merge for low-risk dependency updates). Mean time to remediate is measured and tracked.
Level 5 -- Optimizing: Predictive vulnerability management. Historical data identifies which components are most likely to have future vulnerabilities. Remediation automation handles the majority of routine updates. Exceptional vulnerabilities receive focused human analysis.
5. Artifact Security
Level 1 -- Ad Hoc: Artifacts (container images, packages, binaries) are stored without access controls. No signing or verification. No scanning of artifacts before deployment.
Level 2 -- Repeatable: Artifacts are stored in managed registries with access controls. Container images are scanned for vulnerabilities. Some artifacts are signed but verification is not enforced.
Level 3 -- Defined: All production artifacts are signed with verifiable signatures (Sigstore/cosign or equivalent). Artifact scanning is mandatory before deployment. Base images are maintained and updated regularly.
Level 4 -- Managed: Artifact provenance is verified at deployment time. Only artifacts with valid signatures and passing policy checks can be deployed. Admission controllers enforce artifact policies in Kubernetes and other runtime environments.
Level 5 -- Optimizing: Minimal base images (distroless, scratch) reduce attack surface. Runtime artifact integrity monitoring detects tampering. Artifact lineage is fully traceable from source code to production deployment.
6. Incident Response for Supply Chain Attacks
Level 1 -- Ad Hoc: No specific playbook for supply chain incidents. Response would rely on general incident response procedures, which may not address supply chain-specific challenges.
Level 2 -- Repeatable: Basic awareness of supply chain attack scenarios. Some documentation of dependencies that would need investigation. Ad hoc communication with upstream suppliers during incidents.
Level 3 -- Defined: Documented playbooks for common supply chain attack scenarios (compromised dependency, build system breach, malicious package). Ability to quickly identify all products and deployments affected by a compromised component using SBOM data.
Level 4 -- Managed: Tabletop exercises for supply chain attack scenarios. Automated impact assessment using SBOM correlation. Established communication channels with critical upstream suppliers and downstream consumers. Mean time to identify affected products is measured.
Level 5 -- Optimizing: Continuous supply chain threat intelligence. Proactive monitoring of upstream dependency security. Automated containment actions for known-compromised components. Post-incident analysis feeds back into preventive controls.
Assessment Approach
Self-Assessment Process
For each domain, evaluate your organization honestly against the level descriptions. The goal is accuracy, not aspiration. If you are between levels, round down.
Most organizations find they are unevenly distributed. A Level 4 in vulnerability management but Level 1 in build integrity is common. These gaps represent your highest-value improvement opportunities.
Prioritizing Improvements
Not all domains are equally important for every organization. Prioritize based on:
Regulatory requirements: If you supply software to US federal agencies, SBOM and attestation capabilities are non-negotiable. If you operate in healthcare or finance, vulnerability management SLAs are likely mandated.
Threat landscape: If your primary risk is compromised dependencies (as it is for most organizations consuming open source), dependency management and vulnerability management should be prioritized. If you distribute software to others, build integrity and artifact security become critical.
Current gaps: The domain where you have the lowest maturity level often represents the highest-impact improvement opportunity. Moving from Level 1 to Level 2 in any domain typically requires less effort than moving from Level 3 to Level 4, and the risk reduction is often greater.
Setting Realistic Targets
Level 5 across all domains is aspirational for nearly everyone. For most organizations, a practical target is:
- Level 3 across all domains (the "defined" baseline).
- Level 4 in the two or three domains most relevant to your risk profile.
- Level 5 only where you have specific regulatory or business requirements.
This provides a strong foundation without requiring the organizational maturity and tooling investment that Level 5 demands.
How Safeguard.sh Helps
Safeguard addresses multiple domains in this maturity framework through a single platform. For SBOM maturity, it automates generation, storage, versioning, and continuous monitoring against vulnerability databases. For vulnerability management, it integrates CVSS, EPSS, and reachability analysis to enable risk-based prioritization. For artifact security, it supports container image scanning and SBOM generation for deployed artifacts.
The platform's policy engine maps directly to organizational security standards, enabling the policy-as-code approach required at Level 3 and above. And the centralized dashboard provides the visibility needed to track maturity improvements over time, showing trends in SBOM coverage, vulnerability remediation velocity, and policy compliance across your entire software portfolio.
Organizations using Safeguard typically accelerate from Level 1-2 to Level 3-4 significantly faster than those assembling point solutions, because the integrated platform eliminates the integration overhead that slows most supply chain security programs.