Verify Container Digests, Signers and Builds

Before deploying an updated container, establish three things: the exact image being introduced, the identity authorised to sign it and the evidence connecting it to the expected build. These checks answer different questions and should appear separately in the change record.

For a small team, begin with the images running important customer services and administrative tools. You do not need to build a complex admission platform before making the review more precise.

Record the exact content

An image tag is a convenient name that can be moved to different content. An image digest identifies particular content. Docker's digest documentation explains why a digest is useful for repeatable deployment.

Record the source registry, repository, intended version and resolved digest when reviewing an update. Confirm that the deployment uses the approved reference rather than resolving the tag again later and assuming it still points to the reviewed image.

Digest pinning makes a choice repeatable; it does not make that choice trustworthy or current. If the image contains a known vulnerable package, repeatedly obtaining exactly the same image preserves that package too. Assign an owner and a review process for replacing the pin when a suitable update arrives.

Keep the previous approved image available for a supported rollback. Check whether the application update changes database schemas or stored data before treating an image rollback as sufficient to reverse the whole release.

Verify the expected signer

Ask the image publisher how it signs releases and where it documents the expected verification identity. Obtain that information through the publisher's established documentation, not from an unexplained signature attached to the image you are investigating.

Sigstore's Cosign verification guide supports identity-based verification using an expected certificate identity and issuer. It also verifies that the signed image digest matches the image being checked. Those restrictions matter: accepting any valid identity would answer a much weaker question.

Record the identity rule used, verification outcome, tool version and image digest. If the publisher uses public-key verification instead, document how the trusted public key is distributed, updated and revoked. Different signing arrangements need different trust configuration.

Treat a missing or unexpected signature as a review failure to resolve. Check for a changed release process, wrong repository or unsupported image before creating an exception. If an exception is necessary, give it an owner, a specific image and an expiry; avoid permanently disabling verification for the entire registry.

Check what the build evidence actually claims

Provenance can connect an artefact to a builder and declared inputs. Its value depends on verifying the statement and deciding which builder and source are acceptable. SLSA's artefact verification guidance describes checking the artefact digest, recognised builder and expected source-related information.

Review those fields against the release you intended to deploy. A valid statement from an unexpected build workflow is still unexpected. Likewise, a statement about one digest does not describe another image simply because both carry the same version label.

Keep claims within the evidence. Provenance is not a code review, and a signature is not a vulnerability assessment. Continue checking relevant advisories, image configuration, exposed services and application behaviour. The supply-chain evidence establishes part of the origin story, not every property of the resulting software.

Put the checks into the update path

Use a repeatable review record:

Run the checks in the same path used for production changes. If a person verifies an image manually but deployment later pulls a different tag, the evidence and the running service have separated.

Test the process with an intentionally unapproved image in an isolated environment. Confirm that the review or deployment gate rejects it for the expected reason. Keep failure messages useful enough for an operator to distinguish an unavailable registry from an identity mismatch.

Start in a reporting stage if the estate contains many undocumented images, then enforce the policy for a small, understood set. Resolve the remaining publishers one by one. Review pins and trust configuration together when suppliers change their release infrastructure, so the next security update can still be deployed through a controlled process.

References

• Docker, Image digests. Accessed 17 October 2026.
• Sigstore, Verifying signatures with Cosign. Accessed 17 October 2026.
• SLSA, Build: Verifying artifacts. Accessed 17 October 2026.