पाठ 18 / 31
Supply Chain Integrity: Signing and Provenance
यह पाठ अभी हिंदी में अनुवादित नहीं है, इसलिए अंग्रेज़ी में दिखाया जा रहा है।
Verify artefact integrity with checksums and signatures, and explain SLSA provenance and keyless signing with Sigstore.
लेखक: Rahul Agarwal · 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.