Content-Addressable Storage

In a CAS system, the content address is the cryptographic digest of the data blob itself—typically a SHA-256 or SHA-512 hash. When a blob is stored, the system computes its hash and uses that value as the retrieval key. This guarantees verifiable integrity: any alteration to the data produces a different hash, making tampering immediately detectable. In container registries, this is why image digests like sha256:abc123... are immutable identifiers, while tags like latest are mutable pointers.

Because identical content produces identical hashes, CAS systems inherently deduplicate data at the block or blob level. When a new object is ingested, the system checks if its hash already exists in the storage backend. If so, only a reference counter is incremented—no duplicate data is written. This is critical for container registries where thousands of images may share common base layers. A Distroless image and a full Ubuntu image might share identical libc layers, stored only once.

CAS systems are designed for write-once, read-many (WORM) semantics. Once a blob is stored under its content address, it cannot be modified—only deleted or replaced by a new blob with a different hash. This immutability is foundational for SLSA provenance and supply chain security, ensuring that a build artifact referenced by its digest today will be bit-for-bit identical tomorrow. Garbage collection processes periodically remove blobs with zero references.

Container images are not single blobs—they are Merkle Directed Acyclic Graphs (DAGs) of content-addressable layers. The top-level manifest contains hashes of configuration blobs and layer blobs. Each layer blob is itself content-addressed. This creates a tamper-evident chain: verifying the manifest's digest cryptographically guarantees the integrity of every referenced layer. Tools like Cosign attach signatures to these manifests, creating verifiable attestations.

Traditional storage retrieves data by where it is stored (file path, URL, block offset). CAS retrieves data by what it is. This decoupling enables seamless geo-replication and registry mirroring—a blob can be pulled from any mirror that holds it, and its integrity is verified locally against the expected digest. The Skopeo tool leverages this to copy images between registries without a Docker daemon, simply transferring content-addressed blobs.

A registry mirror acts as a pull-through cache for CAS objects. When a client requests an image by digest, the mirror checks its local CAS store. On a miss, it fetches the blob from the upstream, verifies the hash matches the requested digest, and caches it locally. This ensures that even cached data maintains end-to-end cryptographic integrity. No trust in the mirror is required—the client always validates the final digest.

A SHA256 hash that serves as the immutable, content-addressable identifier for a container image manifest or layer. Unlike mutable tags, the digest changes if even a single byte of the content is modified, providing cryptographic integrity verification. Registries resolve pull requests by digest to guarantee the exact artifact retrieved matches the one originally pushed, eliminating tampering risks.

An automated process that reclaims storage by deleting unreferenced blobs and orphaned manifests. In CAS registries, garbage collection identifies layers no longer pointed to by any manifest and removes them. This is critical because CAS deduplication means multiple images share common layers—deleting a layer prematurely would corrupt dependent images. The process walks the Merkle DAG of references to determine reachability.

A tool for cryptographically signing OCI artifacts using keyless or long-lived key pairs. Cosign generates a signature object stored alongside the image in the registry, referenced by digest. Verification relies on the content-addressable nature of the image—the signature attests to a specific digest, ensuring the artifact hasn't been altered. Integrates with Sigstore for automated, identity-based signing without manual key management.

A verifiable statement about a container image, such as an SBOM or vulnerability scan result, cryptographically signed and stored in the registry. Attestations are bound to the image digest, not a mutable tag, ensuring the metadata remains coupled to the exact artifact. This enables policy engines to verify provenance and compliance at deployment time by querying attestations linked to the content-addressable identifier.

An OCI index or manifest list that references platform-specific manifests by digest. A single tag resolves to different content-addressable images for amd64, arm64, and other architectures. The registry selects the appropriate manifest based on the client's platform, but each variant is independently content-addressable. This ensures architecture-specific integrity while maintaining a unified tagging interface.

The Supply-chain Levels for Software Artifacts framework provides a tamper-proof record of how an artifact was built. Provenance attestations are bound to the content-addressable digest of the output image, linking the build process—source repository, builder identity, build steps—to the exact artifact. This creates a verifiable chain of custody from source code to registry blob, enabling policy-based deployment gating.