Practical DevSecOps with Sigstore and cosign
Actualizado: 2026-05-03
Sigstore[1] and its CLI cosign[2] have moved past being an experiment. Today large projects — Kubernetes, Istio, NPM with provenance, Python via PEP 740 — sign their artifacts through the Sigstore chain. But between “it exists” and “my team uses it well” there’s still a gap. This article is about closing that gap: signing images and binaries so that the signature means something and doesn’t become another checklist item.
Key takeaways
- Sigstore is three pieces: cosign (signing CLI), Fulcio (ephemeral CA tied to OIDC), and Rekor (immutable transparency log).
- The keyless model eliminates persistent private key management; the OIDC identity is the anchor.
- Signing without verifying at deployment is work without benefit — as dangerous as not signing at all.
- Correct verification validates identity (who signed), not just signature existence.
- For regulated or air-gapped environments, KMS or private Sigstore are the appropriate options.
What Sigstore Actually Does
Sigstore is three pieces that fit together:
- cosign: the CLI that signs and verifies artifacts — OCI images, blobs, SBOMs.
- Fulcio: a certificate authority issuing short-lived certs (~10 minutes) bound to an OIDC identity: your GitHub, Google, or corporate identity provider.
- Rekor: an immutable transparency log where signatures are recorded with audited timestamps.
The practical magic: you don’t manage persistent private keys. You sign with an OIDC identity, get an ephemeral cert, sign, the cert expires, and the Rekor entry remains for anyone to verify later. This keyless model eliminates the biggest source of signing incidents: compromised or lost keys.
Signing an OCI Image
The most common use case: signing a Docker/OCI image after building.
# Build + push as usual
docker build -t registry.example.com/myapp:1.2.3 .
docker push registry.example.com/myapp:1.2.3
# Keyless sign (uses OIDC automatically)
cosign sign registry.example.com/myapp:1.2.3Cosign detects the environment (GitHub Actions, GitLab CI, local) and gets the appropriate OIDC token. The signature attaches to the registry as an additional referenced artifact, not a separate tag.
Verify:
cosign verify registry.example.com/myapp:1.2.3
--certificate-identity=ci@example.com
--certificate-oidc-issuer=https://token.actions.githubusercontent.comVerification is not “does it have a signature?”. It’s “does it have a signature from the identity I expect?”. Without the identity part, a signature is decoration.
Integrating into a Real Pipeline
Three patterns that work for high-volume teams:
- Auto-sign in CI: every successful build signs. The workflow has OIDC permission to Sigstore’s issuer. If the build passes, signing is complexity-free.
- Policy in admission controller: Kyverno[3] or Gatekeeper[4] in Kubernetes reject pods whose image isn’t signed by authorised identities.
- Verification in GitOps: Flux[5] and Argo CD[6] can verify signatures before reconciling — the signature becomes a real gatekeeper.
The most common mistake is signing without verifying at deployment. Signing without verification is work without benefit.
Signing SBOMs and Provenance
Beyond images, Sigstore signs:
- SBOMs (Software Bill of Materials) generated with Syft[7].
- SLSA provenance generated by the builder — proof of how the image was built, which commit, which workflow.
- Raw binaries with
cosign sign-blob.
To meet SLSA Level 3 you need non-forgeable signed provenance. Sigstore is the natural mechanism to get it without standing up your own infrastructure.
Keys vs Keyless: When to Use Which
- Keyless: default for most cloud-native teams. No key management, no compromise risk. Dependency on public Sigstore.
- Keypair: persistent key (RSA or ECDSA), fully offline, you manage custody. Useful for air-gapped or strict requirements.
- KMS: key in HashiCorp Vault, AWS KMS, or GCP KMS. Good balance of centralised management and verifiable signing. The usual path in regulated environments.
Common Mistakes
The most-seen mistakes in teams adopting signature-based DevSecOps:
- Sign everything, verify nothing: signing without verification is theatre.
- Accept any identity: verifying “has signature” without validating who signed is nearly equivalent to not signing.
- Forget to rotate: in keypair mode, without annual rotation you lose the benefit.
- Not storing Rekor entries: for long-term audit, you need the Rekor entry UUID as evidence.
- No runbook when it fails: if public Sigstore has an incident, your CI halts. Have plan B.
Minimal Checklist
A team starting without complications:
- Sign in CI (keyless) for main images.
- Verify at deployment (Kyverno, Flux, Argo).
- List of authorised identities versioned in Git.
- Alert when an unsigned image reaches production.
- Quarterly review of what’s signed and what isn’t.
With that, you’re already ahead of industry average.
Related: image signing complements service mesh with mTLS well for complete Zero Trust between services, and GitOps with ArgoCD can be the verification point where signatures are validated before deployment.
Conclusion
Sigstore moved from experimental project to de-facto software-signing infrastructure. Adoption friction has dropped. What remains is integrating it so it means something: really verifying, with well-defined identities, and clear runbooks when it fails. Signing for signing’s sake is worse than not signing: it gives the illusion of security without the benefits. Well applied, it closes one of the doors supply-chain attackers have exploited for years.
