The Docker registry goldmine of 2026.

What this report is

For six months, BleedWatch Labs has run pattern observation against the public segment of major container registries — Docker Hub, GHCR, public quay.io, and a small set of regional providers. Pattern observation, not engagement-attributable scanning. The point of this report is to describe what the public registry surface looks like in 2026, not to name organisations.

No company is named. No screenshot identifies an engagement. The artefacts referenced below are reconstructions of recurring patterns, with details adjusted to make pattern-matching back to a specific client impossible. If the description feels precise, it is because the pattern is common.

What still leaks, ranked

The patterns below are listed in approximate order of frequency observed over the period. The order is stable across months — the head of the distribution has not moved.

1. Build arguments serialised into image history. A team passes a database URL or an API token as --build-arg during a CI build, intending it as a parameterisation mechanism. The argument is recorded in the image manifest, in the History block, and remains readable forever from a docker history call. The repository may not contain the value. The image does.

2. Environment files baked into a layer. A .env.production is COPY-ed into the image, then deleted by a later RUN rm. The file remains in the parent layer regardless of the delete. Layer extraction recovers it. We see this in roughly half of the prod-tagged images we audit during a Board-Ready engagement.

3. Wide ENV declarations. ENV AWS_ACCESS_KEY_ID=AKIA… set at build time, often inserted by an assistant or a copy-pasted snippet meant for a local sandbox. The value remains in the image config and is recoverable with docker inspect.

4. Multi-stage final stage missing the right COPY scope. A --from=builder step that copies /app wholesale instead of /app/dist, dragging the entire source tree, lockfiles with proxy credentials, and developer machines' .npmrc tokens into the final image.

5. Tags that should never have been public. Tags like internal-staging-2026-04-21, qa-rc4, temp-debug, revertme. The intent was internal; the registry was set to public; the discoverability window is the entire indexed history.

What we have stopped seeing

A small list, because the encouraging news matters.

• Plaintext private keys inside pem files copied into the image. Almost gone in 2026.
• Direct database connection strings in ENV declarations of images tagged latest. Still present, but a fraction of where it was in 2024.
• Stripe secret keys in NPM-distributed Docker images. Effectively eliminated by Stripe's restricted-key push.

The improvement is not even. It tracks closely with which detection vendors have a strong public signal on the relevant pattern. If a regex is widely shared, the pattern decays. If the pattern is more contextual — a build arg, a partial token, a derived credential — it stays.

What this means for an audit buyer

When a CISO asks Labs to audit their public Docker surface, the question is rarely "is anything leaking right now." The answer is almost always yes, and the volume of noise is high. The useful question is "what is leaking that an attacker can chain into impact, and what is recoverable from layers tagged before our last clean image."

That question requires layer-level reading, not just latest-tag scanning. The historical surface of a registry — every tag the team ever pushed — is the real attack surface. An attacker is patient enough to read it. A scanner that only reads latest is not.

What we will not publish

Several things stay private by Labs publication standard:

• The exact regex patterns used to identify build-arg residue and layer-recovered credentials. Publishing the regexes accelerates evasion by adversaries who study them.
• The list of public images we have observed during a specific engagement. The image namespace alone is identifying.
• Statistics on per-vendor exposure. A frequency table that says "vendor X has Y leaks per quarter" is identifying to vendor X and to vendor X's customers.

The frequency rank above is composed across hundreds of distinct artefact namespaces, none of which are individually identifiable. That is the standard.

What you can do today

Even without an engagement, three things meaningfully reduce the public registry attack surface:

1. Audit every image tag your namespace has produced in the last two years. Not just latest. Every tag. Decide which can be deleted, which need to be rebuilt without the credential, and which need a key rotation.
2. Move every CI build to a multi-stage Dockerfile where the final stage copies a narrow set of paths, never ., never a wildcard.
3. Treat --build-arg as a recorded value, not as a runtime parameter. If it must contain a secret, the secret must be rotated immediately after the build and the image manifest reviewed.

If after that you want a second pair of eyes — specifically, a founder-led audit with a 60-minute restitution call and a retest within 14 days — that is what Labs delivers in the Board-Ready tier.

If the pattern in this report surprised you, the audit will surface more.