Supply Chain draft

Control over software supply chain, dependencies, and third-party components

L0 Unaware

No visibility into software dependencies or third-party components; no SBOM exists and supply chain risks are unquantified

Criteria

SUPPLY-L0-C1 The organisation has no Software Bill of Materials (SBOM) and cannot enumerate its third-party dependencies
SUPPLY-L0-C2 Dependencies are pulled directly from public registries at build time with no pinning, verification, or caching

Indicators

Developers install packages from public registries without reviewing licenses, maintainers, or known vulnerabilities
No process exists to evaluate the trustworthiness of new dependencies before adoption

Upgrade path

Implement basic dependency tracking by generating SBOMs for all production applications. Introduce dependency pinning and begin scanning for known vulnerabilities in third-party packages.

Risk if stagnant

Without supply chain visibility, the organisation is exposed to dependency confusion attacks, compromised upstream packages, and undisclosed vulnerabilities. A single poisoned dependency can compromise the entire production environment.

L1 Dependent

Basic dependency tracking exists but relies entirely on provider-managed tools with no independent verification or policy enforcement

Criteria

SUPPLY-L1-C1 Dependencies are tracked through a provider-managed tool (e.g., GitHub Dependabot, Snyk) but the organisation has no independent SBOM generation
SUPPLY-L1-C2 Vulnerability alerts are received from the provider but there is no defined SLA for remediation or escalation

Indicators

Automated dependency alerts are enabled but frequently ignored or unactioned
The organisation cannot produce a complete SBOM independently of its tooling provider

Upgrade path

Establish contractual requirements for supply chain transparency with all software vendors. Define remediation SLAs for critical and high-severity vulnerabilities. Begin generating provider-independent SBOMs as part of the CI/CD pipeline.

Risk if stagnant

Reliance on a single tool for supply chain visibility creates a false sense of security. If the tool misses a vulnerability or the provider discontinues the service, the organisation has no fallback. Unactioned alerts accumulate into a growing attack surface.

L2 Contractual

Supply chain requirements are formalised through contracts with vendors and internal policies for dependency management

Criteria

SUPPLY-L2-C1 Contracts with software vendors require SBOM delivery in a standard format (SPDX or CycloneDX) and timely disclosure of known vulnerabilities
SUPPLY-L2-C2 Internal policy defines approved dependency sources, licence compatibility requirements, and vulnerability remediation SLAs

Indicators

SBOMs are received from vendors as part of software procurement and reviewed before deployment
A dependency policy document exists and is enforced through CI/CD pipeline gates

Upgrade path

Deploy a private package registry that mirrors approved dependencies. Implement automated SBOM generation and vulnerability scanning integrated into every build pipeline. Begin verifying package signatures and provenance attestations.

Risk if stagnant

Contractual requirements improve transparency but rely on vendor honesty and compliance. Without independent verification, the organisation cannot detect supply chain compromises that vendors themselves may not be aware of.

L3 Controlled

Full SBOM generation with automated vulnerability scanning, private package registries, and verified dependency provenance

Criteria

SUPPLY-L3-C1 All builds produce machine-readable SBOMs automatically, and a private package registry serves as the sole source for all production dependencies
SUPPLY-L3-C2 Dependency signatures and provenance attestations (e.g., SLSA, Sigstore) are verified before any package enters the private registry

Indicators

No production build can pull dependencies directly from public registries; all packages flow through the private registry
Provenance verification failures automatically block package ingestion with alerts to the security team

Upgrade path

Establish a dedicated supply chain security team that audits critical dependencies at the source-code level. Contribute to or fork essential open-source projects to ensure long-term availability and trustworthiness.

Risk if stagnant

Automated scanning and private registries significantly reduce supply chain risk, but the organisation still depends on upstream maintainers for critical open-source components. A key maintainer abandoning a project or introducing a backdoor remains a residual risk.

L4 Autonomous

Fully audited sovereign supply chain with source-level review of critical dependencies, maintained forks of essential components, and end-to-end provenance guarantees

Criteria

SUPPLY-L4-C1 Critical dependencies are audited at the source-code level, and the organisation maintains forks or mirrors of essential open-source components
SUPPLY-L4-C2 End-to-end supply chain provenance is cryptographically verifiable from source code to production deployment, meeting SLSA Level 3 or higher

Indicators

The organisation actively contributes to or maintains forks of its most critical open-source dependencies
Every production artefact includes a cryptographically signed provenance chain traceable to reviewed source code

Risk if stagnant

Maintaining sovereign supply chain controls is resource-intensive. Source-code audits and maintained forks require dedicated staff and ongoing investment. Without sustained commitment, audit coverage degrades and forked dependencies drift from upstream.