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 Rahul Agarwal · 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.comQuick 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.