Cosign is an open-source command-line tool and Go library, part of the Sigstore project, that creates and verifies cryptographic signatures for container images and other OCI artifacts. So what is Cosign, exactly, in practical terms? It lets a build pipeline attach a signature to an image immediately after it's pushed to a registry, and lets any downstream consumer -- a Kubernetes admission controller, a CI job, a security team -- cryptographically confirm that the image came from a trusted source and hasn't been altered since. Cosign supports both traditional key-pair signing and "keyless" signing backed by short-lived certificates issued through OpenID Connect identity, storing signatures as OCI artifacts alongside the image itself rather than in a separate system. Maintained by the Sigstore project under the Linux Foundation's Open Source Security Foundation (OpenSSF), Cosign has become the de facto standard for signing artifacts in cloud-native supply chain security, integrated into tools like Kyverno, GitHub Actions, GitLab CI, and most major registries.
What Is Cosign and Why Did the Industry Need It?
Cosign exists because container registries historically had no built-in way to prove who published an image or whether it had been tampered with after the fact. Before Sigstore, teams relying on Docker Content Trust (Notary v1) found the tooling clunky, poorly documented, and largely abandoned by the ecosystem -- adoption stayed low for years. Cosign, launched in 2021 as part of the Sigstore project (alongside Rekor, a transparency log, and Fulcio, a certificate authority), was designed specifically for OCI images and artifacts, with a workflow simple enough to drop into a CI pipeline in a few lines. A concrete example: after the 2020 SolarWinds compromise showed how a poisoned build could ship trusted-looking software to thousands of customers, container-native companies accelerated adoption of image signing so that a compromised build server alone wouldn't be enough to push a malicious image without detection -- verification at deploy time would catch the mismatch.
How Do You Sign a Container Image With Cosign?
You sign a container image with Cosign by running cosign sign <image-digest>, which generates a signature over the image's SHA-256 digest and pushes that signature to the same registry as a separate OCI artifact tagged against the image manifest. In a traditional key-based workflow, a team first runs cosign generate-key-pair to produce a private/public key pair (optionally encrypted and stored in a KMS like AWS KMS, Google Cloud KMS, or HashiCorp Vault), then signs with cosign sign --key cosign.key registry.example.com/app@sha256:abcd.... Critically, Cosign signs the immutable digest, not a mutable tag, so a signature can't silently apply to a different image if a tag gets overwritten later. A real-world pattern: a CI pipeline builds an image, pushes it, computes the digest, signs it with a key held in KMS, and then a Kubernetes admission controller like Kyverno or Connaisseur blocks any deployment whose image digest lacks a valid signature from the expected key -- turning "did this pass our pipeline" into a policy the cluster enforces automatically rather than something a human has to check.
What Is Keyless Container Signing and Why Does It Matter?
Keyless container signing is a Cosign mode that eliminates long-lived private keys entirely, replacing them with short-lived certificates bound to an OpenID Connect identity, such as a GitHub Actions workflow or a Google account. When a developer or CI job runs cosign sign --yes <image> in keyless mode, Cosign requests an ephemeral certificate from Fulcio (Sigstore's certificate authority), proving identity via an OIDC token rather than a static secret, signs the image with a key that exists only for seconds, and then records the signing event in Rekor, Sigstore's public, tamper-evident transparency log. This matters because long-lived signing keys are a persistent liability: if a private key leaks -- as happened in numerous supply chain incidents where CI secrets were exfiltrated -- an attacker can forge signatures indefinitely until someone notices and rotates it. With keyless signing, there's no static key to steal; the transparency log instead provides an auditable record of exactly which identity signed which artifact and when, which is why GitHub's own container publishing guidance and projects like Kubernetes now default to keyless workflows for release artifacts.
How Does Cosign Compare to Notary v2?
Cosign and Notary v2 (now developed under the name Notation, an OCI/CNCF initiative) both solve container image signing but differ in scope, maturity, and design philosophy. Cosign was purpose-built for OCI artifacts from day one, ships as a single self-contained binary, and integrates tightly with Sigstore's keyless, transparency-log-backed trust model, making it the faster path to adoption for teams already using GitHub Actions or cloud-native CI. Notation, by contrast, grew out of Notary v1 and the CNCF's broader "Notary Project," emphasizes pluggable signature formats and works closely with registry-side trust policies and X.509-based PKI, which appeals to enterprises with existing certificate infrastructure and compliance requirements around traditional PKI rather than a public transparency log. In practice, many registries -- including Docker Hub, Amazon ECR, Azure Container Registry, and Harbor -- now support both, and the choice often comes down to whether an organization prefers Sigstore's keyless, community-transparency-log model (Cosign) or a PKI-centric model with formal certificate chains (Notation). Some regulated industries lean toward Notation specifically because it maps more directly onto existing certificate authority relationships auditors already understand.
How Do You Verify a Container Image Signature Before Deployment?
You verify a container image signature by running cosign verify --key cosign.pub <image> for key-based signatures, or cosign verify --certificate-identity <identity> --certificate-oidc-issuer <issuer> <image> for keyless signatures, both of which pull the signature artifact from the registry, check it against the digest, and confirm it was produced by the expected signer. Container image signature verification is where signing actually pays off operationally: signing without enforced verification is just decoration. A concrete deployment pattern looks like this -- an admission controller intercepts every pod creation request, extracts the image reference, calls Cosign's verification logic against a policy (a specific public key, or a keyless identity matching https://github.com/org/repo/.github/workflows/build.yml@refs/heads/main), and rejects the pod if verification fails, logging the attempted deployment for incident review. Teams typically layer this with Rekor lookups to confirm the signature also appears in the public transparency log, catching cases where a signature exists but was never actually logged -- a signal of a bypassed or misconfigured pipeline.
How Safeguard Helps
Safeguard extends this signing-and-verification model across the full software supply chain rather than treating it as a point solution bolted onto one pipeline stage. Safeguard automatically enforces that every container image reaching a protected environment carries a valid Cosign signature -- key-based or keyless -- tied to an approved build identity, and it fails builds or blocks deployments when that chain breaks, whether the gap is a missing signature, an unlogged Rekor entry, or a signer identity that doesn't match your registered CI workflows. Rather than asking every team to hand-roll admission controller policies and Rekor lookups, Safeguard centralizes signature verification, policy management, and audit evidence in one place, so security teams get a single view of which images are signed, by whom, and whether that matches expected build provenance -- turning Cosign's cryptographic guarantees into an enforceable, auditable control across every cluster and registry in the environment, with the evidence trail SOC 2 and other compliance frameworks expect already assembled.