Artifact identity: what a digest does

A container tag is a name someone may move. An image digest identifies a particular manifest by its cryptographic hash. When a release selects repository@sha256:…, the reference says which artifact should be fetched even if other tags or objects change.

That property is valuable because a review, a scan, and a signature become ambiguous if they silently refer to different image bytes. A digest provides the recurring identifier that keeps those decisions connected. It does not say whether the identified bytes are secure.

Follow the same immutable identity

Illustrative identity D represents one digest; it is not a recorded deployment digest.

1. The build output identifies an OCI manifest by digest D.
2. The signature, SPDX SBOM and provenance bind claims to D; authenticity does not guarantee safety.
3. Helm values reference D rather than a mutable tag.
4. Admission checks the requested image D and the associated trust metadata.

Solid arrows indicate the stated handoff, not a claim of independent trust. Optional relationships are described in the text equivalent. Historical components are labeled in the caption.

The actual chain in this project

The build-push workflow receives the source revision as the tag and build argument. Docker’s build action returns a digest output. The final-image Trivy scan uses that output as repository@digest. The signing and verification workflows receive the same digest input, rather than rebuilding or resolving a tag themselves.

Cosign signs that digest. The SPDX SBOM and SLSA v0.2 provenance are attached as attestations whose subject includes the image digest. CI checks that the signature’s manifest digest equals its expected digest and that the decoded attestations contain the expected subject digest. It also verifies provenance source commit and material commit against github.sha.

GCP promotion is a separate edit to the Helm image.digest value. The Deployment template renders image.repository@image.digest. Argo CD reconciles that selected value. Kyverno’s policy specifies verifyDigest: true, required: true, and mutateDigest: false; it is not being used as a tag-to-digest mutation service in the documented release path.

Image identity is not source identity

The Git revision names the source state. The image digest names a built artifact. They differ because building also incorporates a base image, package resolution, runtime updates, tool execution, and metadata. The Dockerfile writes the source revision into a label and GIT_SHA, but those are builder-generated metadata. They become useful claims when connected to authenticated provenance, not independent proof of origin.

The Python base image is selected by python:3.12-slim-trixie. The build updates package tooling and downloads packages; the runtime stage applies available Debian upgrades. This baseline therefore does not demonstrate hermetic or reproducible builds. Two builds from the same Git commit may produce different digests. Digest pinning makes the chosen output stable even when the inputs are not fully pinned.

Two storage policies support one identity

Terraform defines an immutable-tag application repository and a separate mutable-tag Cosign metadata repository. Legacy Cosign v2 metadata uses indexes such as sha256-<digest>.att, allowing more than one attestation to be appended. Making those indexes immutable would interfere with that metadata flow.

This separation does not replace cryptographic binding. The verifier reads metadata from the configured repository and checks it against the application’s digest and expected signer. Mutable metadata storage can still be deleted, made unavailable, or filled with unwanted claims by a storage writer. Availability and authenticated origin remain separate concerns. A signature object stored somewhere is not evidence until the consuming verifier validates the correct subject and identity.

What historical captures establish

The live-acceptance capture and baseline Helm value identify digest sha256:32a90d832fdf76794fa5477e42e1fdcec28c9eb6e0deee48ad466d1f7d9fc563. The workflow and attestation screenshots visibly show a different artifact beginning sha256:a0073f8f. They illustrate the same contract in separate observations; they cannot be assembled into one measured end-to-end trace of a single digest.

A runtime event’s image tag is not enough to establish the running image’s manifest digest. For a fresh reproduction, preserve build digest output, verified claim subjects, selected GitOps value, admitted Pod image reference, and container status image ID together. This handbook records the available historical pieces and their association limits.

The next question is what the statements bound to a digest actually mean. Read a valid signature is not enough.

Implementation sources

• Build digest output and final-image scan.
• Signature and attestation binding.
• Exact CI digest assertions.
• Application/metadata repository policies.
• Selected Helm digest and Deployment template.