Skip to content
Calcrivo

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

artefacts
%
%
%
%
packages
packages

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

  1. 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

  2. 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.

  3. Marginal gain

    Available gain per pillar = (100 − current value) × its weight; the largest is where the next unit of effort moves the score most.

  4. Supply Chain Score

    = 59.9 / 100

  5. Grade

    = D — Weak

  6. SLSA Component Score

    = 66.7 / 100

  7. Unsigned Artefacts per Month

    = 588 artefacts

  8. Deploys With No Verification

    = 840 deploys

  9. 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