Supply Chain Security Controls for Moby Project Registries

Container registries are third-party infrastructure by definition, and the Moby Project (the open-source framework behind Docker Engine, Mirantis Container Runtime, and a handful of other downstream products) exposes three distinct layers where that infrastructure can fail: the containerd image store that handles pulls at runtime, BuildKit which stamps images with supply chain metadata at build time, and the OCI Distribution Specification that governs how any conformant registry accepts and serves that data. Most security programs pick one of the three and call it done, usually signing at push time, then wonder how an attacker moved laterally through a registry they thought was locked down. Signing is the one everyone reaches for first, though the incidents below illustrate how often attacks bypass it entirely. This piece maps each control to the layer where it actually works, because no single tool, plugin, or vendor product covers all three at once.

One naming note before the mechanics: the daemon most people call "Docker" is dockerd, the moby/moby project. As of Docker v29 (November 2025), the github.com/docker/docker Go module is deprecated. Anyone importing it for tooling, scanners, or custom AuthZ plugins is building on a dead path; the supported modules include github.com/moby/moby/client and github.com/moby/moby/api. Tooling still pinned to the old import won't get upstream fixes. This point is central rather than a footnote. It's the kind of dependency drift that turns into a security flaw nobody notices for years, which is exactly the pattern the rest of this piece keeps running into.

What attackers actually do to registries and build pipelines in the Moby ecosystem

Open-source malware detections rose sharply in 2025 compared to 2024, and exposed development secrets across major repositories climbed too, according to ReversingLabs' fourth annual Software Supply Chain Security report. A vendor's 2026 breach report puts third-party involvement in breaches at 48%, up from 30% the year before. A registry is third-party infrastructure the moment more than one team pulls from it, so that number is not abstract for anyone running deployments on a widely used container engine at scale.

The attack patterns are not exotic. Malicious image injection is the simplest: get write access to a registry namespace, replace or poison a tag, wait for downstream systems to pull it. Base image poisoning works the same way but slower, since standard official Docker Hub images typically ship with 50 to 60 known vulnerabilities, 15 to 20 of them rated High or Critical, most traceable to packages the application never actually uses. Nobody audits every layer of a base image before FROM-ing it. That's the joke and the vulnerability, same line.

Helm chart abuse deserves its own mention because it scales differently. If an attacker reaches an internal deployment platform, running one arbitrary Helm chart doesn't compromise a single container, it stands up malicious workloads across the whole cluster in one shot.

A well-documented illustration of registry-adjacent risk is a cryptojacking campaign against exposed Docker daemon APIs. Threat actors found an unauthenticated Docker API endpoint, used it to create a container, ran lateral-movement scripts from inside it, then pulled down an XMRig miner. Nobody signed anything. Nobody forged a registry credential. The API itself was the open door, and it counts as a registry-adjacent control plane whether or not anyone draws it that way on the architecture diagram. Another vendor's 2026 open source security report found that 65% of organizations hit a software supply chain attack in the past year. This is a recurring risk rather than a rare-event tail risk. That's close to a coin flip.

CVE-2024-41110 and what it reveals about AuthZ enforcement in the Docker daemon

CVE-2024-41110 carries a CVSS score of 10.0, the maximum, and the mechanism behind it is almost insultingly simple. Send an API request to the Docker daemon with Content-Length: 0. The daemon forwards that request to the AuthZ plugin without a body, and the plugin, with nothing to evaluate, approves it anyway. Authorization checks don't fail loudly here. They just quietly agree to whatever's asked.

Here's what should bother anyone who trusts patch status as a proxy for security posture: this bug is not new. It was found and fixed back in Docker Engine v18.09.1, in January 2019. That fix never carried forward into later major version branches, so the same hole sat there, unpatched, for five years, until someone re-found it in April 2024. This wasn't a novel exploit. It was a known, previously patched vulnerability that came back from the dead with a five-year head start and a passport it lost somewhere in version control.

Docker resolved it as of July 23, 2024, backporting the patch into master and the 19.033, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 branches, with docker-ce v27.1.1 carrying it forward. Anyone who couldn't upgrade immediately got the standard interim advice: skip AuthZ plugins entirely if unpatched, restrict Docker API access to trusted parties only, and apply least-privilege rules to the daemon socket. The stakes were not abstract either. A successful bypass here means privilege escalation into cloud tokens, Kubernetes service accounts, and other credentials, registry access among them.

