Poisoned at the Source: How Container Registries Became Enterprise CI/CD's Most Exploitable Weakness

For years, enterprise security teams have treated source code repositories as the crown jewels of the software supply chain. Version control systems receive rigorous scrutiny — commit signing policies, branch protection rules, mandatory code review gates. Yet a parallel infrastructure, one that sits directly between the code repository and the production environment, has largely escaped that same level of discipline. Container registries have become the overlooked hinge point in the modern CI/CD pipeline, and adversaries have learned exactly how to exploit that neglect.

The consequences are not theoretical. When an attacker successfully poisons a base image in a private or public registry, every downstream build that inherits from that image carries the malicious payload forward — often without triggering a single alert.

The Anatomy of a Registry Poisoning Attack

Container images are built in layers. A typical enterprise application image might start from an official Linux distribution layer, add a language runtime, install application dependencies, and then incorporate proprietary code. Each layer represents a trust decision, and most organizations scrutinize only the final proprietary layer with any rigor.

Attackers who gain write access to a registry — whether through compromised service account credentials, misconfigured registry permissions, or a vulnerability in the registry platform itself — do not need to touch a single line of application code. Instead, they modify an upstream base image. A patched Alpine Linux layer that includes a persistent backdoor. A Node.js runtime image with an exfiltration hook embedded in a rarely-called initialization function. Because the modification occurs at the infrastructure level rather than the application level, standard code review processes never encounter it.

Public registries such as Docker Hub introduce an additional dimension of risk. Research from multiple security firms has documented the presence of malicious images on public registries that mimic the naming conventions of legitimate official images. Developers under deadline pressure who pull an image with a plausible name and a respectable download count may unknowingly introduce a compromised layer into their organization's private registry when they re-tag and push for internal use.

Why Image Scanning Tools Offer Incomplete Protection

The predominant response to container security concerns has been the deployment of image scanning tools integrated into CI/CD pipelines. These tools perform valuable work — identifying known CVEs in installed packages, flagging outdated dependencies, and detecting certain categories of misconfigurations. However, their architectural design creates a significant gap when it comes to supply chain attacks.

Most scanning tools operate against a known-vulnerability database. An attacker who embeds a novel, custom backdoor into a base image layer — one that does not correspond to any catalogued CVE — will pass the scanner without generating an alert. The tool confirms that no known vulnerabilities are present, and the build pipeline proceeds with confidence. That confidence is precisely what the attacker depends upon.

Beyond detection limitations, scanning tools are typically invoked at a specific stage in the pipeline. An image that passes the scanner at build time may be pulled from the registry again at deployment time, potentially after the registry has been modified. Organizations that scan once and assume continuous safety have created a window that a persistent attacker can exploit.

The Access Control Problem

Registry access control deserves attention that it rarely receives. In many enterprise environments, the service accounts used by CI/CD systems to push and pull images are granted broad permissions across the registry. A single compromised pipeline credential can therefore provide write access to every image in the organization's registry, not merely the images associated with the affected pipeline.

Furthermore, registries are frequently treated as infrastructure rather than as application-layer security assets. They may be excluded from regular access reviews, exempt from the same credential rotation policies applied to application secrets, and managed by infrastructure teams that lack a security-first orientation. The result is a permissions landscape that accumulates stale, over-privileged accounts over time.

Building a Registry-Level Verification Framework

Addressing container registry risk requires moving beyond reactive scanning toward a proactive verification architecture. The following framework offers a practical starting point for enterprise security teams.

Establish image provenance requirements. Every image permitted to enter the internal registry should carry a verifiable provenance record. Tools such as Sigstore's Cosign enable cryptographic signing of container images, allowing the pipeline to verify that a given image was produced by an authorized build process and has not been modified since signing. Unsigned images should be blocked from deployment by policy, not merely flagged as warnings.

Implement registry-level immutability for promoted images. Once an image has been scanned, signed, and promoted to a production-eligible repository, it should be treated as immutable. Write access to production image repositories should be restricted to the CI/CD service accounts responsible for promotion, and those accounts should be distinct from the accounts used during development builds.

Separate public and internal registries with an explicit promotion gate. Any base image sourced from a public registry should be pulled into an isolated staging repository, scanned, verified for behavioral anomalies where tooling permits, and only then promoted to the internal base image repository. Developers should be prohibited from referencing public registries directly in build definitions.

Apply continuous re-verification at deployment time. Rather than treating a successful build-time scan as a permanent clearance, deployment orchestration should re-verify image signatures immediately before container instantiation. This eliminates the window between build and deployment during which registry contents could be altered.

Conduct regular access reviews with a least-privilege orientation. Registry permissions should be reviewed on the same cadence as application-layer access controls. Service accounts that have not pushed or pulled images within a defined period should be suspended pending review. Pull access should be separated from push access, and push access should be scoped to specific repositories rather than granted registry-wide.

The Organizational Dimension

Technical controls alone will not close this gap if the organizational structure treats registry security as an infrastructure concern rather than a security concern. Enterprise security teams must assert ownership over registry policy in the same way they assert ownership over repository policy. This means defining and enforcing image provenance requirements, participating in the selection and configuration of registry platforms, and ensuring that CI/CD pipeline design reviews include registry interaction as an explicit scope item.

Game studios and software enterprises that operate at scale ship containers across hundreds of services. Each service represents a potential entry point if registry hygiene is not enforced uniformly. A single poisoned base image in a widely-inherited layer can propagate across an entire production fleet before the first anomaly surfaces in runtime monitoring.

The CI/CD pipeline was designed to accelerate delivery. Without deliberate hardening at the registry layer, it also accelerates the delivery of whatever an attacker has chosen to embed in the build chain. Fortifying that layer is not optional — it is the logical extension of every other security investment the enterprise has already made.