Keyless signing has become the default for container image signing in three years, and the Sigstore ecosystem has matured around it. The 2.4 release of Cosign in early 2026 added several quality-of-life improvements for offline verification and trust root handling, and the public-good Fulcio and Rekor instances have been stable enough that most teams have stopped considering self-hosted alternatives. This is a good moment to write down what a competent keyless workflow looks like and which design decisions still trip teams up.
The premise of keyless signing is that you replace long-lived signing keys with short-lived certificates issued by Fulcio against an OIDC identity, with the resulting signature recorded in the Rekor transparency log. The identity is what gets verified at consumption time, not a key. This solves several problems that key-based signing did not solve well, and it introduces a couple of new ones.
What OIDC identity should be on the certificate?
The right identity is workload identity, not human identity. Sign images from your CI runner using the GitHub Actions OIDC token, the GitLab CI JWT, or whatever federation your CI provider supports. The Fulcio certificate will then carry the workflow identity, including the repo and ref, and verification at the consumer end can pin to those values. Human identity should be reserved for break-glass cases where a human is making an out-of-band signing decision, and those should be rare.
The mistake that teams still make is signing with a personal Google or GitHub identity from a developer laptop and putting that pattern in their documentation. It works, but it creates a verification rule that says "trust signatures from this email address," which is the wrong long-term posture. Personal identity rotates, individuals leave companies, and the verification configuration becomes a maintenance burden. Workload identity is auditable, attributable to a specific automated process, and naturally rotates without manual intervention.
How do you handle the Rekor transparency log dependency?
Rekor is in the critical path of keyless signing and verification, and that dependency is the most common source of unease. The public-good Rekor instance has had high availability over the last two years but it is not in your blast radius and you cannot fix it if it goes down. For verification, Cosign 2.0 and later support offline verification using a Rekor inclusion proof and a Signed Entry Timestamp embedded in the signature bundle, which removes the verification-time dependency on Rekor being online.
Sign-time still requires Rekor, but the failure mode is that you cannot produce a new signature, not that existing signatures stop working. That is an acceptable failure mode for most deployments. For organizations that cannot tolerate any sign-time external dependency, the alternatives are running self-hosted Fulcio and Rekor, or using key-based signing with hardware-backed keys. The self-hosted path is operationally heavy, requires careful trust root management, and is rarely the right choice unless you have a regulatory reason to run it.
How should attestations be structured?
An image signature is the lightest form of provenance. The real value comes from attaching in-toto attestations: SLSA provenance describing how the image was built, SBOM attestations describing what is inside, vulnerability scan attestations describing what was known about it at build time, and test-result attestations describing what passed. Each attestation is itself signed using the same keyless flow, and each can be verified independently.
The pattern that works is to generate every attestation at build time and attach it to the image as it is pushed. Slim base images, deterministic builds, and SLSA Level 3 provenance all become straightforward at that point. The anti-pattern is generating attestations as a separate post-build step that runs hours or days later. The signing identity for that out-of-band step is harder to justify, and the attestation freshness becomes hard to verify because the build context is gone.
What does verification look like in production?
Production verification happens at admission time and ideally also at deployment time and registry pull time, for defense in depth. The Sigstore Policy Controller is the most common admission-time verifier and integrates with Kyverno's verifyImages rule. The verification predicate should be specific: identity match against a known workload identity, issuer match against the expected OIDC provider, certificate-extension match against the expected workflow path, and attestation predicate match against the expected SLSA build requirements.
The mistake to avoid is broad predicates like "any signature from Fulcio is acceptable." That admits any image anyone has ever signed through Sigstore, which is not a meaningful policy. Specificity is the entire point of keyless verification, and a vague predicate undoes the security benefit.
What about the trust root and TUF distribution?
The Sigstore trust root is distributed through TUF, which handles rotation of the Fulcio CA and Rekor public keys. Cosign 2.4 made the TUF refresh more robust against transient network failures and added cache-warming for air-gapped scenarios. For most deployments, the TUF refresh just works and you do not need to think about it. For air-gapped environments, you need to mirror the TUF metadata and ensure it refreshes on a schedule that matches the upstream rotation cadence, which is currently quarterly.
The trust root is the foundation of every verification decision you make, and a stale or corrupted trust root silently produces wrong answers. Monitor the TUF refresh in your verification path and alert on freshness violations. This is the boring infrastructure work that distinguishes a real deployment from a demo.
How Safeguard Helps
Safeguard integrates Cosign verification into our policy gates so that signature checks, attestation predicate matching, and SBOM provenance verification all run as part of the same evaluation. Griffin AI cross-references signature identity against your sanctioned build-system inventory and flags drift, such as an image suddenly signed by a workflow identity that has not produced builds historically. Policy gates can require fresh SLSA provenance attestations, block images whose signatures fail keyless verification, and quarantine images whose Rekor inclusion proofs do not validate. TPRM scoring for third-party images factors signature posture into supplier risk, and our zero-CVE base images ship with full keyless signatures and attestations out of the box.