Docker Hodgepodge Images

Yesterday, Docker published a 3,000-word blog post, "Why We Chose the Harder Path," attacking competitors for shipping their own Linux distributions. They describe these competitors as building "a proprietary OS your teams have never run, tested, or audited" — framing distro-building as a red flag and something customers should be asking hard questions about.

The only problem here is that Docker also ships their own Linux distro, they just pretend not to.

Docker Hardened Images are a Linux distribution

DHI images are Debian Trixie derivatives. Each image ships with two apt source files: the standard Debian repos and a custom DHI repository at dhi.io/deb/debian/main, signed by Docker's own keyring. The vast majority of installed packages come unmodified from Debian, but Docker adds and rebuilds a small set of packages through their private repo — application binaries packaged as .deb files, patched system libraries carrying a 1dhi1 version suffix, and their own /etc/os-release with HOME_URL and BUG_REPORT_URL pointing to Docker.

In the Linux ecosystem, there's a term for this: a derivative distribution. Ubuntu does it. Linux Mint does it. Pop!_OS does it. It is a completely legitimate thing to do. Docker could do this, but they’re just not, and then they're attacking others for doing it the right way.

"Docker doesn't ship its own distribution"

That's a direct claim from the blog post. Let's hold it against reality.

Docker's images set ID=debian in /etc/os-release. The freedesktop os-release specification reserves the ID field as a unique identifier for the operating system. When you ship modified packages from your own repository, signed by your own key, with your own bug report URLs, you are not Debian. You are a derivative. The spec is clear: the correct approach is to set ID=dhi (or similar) and declare ID_LIKE=debian to signal compatibility. This is exactly what Ubuntu, Pop!_OS, and every other well-behaved derivative does. DHI doesn't set ID_LIKE at all.

Why does this matter? Because every vulnerability scanner, configuration management tool, and compliance engine on the planet reads ID from os-release to determine what operating system it's looking at. When Docker sets ID=debian, those tools conclude they're scanning a Debian system. They aren't. They're scanning a system with a custom package repository, rebuilt libraries, and no upstream traceability for the modified packages. The tools don't know to check Docker's repo. They don't know to apply Docker's advisories. The scan results are, in a word, wrong.

This is not an academic nitpick. This is exactly the kind of scanner manipulation Docker accuses others of doing.

The violations go deeper than os-release

The Debian Derivatives Guidelines exist specifically for situations like this. They're maintained by the Debian project to ensure that derivatives identify themselves properly, don't confuse tooling, and don't send bug reports to the wrong place. Here's how DHI stacks up:

No dpkg vendor identity. /etc/dpkg/origins/default is missing entirely. As a result, dpkg-vendor reports the system as Debian. The Debian Derivatives Guidelines explicitly require a vendor file declaring a non-Debian vendor name with Parent: Debian. Every well-known Debian derivative — Ubuntu, Raspbian, Devuan — creates this file. Docker doesn't.

Maintainer fields not updated on modified packages. libtinfo6 is rebuilt by Docker (as evidenced by its 1dhi1 version suffix), but still lists the original Debian maintainer: Maintainer: Ncurses Maintainers <ncurses@packages.debian.org>. The guidelines require renaming this to XSBC-Original-Maintainer and setting a new Maintainer field pointing to Docker. When a user files a bug against this package, where does it go? To the Debian ncurses maintainers, who didn't build it and can't reproduce the issue.

Application packages lack derivative version suffixes. kyverno-cleanup-controller-dev is versioned 1.17.1-0 with no DHI-specific suffix. Guidelines recommend a derivative-specific suffix (e.g., 1.17.1-0dhi1) on all derivative-originated packages. Without it, there's no way to distinguish this package from a hypothetical upstream equivalent.

To be fair, DHI gets some things right: the derivative name "Docker Hardened Images" doesn't misuse the word "Debian," the NAME and PRETTY_NAME fields in os-release correctly identify the derivative, and packages come from a separate repo with an independent keyring. But these partial compliances make the violations more striking, not less. Docker clearly knows the guidelines exist. They followed some of them. They skipped the ones that would make their images identifiable as not-Debian to automated tooling.

Having their cake and eating it too

Now re-read Docker's blog post with this context. They describe competitors as shipping "a proprietary OS that your teams have never run, tested, or audited." They say these competitors built "an entirely new Linux distribution and called it 'distroless,' which is a remarkable piece of branding."

Docker is also shipping a Linux distribution. The difference is that competitors are transparent about it. Wolfi, for example, has its own ID in os-release, its own package manager, its own advisory feed, and its own build system. You know exactly what you're running. You can audit it. Scanners can identify it.

Docker's distribution hides behind Debian's identity. It reports ID=debian to every tool that asks. It lacks the dpkg vendor metadata that would let package-level tooling distinguish it from upstream. It ships rebuilt packages under the original maintainer's name. It is, by the freedesktop specification and Debian's own guidelines, an improperly identified derivative distribution. And then Docker publishes a 3,000-word blog post attacking competitors for having a distro.

The VEX laundering machine

The ID=debian misidentification isn't just a metadata problem. It's load-bearing infrastructure for Docker's entire vulnerability story.

Docker's blog post trumpets their use of VEX, the CISA-backed standard for communicating exploitability, as proof of their transparency. They publish per-CVE, machine-readable justifications for why certain vulnerabilities don't affect their images. Sounds great on paper. Here's what it looks like in practice.

Debian's security team maintains a set of "no-dsa" annotations. These aren't assessments that a vulnerability is unexploitable. They're triage decisions that say "we're not going to issue a Debian Security Advisory for this one" — typically because the severity is low, the fix is disruptive, or the package isn't a priority. It's Debian's way of saying "we know about it, we're not acting on it right now." That's a perfectly reasonable thing for an upstream distribution to do.

Docker's VEX pipeline converts these "no-dsa" statuses into affirmative "not_affected" statements in their VEX feed. A Debian triage decision that means "we're not going to fix this" gets laundered into a Docker attestation that means "you're not affected by this." Those are wildly different claims. One is a resource-allocation decision made by volunteer maintainers. The other is a security assurance that your compliance team will rely on.

And the whole thing is only possible because Docker's images claim to be Debian. The VEX statements reference Debian packages. The scanners see Debian. The advisory lookups hit Debian's tracker. Docker gets to free-ride on Debian's triage work, repackage "we won't fix it" as "you're safe," and then ship the result as a signed attestation that your auditors are supposed to trust. Neil Carpenter did a solid evaluation of this.

This is what Docker means when they say competitors' advisory feeds "have gaps" and that scanners "inherit those gaps." Docker's feed doesn't have gaps; it has fabrications. A gap is the absence of data. What Docker does is the presence of false data: actively telling scanners and compliance tools that a vulnerability doesn't affect you, based on nothing more than Debian's decision not to prioritize a fix.

The real question

Docker's blog post asks, "What should you ask your vendor?" Here's one they left off the list:

Does your vendor accurately identify its operating system to standard tooling, or does it masquerade as an upstream distribution to game scanner results?

The post also says that language libraries are next, with npm, pip, and Maven carrying "the same provenance and patching guarantees as the OS layer." We've been doing this for a year. It is, by a wide margin, the hardest problem in this space. And this time there’s no Debian to copy. Good luck!