For a keyless signature, run cosign verify with both a certificate identity and a certificate OIDC issuer, and point it at the image. The check passes only if the signature matches that identity and issuer. You must get both values from the publisher, because a signature by the wrong identity is still a valid signature.
The command
The Sigstore documentation shows keyless verification like this, with your values in place of the examples:
cosign verify IMAGE \
--certificate-identity=name@example.com \
--certificate-oidc-issuer=https://accounts.example.com
It lists issuer URLs for several providers, including Google, Microsoft, GitHub (https://github.com/login/oauth) and GitLab (https://gitlab.com). For key-based signing the form is cosign verify with a key flag and a public key file.
The documentation also notes that signature payloads include the image digest, and by default cosign verify checks that this digest matches the container. A flag exists to skip claim checks, but the docs warn that this still verifies the signature without verifying the payload claims, so leave it alone unless you know why you need it.
What to ask the publisher
A signature proves a particular identity signed it. It says nothing about whether that is the identity you wanted. So collect, before you verify:
- The expected signer identity: for a keyless build in a pipeline this is typically an identity tied to the project, not a person. The publisher should state it in their documentation.
- The expected issuer for that identity.
- Where the signature is stored, if it is not alongside the image.
If a publisher offers a signature but no statement of the expected identity, you cannot do a meaningful check. You would be verifying that someone signed it.
Steps to adopt in a pipeline
- Resolve the tag to a digest and verify the digest, not the tag. A tag can move after you check it.
- Pass the identity and issuer from a reviewed configuration file in your repository.
- Fail the build on verification failure.
- Record the digest and the verification result with the build.
- Re-verify when you change the pinned digest.
What a pass tells you
| A pass means | A pass does not mean |
|---|---|
| The named identity signed this digest | The image has no vulnerabilities |
| The digest was not altered after signing | The build was not compromised before signing |
| You checked against a value you chose | The publisher is trustworthy in general |
Docker has said it is retiring Docker Content Trust for official images, and recommends planning a move to a different signing solution, such as Sigstore or Notation. If you were relying on the old mechanism, this is the route to look at.
Combine with other checks
Signature checks fit with provenance, a scan and a pinned digest. Together they answer who built it, how, what is inside, and whether it has changed.
Quick check
Why verify the digest instead of the tag?
A tag can be moved after you verify it. A digest names exact content, so the check and the run refer to the same bytes.
If cosign verify passes, can I skip scanning?
No. It shows who signed and that the digest is unchanged. It says nothing about vulnerabilities inside.
Safeguard policies and gates can enforce checks in your pipeline, and dependency scanning and SBOM cover what is inside the image. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
