Make zero CVEs your new default | Docker

Secure, minimal container images for every team, free with enterprise features, if needed.
Supply-chain attacks have stopped being isolated incidents somewhere in the past year. The compromises now reach the tools the industry trusts to defend itself, with Trivy and KICS among this year’s targets. Mark Lechner, Docker’s Chief Information Security Officer, called the latest wave ‘a permanent shift in the threat landscape’, and the months since have borne that out. The volume is growing at the same time. Over a quarter of production code is now AI-authored, and agents pull in dependencies at machine speed. If you run a platform team or a security program, this is the math you are already living with. More code and more images arrive every week, almost none of it written by your own engineers, and all of it has become your responsibility the moment it ships.
None of this is news to us. Securing the software supply chain is the problem we’re here to solve. The latest round of updates widens the trusted foundation Docker is building under your supply chain, and tightens how it’s enforced. More of the software inside your images is now built and patched by Docker itself, and security coverage continues after software reaches end of life. Images can be tailored to your environment without losing their guarantees, and policy enforcement now reaches every developer machine.
It all starts from one principle, and Docker Hardened Images was built on it. Security that doesn’t get adopted doesn’t secure anything. The entire catalog is free for every developer, because a secure baseline shouldn’t be a premium feature. Every image is compatible with Alpine and Debian, the distributions your teams already run, and Docker builds every one of them itself, from source. Adoption is a FROM-line change, not a migration project. And every image is independently verifiable, with signed SBOMs (software bills of materials) and SLSA Build Level 3 provenance, so your auditors work from evidence instead of vendor claims.
A year in, the numbers make the case. The catalog has grown past 4,000 hardened images, plus MCP servers, Helm charts, and ELS images. It draws more than 3.5 million pulls a week, with over a million builds running regularly to keep all of it patched, and open source projects like n8n run production on DHI. The catalog grows the way it always has, driven by what customers request. But the goal was never just a catalog. The goal is one trusted foundation under your whole software supply chain, where the images you run, the packages inside them, the charts that deploy them, and the tools your agents call all carry the same provenance. Security becomes the default from day one, and it holds, without asking your teams to change how they work.
The hardening keeps reaching deeper into the stack. Docker Hardened System Packages take hardening below the image, to the packages inside it, across both Alpine and Debian, with every package built from upstream source, patched, and maintained by Docker in the same SLSA Build Level 3 pipeline that builds the images themselves. And the repository behind them is open to more than the catalog. DHI Enterprise customers can point apt or apk directly at Docker’s hardened package repository and bring the same packages into images they build themselves, extending the hardened supply chain beyond the images Docker ships to every image your organization builds.
The coverage keeps widening. What began with Alpine now spans Debian, with Python, the catalog’s most pulled image, among the first to ship fully hardened. The work compounds every week, and the Debian and Alpine package lists are public, so you can watch the catalog harden in real time.
If you’ve spent time chasing base-image CVEs, you know why this matters. System packages are notorious for slow fixes; a patch can sit waiting on the distribution’s next release for months or years. Docker doesn’t wait. We patch at the package level, ahead of upstream when it counts, and the fix lands in every image that uses that package, in one build wave instead of image by image. Entire businesses have been built on delivering community-distribution security updates faster than the community. With DHI, that speed is included.
The guarantees hold up under inspection, too. Packages you add through DHI customization, tailoring an image to your workloads, come from that same hardened repository, not an unverified public mirror, so they are hardened system packages in their own right and the SLA that covers the base image extends through everything you add. And because one vendor stands behind the image, the packages inside it, the CVE investigation, and the patch, your auditors get a single chain of signed provenance instead of a stack of vendor assurances.
Your distribution, meanwhile, stays your distribution. Building a hardened package ecosystem from source is a serious engineering commitment, and Docker made it twice, for Alpine and for Debian, so keeping your house standard never costs you your security posture.
Production software has a habit of outliving its maintainers. Migrations wait on budgets, dependencies, and test cycles, and CVEs don’t wait with them. That’s the problem DHI Extended Lifecycle Support (ELS) exists for. It keeps end-of-life software patched, with SBOMs and provenance maintained, for up to five more years.
ELS isn’t limited to a set catalog, either. Docker watches the end-of-life calendar and builds coverage ahead of it, and anything you don’t see, you can request. MinIO is the newest addition. Upstream archived the project in February 2026, yet in the DHI catalog it lives on, patched and hardened, and your migration runs on your schedule instead of upstream’s.
Nobody runs stock images in production. You add CA certificates, agents, and the packages your applications demand. The trouble is that in most of this market, the first change you make is where the vendor’s guarantees end, and everything after it i