A valid image signature shows that a particular identity or key signed a particular digest, and that the digest has not changed since. It does not show the image is free of vulnerabilities, built from clean source, or safe to run. Signing answers who and what, not whether it is good.
What signing binds together
The Sigstore documentation describes signing as binding an artifact to an identity. In keyless signing, a certificate authority issues a short-lived certificate that ties an ephemeral key to an OIDC identity, and the signing event is recorded in a transparency log. The signed object contains the hash of the artifact, the public key, and the signature.
Verification compares the signature, the key or certificate, and the artifact against the log entry. If they match, the signature is valid because the expected signer's identity was certified at signing time. The log entry is immutable, so a signer can monitor it for unexpected signing events.
Key-based signing works too: you hold a private key, and verifiers hold the public key. The tradeoff is key management. The Sigstore page notes that identity-based signing is the default because managing keys securely is hard.
What a good verification checks
A useful policy checks more than "is there a signature."
- The signature is valid for this exact digest.
- The signer is the one you expect, such as your build workflow's identity, not any identity.
- The signature was made in a way you accept, for instance recorded in a log.
- You verified the digest you will actually deploy, not a tag that can move.
If a policy says only "signed by someone," then anyone who can sign passes.
What a signature does not prove
- It is not a vulnerability verdict. A signed image can contain known flaws. Scanning is separate.
- It does not prove clean source. If an attacker controlled the build input, the build will faithfully sign the result.
- It does not prove a trustworthy builder unless you also know how it was built. Build provenance records that. See signatures, provenance and SBOMs compared.
- It does not prove the signer was uncompromised. A stolen key or a hijacked workflow signs bad images just as well.
- It says nothing about the dependencies inside the image.
Where signatures help
They shine against a narrower set of problems. Someone replaces an image in a registry with a lookalike. A mirror serves something different from the upstream. A tag is moved to another image. A deployment pulls from the wrong place. In each case, a verification step that requires your signer on the exact digest catches the swap.
A realistic stack
Treat a signature as one layer.
- Sign in CI with a scoped identity.
- Verify at deploy time against that identity.
- Scan the image for vulnerabilities and secrets before and after release.
- Keep an SBOM so you can answer which images contain a newly disclosed package.
Safeguard's SBOM and dependency scanning, policies and gates cover the scanning and rule layers around signing. A free scan is a way to see the contents behind a digest.
Quick check
If an image is signed, can I skip scanning?
No. Signing proves origin and integrity of the digest. It says nothing about flaws inside it.
Is keyless signing less secure than keys?
They trade different risks. Keyless avoids long-lived keys to protect, and relies on identity and the log. Keys give you control but need careful storage and rotation.
Sources
Last reviewed: 19 October 2026.
