For the past five years, I’ve worked on supply chain security for containers and cloud-native workloads, and I’ve had the same conversation with security-conscious enterprises over and over. They don’t want their developers – or, now, their AI agents – pulling insecure images directly from public registries. Over those conversations, several clear patterns for securing the supply chain emerged. The most common one is to quarantine images: pull them into a dedicated registry, run security checks, and only release them to an internal registry once they pass. This is the “golden image” pattern, and it’s a well established one – though it’s only one of several patterns I’ll cover in future posts.
Almost everyone implements this in their CI/CD system. That made sense when it started. It makes less sense now, and as supply chain attacks grow and agentic workloads start pulling images on their own, it’s becoming the wrong place for this work.
This post walks through why.
The Pattern Today
The typical implementation looks like this: a CI/CD pipeline pulls an image from a public registry into a quarantine registry, runs scans and policy checks, and – if it passes – pushes it to the registry developers are allowed to consume from. I’ve written about the mechanics of this before in Implementing Quarantine Pattern for Container Images.
Teams reach for CI/CD because their DevOps engineers already know the tool. Pipelines are easy to write, easy to trigger, easy to audit. For a registry sitting on the public internet, this works fine.
The trouble starts when the network gets more restrictive.
Where It Breaks?
Walk up the security spectrum and the CI/CD-based approach degrades at every step.
Public registry. No issue. SaaS CI/CD like GitHub Actions, GitLab, or CircleCI can reach the registry, run the workflow, and push results back. This is the happy path.
Firewalled registry. Now the CI/CD system needs to be on the allowlist. For self-hosted CI/CD, that’s a configuration exercise. For SaaS, you’re trying to allowlist IP ranges that the vendor may publish but that rotate, expand, and span a huge surface area. Most teams give up on network controls here and fall back to authentication alone – which compromises the defense-in-depth. Here are the more secure architectures but sometimes hard to achieve:
or
Private VNet. Some SaaS offerings can’t reach into a private network at all. The ones that can, typically require self-hosted runners with private IPs, which means you’re now operating CI/CD infrastructure inside the secure zone – paying for the SaaS and maintaining the agents – increased maintenance and cost.
Air-gap. This is where the model really strains. You need a full CI/CD environment on the air-gap side, mirroring the one on the public side, because development happens on the public side but the security checks need to run where the protected registry lives. Most teams don’t actually do this – they build something bespoke and lighter-weight, and then carry the maintenance burden of two divergent systems forever.
The problems become more obvious as the network gets more restrictive – the CI/CD approach gets more expensive, more complex, and less secure, because teams cut corners to make it work.
A Different Approach to Run Supply Chain Workflows
The alternative is to run the supply chain security workflow in the cluster that’s colocated with the registry, or – better – in the registry itself.
This sounds like a small move but it isn’t. It changes which network paths need to exist, where credentials live, and what has to be duplicated across environments.
- Firewalled and VNet registries no longer need inbound paths from an external CI/CD system. The cluster already has the network access it needs to talk to the registry – that’s its day job. No new firewall rules, no IP allowlisting, no self-hosted runners inside the secure zone.
- Air-gap stops requiring a parallel CI/CD environment. The workflow lives next to the registry on the air-gap side and runs there natively. You still need a way to move images across the gap, but you’re no longer maintaining two CI/CD systems.
There are concrete advantages beyond network topology:
- Authentication and authorization consolidate. The cluster already has identities that can access the registry; you apply policy in one place instead of granting broad registry access to an external pipeline system.
- OCI artifacts and referrers can be used to implement workflows – the OCI spec mechanism that lets you attach signatures, SBOMs, scan results, and attestations offers the natural building blocks for workflows. Workflow activities and connectors can be implemented as images. Workflow definitions, templates, and manifests can be packaged as OCI artifacts and easily moved between registries – using promotion workflow.
- Implementations become portable. The same workflow definition runs in the public-side registry and the air-gap registry, because the runtime is the cluster, not a vendor-specific CI/CD DSL.
The Honest Caveat
Most registries don’t support this model fully today. Some have hooks. Harbor has scanning and policy integrations. Azure has ACR Tasks. But the end state – workflows defined and executed inside the registry, with the registry as the policy enforcement point – is not where the ecosystem is yet.
That’s a gap worth closing, especially as AI agents start consuming images at machine speed and machine scale. A pipeline-based quarantine that works at human review pace is going to look very different from one that has to make decisions about an image an agent is about to pull in the next 200 milliseconds.
Custos
Custos is a project I’ve been building to demonstrate what this architecture looks like in practice – a supply chain security workflow that runs in a cluster colocated with the registry, uses OCI artifacts and referrers to attach valuable metadata to images, and is designed to work identically in public, firewalled, and air-gap environments. It’s a vibe-coding project, not a product, but it makes the argument concrete in a way a blog post can’t. If the model in this post resonates with how you’re thinking about your own supply chain, take a look – I’d genuinely value the feedback.
In future posts I’ll go deeper into other supply chain security patterns I see in the field. The quarantine pattern is the most common one, but it’s only the start.