Every worker a company employs, be it a person or a program, builds on a foundation someone else assembled, and that includes the newest hire on your team. This new hire got to work the moment they arrived, building with what your company already has in place and they’re shipping code at a pace your reviews can’t keep up with. Also, everything they make is going out under your name. If it were a human, they’d spend the first week asking where things live and who maintains what. This one never asks. It treats everything it finds as trustworthy, so everything it builds carries that unexamined trust forward. And because this new hire is an agent that’s working all night at machine-class throughput, the foundational problems that used to surface slowly now surface all at once.

The foundation that nobody audited

The line between a supply chain attack and an AI attack no longer exists. Take a look at what the average foundation holds, because most of it comes from outside the company. For a long time now, public base images have carried hundreds of packages that your application never uses. Every one of those packages adds to the attack surface. Almost none of them ever get reviewed because no team has time to read code it didn’t choose and doesn’t use. In most stacks, something like a ten-year-old Java service is keeping the business running on software whose maintainers stopped patching years ago. Platform teams have been coping in their own ways, usually with a golden-image program somebody built years ago and a scanner pointed at it all. Because the images underneath are so bloated, that scanner cries wolf about four hundred times a week. All of this together is why audit season now eats up most of a quarter.

Attackers know all of this, and they’ve been working on the foundation layer all year. They’ve poisoned packages and developer tools, and they’ve had real success harvesting coding-assistant credentials at scale. Most foundations were built for a world that no longer exists.

What a good foundation takes

The good news is that none of this is unsolvable. A foundation can be strengthened to carry what’s now being built on top of it. It has to meet a few requirements, and each one depends on who does the security work, because when the vendor doesn’t, your team picks up the slack. A foundation holds when every part of it is built from source by someone who signs the work and stands behind it. Nothing should ship that your application doesn’t need, because anything extra adds surface area to defend later. Patching needs the same treatment because new vulnerabilities keep landing no matter how clean an image starts. A fix should come with contractual backing and a date. You should know exactly what’s inside every image the day it ships. And none of this should force you to move your stack onto a different distribution just to get safer images. A migration like that becomes a quarter-long project in its own right, and the foundation can’t protect anything until the move is complete.

This is exactly what Docker Hardened Images were built for. They stay compatible with the Alpine and Debian images teams already run, so adoption amounts to a one-line change to the FROM line in your Dockerfile, with no migration project attached. The images are also minimal by design, carrying only what your application needs, which reduces the attack surface by up to 95% and leaves near-zero critical and high CVEs from day one. The difference is immediately visible in scanning. Scans complete much faster with low noise, and the few findings that do remain are worth directing the team’s attention to. When a CVE does get disclosed, the remediated image is available within seven days of the upstream fix, and what once consumed a sprint of engineering time closes as a pull request. The same evidence carries through to audits, which most organizations will eventually face. Every hardened image ships with a signed SBOM (Software Bill of Materials) and build provenance, a verifiable record of the image’s contents and build process. You present auditors with proof that already exists, and no one needs to spend weeks reconstructing it.

Furthermore, a hardened base image by itself may not be enough, because minimal images almost always need customization before they fit production workflows. Teams add their own CA certificates and init scripts, install additional system packages through apt and apk, or adopt separate products entirely to cover what the base image cannot, fragmenting their foundation across vendors. That’s usually where a hardened foundation breaks down, because customizing an image invalidates the provenance and the SBOM, and with them the assurances you paid for. Not with Docker.

Hardened system packages give everything you add the same built-from-source treatment, ensure your customizations run through the same hardened pipeline, and keep the guarantees intact, with the SLA still behind them. With Docker, the entire foundation stays within a single ecosystem.

One thing stays inevitable no matter how well you do all of this. The software you depend on will eventually go unsupported upstream, and without coverage, the security patches stop, and the compliance answers get harder every quarter. Extended Lifecycle Support closes that gap with commercially backed patches for up to five years past end of life, so the move to whatever comes next happens on your timeline and your terms, instead of upstream’s. That is what a solid foundation looks like, and it has never mattered more, because your newest employee, the agent, is stress-testing what everyone before it built.

The new layer

