Score software supply chain maturity from SLSA build level, signed artefact share, SBOM coverage, dependency pinning and deploy-time verification.
Signing and verification carry equal weight on purpose: a signature nobody checks changes nothing, so the score only rewards the pair. SLSA build level is the largest single component because it is the property that makes the provenance trustworthy — at Build L3 the builder itself cannot be induced to lie about what it built. Supply chain attacks succeed by substituting an artefact somewhere between commit and runtime, and the only control that closes that gap is verifying at deploy time that the thing you are about to run is the thing your builder produced.
Supply Chain Security
Supply chain score = SLSA component × 0.30 + signed artefact share × 0.20 + deploy verification share × 0.20 + SBOM coverage × 0.15 + dependency pinning × 0.15.
Marginal gain
Available gain per pillar = (100 − current value) × its weight; the largest is where the next unit of effort moves the score most.
Supply chain score = SLSA component × 0.30 + signed artefact share × 0.20 + deploy verification share × 0.20 + SBOM coverage × 0.15 + dependency pinning × 0.15. Signing and verification carry equal weight on purpose: a signature nobody checks changes nothing, so the score only rewards the pair. SLSA build level is the largest single component because it is the property that makes the provenance trustworthy — at Build L3 the builder itself cannot be induced to lie about what it built.
Supply chain attacks succeed by substituting an artefact somewhere between commit and runtime, and the only control that closes that gap is verifying at deploy time that the thing you are about to run is the thing your builder produced.
This calculator takes 8 inputs: SLSA build level achieved, Artefacts published per month, Artefacts signed at build time, Builds producing an SBOM, Dependencies pinned to a digest, Deploys verifying signature and provenance, Direct dependencies, Transitive dependencies. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
The single level ladder was split into tracks, and the Build track runs L1 to L3 — the old L4 was dropped as impractical. L1 means provenance exists, L2 means it is signed by a hosted builder, L3 means the builder is hardened so the provenance cannot be forged. Most teams using a managed CI provider with OIDC signing are at L2.
An SBOM tells you what was in the build after the fact; pinning determines what goes in. A floating tag or version range means the same build definition can produce different artefacts on different days, so your SBOM is accurate and your build is not reproducible — and a compromised upstream tag reaches production without any change on your side.