Container Image Signing & SLSA Provenance Verification with Sigstore Cosign

An OCI container image is a standardized package for distributing container software. It contains application files, dependencies, configuration, and metadata. A registry can store and deliver it. Signing the image with Cosign creates a cryptographic record tied to that image's content. This matters because recipients need evidence that the image was not replaced or altered after it was built.

For example, a CI/CD workflow builds an image and asks Cosign to sign its immutable digest. In keyless mode, the workflow uses an OIDC identity token rather than a stored private key. Fulcio issues a short-lived certificate connecting the signing event to that identity. Cosign then records signature metadata in Rekor, the public transparency log.

Verification checks whether the signature matches the image and whether its certificate and transparency record are valid. The article focuses on OCI images, keyless signing, Rekor, and SLSA provenance. Together, these checks provide stronger supply-chain evidence than trusting a registry location or image tag alone.

Keyless signing replaces a stored, reusable private key with an identity assertion from the CI/CD platform. OIDC tokens are signed claims about the workflow, such as which repository or job requested the operation. The token gives a signing service evidence about the caller's identity. This reduces the need to create, distribute, rotate, and protect a permanent secret in CI/CD.

For example, a workflow builds an OCI image and requests an OIDC identity token. Cosign presents that token to Fulcio, the certificate authority. Fulcio validates the identity and issues a short-lived certificate binding the signing key to that workflow identity. Cosign uses the associated ephemeral key to sign the image, while Rekor records signature metadata.

This model does not make identity checks unnecessary. Verifiers still need to check the certificate, the expected identity, the image signature, and Rekor's record. The article's keyless approach is especially suited to automated pipelines, where short-lived credentials can limit exposure compared with long-lived private keys.

Fulcio is the certificate authority in this workflow. It validates the CI/CD system's OIDC identity token and issues a certificate for the signing key used by Cosign. That certificate links the signature to an identity, such as an authorized workflow, without requiring a permanent private key. It provides the identity layer behind a keyless signature.

Rekor is the public transparency log. After Cosign signs an OCI image, signature metadata is recorded there. A verifier can inspect the log and confirm that the signing information was publicly recorded. The article describes Rekor as immutable and says it helps prevent signature tampering. The image signature itself still proves content integrity.

These services serve different purposes. Fulcio establishes identity for a short-lived certificate. Rekor preserves evidence of the signing event in a visible, append-only history. Verification can therefore assess the image, the certificate, the expected identity, and the transparency record. This combination makes supply-chain evidence easier to audit than an isolated signature file.

There are four distinct trust layers in the approach described: identity, signing, transparency logging, and build provenance. Identity establishes which CI/CD workflow or organization requested the operation. It is supported by an OIDC token and a Fulcio certificate. This prevents a signature from being treated as anonymous evidence.

Signing proves that the signed statement matches the specific image content, normally identified by its immutable digest. Transparency logging adds a public Rekor record of the signature metadata. That record helps expose later alteration or backdated claims. Build provenance adds information about how the image was produced, such as the build process and source context represented through SLSA provenance.

Each layer covers a different failure or trust question. Identity asks who acted. Signing asks whether the artifact changed. Rekor asks whether the evidence was recorded consistently. Provenance asks how the artifact was built. The article combines these layers so deployment decisions can rely on more than a registry tag or a single cryptographic check.

If a container signature cannot be verified, the system cannot reliably show that the deployed bytes match what the signer approved. The image may still be legitimate, but its integrity and signer identity are unproven. If SLSA provenance cannot be verified, the build's source, process, or claimed origin also lacks the expected evidence. These are supply-chain trust failures.

For example, a deployment policy may require a valid Cosign signature, a certificate for an approved CI/CD identity, a Rekor entry, and matching SLSA provenance. If any required check fails, the policy can reject the image, quarantine it, or request investigation instead of deploying it. This avoids treating an unverified artifact as trusted software.

The source article presents verification as a security control, but it does not prescribe one universal failure response. In practice, organizations should define fail-closed rules for sensitive systems and an exception process for outages or missing records. A failed check is a warning requiring evidence, not automatic proof that an image is malicious.

A traditional alternative is to generate a private signing key, store it in CI/CD secrets or a hardware-backed service, and use it for every release. The corresponding public key is distributed to verifiers. This model can be effective, especially when an organization needs a stable signing identity or operates without an OIDC provider. It requires careful key custody.

The main risk is persistence. If a long-lived private key leaks through logs, backups, a compromised runner, or poor secret handling, an attacker may sign malicious images that appear authentic. Organizations must protect, rotate, revoke, and distribute keys, and must handle recovery when a key is lost. A stolen key may remain useful until detection or rotation.

Keyless Cosign changes the risk profile rather than removing trust requirements. It uses OIDC identity tokens, Fulcio certificates, and Rekor records instead of a stored permanent key. Short-lived credentials reduce the value of a single compromise. They also create dependencies on the identity provider, certificate authority, and transparency service, which must remain available and correctly verified.

Software received from another party needs evidence that it is both authentic and unchanged. A cryptographic signature uses a private key to approve specific content, while a public key verifies that approval and detects changes. For a container, verification should target the image's immutable content or digest, not merely a mutable tag. This establishes integrity, but not automatically who built it.

A certificate adds identity context. In the article's keyless model, Fulcio issues a certificate connected to the CI/CD system's OIDC identity. A verifier can then ask whether an approved workflow or organization made the signature. Rekor adds a public, immutable transparency record containing signature metadata. That record makes later alteration or hidden signing claims easier to detect.

SLSA provenance adds build context: evidence about how the artifact was produced. These layers complement one another. Signatures protect content, certificates connect approval to an identity, Rekor preserves the event, and provenance describes the build. None replaces careful policy, but together they let a recipient evaluate software built and distributed by someone else.