Agents build on this foundation the same way every human before them has, and the trust it carries passes into what they build. But there’s a new reality now. Agents have created a new layer on top, and it matters almost as much as the foundation itself. They pull packages from the foundation and wire tools together, running what they build as soon as it exists. They’re also non-deterministic and ephemeral. The same task can go differently every run, and the agent session that did the work no longer exists by the time anyone comes back with questions.

Every control in the standard stack was built for a human worker, one with a permanent identity and a predictable pace, whose work can be reviewed before it ships. Agents have none of those traits. The market’s first response was to ask for human permission before every agent action, and when the prompts got too cumbersome, teams moved to isolating agents. That created its own gap because the endpoint tools meant to watch the work sit on the host, and the more you isolate the agent, the less those tools see. There has never been a control surface built for a workflow like this, and retrofitting the old parts leaves teams stuck between prompt fatigue and blind spots.

So Docker built the missing layer, one that adds to your defense in depth without replacing anything you already run. At Docker, every agent session runs in its own disposable, MicroVM-based Docker Sandbox. The sandbox walls the agent off from the host at the operating-system level. Credentials get proxied in for the task at hand and never stored inside, and you decide what gets piped in and out of the box. Our own security team has blocked coding agents on the host outright and runs them in sandboxes with full autonomy, several at a time. An infostealer that lands in one of those boxes finds nothing to grab. Call it YOLO mode with guardrails.

The tools agents reach for are the next layer, built on the same foundation. Agents interact with the outside world through MCP (Model Context Protocol) servers, connectors that let them call external tools and access data. An agent grabbing connectors off the open internet is the package problem all over again. So Docker ships hardened MCP servers through the same catalog as the hardened images, built and signed the same way. The MCP Catalog and Toolkit give your teams one trusted place to find and run them. Every tool call routes through the MCP Gateway, where it is authenticated, authorized, and logged before reaching the external system. That turns enforcement from advisory to strict. 

Docker Scout enforces the policy at build time, so the secure path remains the default without anyone having to police it by hand. And where the box sits stops mattering, whether it’s a laptop or the cloud, because the boundary travels with the work, as Docker containers always have.

The winning playbook already exists

Docker wrote this playbook the first time. In the 2010s, software pulled in parts its builders didn’t control, and shipping outpaced review. Slowing down was never on the table, so Docker packaged the application and its dependencies into one portable, isolated unit, and speed and safety started pulling in the same direction. That bet is a large part of how the modern software supply chain took shape, and now we’re making it again for agents. One foundation and one boundary serve people and agents on the same supply chain, under the same policy. Security gets quieter, and development gets faster. There’s no separate AI security program to buy. Docker has been making the case that security is a developer experience problem from the start.

See it live in San Jose

We’re bringing all of it to WeAreDevelopers World Congress in San Jose, September 23 to 25. Docker’s CISO Mark Lechner will take the stage with One boundary for the agentic era, the boundary his own team lives inside, and the Docker Zone will run live demos all three days.

The newest hire starts Monday either way. What will you have ready for them to build on?

The hardened-images space gets better when more people are working on the problem, and Minimus has been a valuable part of that work. That changed this week, when they announced they are ending operations. Though we were competitors, we both believed strongly in the importance of reducing vulnerabilities at the foundation of the software supply chain. Their efforts to bring needed awareness to this challenge will be missed, and our thoughts go out to Minimus employees who are impacted by this decision.

While the human side of this story deserves the most attention, there’s also a practical side: if you’re a customer running Minimus images in production, you’re now facing a migration you didn’t plan for. Their notice commits to a 60-day maintenance window, with images receiving upstream updates until the registry goes offline on October 22, 2026. Images already pulled will keep running after that date, but no further updates will ship to them, and any new CVE stays unpatched from that point on.

If you need a hand, Docker is offering free migration assistance to Minimus customers. Write to minimus@docker.com to walk through your specific image list, your compliance requirements, or questions around your migration plans, and a technical migration expert will get back to you. You don’t need a sales call to start migrating to DHI today.

Docker’s free, open source catalog is available to everyone under Apache 2.0, allows production use, and has no user caps. The migration is about as easy as these things get, a drop-in with minimal workflow changes. It’s more of a swap than a rebuild. It’s easy to find your images’ equivalents in the DHI catalog, and for most of your services, the whole change is updating the FROM line. Use the migration guide for the step-by-step process and the checklist to track each image through the swap and verification. The worked examples show full migrations end to end, and Gordon, Docker’s AI assistant, runs the first pass with you.

