The 'Sidecar' Hack is Dead
For years, we’ve been lying to ourselves about container security. We build a shiny image, run a vulnerability scan, and then... what? We push a signature or an SBOM to the registry and cross our fingers that the 'sidecar' tag—you know the one, image:latest.sig—doesn't get deleted by a cleanup script or desynced from the actual binary. We've been treating our registries like dumb FTP servers when we actually need them to be verifiable, cryptographic ledgers.
The release of the OCI 1.1 specification in February 2024 finally addresses this technical debt. It marks a fundamental shift in how we think about container supply chain security. Instead of hacking together naming conventions to link metadata to images, the OCI 1.1 specification introduces a native way to create a 'graph of trust' directly within the registry. If you are a DevOps engineer or a Security Architect still relying on OCI 1.0 tricks, your supply chain is more fragile than you think.
The Ghost in the Registry: Why OCI 1.0 Failed the Supply Chain
In the OCI 1.0 era, registries only understood 'images' and 'tags.' If you wanted to attach a Software Bill of Materials (SBOM) or a digital signature to an image, the registry had no native concept of that relationship. Tools like Cosign had to invent workarounds, creating 'zombie artifacts' that floated around the registry. These were essentially orphaned manifests that pointed back to a parent image via tag naming conventions.
This created three massive headaches for SREs:
- Lifecycle Management: If you deleted an image, the signatures and SBOMs stayed behind, cluttering storage and costs.
- Discovery: There was no standard way to ask a registry, 'Give me everything you know about this specific image digest.'
- Fragility: Anyone with push access could break the link between an image and its security metadata just by renaming a tag.
The OCI 1.1 specification solves this by introducing the subject field and the Referrers API. As noted in the official OCI release announcement, these additions allow any artifact to point back to a 'parent' image digest with cryptographic certainty. The registry now understands that the SBOM belongs to the image.
The Referrers API: Turning Registries into Graph Databases
The real magic of the OCI 1.1 specification is the new Referrers API endpoint (/v2/<name>/referrers/<digest>). This isn't just a minor update; it's a paradigm shift. Instead of a flat list of tags, your registry now acts as a graph database.
Imagine a scenario where a developer pushes an image. An automated pipeline then pushes a signature, followed by a Trivy vulnerability report, and finally a CycloneDX SBOM. In an OCI 1.1-compliant registry, these aren't just four random files. They are nodes in a graph. When your admission controller in Kubernetes wants to verify the image, it doesn't look for a specific tag. It queries the Referrers API for the image's digest and receives a JSON response containing every piece of linked metadata.
Native Linking with the Subject Field
The subject field is a new first-class citizen in the manifest. When you push an attestation using the OCI 1.1 specification, the manifest explicitly declares its parent. This creates a permanent, immutable link. Major providers have jumped on this quickly; for instance, Amazon ECR has already implemented full support for these features, allowing teams to move away from 'sidecar' hacks and toward stable, native metadata discovery.
Notation vs. Cosign: The New Battleground
With the OCI 1.1 specification, the debate between signing tools has shifted. Cosign (part of the Sigstore project) was built to thrive in the OCI 1.0 world of workarounds. It is incredibly flexible but historically relied on its own way of doing things. On the other hand, Notation (from the Notary Project) was built from the ground up to utilize the OCI 1.1 specification.
Notation focuses on 'purpose-built' signing, leveraging the artifactType field to distinguish between different types of signatures and attestations. While Cosign is rapidly evolving to support OCI 1.1, Notation feels more 'at home' in the new spec, focusing on enterprise-grade signature envelopes that registries can natively parse and validate. For DevOps teams, the choice now comes down to whether you want the broad ecosystem of Sigstore or the spec-native strictness of Notation.
The 'Zombie Artifact' Problem and Recursive Deletes
One of the most practical benefits of the OCI 1.1 specification is how it handles garbage collection. In the old world, registries were terrified of deleting anything because they didn't know what was linked to what. This led to 'registry bloat'—thousands of dollars spent on storage for signatures of images that were deleted three years ago.
Because OCI 1.1 registries understand the subject relationship, they can now perform recursive deletes. If you delete the base node:latest image, the registry knows it can also safely prune the associated SBOMs and signatures. This makes platform engineering significantly cleaner and more cost-effective. Azure Container Registry (ACR) has highlighted this as a key benefit, emphasizing how it simplifies the lifecycle management of non-container content like Helm charts and WASM modules.
Implementation Reality: It's Not All Sunshine
Despite the excitement, we aren't in a post-hack utopia yet. The 'registry parity' gap is real. While AWS ECR and Azure ACR are leading the charge, other major players like GitHub Container Registry (GHCR) and Google Artifact Registry have been slower to roll out full Referrers API support. This leaves many teams in a 'hybrid' hell where they have to use OCI 1.1 features for production but fall back to 1.0 tricks for local development or CI/CD on GitHub Actions.
Furthermore, the decision by the OCI working group to reuse the Image Manifest instead of creating a dedicated 'Artifact Manifest' remains a point of contention. To make it work, you have to include an 'empty config' layer in your attestations, which feels like a bit of technical debt right out of the gate. However, this was a necessary compromise to ensure that older registries wouldn't simply reject the new manifests.
Summary: Moving Toward a Verifiable Future
The transition to the OCI 1.1 specification is the most important infrastructure upgrade for container security in the last five years. It moves us away from 'security by convention' and toward 'security by design.' By treating the registry as a graph of trust, we can finally automate the verification of signed attestations without worrying about broken links or orphaned data.
If you are managing a container platform, your next steps are clear: start auditing your registry's support for the Referrers API. Begin experimenting with tools like ORAS (OCI Registry As Storage) to push non-image artifacts, and look into how Notation can formalize your signing process. The era of the insecure sidecar is over—it's time to embrace the graph.
What's your registry of choice, and are they supporting OCI 1.1 yet? If not, it might be time to start putting pressure on your cloud provider.
