Cosign verify checks that a valid signature exists for the image, that the signed payload digest matches the container, and, if you supply an identity or a key, that the signer is who you expect. It does not decide whether the image is safe or whether your policy is met.
The three layers of a check
| Layer | What is checked | Needs you to supply |
|---|---|---|
| Signature | A signature exists and verifies against a key or certificate | A key or keyless trust roots |
| Digest | The digest in the signed payload matches the container | Nothing, it is the default |
| Identity | The certificate identity and OIDC issuer match | Both identity and issuer values |
The cosign docs say that by default cosign validates the digest matches the container during verify. They also describe a flag that turns off claim checking and advise using it only for non cosign payload formats. Leave it alone otherwise.
Identity is the part people skip
For keyless signatures the docs show verification with both an expected identity and an issuer:
cosign verify <image URI> \
--certificate-identity=name@example.com \
--certificate-oidc-issuer=https://accounts.example.com
Common issuers listed in the docs include Google, Microsoft, GitHub and GitLab. If you skip these, you learn that someone signed, and anyone with an account can sign. The identity check is what turns a signature into a statement about your publisher.
For key based signing, verify with the public key file, or a KMS reference. To avoid a KMS call at verification time, export the public key first.
Attestations
The verify attestation command checks attestations attached to an image. Payloads use the DSSE spec and decode to an in-toto Statement. Cosign can also validate the predicate against a policy file written in CUE or Rego. The docs add that systems should fail closed rather than open.
What it does not check
- Whether the image has vulnerabilities.
- Whether the signer is trustworthy beyond the identity you named.
- Whether the tag you typed points where you think. Verify a digest reference.
- Whether your organisation's policy, such as required provenance level, is met. That needs a policy step.
A solid verification step for a pipeline
- Resolve the tag to a digest.
- Run verify with identity and issuer, or the public key.
- Run verify attestation for provenance and check the predicate type and fields.
- Fail the deploy on any non zero exit.
- Log the digest and the identity that verified.
Where Safeguard fits
Safeguard's policy gates can enforce deployment rules, and image scanning covers vulnerabilities, which verify does not.
Try it yourself
Click through it at your own pace, or open it full screen.
Scan an image in the demo to see the content findings that a signature check will never show.
Quick check
Does a passing cosign verify mean the image is clean?
No. It means the signature and digest checks passed, plus identity if you supplied it. Scan the contents separately.
Should I ever turn off claim checking?
Only for payload formats that are not produced by cosign, as the docs advise.
Sources
Last reviewed: 19 October 2026.