Two more Moby advisories from the v29 release notes round out the picture. CVE-2025-61729 covers a denial-of-service path through excessive resource use when formatting hostname validation errors. CVE-2025-61727 is more directly relevant to registries: incorrect enforcement of excluded subdomain constraints on wildcard SANs, which can let improperly trusted certificates slip through TLS verification during registry communication. Separately, a Moby release vendored containerd v1.7.33 specifically to pull in a fix for CVE-2024-40635, a reminder that containerd vulnerabilities travel into Moby through the dependency chain whether or not anyone at the daemon level wrote a line of vulnerable code themselves.

The through-line across all of this: a fix that existed, got dropped during version branching, and stayed invisible for years is not a patching problem. It's proof that patch status alone tells you almost nothing about actual exposure at any given moment. Runtime monitoring exists because version numbers lie by omission.

Image signing approaches available for Moby-compatible registries and which ones are still viable

Signing does two things and only two things. It proves integrity, meaning the image pulled matches a specific signed digest and hasn't been altered in transit or at rest. And it establishes authenticity, meaning it defines which identities get to sign images that are then treated as approved. What it doesn't do is vouch for what's inside the container. A malicious image, signed correctly, is just a verified malicious image. Signing without scanning, attestations, and runtime checks is a lock on a door with no idea what's already in the room.

Sonatype's 2024 State of the Software Supply Chain report recorded a 156% year-over-year jump in malicious packages, roughly the moment signing stopped being a nice-to-have and became table stakes for anyone shipping containers professionally.

Docker Content Trust, built on Notary v1, is dead and should be treated that way. Deprecation started March 31, 2025, with full removal from Azure Container Registry set for March 31, 2028. Starting August 8, 2025, the oldest DCT signing certificates on Docker Official Images began expiring, so anyone still relying on it is now staring at trust warnings that won't go away. The underlying Notary project isn't actively maintained, and Harbor dropped Notary v1 support back in version 2.9.0, in 2023. What killed DCT was structural: it required running a separate Notary server alongside the registry, and standing up a whole second server just to sign images never worked well in practice. Don't adopt it, and don't keep it running out of inertia either.

Notary v2, implemented through the Notation CLI, is the current OCI standard and the right call for organizations already running enterprise PKI. It is designed to eliminate the need for a separate signing server, so the signature can travel with the image across registries. It supports multiple signatures per image and plugs into existing PKI infrastructure, which makes it the natural pick for shops that already run a certificate authority with audit requirements around signing identity.

Sigstore, through Cosign, takes the opposite philosophy and fits CI/CD pipelines better. It's an open-source project originally backed by Google, Red Hat, and Purdue University, now under the Linux Foundation, free to use. The keyless signing model is the interesting part: it uses OIDC to mint a short-lived Fulcio certificate tied to the CI identity doing the signing, signs the image, then throws away the private key. No long-lived key to rotate, lose, or leak. Every signing event lands in Rekor, an append-only, publicly auditable transparency log, so even if the registry itself gets compromised, the signing record can't be quietly rewritten. The signature is stored alongside the image in the registry, so it remains associated with the image as it moves through a pipeline.

OpenPubkey is worth naming because Docker announced it, not because it's usable yet. Built by BastionZero and launched in partnership with Docker in 2023, later donated to the Linux Foundation, it was pitched as the mechanism for signing Docker Official Images. Docker said in October 2023 it planned to use OpenPubkey for exactly that. As of March 2025, that plan hadn't shipped. Docker Official Images are not currently signed with OpenPubkey. Treat it as a roadmap item, not a control anyone can rely on today.

How BuildKit generates and stores SBOM and SLSA provenance attestations in OCI registries

BuildKit is the piece of Moby that actually produces the supply chain metadata attached to an image once it lands in a registry. As of February 2025, it supports two attestation types. The first is an SBOM (Software Bill of Materials), generated in SPDX-JSON format, listing every software component detected in the image. Syft is the default generator, with Docker Scout available as an alternative. The second is SLSA Provenance, which records how, when, and where the image got built, using the SLSA provenance schema and supporting both v0.2 and v1 of the spec.