Whether you decide to migrate to Docker or somewhere else, we recommend you start that process now, while the maintenance window keeps your current images patched. You can browse the full DHI catalog on Docker Hub, make the first swap, and, of course, reach out to us if you need help.

Docker Hardened Images

Docker Hardened Images are minimal, hardened images built from source and continuously maintained by Docker. The catalog covers 4,000+ images, compatible with Alpine and Debian, so your Dockerfiles and CI keep working as they are. Every image ships near-zero CVEs with full, unsuppressed CVE visibility, and each carries a complete SBOM, SLSA Build Level 3 provenance, and cryptographic signatures. Docker manages the full lifecycle of your image, and teams moving from standard public images see up to 95% CVE reduction and up to 90% attack-surface reduction. Paid tiers add SLA-backed remediation, FIPS and STIG variants, customizations, and up to five years of coverage for versions past end of life.

MinIO reached end of life in February 2026. Docker Extended Lifecycle Support (ELS) keeps end-of-life software like it patched, compliant, and audit-ready for up to five years, covering versions upstream no longer supports all the way up to entire projects.

On February 13, 2026, the MinIO open-source project was archived upstream. A project with more than a billion Docker pulls stopped shipping releases, bug fixes, and security patches overnight. From that day forward, every environment running MinIO is exposed. New CVEs in MinIO and its Go dependency tree now arrive with no upstream patch behind them, and an audit reads that as unsupported software in production.

And MinIO is only the newest instance of a wider problem. Black Duck’s 2026 Open Source Security and Risk Analysis report found that 93% of commercial codebases carry components with no development activity in at least two years. The same pattern runs across the stack. Node 18, Python 3.8, and older Airflow releases still run in production long after upstream support ended, and frameworks like FedRAMP, DORA, and the Cyber Resilience Act treat unpatched end-of-life software as an audit finding. The migration deadline ends up set by the audit calendar instead of the roadmap.

Docker Hardened Images Extended Lifecycle Support exists to hand that schedule back to you. The model is simple. Request an ELS image, and Docker builds and maintains it for up to five years past upstream end of life. The maintained MinIO image is the newest proof of that model.

MinIO lives on as the newest ELS update

The archive lands on the storage layer, where migrations are measured in petabytes. Moving a production object store to a different system is slow, expensive work, and the CVE exposure keeps growing while that work runs.

Teams running MinIO have three options

1. Move to a commercial replacement and take on new licensing and lock-in.
2. Carry the patches yourself, which means staffing sustained Go security engineering for a project that no longer ships fixes.
3. Keep what you run and put a vendor on the hook for it. 

Doing nothing is not a fourth option. 

Docker identified the archive as a live exposure across its customers’ software supply chains and built the answer into the catalog, where MinIO lives on as a maintained, hardened image. Docker tracks new CVEs across MinIO and its full Go dependency graph, transitive dependencies included at no extra cost, then backports the fixes, rebuilds, and ships. Your object store stays supported and your audits stay clean.

Extended Lifecycle Support for your whole fleet

What ELS does for MinIO, it does for any end-of-life component you need to keep. An EOL finding forces a choice between two bad projects. Rush the migration and risk breaking production, or file the exception and watch the list grow every quarter. ELS removes that deadline. Patches and audit evidence keep flowing on the images already in production while the migration happens on the roadmap’s schedule.

The entitlement is built for how end of life actually arrives, on staggered dates across a fleet. Applied to a repository, it covers every available ELS version there. When one migration completes, you re-point it at the next repository, and the coverage moves with the risk.

Coverage is not limited to a fixed list either. Docker watches the end-of-life calendar and builds ahead of it, and anything you don’t see in the catalog, you can request. The span runs from end-of-life versions of supported software all the way up to entire archived projects. Nginx, Node, and Python ELS images are already there.

ELS is a paid add-on to a Docker Hardened Images subscription, and it runs on the same rails as the rest of DHI:

