Why Storage Alone Is Not Enough
Storing an artifact in a registry answers the question "where is it?" but not "can I trust it?" Consider this scenario: an attacker compromises a CI runner and pushes a malicious image to your registry with a legitimate-looking tag. Without signing, there is no way to distinguish this image from a legitimate build. Your deployment pipeline pulls it and runs it in production.
Artifact signing solves this by creating a cryptographic proof that a specific artifact was produced by a specific, trusted system. It answers: "Was this artifact built by our CI pipeline, or did someone tamper with it?"
Cosign and the Sigstore Ecosystem
Cosign (part of the Sigstore project) is the current standard for signing OCI artifacts. Sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue University, designed to make signing as easy as git commit.
The signing workflow works as follows:
- CI pipeline builds an image and pushes it to the registry. The image has a digest:
sha256:abc123... - CI pipeline signs the image using
cosign sign. In keyless mode (the recommended approach), Cosign uses the CI runner's OIDC identity token (e.g., from GitHub Actions) to obtain a short-lived signing certificate from Sigstore's Fulcio certificate authority. No long-lived private key needs to be managed. - The signature is stored as a separate OCI artifact in the same registry, linked to the image digest.
- At deploy time, the admission controller (e.g., Kyverno or Connaisseur) runs
cosign verifybefore allowing the image to be pulled. If the signature is missing or invalid, the deployment is rejected.
Signing an image with Cosign in keyless mode is a single command against the image's digest, using GitHub Actions' OIDC identity as the signer. Verifying it before deployment is the mirror operation — checking that the signature's identity matches an expected pattern (like a specific repository) and issuer.
SBOMs: The Ingredient List
A Software Bill of Materials (SBOM) is a machine-readable list of every component that went into building an artifact — every library, every dependency, every version. Think of it as the ingredient list on a food package, but for software.
SBOMs are increasingly required by regulation (the US Executive Order 14028 on cybersecurity mandates SBOMs for software sold to the federal government) and are essential for rapid response to vulnerabilities. When Log4Shell was disclosed in December 2021, organizations with SBOMs could query them in minutes to find every affected service. Organizations without them spent days manually auditing codebases.
SBOMs can be generated at build time using tools like Syft, which scans the image and writes out a structured inventory, and then attached to the image in the registry using Cosign — stored as an OCI artifact linked to the image, versioned alongside it, and subject to the same retention policies.
"How do you prevent a compromised CI runner from pushing malicious images to production?" is a common senior DevOps/platform engineering interview question. The answer has two layers: (1) signing — use Cosign keyless signing so that only images signed with a valid OIDC identity from your CI system are accepted by the cluster's admission controller; (2) separation — the CI runner has write access only to the dev registry, and promotion to production requires a separate, more tightly controlled pipeline step. Mentioning both layers demonstrates you understand defense in depth.