पाठ 18 / 31

Supply Chain Integrity: Signing and Provenance

यह पाठ अभी हिंदी में अनुवादित नहीं है, इसलिए अंग्रेज़ी में दिखाया जा रहा है।

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

लेखक: · 15 साल से वेब डेवलपर

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

त्वरित जाँच: 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.