It's been nearly a year since we launched Docker Hardened Images (DHI), and a recent milestone—surpassing 500,000 daily pulls—made me pause and appreciate what we've built. With over 25,000 continuously patched OS-level artifacts in our SLSA Build Level 3 pipeline, and a catalog that has grown to 2,000+ hardened images, MCP servers, Helm charts, and ELS images, we're now running more than a million builds regularly. But numbers alone don't tell the story; it's the how that matters. Every decision we made was harder to build and operate, but better for developers and ecosystem security. Let's dive into the key questions behind our approach.

Why Did We Make Hardened Images Free and Open Source?

We wanted to make a real dent in the internet's security posture, and that meant removing barriers. Instead of putting our catalog behind a paywall like many vendors, we released DHI Community under an Apache 2.0 license. Security shouldn't be a premium feature. By making hardened images freely available, every team can raise their security baseline without worrying about licensing costs. This approach builds on our decade of experience with Docker Official Images, which we've always maintained for the community. The result: widespread adoption and a baseline shift across the ecosystem. When security is accessible, everyone benefits—and we've seen that in the rapid growth of daily pulls and artifact count.

Why Did We Choose a Multi-Distro Approach Instead of a Proprietary OS?

Some vendors create a proprietary Linux distribution and call it "distroless." That's clever branding, but in practice it's a closed OS your teams have never tested or audited. We took a different path: we support established distributions like Debian and Alpine that developers already use. This makes adoption drop-in—no migration tax, no retraining, no rewriting Dockerfiles. You keep your existing workflows and just swap in a hardened image. Multi-distro means we're not forcing you into a vendor lock-in; we're meeting you where you are. It's harder to build and maintain, but it's the right choice for real-world security and usability.

Why Do We Build Every System Package from Source?

Most hardened image providers patch only the latest versions or rely on pre-built binaries. We build every system package from source for the distributions you already run. This gives us fine-grained control over dependencies, ensures we can backport security fixes even to older versions, and allows us to produce accurate provenance. It's a massive engineering effort—our pipeline now handles over a million builds—but it guarantees that every artifact is independently verifiable and free from supply chain tampering. Building from source is the foundation of our SLSA Build Level 3 compliance and the reason our patch timelines are among the fastest in the industry.

Why Do We Ship Signed Attestations with Every Image?

Independent verifiability requires more than just a signed image. We ship a comprehensive set of signed attestations—including SBOMs, provenance statements, and vulnerability scan results—with every hardened image. These attestations allow you to cryptographically verify what's inside, how it was built, and whether it's been tampered with. This goes beyond industry norms, where SBOMs are often incomplete or advisory coverage is spotty. By providing granular, machine-readable attestations, we enable automated policy enforcement in your CI/CD pipelines. It's a harder path—both in generation and maintenance—but it's the only way to achieve true transparency and trust at scale.

What Industry Patterns Did You Observe in Patching, SBOMs, and Advisories?

After evaluating how other providers approach hardened images, we found several troubling patterns:

• Patching timelines: Many vendors only patch on a fixed schedule (e.g., monthly), leaving critical vulnerabilities exposed for days or weeks.
• SBOM completeness: SBOMs often miss transitive dependencies or omit OS-level packages, giving a false sense of security.
• Advisory coverage: Advisories frequently focus only on CVE identifiers without providing context about exploitability or affected versions in the image.

These gaps mean that even when images are "hardened," you might still be vulnerable. We designed DHI to address each of these: continuous patching, comprehensive SBOMs that cover every layer, and advisories that link to specific artifacts and versions. Understanding these patterns helps you evaluate any hardened image provider critically.

What's Next for Docker Hardened Images?

We're just getting started. In the coming months, our catalog will expand significantly with more Debian packages, Extended Lifecycle Support (ELS) images, and new artifact types like MCP servers and Helm charts. We're also scaling our build pipeline to handle even more frequent patching cycles. Our goal remains the same: make hardened images the default, not a premium add-on. By staying open, multi-distro, and verifiable, we aim to raise the security bar for the entire container ecosystem. The path is harder, but we believe—and the numbers confirm—that it's the right one.