Image signatures bind a digest to a trusted signer

Thu, 21 Oct 2027 00:00:00 +0000

A container image tag is a mutable pointer; a digest identifies content. A valid signature binds a signed statement about that digest to a signing key. Whether that key represents an authorized person or workload is a trust-policy decision. Signing alone does not prove who built the image, that the build followed a claimed process, or that the resulting software is safe.

The useful boundary is the verifier’s decision before deployment. It must check the content binding and the intended trust root, then apply the required identity and provenance policy. A registry location, a familiar tag, or the existence of a signature is insufficient.

Digests are the identity, tags are pointers

An OCI manifest digest hashes the manifest bytes. Descriptors in that manifest identify configuration and layers by their own digests; clients must check those bindings too. A changed manifest has a different digest under the collision-resistance assumption. Mutating a stored blob without updating its descriptor should cause a content-integrity failure, not silently redefine the image.

Cosign’s normal image-signature payload contains the image digest, which verification checks against the requested image. Different tags can resolve to the same signed digest. If a tag moves, the previously verified digest says nothing about the newly resolved object. Resolve and verify the intended digest, then deploy that same digest; a later tag lookup leaves a race between checking and use.

A tag string does not bind image content

A signature over the literal string app:v2 authenticates that statement, not the changing object behind it. A signature can include other contextual claims, so inspect its actual format and verifier behavior. Do not disable digest-claim checks merely to make an unrelated payload pass.

For key-based verification, policy must establish why the supplied public key is trusted. For keyless verification, check the expected certificate identity and OIDC issuer as well as the certificate chain and required transparency evidence. Fulcio certificates associate an identity with a key; they do not inspect a build or certify its output. A build claim requires suitable provenance, a trusted builder, and checks that the attested subject matches the artifact.

Verification is the control, not the signature

Enforcement can happen at admission or before deployment, but only within the configured scope. Confirm which workloads and registries are covered and how verification failures are handled. Merely recording a digest does not establish authorization, and even a correctly verified signature does not detect every vulnerability or malicious behavior in signed software.

Cryptographic signature validity and current policy acceptance are separate. Retiring a key requires changing the accepted trust policy; generating a replacement key alone does not update every verifier. Short-lived certificates and trusted signing-time evidence can support verification of historical signatures after certificate expiry. Transparency makes signing activity inspectable, but does not automatically revoke compromised identities or block malicious releases. Incident response must decide which identities, time windows, digests, and attestations remain acceptable.

When it breaks

A deploy step verifies one digest and later pulls a mutable tag. Another push can change the deployed bytes after verification. Pin the verified digest through the handoff, including the intended manifest or multi-platform index, and check how the runtime selects the platform-specific image.

Another failure accepts any cryptographically valid signer. Restrict trust to authorized keys or expected identity-and-issuer pairs, and test rejection of a wrong signer and an unapproved digest. A compromise requires investigation and an explicit policy change; it does not retroactively prove that every older artifact was malicious.

Image signature trust: mechanism and evidence boundaries.

Check it quickly

The following commands are a template, not a runnable fixture: the registry is an example and the digest is abbreviated. Before any authorized registry check, supply an existing test image’s complete digest, its trusted public key, and installed Cosign and Skopeo versions. No signing, registry operation, or deployment was run for this source review.

cosign verify --key cosign.pub registry.example.com/app@sha256:9ab5a134...
cosign tree registry.example.com/app@sha256:9ab5a134...
skopeo inspect --format '{{.Digest}}' docker://registry.example.com/app:latest

Expect successful verification of the specified digest under the selected key, not necessarily a printed human identity. cosign tree discovers associated objects; listing them does not verify their claims. The Skopeo result can check the tag’s current resolution, but a mismatch only means it differs from the digest just checked; the other digest might have its own signatures. Even equality is a snapshot, not protection against the tag moving afterward.

Sources

Sigstore: verifying signatures with cosign, key-based and keyless verification over a digest, checked 2026-09-16.
SLSA v1.0 specification, provenance, digests and what a signature is claimed to attest, checked 2026-09-16.
Sigstore policy-controller, enforcing signature and identity policy at admission, checked 2026-09-16.
OCI image descriptor specification, digest binding to referenced content, checked 2026-10-18.
SLSA v1.0: verifying artifacts, trusted builder and provenance policy distinct from signature validity, checked 2026-10-18.
Sigstore overview, identity certificates and transparency boundaries, checked 2026-10-18.
Sigstore timestamps, trusted signing time and certificate validity, checked 2026-10-18.
Sigstore: signing containers, tree discovers associated signatures, checked 2026-10-18.
Skopeo inspect manual, top-level manifest digest and platform-specific fields, checked 2026-10-18.