The `cosign verify` Command You're Not Running (That Saves Your Supply Chain)

You’re deploying container images to production without verifying their provenance. That’s a blind trust in your CI/CD, the registry, and every tool in between. Misconfigurations, compromised build systems, or malicious insertions upstream are all paths to disaster that cosign verify is designed to close.

TL;DR: cosign verify cryptographically checks an image’s signature against a trusted public key or a transparency log like Rekor. This single command is your first line of defense against supply chain attacks, ensuring the image you pull is exactly what was pushed by an authorized source. Integrate it into your deployment pipeline to enforce integrity before runtime.

Why Do You Need to Verify Container Image Signatures?

You need to verify container image signatures because container registries themselves don’t guarantee the integrity or origin of an artifact. They are storage, not trust anchors. Signature verification provides cryptographic proof that an image was signed by a trusted entity and hasn’t been tampered with since.

Sigstore is an open-source project providing a public good for signing, verifying, and protecting software supply chains. It includes tools like Cosign, a certificate authority (Fulcio) for issuing short-lived signing certificates, and a transparency log (Rekor) for immutable recording of signing events. Together, these ensure non-repudiation and public auditability for signed artifacts.

Every time an image moves through your pipeline, there’s a risk. A signature acts as a tamper-evident seal, alerting you if anything changes.

Always verify signatures as close to deployment time as possible to catch last-minute tampering.

How Do You Verify an Image with cosign verify?

The cosign verify command, available in cosign 2.2, takes an image reference and checks its associated signature against a specified public key or the Sigstore transparency log. The simplest usage involves specifying the image and a public key. However, keyless signing via Fulcio and Rekor is the preferred modern approach.

Here’s the basic command to verify an image using keyless signing:

cosign verify --fulcio --rekor ghcr.io/your-org/your-image:latest

Flag/Argument	Description	Best For
IMAGE_REF	The full OCI image reference (e.g., ghcr.io/my-org/my-app:v1.0).	All verification operations.
--key <path>	Verifies the signature against a local public key file. This key must correspond to the private key used during signing.	Air-gapped environments or highly restricted signing workflows.
--fulcio	Verifies the signature against a certificate issued by the Sigstore Fulcio CA. This implies keyless signing was used.	Modern CI/CD systems using OIDC for identity.
--rekor	Ensures the signature’s certificate has been recorded in the Rekor transparency log, providing an immutable public record and non-repudiation.	All production deployments for auditability and tamper-proofing.
--certificate-identity <identity>	Restricts verification to signatures made by a specific OIDC identity (e.g., https://github.com/your-org/your-repo/.github/workflows/main.yml@refs/heads/main).	Enforcing granular trust boundaries in keyless signing.
--certificate-oidc-issuer <issuer>	Restricts verification to signatures made by a certificate from a specific OIDC issuer (e.g., https://token.actions.githubusercontent.com).	Ensuring certificates originate from a trusted OIDC provider (e.g., GitHub Actions, GitLab CI).

How Do You Enforce Strict Identity Verification?

For robust supply chain security, always combine --fulcio and --rekor with explicit identity and issuer checks. This ensures the signing entity matches your expectations. This is crucial as it prevents a valid signature from an unauthorized identity from being accepted.

cosign verify \
  --fulcio --rekor \
  --certificate-identity "https://github.com/my-org/my-app/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/my-org/my-app:v1.0

This command verifies that ghcr.io/my-org/my-app:v1.0 was signed by a specific GitHub Actions workflow in a specific repository and branch. It’s a precise trust anchor. You can find these values from the SIGNATURE output during a cosign sign command.

Example output from a `cosign sign` command showing identity and issuer details

Signing artifacts via keyless signing...
Successfully verified SCT for certificate...
tlog entry created with index: 123456789
Pushing signature to ghcr.io/my-org/my-app:sha256-abcde12345.sig
  ...
  "identity": {
    "certificate": {
      "subject": {
        "commonName": "https://github.com/my-org/my-app/.github/workflows/release.yml@refs/heads/main"
      },
      "issuer": {
        "url": "https://token.actions.githubusercontent.com"
      },
      ...
    }
  }

What If You Use Your Own Keys?

While keyless signing is preferred, if you’re using a static public key (e.g., for internal-only artifacts or air-gapped systems), you can verify against it directly. You’ll need access to the .pub file generated during signing.

cosign verify --key my-signing-key.pub ghcr.io/my-org/my-private-app:v2.0

When NOT to use cosign verify?

Do not use cosign verify if the image wasn’t signed in the first place, or if you only care about whether an image exists in a registry. cosign verify specifically checks for cryptographic signatures; it cannot magically invent them or validate unsigned artifacts. Attempting to verify an unsigned image will simply fail.

Always use cosign verify --fulcio --rekor --certificate-identity <id> --certificate-oidc-issuer <issuer> for maximum security with keyless signing.

Bottom Line

cosign verify is not just a good practice; it’s a non-negotiable step for modern software supply chain security. By incorporating this command into your CI/CD pipelines and deployment manifests, you establish an unbreakable chain of trust for every artifact you deploy. Start enforcing signature verification today to mitigate a significant class of supply chain risks, especially as frameworks like CISA 2026 push for greater software assurance. It’s the simplest way to move beyond the false sense of security that registries alone provide.

FAQ

What is the difference between --key and --fulcio/--rekor?

--key verifies against a locally provided public key, suitable for traditional PKI setups. --fulcio and --rekor enable “keyless” signing, where a short-lived certificate (from Fulcio) is recorded in a transparency log (Rekor), leveraging OIDC for identity instead of static keys.

Can cosign verify protect against vulnerabilities within an image?

No, cosign verify only guarantees the integrity and origin of the image artifact itself, ensuring it hasn’t been tampered with. It does not scan for or mitigate software vulnerabilities within the image’s contents. For that, you need an SBOM-driven risk assessment or a vulnerability scanner.

What happens if an image is not signed, and I try to verify it?

cosign verify will report an error, indicating that no signatures were found for the specified image. For example: Error: no signatures found for .... You cannot verify an unsigned image.

How do I integrate cosign verify into my CI/CD pipeline?

You should add cosign verify as a mandatory step in your deployment or release pipeline, typically after pulling an image but before deploying it to your cluster. This ensures that only verified images proceed. Combine it with a script that fails the pipeline if verification fails.

Where can I learn more about Sigstore and keyless signing?

The official Sigstore documentation and the Rekor project site are excellent resources. They provide detailed explanations and guides on setting up signing and verification workflows.

Further Reading

• https://www.rekor.dev/
• https://github.com/sigstore/cosign

---

🚀 Ready to get hands-on? Spin up an interactive AI or Kubernetes Sandbox at Aicademy Labs for free.