Sigstore Cosign: Image Signing and Verification

Container images move through build systems, registries, and deployment platforms, and a tag such as latest does not prove who published an image or whether it changed. Developers, platform engineers, and security teams use Sigstore Cosign to attach verifiable signatures and attestations to artifacts, then check that evidence before deployment. This explainer covers the trust model, keyless signing, verification policy, and practical limits of image signatures.

What Is Sigstore Cosign?

Sigstore is an open-source project for signing and verifying software artifacts. Cosign is its container-signing client: it can sign an image, verify its signature, and attach or inspect attestations that describe claims about the image. Signatures and related metadata can be stored alongside the image in an OCI-compatible registry.

A signature binds a cryptographic statement to an artifact digest. If the image bytes change, its digest changes and the signature no longer verifies for that content. A verifier can also check the signing identity, such as a specific CI workflow, rather than merely accepting any mathematically valid signature. That distinction lets teams express a trust rule like “this release must come from our protected release workflow.”

Cosign supports both key-based signing and keyless signing. With a managed key, the team protects and distributes key material. With keyless signing, a workload authenticates through an OpenID Connect (OIDC) identity provider, and Sigstore issues a short-lived certificate for the signing operation. The Sigstore Cosign signing overview describes these signing modes and their workflow.

The Problem Image Signing Solves

Container registries make images easy to publish and retrieve, but the name used to fetch an image is not proof of its origin. A mutable tag can point to different content over time. A registry credential can be stolen, a build runner can be compromised, or an image can be replaced after a release process approves it. Vulnerability scanning can find known weaknesses in image contents, but it does not establish who produced a particular image.

Signing adds an identity and integrity check to the delivery process. A signature lets a consumer confirm that the retrieved digest is the one a trusted signer approved. Identity constraints can limit accepted signatures to a known repository, branch, workflow, or issuer. This is useful evidence, not a complete security guarantee: a trusted workflow can still build vulnerable code, and an authorized identity can still be misused.

Image signatures therefore complement, rather than replace, controls such as protected source branches, isolated build runners, dependency review, vulnerability scanning, and least-privilege registry access. For a broader view of these controls, see software supply-chain attack paths and defenses.

How Cosign Signing and Verification Work

At a high level, the producer builds and publishes an image, resolves the exact image digest, signs that digest, and stores signature data in the registry. A consumer retrieves the same artifact, checks the signature, and applies a policy to the signer identity and issuer.

In keyless signing, the workload obtains an OIDC token from an identity provider. Cosign uses it to request a short-lived certificate from Fulcio, signs the image digest with a temporary key pair, and records transparency evidence through Rekor. The private key is temporary rather than a long-lived secret stored in a CI variable. The certificate connects the signature to an identity claim, while the transparency log provides an auditable record. Verifiers still need to check that the identity and issuer match the expected release process.

Cosign associates signatures with the image digest, not with the human meaning of a tag. Signing a tag resolves it to content at signing time; recording and deploying the resulting digest makes that content explicit. The verification documentation explains how to validate signatures and constrain the certificate identity and issuer.

Components and Key Concepts

• Image digest: A content-derived identifier for an image manifest. A digest identifies the artifact being signed more precisely than a mutable tag.
• Signature: Cryptographic evidence that a signer approved a particular digest. It does not state that the image is vulnerability-free.
• OIDC identity: A claim issued to a workload by an identity provider. A verifier should constrain the expected issuer and signer identity instead of trusting any valid identity.
• Fulcio certificate: A short-lived certificate that binds a keyless signing key to the authenticated identity for that signing event.
• Rekor transparency log: An append-only record of signing events and related materials. Transparency evidence improves auditability; it does not decide whether the signer is trusted.
• Attestation: A signed statement about an artifact, such as build provenance or an SBOM. A signature establishes who made the statement and whether it changed; a policy must still decide whether its claims are acceptable.

Build provenance describes how an artifact was produced: for example, the source repository and revision, builder, and build process. The SLSA specification defines provenance and supply-chain assurance concepts that can be used with signed attestations. SLSA is not a Cosign feature or a guarantee that source code is safe; it provides a framework for describing and evaluating build integrity.

