Skip to content

Sigstore and SLSA: Verifying Who Built an Artifact with Which Process

Aug 22, 2026 1 min
TL;DR Sigstore provides identity-bound signing, short-lived certificates, and transparency logs; SLSA describes trustworthy build provenance. They protect only when admission verifies identity, issuer, digest, and build expectations.
Table of Contents
  1. Keyless means ephemeral keys, not no keys
  2. Provenance matters when compared with expectations
  3. Sign inside a protected build boundary
  4. References

🌏 中文版

Sigstore and SLSA solve adjacent problems. Sigstore and Cosign sign and verify artifacts and attestations. SLSA defines what provenance should establish and how trustworthy a build platform is. A signature proves an identity signed a digest, not that source, workflows, or dependencies are safe.

Keyless means ephemeral keys, not no keys

Cosign keyless signing obtains an OIDC identity token and creates an ephemeral key pair. Fulcio validates the identity and issues a short-lived certificate binding the public key to it. Rekor records the signing event in a transparency log, and the private key is destroyed. A bundle carries the signature, certificate, timestamp, and inclusion proof for offline verification.

cosign verify-blob artifact.tar.gz \
  --bundle artifact.sigstore.json \
  --certificate-identity release@example.com \
  --certificate-oidc-issuer https://accounts.example.com

Verification must specify expected identity and issuer; a broad regex merely proves somebody signed. Bind CI identity to repository, workflow, ref, and environment, and verify immutable release digests rather than tags. Rekor provides public evidence and may expose identity or artifact metadata, which needs review.

Provenance matters when compared with expectations

SLSA provenance attests that a build platform produced subject digests from a build definition, parameters, and resolved dependencies. The Build track progresses from provenance existence toward hosted, authenticated provenance and hardened build platforms. Evaluate the current SLSA version and track requirements rather than applying an obsolete level badge.

Consumer policy should verify the subject digest, builder ID, source repository, commit or tag, workflow or build type, external parameters, and claimed level. Storing provenance without checking expectations still permits a malicious actor to run an unexpected debug workflow on an official builder and receive a legitimate attestation.

Sign inside a protected build boundary

Do not expose long-lived signing keys to user-controlled build steps. A compromised script could sign arbitrary outputs. Trusted control planes should generate provenance automatically, isolate runs, protect release environments, and use short-lived OIDC identities. Fail closed on verification and plan root rotation, offline bundles, transparency-log outages, and emergency rollback.

Sigstore and SLSA complement SBOMs, scanners, and reproducible builds. SBOMs list contents, scanners find known risk, provenance explains the build, and signatures bind identity to digest. A complete path is build, attest and sign, immutable registry storage, admission verification, and runtime inventory—not an extra .sig file after release.

References