Image Digest

The digest is computed from the manifest or layer content itself, not assigned arbitrarily. Any modification to a single file, environment variable, or metadata field produces a completely different hash. This property enables cryptographic verification that the image pulled at runtime is byte-for-byte identical to the one scanned and approved in the CI/CD pipeline. Content-addressable storage also enables automatic deduplication across registries, since identical layers share the same digest regardless of the image name or tag.

Once an image manifest is hashed, the resulting digest is permanently bound to that specific content. Registries enforce immutability by rejecting any attempt to overwrite an existing digest with different content. This makes digests the foundation of supply chain security—a digest pinned in a Kubernetes deployment manifest or policy engine cannot be silently replaced by a malicious actor. Any tampering is immediately detectable because the recomputed hash will not match the pinned value.

Tags like latest or v1.2.3 are mutable pointers that can be moved to different images over time. A digest like sha256:abc123... is a deterministic, immutable reference. Production deployments should always pin by digest to guarantee repeatability:

• Tag: Mutable, human-friendly, can be retagged
• Digest: Immutable, machine-verifiable, unique per content
• Best practice: Use tags for human identification, digests for deployment manifests and policy enforcement

Two distinct digest types exist in the OCI specification:

• Manifest Digest: The SHA256 hash of the entire image manifest JSON, which references all layers and configuration. This is the digest typically used to pull an image.
• Layer Digest: The SHA256 hash of an individual compressed filesystem layer blob. Each layer is independently content-addressable. Changing a single layer changes the manifest digest, creating a cryptographic chain of custody from the final image back to every constituent component.

Image digests are the anchor for deploy-time security controls. Admission controllers and binary authorization systems evaluate policies against the digest, not the tag, to prevent tag-spoofing attacks. A typical enforcement flow:

• Build system pushes image, records the digest
• Vulnerability scanner attests to the digest via Cosign or Notary
• Admission controller verifies the signature and attestation against the exact digest before allowing pod creation This ensures the image that was scanned is the image that runs.

When pulling by tag, the registry returns the current manifest digest in the response header (Docker-Content-Digest). Tools can capture this to convert a mutable tag reference into an immutable digest pin. Common patterns:

• docker pull alpine@sha256:... — pull by digest directly
• skopeo inspect docker://image:tag — resolve tag to digest without pulling
• Kubernetes imagePullPolicy: IfNotPresent combined with digest references ensures nodes never accidentally pull a mutated image

A security mechanism that uses digital signatures to ensure only authorized, untampered container images are pulled and executed. Content trust relies on image digests as the immutable reference point—signatures are generated over the digest, not the mutable tag. When enabled, the container runtime verifies the signature against the digest before extraction, blocking any image whose manifest has been altered or replaced.

The Supply-chain Levels for Software Artifacts framework provides a tamper-proof, attestable record of the build process. SLSA provenance documents reference the image digest as the subject, binding build metadata—builder identity, source repository, build commands—to the immutable artifact. This creates a verifiable chain from source code to the specific digest deployed in production, critical for air-gapped AI infrastructure audits.

A deploy-time security control in Kubernetes that enforces strict signature validation. Policies reference image digests to whitelist only specific, signed artifacts. The admission controller intercepts pod creation requests and verifies that the digest matches an approved attestation before allowing scheduling. This prevents unsigned or tampered images from ever reaching the container runtime, even if an attacker compromises the registry.

A storage architecture where data blobs are located by a cryptographic hash of their content rather than a mutable name. Container registries use this model: each layer blob is stored under its SHA256 digest, enabling automatic deduplication—identical layers across different images share the same storage. This guarantees that retrieving a blob by digest always returns the exact bytes originally pushed, with no possibility of substitution.

A cryptographically signed, verifiable statement about a container image stored alongside it in the registry. Common attestations include SBOMs, vulnerability scan results, and build provenance. Each attestation references the image digest as its subject, creating a cryptographic binding. During deployment, policy engines verify that the digest has the required attestations—such as a clean vulnerability scan—before allowing execution.