Lesson 18 / 31

Supply Chain Integrity: Signing and Provenance

Verify artefact integrity with checksums and signatures, and explain SLSA provenance and keyless signing with Sigstore.

By · 15 years in web development

Proving what you ship is what you built

Supply chain attacks target the path between source and production: a compromised build server, a typosquatted package, a tampered artefact in a registry. Three controls answer 'is this artefact genuine?'. A checksum (such as SHA-256) detects accidental or malicious changes, but only if you got the expected hash from a trusted place. A signature proves who produced the artefact. Sigstore's cosign supports keyless signing: in CI, the job's OIDC identity is used to get a short-lived certificate, the signature is recorded in a public transparency log, and verifiers check that the signer was, for example, a specific workflow in a specific repository. Provenance is a signed statement of how an artefact was built: source commit, builder, parameters. SLSA (Supply-chain Levels for Software Artifacts) is a framework that grades build integrity in levels, from having provenance at all to builds on hardened, isolated platforms whose provenance cannot be forged by the build itself.

Verifying a checksum

The -c flag re-computes the hash and compares it with the recorded value. Any modification makes the check fail.

printf 'release build 1.4.2\n' > app.tar
sha256sum app.tar > app.tar.sha256
sha256sum -c app.tar.sha256
printf 'tampered\n' >> app.tar
sha256sum -c app.tar.sha256 2>/dev/null || echo "verification failed: do not deploy"

Output:

app.tar: OK
app.tar: FAILED
verification failed: do not deploy

Keyless signing and verification with cosign

Sign by digest, never by a mutable tag. Verification pins the expected signer identity and issuer.

# In CI (needs id-token: write permission)
cosign sign --yes registry.example.com/shop/api@sha256:<digest>

# At deploy time or in an admission controller
cosign verify registry.example.com/shop/api@sha256:<digest> \
  --certificate-identity-regexp '^https://github.com/acme/shop/\.github/workflows/release\.yml@refs/heads/main$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Quick check: What does a keyless cosign verification check, beyond the signature being mathematically valid?

  • That the image is smaller than 1 GB
  • That the signer identity and OIDC issuer match what you expect
  • That the image has no vulnerabilities
  • That the registry uses HTTPS
Answer

That the signer identity and OIDC issuer match what you expect — Keyless signatures are tied to an identity (such as a workflow path) and issuer; verifying them is what makes the signature meaningful.