We\u2019re coming up on a year since launching Docker Hardened Images (DHI) this May, and crossing a milestone earlier this month made me stop and reflect on what we\u2019ve actually been building.<\/p>\n
Earlier this month, we crossed over 500k daily pulls of DHIs, and over 25k continuously patched OS level artifacts in our SLSA Level 3 pipeline. From the time we launched the free DHI Community tier at the end of last year, the catalog has now grown to 2,000+ hardened images, MCP servers, Helm charts, and ELS images. We continuously patch every artifact (across CVEs, distros, versions), so we\u2019re now running over a million builds running regularly, and just getting started. Catalog coverage will jump again soon, as more Debian packages, ELS images, and newer artifact types are added.<\/p>\n
But the numbers aren\u2019t the interesting part. What matters is how we got here.<\/p>\n
We chose the harder path, on purpose. Every product and engineering decision we made was consistently harder to build and operate, but better for developers and for the security of the ecosystem. We made hardened images free and open source. We built a multi-distro product, so adoption doesn\u2019t mean migrating to a vendor\u2019s proprietary OS. We build every system package from source for distros you already run. We ship a huge range of signed attestations with every image because that\u2019s what independent verifiability actually requires.<\/p>\n
Along the way, we also looked closely at how the rest of the industry approaches the same problems, and found patterns in patching timelines, SBOM completeness, and advisory coverage that are worth understanding before you evaluate any hardened image provider.<\/p>\n
We wanted to make a real dent in the security posture of the internet, and that meant making hardened images widely accessible. That is why we did not put our catalog behind a gated paywall, as was the industry norm, but freely available to every developer.<\/p>\n
Building and sustaining a hardened image pipeline at this scale isn\u2019t trivial. We know because we\u2019ve been doing this for over a decade with Docker Official Images, freely for the community. <\/p>\n
With the release of DHI Community under a permissive Apache 2.0 license, we raised the baseline for security across the ecosystem. Security should not be a premium feature. That kind of impact, at scale, is only possible because the foundation is open.<\/p>\n
Some vendors in this space created an entirely new Linux distribution and called it \u201cdistroless,\u201d which is a remarkable piece of branding for what is, in practice, a proprietary OS that your teams have never run, tested, or audited. Established Linux distributions like Debian and Alpine have a name for a package repository that only tracks the latest upstream version: they call it \u201cunstable\u201d or \u201cedge,\u201d not stable.<\/p>\n
Docker doesn\u2019t ship its own distribution, we harden the ones you already trust. That decision optimizes for your engineering reality, not ours. The hardened image that never gets adopted provides zero security value, full stop.\u00a0<\/p>\n
With the Docker \u201cmulti-distro\u201d approach, we support both Debian and Alpine today, with support for more distros to come. This is actually hard to do: the Debian and Alpine ecosystems don\u2019t just differ in packaging; they diverge in libc, dependency trees, CVE streams, patch timing, and tooling. You are effectively maintaining parallel supply chains, each with its own nuances and security posture. Every hardened image in the DHI catalog is available in both Alpine and Debian, across both amd64 and arm64 architectures, which means we build, patch, and attest each combination independently, taking on that operational burden so you don\u2019t have to.<\/p>\n
We regularly speak with engineering teams who evaluate proprietary distributions from other vendors and run into the same wall: your existing internal expertise, tools, tests, and pipelines are built around Alpine or Debian.<\/p>\n
Migrating to an unfamiliar, vendor-owned OS isn\u2019t a security upgrade, it\u2019s an adoption project and a material line item of cost, alongside the sticker price of the hardened images subscription itself. The vendor lock-in aspect goes without saying.<\/p>\n
The migration effort means revalidating CI pipelines, retraining platform teams, auditing an entirely new package ecosystem, and working through compatibility gaps that surface weeks into a rollout. Several teams tell us they bought the migration story, spent months on it, and are still paying for images their engineers haven\u2019t adopted. With Docker, your teams stay on the distros they already run, which means the adoption cost is measured in hours, not quarters.<\/p>\n
One of our customers at Attentive (Stephen Commisso, Principal Engineer) captured their experience in the phrase \u201c200 services \u2013 zero drama\u201d, when describing their DHI rollout:<\/p>\n
\u201cThe rollout was completely transparent to product teams. We had zero issues across over 200 services, which was particularly impressive since we were simultaneously switching Linux distributions from Ubuntu to Debian. All the heavy lifting happened during POC.\u201d<\/em><\/p>\n With the launch of Hardened System Packages, Docker builds tens of thousands of Alpine and Debian system packages from source in a SLSA Build Level 3 pipeline with cryptographic signed, full provenance. This fundamentally changes the CVE equation.<\/p>\n Other vendors also claim to build system packages from source. The difference is that they build them for proprietary Linux distributions that have not had the benefit of independent community scrutiny and that customers have never run in production.<\/p>\n Docker builds packages for Alpine and Debian, the distributions your teams already operate, already test against, and already trust. Alpine and Debian are vast ecosystems that have independent maintainers, public mailing lists, coordinated disclosure with upstream projects, and volunteer security teams that operate independently of any commercial interest. You get the security benefit of from-source patching without the compatibility cost of adopting an unfamiliar OS.<\/p>\n Docker\u2019s approach to container security is built on five pillars<\/a>: minimal attack surface, verifiable SBOMs, secure build provenance, exploitability context, and cryptographic verification. We distilled our product development philosophy to these ideas, because we think your security posture depends on it. Not every vendor in the hardened image market shares this philosophy.<\/p>\n Most vendors in this space optimize for one metric: a clean CVE scan result.<\/p>\n Docker obsesses over near-zero CVEs too, but we went further: we built an attestation infrastructure that gives your security team, auditors, SOC, and change advisory boards machine-readable, cryptographically signed evidence for every question they will ask about an image.<\/p>\n We add 17 signed attestations<\/strong> to every single one of our 2000+ images in the DHI catalog, because that is what it takes to give you independent verifiability<\/strong>:<\/p>\nWe build every system package from source, for the distros you already use<\/h2>\n
We didn\u2019t stop at near-zero CVEs, we made every image independently verifiable<\/h2>\n