Both get represented in the in-toto format and stored as manifest objects attached to the root image index, under a separate OCI image manifest. That detail matters more than it sounds: attestations are OCI artifacts, not sidecar files sitting in a folder someone forgets to copy during a migration.

SLSA Level 3 provenance, done right, provides cryptographically backed build records and source integrity guarantees, giving verifiers confidence that an image came from the expected repository and commit rather than a fork or tampered branch.

The practical guidance here is simple: attach the SBOM as an OCI attestation inside the registry rather than exporting it as a standalone file somewhere. When an image gets promoted from dev to staging to production, the SBOM travels with the digest automatically. A separate file needs a separate copy-and-sync process, and separate processes drift. They always drift.

None of this catches malice at the point of ingredients, and that limit needs to be stated in clear terms. Attestations describe what was present at build time, not whether what was present was safe. A malicious package, styled after the event-stream compromise, can look entirely legitimate at build time. The SBOM passes. The provenance passes. The signature checks out. The image still carries malware, because none of those three controls were built to catch it. Base image risk inherits the same blind spot: the XZ Utils backdoor hid inside official Debian testing and unstable Docker images, not the stable releases, and provenance can tell you exactly which base image was used without ever telling you that base was compromised.

OCI Distribution Specification controls that apply at the registry protocol layer

The OCI Distribution Specification sits underneath all of the above, governing how any conformant registry exposes and accepts image data regardless of which signing tool or attestation format runs on top of it. A handful of controls live specifically at this layer.

Content addressing by digest is the simplest and most underused. An image pinned by sha256:... digest can't be silently swapped the way a mutable tag can; latest can point to something entirely different tomorrow, but a digest is the artifact, permanently. Enforcing digest-pinned pulls in deployment manifests is a distribution-layer decision, and it's one of the cheapest controls available. Skip it and every other control in this piece is bolted onto a foundation that can shift under it.

The OCI artifact referrers API is the mechanism that makes Notation signatures, Cosign signatures, SBOMs, and SLSA attestations discoverable and portable as OCI artifacts tied to a specific image. Not every registry that claims OCI conformance actually implements this API, and that gap is worth checking before an organization builds its attestation strategy on top of it. Conformance and referrers support are not the same claim, and vendors are not always careful about which one they're advertising.

Registry push access is a policy question, not a technical afterthought. Whoever can push to a namespace effectively controls what gets deployed downstream, and the 65% supply chain breach figure cited earlier includes plenty of cases where the entry point was exactly this: an access control gap rather than a cryptographic one. TLS certificate enforcement belongs here too. CVE-2025-61727, the wildcard SAN bypass in Docker Engine v29, is a direct reminder that TLS verification during registry communication can get quietly undermined by a daemon-level bug, a separate risk from patch management that needs its own enforcement policy.

Mutable tags are convenient, and that convenience is exactly the problem. Registries that support immutable tag policies close off overwrite attacks without requiring every deployment manifest to remember digest pinning by hand. Registry mirroring helps too, particularly in air-gapped or tightly controlled environments: pulling from an internal mirror instead of straight from Docker Hub shrinks the blast radius if the upstream registry gets compromised, and paired with digest pinning, that's a real layer of defense, not a box-checking exercise.

Access policy and least-privilege controls across the Moby daemon and registry interfaces

The interim mitigation guidance for CVE-2024-41110 doubles as a permanent operating principle, not a temporary workaround to drop once a patch lands. Skip AuthZ plugins where they can't be fully trusted or verified. Restrict Docker API access to known, trusted parties, full stop, no exceptions carved out for convenience. Apply least-privilege rules to the daemon socket itself, because that socket is effectively root access to everything the daemon can touch, registries included.

None of the three layers covered here, containerd's image store, BuildKit's attestation pipeline, or the OCI Distribution Specification's protocol controls, substitutes for the others. Signing an image says nothing about API exposure. A clean SBOM says nothing about who can push to the namespace it lives in. Locking down the daemon socket says nothing about whether the base image inside was compromised before it ever reached the registry. Treat these as one continuous surface, not three separate boxes on three separate teams' to-do lists. This is the only approach that holds up against the pattern CVE-2024-41110 already proved: a control that quietly stops working looks exactly like a control that was never applied in the first place.