Skip to main content
  1. Index/

OCI Referrers API

OCI Referrers is a mechanism introduced in the OCI Image and Distribution Specification v1.1 (finalised 2024) that allows arbitrary artifacts — signatures, SBOMs, vulnerability scan reports, attestations, provenance documents — to be attached to an existing image in a registry without modifying the image itself and without requiring out-of-band storage or tag conventions. The attachment is expressed through a subject field added to any OCI manifest: a descriptor pointing to the digest of the target image. The registry then indexes these relationships, and the referrers API makes them discoverable.

The mechanics are straightforward. An artifact manifest carrying a subject field is pushed to the same repository as the image it annotates; conformant registries respond with an OCI-Subject header confirming the relationship was recorded. To discover what is attached to a given image, any client issues a GET /v2/<name>/referrers/<digest> request; the registry returns an OCI Image Index whose descriptors point to all manifests with that digest as their subject. Each descriptor in the response carries an artifactType field — a media type string identifying what kind of artifact it is (e.g. application/vnd.dev.cosign.artifact.sig.v1+json for a cosign signature, application/spdx+json for an SPDX SBOM) — enabling clients to filter the response to only the artifact types they need without fetching everything. For registries that do not yet implement the referrers API, a client-side fallback exists: the client maintains a tag derived from the subject digest (replacing : with -) that points to an equivalent index, preserving interoperability with older infrastructure at the cost of requiring client-side writes.

The practical effect is a content-addressed, registry-native supply chain graph. Cosign uses referrers to attach signatures and attestations (including SLSA provenance) to images without the tag mutation that cosign:sha256-<digest>.sig tags previously required. ORAS uses referrers to attach arbitrary files — Helm charts, OPA policies, licence documents — as first-class registry objects linked to the images they govern. bootc and image-based Linux tooling can attach OS-level SBOMs and attestation bundles to OS image releases, queryable by any tool that speaks the distribution spec. Because the subject relationship is expressed as a content-addressed digest, the attachment is immutable and tamper-evident: a referrer can only claim to be attached to an image it actually knows the digest of, and the image’s own digest — and therefore its referrers list — changes if the image changes. The referrers API is the OCI ecosystem’s answer to the question of how supply chain metadata travels with an image through promotion across registries and deployment into production.

Related

SBOM (Software Bill of Materials)

A Software Bill of Materials (SBOM) is a structured, machine-readable list of the components that make up a software artifact: open-source libraries, proprietary packages, operating system packages, programming language dependencies, and the transitive dependencies of all of the above. It is the software analogue of the ingredient list on packaged food — the thing that tells a consumer (or an automated system) precisely what is inside. The term and concept predate current security mandates but became a regulatory requirement in the US through Executive Order 14028 (May 2021), which directed NIST and NTIA to define minimum SBOM elements for software sold to the federal government. The NTIA’s resulting guidance specifies seven minimum data fields per component: supplier name, component name, version, component identifier (CPE or PURL), dependency relationships, SBOM author, and timestamp. The practical use cases SBOMs enable are vulnerability management (correlating component versions against CVE databases to identify affected software), licence compliance (detecting GPL or other licence obligations across the dependency graph), and incident response (determining within minutes which systems in a fleet contain a newly-disclosed vulnerable component, as organisations that had SBOMs could do during the Log4Shell response and those without could not).

ORAS (OCI Registry As Storage)

ORAS (OCI Registry As Storage) is a CNCF project that treats an OCI-conformant registry not as a container image store but as a general-purpose content-addressable storage system for any kind of artifact. Its central insight is that the OCI Distribution and Image specifications are already a well-understood, widely-deployed, access-controlled, geo-replicated, content-addressed storage substrate — and that the ecosystem does not need a separate storage solution for every new artifact type (Helm charts, WebAssembly modules, ML models, firmware images, OPA policies, SBOMs, attestations) when the same registry infrastructure can store all of them, using the same authentication, the same tooling, and the same pull-by-digest semantics that container images already use.

Kata Containers

Kata Containers is an Open Infrastructure Foundation (OpenInfra Foundation) project that replaces the Linux namespace and cgroup isolation of a conventional container runtime with a full VM boundary, while remaining entirely compatible with the OCI runtime specification and the Kubernetes CRI. From the perspective of containerd, CRI-O, or the Kubernetes kubelet, a Kata pod is indistinguishable from a runc or crun pod — the same API calls, the same lifecycle verbs, the same pod spec — but instead of calling clone() to create a new namespace, Kata starts a lightweight virtual machine. The workload runs inside that VM with its own kernel, its own device model, and a hardware-enforced isolation boundary between itself and the host kernel. The premise is that Linux namespaces, while convenient, share the same kernel as the host: a kernel vulnerability exploitable from inside a container can affect the host and every other container running on the same node. A VM boundary means that even a full guest kernel compromise cannot directly affect the host.