← Concepts & Glossary
Signing & Supply Chain Trust

Cosign

The container-signing tool at the core of modern supply chain trust.

What is Cosign?

Cosign is the command-line client inside the Sigstore stack that developers and CI pipelines use to sign and verify container images, SBOMs, attestations, and arbitrary blobs. It is small, fast, and opinionated: one binary, a handful of commands, and sensible defaults that push users toward the keyless, transparency-logged path.

In practice, Cosign is what runs in your GitHub Actions step when a release is cut. It produces the signature, the certificate, and the Rekor log entry that downstream verifiers will consume — and it hides the cryptographic machinery behind two commands: cosign sign and cosign verify.

How it works

Cosign supports three signing modes, from least to most ergonomic:

  1. Keypair signing. Classic asymmetric signing with a locally-generated key. Useful for air-gapped environments, but inherits all the key-management problems that Sigstore was designed to eliminate.
  2. KMS-backed signing. The private key lives in AWS KMS, Google Cloud KMS, Azure Key Vault, or HashiCorp Vault — Cosign calls the KMS for each signing operation. Good for regulated environments that require FIPS-validated key storage.
  3. Keyless signing (the default). Cosign authenticates to an OIDC provider, receives an ephemeral Fulcio certificate tied to that identity, signs the artifact, and publishes the entry to Rekor. No long-lived private key ever exists on disk.

Verification is symmetric in spirit: cosign verify fetches the signature bundle, checks the certificate chain against the Sigstore root, confirms Rekor inclusion, and optionally enforces a policy — "the signer must be the release workflow in my-org/my-repo, on the main branch."

Why it matters

Cosign is the thinnest possible bridge between a developer workflow and supply chain cryptography. Before Cosign, signing a container required a PKI, a key rotation policy, a vault, and a custom verifier. After Cosign, signing a container is a CI step.

That ergonomic shift is what turned container signing from an aspirational best practice into an enforceable policy — which is why admission controllers in Kubernetes (Kyverno, Gatekeeper, Sigstore policy-controller) now speak Cosign natively.

What value it adds

  • One command to sign, one to verify

    The entire surface area is two verbs — which is why adoption curves look like Git's did in 2008.

  • Native OCI registry support

    Signatures, SBOMs, and attestations are stored alongside the image as OCI artifacts — no separate signing infrastructure to operate.

  • Verifiable CI identity

    Keyless signing binds the signature to a specific workflow run — so "signed by main" is a cryptographically verifiable claim, not a convention.

  • Policy-ready

    Cosign verification policies express identity constraints directly: issuer, subject, workflow, ref — the vocabulary regulators actually care about.

  • Integration by default

    Kubernetes admission controllers, base-image providers, and most modern registries already speak Cosign — deploying it rarely requires net-new infrastructure.

How Safeguard uses it

Safeguard verifies Cosign signatures as part of every container ingestion — signature validity, Rekor inclusion, and identity constraints become first-class policy inputs. When the security feature set enforces self-healing containers, Cosign is the verifier in the middle.

Make Cosign part of your gate.

See which of your container images are signed, who signed them, and where the gaps are.