Container images move through more hands than most teams can track: a base image from a public registry, a build stage in CI, a push to an internal registry, a pull into a Kubernetes cluster. Every hop is a place where an image can be swapped, tampered with, or spoofed. Sigstore and its signing tool, Cosign, were built to close that gap without forcing developers to manage private keys — the single biggest reason signing programs stall out in practice. Chainguard, founded by the engineers who created Sigstore at Google, has turned keyless signing into a core part of its commercial pitch, bundling it into Chainguard Images and its enforcement tooling. That has made "cosign container image signing" one of the most searched setup questions in the supply chain security space. This post breaks down how Sigstore and Cosign actually work, where Chainguard fits, what keyless signing does and doesn't protect against, and how to verify signed images in a real pipeline.
What Is Sigstore, and Why Does It Matter for Container Signing?
Sigstore is a set of free, open-source tools — Cosign, Fulcio, and Rekor — that together let developers sign software artifacts using their existing identity instead of a long-lived private key. The project was announced publicly in March 2021 by engineers from Google, Red Hat, and the Linux Foundation, in direct response to incidents like the 2020 SolarWinds compromise and the 2021 Codecov breach, both of which involved attackers inserting malicious code into a trusted build pipeline. Traditional code signing (GPG, PKI-based x509) requires someone to generate, store, rotate, and eventually revoke a private key — a process that is expensive at organizational scale and routinely skipped by individual developers. Sigstore's founding bet was that signing adoption was a usability problem, not a cryptography problem. Fulcio acts as a short-lived certificate authority: it issues a code-signing certificate tied to an OpenID Connect (OIDC) identity — a GitHub Actions workflow, a Google account, a GitLab CI job — valid for roughly 10 minutes, just long enough to sign one artifact. Rekor then writes a permanent, publicly auditable record of that signing event to an append-only transparency log, so anyone can later verify an image was signed by that identity at that time, even after the certificate itself has expired.
How Does Cosign Make Keyless Signing Possible?
Cosign makes keyless signing possible by generating an ephemeral key pair in memory, using it to sign the image, and then discarding it — the certificate from Fulcio and the log entry in Rekor become the durable proof, not the key itself. A developer or CI job runs cosign sign <image>, which triggers an OIDC login flow (interactive browser prompt locally, or automatic token exchange in CI systems like GitHub Actions and GitLab CI), requests a short-lived certificate from Fulcio, signs the image digest, and pushes the signature as an OCI artifact alongside the image in the registry. Cosign 1.0 shipped in late 2021 and Cosign 2.0 followed in 2023, adding keyless-by-default workflows and tighter Rekor integration. The practical result: no ~/.cosign/cosign.key file sitting on a laptop or in a CI secret store waiting to be exfiltrated. This is why adoption spread quickly beyond containers — PyPI added Sigstore-based "Trusted Publishing" for Python packages in 2023, and npm added provenance attestations built on the same primitives that same year. For container images specifically, keyless signing solves the operational problem that killed most prior signing initiatives: someone always forgot to rotate a key, or a leaving engineer took one with them.
Why Did Chainguard Build Its Business Around Sigstore?
Chainguard built its business around Sigstore because its founders — Dan Lorenc, Kim Lewandowski, and others — were the same engineers who designed and shipped Sigstore, Cosign, and the Rekor transparency log while at Google, and launched Chainguard in September 2021 to commercialize the practices they'd built. Chainguard Images, the company's flagship product, ships minimal, distroless base images that are signed with Cosign and accompanied by in-toto attestations and SLSA provenance metadata at every build. The pitch to enterprise buyers is that signature verification isn't an add-on step you bolt onto an existing pipeline — it's a default property of the images you start from. Chainguard has also pushed adoption of cosign verify-attestation and OPA/Kyverno-based admission policies that reject unsigned images at deploy time in Kubernetes, rather than only checking signatures at build time. That's a meaningful distinction: a signature that's checked once in CI and never again at the cluster boundary doesn't stop someone from pulling a different, unsigned image straight into production later.
What Does Keyless Signing Not Protect Against?
Keyless signing does not protect against a compromised OIDC identity, a malicious insider with legitimate CI access, or a build system that was already tampered with before signing happens — it proves who signed an image and when, not that the image's contents are safe. If an attacker steals a GitHub Actions OIDC token or compromises a CI runner, Fulcio will happily issue a valid certificate for that stolen identity, and Rekor will faithfully log a "legitimate" signing event for a poisoned image — this is effectively what happened in spirit during the 2021 Codecov incident, before Sigstore existed to log it. Keyless signing also depends on the availability and integrity of Sigstore's public infrastructure: the Fulcio CA and Rekor log are shared, internet-facing services, which means an outage or targeted attack on Sigstore's own infrastructure affects every downstream user simultaneously — a centralization risk that didn't exist with self-managed keys, even though self-managed keys had worse day-to-day operational risk. Organizations running keyless signing at scale should treat identity and CI hardening (branch protection, required reviewers, hermetic builds) as the actual security control, with Cosign and Rekor providing the audit trail, not the prevention.
How Do You Verify Cosign-Signed Images in a Pipeline?
You verify Cosign-signed images in a pipeline by running cosign verify against the expected signing identity before the image is allowed to deploy, not just checking that a signature exists. A bare cosign verify <image> --key cosign.pub only confirms an image was signed by someone holding that key; a keyless verification like cosign verify <image> --certificate-identity=https://github.com/org/repo/.github/workflows/build.yml@refs/heads/main --certificate-oidc-issuer=https://token.actions.githubusercontent.com confirms the image was signed specifically by your production build workflow on your main branch — a much narrower and more useful guarantee. In Kubernetes, this check needs to happen at admission time using a policy engine such as Kyverno's verifyImages rule or the Sigstore policy-controller, both of which call Cosign's verification logic against every image reference before a pod is scheduled. Skipping this step is the most common gap Safeguard sees in the field: teams sign images diligently in CI, generate an SBOM, publish provenance — and then never configure an admission controller to actually enforce that a signature must be present and valid, leaving the entire program advisory rather than preventive.
How Safeguard Helps
Safeguard treats Cosign signatures and Sigstore attestations as first-class evidence rather than a checkbox. Instead of asking teams to bolt together cosign verify calls, Kyverno policies, and Rekor log queries by hand, Safeguard continuously discovers every image running across your registries and clusters, checks each one against its expected signing identity and OIDC issuer, and flags any image that's unsigned, signed by an unexpected workflow, or missing from the transparency log entirely. For teams evaluating or already running Chainguard Images, Safeguard verifies that the signed, attested base images you're paying for are actually the ones reaching production — catching the gap where a signed base image gets rebuilt downstream without re-signing, or where an admission policy silently fails open during a cluster upgrade. Safeguard also maps signature and provenance data directly to SLSA levels and SOC 2 / compliance evidence requirements, so security teams don't have to manually reconcile Rekor log entries with an audit checklist every quarter. The goal isn't to replace Sigstore or Cosign — it's to make sure the signing program you've already invested in is actually enforced everywhere your images run, continuously, instead of trusted on faith after the first pipeline run turns green.