• Name it, get it. Tell Docker the end-of-life line your production depends on. Docker builds it hardened and maintains it at the line’s newest patch version.
• Adopt without a migration. ELS-tagged images appear in the standard DHI catalog alongside LTS tags. Same registry, same workflow, a FROM-line change.
• Stay patched for years. Critical and high-severity CVEs are patched on a 14-day SLA, for up to five years past end of life.
• Evidence included. Every ELS image holds the same standard as the rest of the catalog. Built from source and signed, with SBOMs, VEX statements, and SLSA Build Level 3 provenance maintained for the life of the image.

Those attestations are the difference between extended support and an extended liability. A legacy app with a giant SBOM and no exploitability data just lights up your scanners. ELS ships the evidence with the image, so auditors see signed proof of what’s patched and what’s not exploitable.

If there’s a version in your fleet you can’t migrate off and can’t leave unpatched, that’s an ELS conversation. Browse the DHI catalog to see what’s already covered, and talk to us about the versions you need to keep alive. 

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.

A trusted foundation for the whole supply chain

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.

Built from source, down to every package

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.

Patch past end of life

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.

Customize at scale, manage as code

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 is yours to carry. DHI customization works the other way around. You define what your images need, and Docker manages the full lifecycle of your customized images, rebuilding them through the same hardened pipeline on every upstream patch. The SBOM, the attestations, and the SLA travel with the customization instead of dying at it.

Customization operates at scale, too. Bulk customizations run through the UI, CLI, and API, with YAML configuration and GitHub Actions support, so you can tailor hundreds of repositories in one pass and let the rebuilds take care of themselves. And if your platform runs on Terraform, customization is code as well. The DHI Terraform provider mirrors and customizes hardened images with the same pull requests and reviews as the rest of your infrastructure.

The savings are real infrastructure, not a rounding error. Customers tell us they’ve shut off the CI pipelines that existed only to rebuild images, because Docker rebuilds for them. The blind redeploy cadence goes with those pipelines. You ship an update when a fix actually needs to go out, knowing exactly what changed, instead of rebuilding everything on a schedule and hoping QA catches what moved.

For organizations whose data-residency requirements keep images inside the EU, EU-hosted customizations arrive in September. Your customized images will live in Docker Hub’s EU region with the same SBOMs, attestations, and SLA as everywhere else. Residency stops being the reason your hardening program waits.

Harden beyond base images

The same standard keeps moving up the stack. The catalog now carries fully supported Helm charts, so your Kubernetes deployments start hardened too. And it carries a growing set of hardened MCP servers, because the tools your agents call deserve the same scrutiny as the images they run on.

Govern it all with Docker Scout policy

Scanning tells you what’s wrong. Policy is how you keep it from shipping. And enforcement is where most supply-chain programs quietly fail, because hardened artifacts only protect you when your teams actually use them. Developers move fast and default to what works, and the developer machine is exactly where the current wave of attacks aims.

Docker Scout policy closes that gap. It evaluates flexible, customizable policies from the CLI and inside CI, and it ships with the same policies Docker uses to verify every hardened image in the catalog. The policies are written in Rego, the industry standard, and they’re portable, so the same rules that gate a build in your CI travel with your teams to every developer machine in your organization. Gating at the registry matters, but it stops at the registry; developers can route around it all day. Policy that travels to the machine is how you hold every image you run, and every image your teams build, to the bar Docker holds itself to.

It’s an additive control. It works alongside the scanners you already run, and it’s already in the Docker subscription you have.

The foundation is already in your stack

The supply-chain problem is not going to shrink. More code is coming, agents are becoming contributors, and the patch windows regulators expect keep getting shorter. Point tools won’t carry that weight. A foundation that’s secure by default will, backed by an ecosystem that keeps it that way. That is exactly what Docker’s security portfolio delivers. Hardened content on the distributions you already run, customization that keeps its guarantees, support that outlasts upstream, and policy you control, from one vendor accountable for all of it.

And none of it asks you to adopt something new. It’s all in the Docker you already run. Your builds, tools, and pipelines stay the same. Your CVE count doesn’t.

Browse the DHI catalog and pull your first hardened image today. And if you want the full story, how all of this works together, with your questions answered live, join our live webinar in early September. We’d love to see you there.