Supply Chain Security Calculator
Score software supply chain maturity from SLSA build level, signed artefact share, SBOM coverage, dependency pinning and deploy-time verification.
Inputs
Supply Chain Score
59.9/ 100
Grade
D — Weak
SLSA Component Score
66.7/ 100
Unsigned Artefacts per Month
588artefacts
Deploys With No Verification
840deploys
Transitive Dependencies per Direct One
7.58
Total Dependency Surface
2,060packages
Largest Available Gain
Verify signatures and provenance at deploy time — signing nothing verifies is theatre
Next SLSA Action
Harden the builder so provenance cannot be forged by the build definition itself
Step by step
Values used
SLSA build level achieved = Build L2 — signed provenance from a hosted builder — 2; Artefacts published per month = 1,400 artefacts; Artefacts signed at build time = 58 %; Builds producing an SBOM = 71 %; Dependencies pinned to a digest = 64 %; Deploys verifying signature and provenance = 40 %; Direct dependencies = 240 packages; Transitive dependencies = 1,820 packages
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
= 59.9 / 100
Grade
= D — Weak
SLSA Component Score
= 66.7 / 100
Unsigned Artefacts per Month
= 588 artefacts
Deploys With No Verification
= 840 deploys
Transitive Dependencies per Direct One
= 7.58
How it works
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.
Formulas
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.
- slsaScore
- SLSA build level ÷ 3 × 100
- signedArtefactPct
- Artefacts carrying a signature at build time
- verifiedAtDeployPct
- Deploys that check the signature and provenance before admitting the artefact
Marginal gain
Available gain per pillar = (100 − current value) × its weight; the largest is where the next unit of effort moves the score most.
- verifyGain
- Score points available from deploy-time verification
- slsaGain
- Score points available from the next SLSA build level
Frequently Asked Questions
How is Supply Chain Security calculated?
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.
Why does Supply Chain Security matter?
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.
What values do I need to enter?
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.
What changed in SLSA v1.0?
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.
Why does dependency pinning matter if I have an SBOM?
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.
You might also need
- Admission Controller Coverage CalculatorCommonly used together
- Secrets Exposure CalculatorCommonly used together
- Infrastructure as Code Risk CalculatorCommonly used together
- Container Image Vulnerability CalculatorCommonly used together
- Cloud Security Health Score CalculatorAlso in Cloud Security
- Cloud IAM Risk CalculatorAlso in Cloud Security