Real-World Uses

An organization can require that production images carry a signature from its release pipeline. This helps distinguish approved releases from images pushed by a developer workstation or an unexpected automation identity. A deployment admission policy can verify the digest and signer before allowing a workload to start.

Image publishers can sign once after their final build and distribution steps, then provide the same signed digest to customers. Consumers can check the publisher identity before pulling it into a cluster. This is particularly useful when teams consume third-party images and want a clear allowlist of publishers.

Teams can also attach provenance or SBOM attestations to an image and verify them during release review. The attestation can help answer which source revision produced an image or what components were recorded in its inventory. The trust policy should consider both the signature identity and the statement’s content; a valid signature on a weak or incomplete statement does not make that statement sufficient.

Getting Started: Sign and Verify an Image

Install Cosign using a trusted package manager or the official Cosign installation instructions, then check that the binary is available:

cosign version

Publish the image to a registry first. In a CI environment that supports OIDC, grant the job access to an identity token and the minimum registry permissions needed to publish the image and its signature. For GitHub Actions, the relevant permissions commonly include id-token: write and, when publishing to GitHub Container Registry, packages: write. Do not expose a signing token to untrusted pull-request code.

Set IMAGE to the immutable digest produced by the build and push step. The example uses placeholders that must be replaced with a real registry path and digest:

IMAGE='ghcr.io/acme/payments@sha256:<image-digest>'

# Keyless signing; the CI job must have an OIDC identity and registry write access.
cosign sign --yes "$IMAGE"

On a machine or in a deployment check, verify both the signature and the exact identity expected to have signed the image:

IMAGE='ghcr.io/acme/payments@sha256:<image-digest>'

cosign verify \
  --certificate-identity 'https://github.com/acme/payments/.github/workflows/release.yml@refs/heads/main' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  "$IMAGE"

Replace the example repository, workflow, branch, registry, and digest with the values used by your release system. A successful cryptographic check alone is not a sufficient policy: use an exact identity and issuer, and fail the deployment if verification fails. In production, run this check as part of an enforced admission or deployment policy rather than relying on an operator to remember it.

An attestation can be attached to the same digest when a pipeline has generated a provenance predicate:

cosign attest --yes \
  --type slsaprovenance \
  --predicate provenance.json \
  "$IMAGE"

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity 'https://github.com/acme/payments/.github/workflows/release.yml@refs/heads/main' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  "$IMAGE"

Verification proves that an accepted signer made the attestation for the image; it does not automatically validate every provenance field or guarantee that the build was uncompromised. Inspect the statement and enforce the source, builder, and build parameters that matter to your threat model.

If signing fails, check that the job can obtain an OIDC token, that the registry allows the signature artifact to be written, and that the image exists at the supplied digest. If verification fails, confirm the digest, identity string, issuer, and registry access. Avoid relaxing identity checks to make a failure disappear; determine which expected value differs and correct either the policy or the pipeline.

For adjacent controls around image scanning and container hardening, see container security best practices and CI/CD pipeline security.

Common Misconceptions

“A valid signature means the image is safe.” A signature says that a particular identity approved particular content. The image could still contain exploitable code, a vulnerable dependency, or a malicious change made by an authorized actor. Scanning, review, provenance checks, and runtime controls remain necessary.

“Keyless signing means there are no keys.” It avoids maintaining a long-lived signing key in the workflow, but cryptographic keys still exist briefly during signing. The OIDC identity, certificate, and trust policy are all security-critical. If an attacker controls a trusted workflow or identity, keyless signing can faithfully record an attacker-approved image.

“The transparency log enforces our deployment policy.” Rekor makes signing evidence auditable; it does not choose which identities your organization trusts. Verification must check the expected issuer and identity, and a deployment system must enforce the result.

“A signed tag is a permanent reference.” A tag can be moved. Resolve it to a digest, sign that content, and deploy the same digest that passed verification. This avoids validating one image and later pulling different content under the same tag.

Related Articles

• Software Supply Chain Attacks: Risks and Defenses
• Container Security Best Practices
• DevOps Pipeline Security

Changelog

• Initial publication; last updated October 1.