Docker

Why We Chose the Harder Path: Docker Hardened Images, One Year Later

5.5内容质量
Why We Chose the Harder Path: Docker Hardened Images, One Year Later

TL;DR · AI 摘要

文章标题提及Docker加固镜像一周年回顾，但正文内容缺失，仅展示导航菜单和产品推广信息。

核心要点

  • 原文实际内容未加载，仅有网站导航和广告模块
  • 无法验证关于Docker Hardened Images的技术细节或成效
  • 页面主要功能为产品推广而非技术分享
#Docker#容器安全#DevOps#软件供应链
打开原文

Why We Chose the Harder Path: Docker Hardened Images, One Year Later | Docker

Skip to content

Image 7
Image 7

Insights on the state of AI agents from 800+ builders and leaders. Download your copy

✕

[](http://www.docker.com/)

  • AI

AI

More resources for developers

![Image 8: Featured image Docker Brings Compose to the Agent Era: Building AI Agents is Now Easy Docker Accelerates Agent Development Read more](http://www.docker.com/blog/build-ai-agents-with-docker-compose/)

Products

![Image 9 Secure Agent Execution with NanoClaw and Docker Sandboxes NanoClaw integrates with Docker Sandboxes to run AI Read more](http://www.docker.com/blog/nanoclaw-docker-sandboxes-agent-security/)

  • Developers

Developers

More resources for developers

![Image 10 Introducing Docker Model Runner A faster, simpler way to run and test AI models locally Read more](http://www.docker.com/blog/introducing-docker-model-runner/)![Image 11 Deliver Quickly. Build Securely. Stay Competitive. Meet growing demands for speed and security with integrated, efficient solutions Read more](http://www.docker.com/resources/reducing-every-day-complexities-for-more-efficient-software-development-white-paper/)

Get the latest Docker news

Company

![Image 12 Docker Announces SOC 2 Type 2 Attestation & ISO 27001 Certification Learn what this means for Docker security and compliance Read more](http://www.docker.com/blog/docker-announces-soc-2-type-2-attestation-iso-27001-certification/)

Search

Sign InGet Started

Toggle menu

Why We Chose the Harder Path: Docker Hardened Images, One Year Later

Posted Apr 14, 2026

Image 13: Posts by Christian Dupuis
Image 13: Posts by Christian Dupuis

Christian Dupuis

We’re coming up on a year since launching Docker Hardened Images (DHI) last May, and crossing a milestone earlier this month made me stop and reflect on what we’ve actually been building.

Earlier this month, we crossed over 500k daily pulls of DHIs, and over 25k continuously patched OS level artifacts in our SLSA Build 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’re now running over a million builds regularly, and just getting started. Catalog coverage will jump again soon, as more Debian packages, ELS images, and newer artifact types are added.

But the numbers aren’t the interesting part. What matters is how we got here.

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’t mean migrating to a vendor’s 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’s what independent verifiability actually requires.

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.

We made hardened images widely accessible so every team could raise their security baseline

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.

Building and sustaining a hardened image pipeline at this scale isn’t trivial. We know because we’ve been doing this for over a decade with Docker Official Images, freely for the community.

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.

We built multi-distro so adoption is drop-in, and does not impose a migration tax on you

Some vendors in this space created an entirely new Linux distribution and called it “distroless,” 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 “unstable” or “edge,” not stable.

Docker doesn’t 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.

With the Docker “multi-distro” 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’t 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’t have to.

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.

Migrating to an unfamiliar, vendor-owned OS isn’t a security upgrade, it’s 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.

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’t adopted. With Docker, your teams stay on the distros they already run, which means the adoption cost is measured in hours, not quarters.

One of our customers at Attentive (Stephen Commisso, Principal Engineer) captured their experience in the phrase “200 services – zero drama”, when describing their DHI rollout:

_“The 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.”_

We build every system package from source, for the distros you already use

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.

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.

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.

We didn’t stop at near-zero CVEs, we made every image independently verifiable

Docker’s approach to container security is built on five pillars: 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.

Most vendors in this space optimize for one metric: a clean CVE scan result.

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.

We add 17 signed attestations to every single one of our 2000+ images in the DHI catalog, because that is what it takes to give you independent verifiability:

QuestionDHI included attestation(s)What this attestation isWhy it matters to you What’s in this image?CycloneDX SBOM, SPDX SBOM Machine-readable inventory of every package, version, and transitive dependency.First thing auditors request during compliance reviews. Both formats are included so you don’t have to convert for different toolchains. How was it built, and can I prove it?SLSA provenance v1, SLSA verification summary, Scout provenance, DHI Image Sources Cryptographic proof linking every image to its exact source definition.Required by supply chain security policies. Used by incident responders during forensics to verify whether an image was legitimately built or injected. What vulnerabilities exist, and what’s been assessed?CVEs v0.1, CVEs v0.2, VEX, Scout health score CVE scan results and per-CVE exploitability justifications attached to the image itself.When your GRC team prepares a FedRAMP POA&M or your security team triages a new advisory, the evidence is already on the artifact. Is it compliant?FIPS compliance, STIG scan FIPS evidence and OpenSCAP-generated STIG results Ready artifacts for FedRAMP, PCI DSS, and HIPAA audits. Typically the most expensive artifacts to produce manually. Docker generates them automatically. Has it been checked for non-CVE risks?Secrets scan, Virus scan, Tests Confirms no leaked credentials, no known malware, and that the image functions as expected.These are the checks SOC teams and security review boards require before approving production deployment. Docker runs them on every build. What changed?Changelog Signed record of what was added, removed, or patched between versions.Change advisory boards need this to approve updates. Without it, your team is diffing images manually.

Attestations answer questions about the image, the next set of questions are about the vendor.

What to ask your vendor, and what we found when we asked ourselves the same questions

In a fast-moving ecosystem, CVEs will occasionally get missed, advisories will have gaps, and no vendor operating at scale will have a flawless record. What matters is whether the gaps reveal isolated incidents or a pattern. The following questions are worth asking every vendor, including Docker.

What is the extent of your vendor’s commitment to patching?

Ask your vendor how far they go to resolve vulnerabilities. Docker continuously patches CVEs across both Debian, Alpine, and several major OSS software projects, rebuilding tens of thousands of system packages and several thousand images from source. That is a significant engineering and operational investment that most vendors avoid, because it is easier to build images for a single proprietary OS.

Docker’s commitment doesn’t end at images in our catalog. When a fix doesn’t exist upstream, there are many examples of Docker’s security team creating one. For CVE-2025-12735, a 9.8 CRITICAL RCE in Kibana’s dependency chain, the affected library was unmaintained and had no patch. Docker created the fix, shipped it to customers, and contributed it to LangChain.js. The fix was released as a public npm package on November 17, 2025.

One vendor we looked at has a published CVE policy of 7-day remediation for critical CVEs, once a qualifying patch is publicly available. In this instance, their fix appeared several weeks after that qualifying patch was created by Docker and shipped by the upstream project.

This level of upstream commitment is built into how our security team operates. Docker has been a MITRE CVE Numbering Authority since 2022, part of a sustained investment in our ability to identify, disclose, and fix vulnerabilities at the source.

What assurances do you have about the completeness of your SBOMs?

Ask whether your vendor’s SBOM includes compiled dependencies (Rust crates, Go modules, JavaScript packages), or just system-level packages. Ask whether you can independently verify SBOM completeness against the project’s actual dependency manifest. Docker’s SBOMs include every compiled dependency. We’ve examined images from other vendors, and as one example for Vector (observability pipeline compiled from hundreds of Rust crate dependencies) one vendor’s SBOM did not appear to include those dependencies.

If a dependency isn’t in the SBOM, vulnerabilities in that dependency are invisible to the customer’s scanner and unverifiable by the customer’s security team. When Docker’s security team identified a High-severity CVE in Vector’s Rust dependencies, it was patched and shipped the same evening.

Does your vendor’s advisory feed surface every known CVE for the packages it ships?

Ask whether you can scan the vendor’s images with a third-party scanner against public advisory data, without relying on the vendor’s own advisory feed, and still get consistent results.

Docker recommends validating with Grype, Trivy, Wiz, or Mend. When we examined a vendor’s node image: CVE-2025-9308 and CVE-2025-8262 (both affecting yarn 1.22.22) were present in the shipped image but neither appeared on the vendor’s vulnerability page or in their security advisory feed. Docker’s hardened system package for yarn 1.22.22 is built from source with patches applied for both CVEs.

If your vendor’s advisory feed has gaps, your scanner inherits those gaps, and your security team is making decisions based on incomplete data.

When a CVE is assessed as unexploitable, does your vendor provide an auditable justification?

Not every CVE warrants a patch, and every vendor makes that judgment call. The question is whether your team can see the reasoning. Docker’s security team evaluates exploitability in the context of each minimal container image and publishes every assessment transparently.

Some vendors may set advisory version ranges to values real packages never match, thereby making CVEs invisible to scanners, and not providing a justification or an audit trail.

Docker uses VEX, the CISA-backed standard for communicating exploitability, which provides a per-CVE, machine-readable justification that every customer can read and audit.

We took on the parts of supply chain security others leave behind

Beyond multi-distro support, from-source patching, and transparency, we made a set of choices that compound into a distinctive, secure, simple experience for you.

Most vendor guarantees stop at the edge of the base image. Docker takes full ownership of your customized images: you add what your environment needs, and when a CVE is patched upstream, Docker automatically rebuilds your customized image and our SLA propagates to every artifact we produce. Your customizations don’t void the security guarantee. We’ve also opened up our hardened systems packages repo so you can use those hardened packages in your own bespoke containers.

We will be extending this same rigor to language libraries next. The dependencies your application pulls in through npm, pip, or Maven will carry the same provenance and patching guarantees as the OS layer beneath them.

And for organizations running software that upstream has stopped supporting, Extended Lifecycle Support continues delivering security patches for up to five years past end-of-life, so teams can maintain their security posture while upgrading on their own timeline.

Come join the movement

A year ago, 500k daily pulls of the DHI catalog and a million builds running regularly felt like a milestone. Today, this is the baseline.

None of this would have happened without the teams who trusted us early and pushed us hard, including Adobe, Crypto.com, Attentive, and many others. Projects like n8n.io helped us understand what it takes to operate at scale. Partners like Socket.dev, Snyk, and Mend.io are building security workflows on top of this foundation.

We are continuing to listen, iterate, and do the hard things that are better for you, because that matters. If you are thinking about supply chain security, especially given the quantity and intensity of supply chain risks AI agents bring to the mix, now is the time to raise your baseline with Docker.

Explore the Docker Hardened Images catalog and secure your supply chain here: https://www.docker.com/products/hardened-images/

For every team and developer, the open source DHI Community tier provides an immediately upgraded security posture. For businesses, we have a wide range of options that will work for your specific needs.

More resources:

About the Authors

Image 14: Posts by Christian Dupuis
Image 14: Posts by Christian Dupuis

Christian Dupuis

Senior Principal Software Engineer, Docker

Christian Dupuis is a software engineering leader with 25 years of experience in cloud-native development, microservices, and secure developer tooling.

Products

Table of contents

[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Fwhy-we-chose-the-harder-path-docker-hardened-images-one-year-later%2F "Visit this Linkedin profile")[](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Fwhy-we-chose-the-harder-path-docker-hardened-images-one-year-later%2F "Visit this X profile")[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.docker.com%2Fblog%2Fwhy-we-chose-the-harder-path-docker-hardened-images-one-year-later%2F "Visit this Facebook profile")

Related Posts

Products

Features

Developers

Pricing

Company

Languages

  • [](http://twitter.com/docker)
  • [](https://www.linkedin.com/company/docker)
  • [](https://www.instagram.com/dockerinc/)
  • [](http://www.youtube.com/user/dockerrun)
  • [](https://www.facebook.com/docker.run)
  • [](http://www.docker.com/blog/feed)

© 2026 Docker Inc. All rights reserved

Terms of ServicePrivacyLegal

Cookies Settings

By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts.

Cookies Settings Reject All Accept All Cookies

Image 22: Company Logo
Image 22: Company Logo

Privacy Preference Center

When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.

More information

Allow All

Manage Consent Preferences

#### Functional Cookies

  • [x] Functional Cookies

These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.

#### Strictly Necessary Cookies

Always Active

These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.

#### Performance Cookies

  • [x] Performance Cookies

These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.

#### Targeting Cookies

  • [x] Targeting Cookies

These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

Cookie List

Clear

  • [x] checkbox label label

Apply Cancel

Consent Leg.Interest

  • [x] checkbox label label
  • [x] checkbox label label
  • [x] checkbox label label

Reject All Confirm My Choices

Image 23: Powered by Onetrust
Image 23: Powered by Onetrust

Image 24Image 25