Last December, we made Docker Hardened Images (DHI) free because we believe secure, minimal, production-ready images should be the default. Every developer deserves strong security at no cost. It should not be complicated or locked behind a paywall.

From the start, flexibility mattered just as much as security. Unlike opaque, proprietary hardened alternatives, DHI is built on trusted open source foundations like Alpine and Debian. That gives teams true multi-distro flexibility without forcing change. If you run Alpine, stay on Alpine. If Debian is your standard, keep it. DHI strengthens what you already use. It does not require you to replace it.

Today, we are extending that philosophy beyond images.

With Docker Hardened System Packages, we’re driving security deeper into the stack. Every package is built on the same secure supply chain foundation: source-built and patched by Docker, cryptographically attested, and backed by an SLA.

The best part? Multi-distro support by design.

The result is consistent, end-to-end hardening across environments with the production-grade reliability teams expect.

Since introducing DHI Community (our OSS tier), interest has surged. The DHI catalog has expanded from more than 1,000 to over 2,000 hardened container images. Its openness and ability to meet teams where they are have accelerated adoption across the ecosystem. Companies of all sizes, along with a growing number of open source projects, are making DHI their standard for secure containers.

Just consider this short selection of examples:

• n8n.io has moved its production infrastructure to DHI, they share why and how in this recent webinar
• Medplum, an open-source electronic health records platform (managing data of 20+ million patients) has now standardized to DHI
• Adobe uses DHI because of great alignment with its security posture and developer tooling compatibility
• Attentive co-authored this e-book with Docker on helping others move from POC to production with DHI

Docker Hardened System Packages: Going deeper into the container

From day one, Docker has built and secured the most critical operating system packages to deliver on our CVE remediation commitments. That’s how we continuously maintain near-zero CVEs in DHI images. At the same time, we recognize that many teams extend our minimal base images with additional upstream packages to meet their specific requirements. To support that reality, we are expanding our catalog with more than 8,000 hardened Alpine packages, with Debian coverage coming soon.

This expansion gives teams greater flexibility without weakening their security posture. You can start with a DHI base image and tailor it to your needs while maintaining the same hardened supply chain guarantees. There is no need to switch distros to get continuous patching, verified builds through a SLSA Build Level 3 pipeline, and enterprise-grade assurances. Your teams can continue working with the Alpine and Debian environments they know, now backed by Docker’s secure build system from base image to system package.

Why this matters for your security posture:

Complete provenance chain. Every package is built from source by Docker, attested, and cryptographically signed. From base image to final container, your provenance stays intact.

Faster vulnerability remediation. When a vulnerability is identified, we patch it at the package level and publish it to the catalog. Not image by image. That means fixes move faster and remediation scales across your entire container fleet.

Extending the near-zero CVE guarantee. DHI images maintain near-zero. Hardened System Packages extend that guarantee more broadly across the software ecosystem, covering packages you add during customization.

Use hardened packages with your containers. DHI Enterprise customers get access to the secure packages repository, making it possible to use Hardened System Packages beyond DHI images. Integrate them into your own pipelines and across Alpine and Debian workloads throughout your environment.

The work we’re doing on our users’ behalf: Maintaining thousands of packages is continuous work. We monitor upstream projects, backport patches, test compatibility, rebuild when dependencies change, and generate attestations for every release. Alpine alone accounts for more than 8,000 packages today, soon approaching 10,000, with Debian next.

Making enterprise-grade security even more accessible

We’re also simplifying how teams access DHI. The full catalog of thousands of open-source images under Apache 2.0 now has a new name: DHI Community. There are no licensing changes, this is just a name change, so all of that free goodness has an easy name to refer to.

For teams that need SLA-backed CVE remediation and customization capabilities at a more accessible price point, we’re announcing a new pricing tier today, DHI Select. This new tier brings enterprise-grade security at a price of $5,000 per repo.

For organizations with more demanding requirements, including unlimited customizations, access to the Hardened System Packages repo, and extended lifecycle coverage for up to five years after upstream EOL, DHI Enterprise and the DHI Extended Lifecycle Support add-on remain available.

More options means more teams can adopt the right level of security for where they are today.

Build with the standard that’s redefining container security

Docker’s momentum in securing the software supply chain is accelerating. We’re bringing security to more layers of the stack, making it easier for teams to build securely by default, for open source-based containers as well as your company’s internally-developed software. We’re also pushing toward a one-day (or shorter) timeline for critical CVE fixes. Each step builds on the last, moving us closer to end-to-end supply chain security for all of your critical applications.

Get started:

• Join the n8n webinar to see how they’re running production workloads on DHI
• Start your free trial and get access to the full DHI catalog, now with Docker Hardened System Packages

DHI includes security fixes from Docker’s security team, which simplifies security response. Platform teams can pull the patched base image and redeploy quickly. But free hardened images raise a question: how should this change your security practice? Here’s how our thinking is evolving at Docker.

What Changes (and What Doesn’t)

DHI gives you a security “waterline.” Below the waterline, Docker owns vulnerability management. Above it, you do. When a scanner flags something in a DHI layer, it’s not actionable by your team. Everything above the DHI boundary remains yours.

The scope depends on which DHI images you use. A hardened Python image covers the OS and runtime, shrinking your surface to application code and direct dependencies. A hardened base image with your own runtime on top sets the boundary lower. The goal is to push your waterline as high as possible.

Vulnerabilities don’t disappear. Below the waterline, you need to pull patched DHI images promptly. Above it, you still own application code, dependencies, and anything you’ve layered on top.

Supply Chain Isolation

DHI provides supply chain isolation beyond CVE remediation.

Community images like python:3.11 carry implicit trust assumptions: no compromised maintainer credentials, no malicious layer injection via tag overwrite, no tampering since your last pull. The Shai Hulud campaign(s) demonstrated the consequences when attackers exploit stolen PATs and tag mutability to propagate through the ecosystem.

DHI images come from a controlled namespace where Docker rebuilds from source with review processes and cooldown periods. Supply chain attacks that burn through community images stop at the DHI boundary. You’re not immune to all supply chain risk, but you’ve eliminated exposure to attacks that exploit community image trust models.

This is a different value proposition than CVE reduction. It’s isolation from an entire class of increasingly sophisticated attacks.

The Container Image as the Unit of Assessment

Security scanning is fragmented. Dependency scanning, SAST, and SCA all run in different contexts, and none has full visibility into how everything fits together at deployment time.

The container image is where all of this converges. It’s the actual deployment artifact, which makes it the checkpoint where you can guarantee uniform enforcement from developer workstation to production. The same evaluation criteria you run locally after docker build can be identical to what runs in CI and what gates production deployments.

This doesn’t need to replace earlier pipeline scanning altogether. It means the image is where you enforce policy consistency and build a coherent audit trail that maps directly to what you’re deploying.

Policy-Driven Automation

Every enterprise has a vulnerability management policy. The gap is usually between policy (PDFs and wikis) and practice (spreadsheets and Jira tickets).

DHI makes that gap easier to close by dramatically reducing the volume of findings that require policy decisions in the first place. When your scanner returns 50 CVEs instead of 500, even basic severity filtering becomes a workable triage system rather than an overwhelming backlog.

A simple, achievable policy might include the following:

• High and critical severity vulnerabilities require remediation or documented exception
• Medium and lower severity issues are accepted with periodic review
• CISA KEV vulnerabilities are always in scope

Most scanning platforms support this level of filtering natively, including Grype, Trivy, Snyk, Wiz, Prisma Cloud, Aqua, and Docker Scout. You define your severity thresholds, apply them automatically, and surface only what requires human judgment.

For teams wanting tighter integration with DHI coverage data, Docker Scout evaluates policies against DHI status directly. Third-party scanners can achieve similar results through pipeline scripting or by exporting DHI coverage information for comparison.

The goal isn’t perfect automation but rather reducing noise enough that your existing policy becomes enforceable without burning out your engineers.

VEX: What You Can Do Today

Docker Hardened Images ship with VEX attestations that suppress CVEs Docker has assessed as not exploitable in context. The natural extension is for your teams to add their own VEX statements for application-layer findings.

Here’s what your security team can do today:

Consume DHI VEX data. Grype (v0.65+), Trivy, Wiz, and Docker Scout all ingest DHI VEX attestations automatically or via flags. Scanners without VEX support can still use extracted attestations to inform manual triage.

Write your own VEX statements. OpenVEX provides the JSON format. Use vexctl to generate and sign statements.

Attach VEX to images. Docker recommends docker scout attestation add for attaching VEX to images already in a registry:

docker scout attestation add \
  --file ./cve-2024-1234.vex.json \
  --predicate-type https://openvex.dev/ns/v0.2.0 \
  <image>

Alternatively, COPY VEX documents into the image filesystem at build time, though this prevents updates without rebuilding.

Configure scanner VEX ingestion. The workflow: scan, identify investigated findings, document as VEX, feed back into scanner config. Future scans automatically suppress assessed vulnerabilities.

Compliance: What DHI Actually Provides

Compliance frameworks such as ISO 27001, SOC 2, and the EU Cyber Resilience Act require systematic, auditable vulnerability management. DHI addresses specific control requirements:

Vulnerability management documentation (ISO 27001  A.8.8. , SOC 2 CC7.1). The waterline model provides a defensible answer to “how do you handle base image vulnerabilities?” Point to DHI, explain the attestation model, show policy for everything above the waterline.

Continuous monitoring evidence. DHI images rebuild and re-scan on a defined cadence. New digests mean current assessments. Combined with your scanner’s continuous monitoring, you demonstrate ongoing evaluation rather than point-in-time checks.

Remediation traceability. VEX attestations create machine-readable records of how each CVE was handled. When auditors ask about specific CVEs in specific deployments, you have answers tied to image digests and timestamps.

CRA alignment. The Cyber Resilience Act requires “due diligence” vulnerability handling and SBOMs. DHI images include SBOM attestations, and VEX aligns with CRA expectations for exploitability documentation.

This won’t satisfy every audit question, but it provides the foundation most organizations lack.

What to Do After You Read This Post

1. Identify high-volume base images. Check Docker Hub’s Hardened Images catalog (My Hub → Hardened Images → Catalog) for coverage of your most-used images (Python, Node, Go, Alpine, Debian).
2. Swap one image. Pick a non-critical service, change the FROM line to DHI equivalent, rebuild, scan, compare results.
3. Configure policy-based filtering. Set up your scanner to distinguish DHI-covered vulnerabilities from application-layer findings. Use Docker Scout or Wiz for native VEX integration, or configure Grype/Trivy ignore policies based on extracted VEX data.
4. Document your waterline. Write down what DHI covers and what remains your responsibility. This becomes your policy reference and audit documentation.
5. Start a VEX practice. Convert one informally-documented vulnerability assessment into a VEX statement and attach it to the relevant image.

DHI solves specific, expensive problems around base image vulnerabilities and supply chain trust. The opportunity is building a practice around it that scales.

The Bigger Picture

DHI coverage is expanding. Today it might cover your OS layer, tomorrow it extends through runtimes and into hardened libraries. Build your framework to be agnostic to where the boundary sits. The question is always the same, though, namely —  what has Docker attested to, and what remains yours to assess?

The methodology Docker uses for DHI (policy-driven assessment, VEX attestations, auditable decisions) extends into your application layer. We can’t own your custom code, but we can provide the framework for consistent practices above the waterline. Whether you use Scout, Wiz, Grype, Trivy, or another scanner, the pattern is the same. You can let DHI handle what it covers, automate policy for what remains, and document decisions in formats that travel with artifacts.

At Docker, we’re using DHI internally to build this vulnerability management model. The framework stays constant regardless of how much of our stack is hardened today versus a year from now. Only the boundary moves.

The hardened images are free. The VEX attestations are included. What’s left is integrating these pieces into a coherent security practice where the container is the unit of truth, policy drives automation, and every vulnerability decision is documented by default.

For organizations that require stronger guarantees, FIPS-enabled and STIG-ready images, and customizations, DHI Enterprise is tailor made for those use cases. Get in touch with the Docker team if you would like a demo. If you’re still exploring, take a look at the catalog (no-signup needed) or take DHI Enterprise for a spin with a free trial.

With that decision comes a responsibility: if Docker Hardened Images become the new starting point for modern development, then developers must be able to trust them completely. Not because we say they’re secure, but because they prove it: under scrutiny, under pressure, and through independent validation.

Security threats evolve constantly. Supply chains grow more complex. Attackers get smarter. The only way DHI stays ahead is by continuously pushing our security forward. That’s why we partnered with  SRLabs, one of the world’s leading cybersecurity research groups, known for uncovering high-impact vulnerabilities in highly sensitive systems.

This review included threat modeling, architecture analysis, and grey-box testing using publicly available artifacts. At Docker, we understand that trust is not earned through claims, it is earned through testing, validation and a commitment to do this continuously.  

Phase One: Grey Box Assessment

SRLabs started with a grey box assessment focused on how we build, sign, scan, and distribute hardened images. They validated our provenance chain, our signing practices, and our vulnerability management workflow.

One of the first things they called out was the strength of our verifiability model. Every artifact in DHI carries SLSA Build Level 3 provenance and Cosign signatures, all anchored in transparency logs via Rekor. This gives users a clear, cryptographically verifiable trail for where every hardened image came from and how it was built. As SRLabs put it:

“Docker incorporates signed provenance with Cosign, providing a verifiable audit trail aligned with SLSA level 3 standards.”

They also highlighted the speed and clarity of our vulnerability management process. Every image includes an SBOM and VEX data, and our automated rebuild system responds quickly when new CVEs appear. SRLabs noted:

“Fast patching. Docker promises a 7 day patch SLA, greatly reducing vulnerability exposure windows.”

They validated the impact of our minimization strategy as well. Non root by default, reduced footprint, and the removal of unnecessary utilities dramatically reduce what an attacker could exploit inside a container. Their assessment:

“Non root, minimal container images significantly reduce attack vectors compared to traditional images.”

After three weeks of targeted testing, including adversarial modeling and architectural probing, SRLabs came back with a clear message: no critical vulnerabilities, no high-severity exploitation paths, just a medium residual risk driven by industry-wide challenges like key stewardship and upstream trust. And the best part? The architecture is already set up to reach even higher assurance without needing a major redesign. In their words:

“Docker Hardened Images deliver on their public security promises for today’s threat landscape.”

 “No critical or high severity break outs were identified.”

And 

“By implementing recommended hardening steps, Docker can raise assurance to the level expected of a reference implementation for supply chain security without major re engineering.”

Throughout the assessment, our engineering teams worked closely with SRLabs. Several findings, such as a labeling issue and a race condition, were resolved during the engagement. Others, including a prefix-hijacking edge case, moved into remediation quickly. For SRLabs, this responsiveness showed more than secure technology; it demonstrated a security-first culture where issues are triaged fast, fixes land quickly, and collaboration is part of the process. 

SRLabs pointed to places where raising the bar would make DHI even stronger, and we are already acting on them. They told us our signing keys should live in Hardware Security Modules with quorum controls, and that we should move toward a keyless Fulcio flow, so we have started that work right away. They pointed out that offline environments need better protection against outdated or revoked signatures, and we are updating our guidance and exploring freshness checks to close that gap.They also flagged that privileged builds weaken reproducibility and SBOM accuracy. Several of those builds have already been removed or rebuilt, and the rest are being redesigned to meet our hardening standards.

 You can read more about the findings from the report here.

Phase Two: Full White Box Assessment

Grey box testing is just the beginning. 

This next phase goes much deeper. SRLabs will step into the role of an insider-level attacker. They’ll dig through code paths, dependency chains, and configuration logic. They’ll map every trust boundary, hunt for logic flaws, and stress-test every assumption baked into the hardened image pipeline. We expect to share that report in the coming months.

SRLabs showed us how DHI performs under pressure, but validation in the lab is only half the story.

The real question is: what happens when teams put Docker at the center of their daily work? The good news is,  we have the data. When organizations adopt Docker, the impact reaches far beyond reducing vulnerabilities.

New research from theCUBE, based on a survey of 393 IT, platform, and engineering leaders, reveals that 95 percent improved vulnerability detection and remediation, 93 percent strengthened policy and compliance, and 81 percent now meet most or all of their security goals across the entire SDLC. You can read about it in the report linked above.

By combining Independent validation, Continuous security testing and Transparent attestations and provenance, Docker is raising the baseline for what secure software supply chains should look like.

The full white-box report from SRLabs will be shared when complete, and every new finding, good or bad, will shape how we continue improving DHI. Being secure-by-default is something we aim to prove, continuously.

The first question produces a phone book of curated, controlled, static resources. The second points toward an AI playground where agents and developers interact and learn from each other. What if private catalogs of MCP servers become composable playlists that encourage mixing, reshaping, and myriad combinations of tool calls? This requires treating MCP catalogs as OCI artifacts, not databases.

Cloud-native computing created feedback loops where infrastructure became code, deployments became declarative, and operational knowledge became shareable artifacts. MCP catalogs need to follow the same path. OCI artifacts, immutable versioning, and container-native workflows provide the model because they represent a well-understood approach that balances trust with creative evolution.

Trust Boundaries That Expand and Learn

iTunes provided a store. Spotify provided a store plus algorithmic discovery, playlist sharing, and taste profiles that improved over time. Private MCP catalogs can enable the same evolution. Today, this means curated, verified collections. Tomorrow, this becomes the foundation for self-improving discovery systems.

Tens of thousands of MCP servers are scattered across GitHub, registries, and forums. Community registries like mcp.so, Smithery, Glama, and PulseMCP are attempting to organize this ecosystem, but provenance remains unclear and quality varies wildly. Private catalogs with tighter access controls offer centralized discovery, enhanced security through vetted servers, and visibility into which tools developers actually use. Organizations can build curated subsets of approved servers, add proprietary internal servers, and selectively import from community registries. This solves the phone book problem. 

When Output Becomes Input

The real opportunity is when the work agents do creates shareable artifacts plus organizational learning automatically. Your agent faces a complex problem analyzing customer churn across three data sources. The MCP gateway then constructs a profile capturing the tools, API keys, sequence of operations, and documentation about what worked. That profile becomes an OCI artifact in your registry.

Next month, another team faces a similar problem. Their agent pulls your profile as a starting point, adapts it, and pushes a refined version. The customer success team creates a churn profile combining data warehouse connectors, visualization tools, and notification servers. The sales team imports that profile, adds CRM connectors, and uses it to strategize on renewals. They publish their enhanced version back to the catalog. Teams stop rebuilding identical solutions and instead reuse or remix. Knowledge is captured, shared, and refined.

Why OCI Makes This Possible

Treating catalogs as immutable OCI artifacts lets agents pin to versions or profiles. Your production agents use catalog v2.3 while QA uses v2.4, and they do not drift. Without this, Agent A mysteriously fails because the database connector it relied on got silently updated with breaking changes. Audit trails become straightforward. You can prove which tools were available when incident X occurred. OCI-based catalogs are the only approach that makes catalogs and agents first-class infrastructure fully addressable with GitOps tooling.

OCI with containers delivers two benefits that matter for MCP. First, containers provide hermetic but customizable and context-rich security boundaries. The MCP server runs in a sandboxed container with explicit network policies, filesystem isolation, and resource limits. Secret injection happens through standard mechanisms with no credentials in prompts. This is key if MCP servers execute arbitrary code or have filesystem access.

Second, containers and the associated OCI versioning appends reusable governance tooling in just the right way, matching other governance tooling in your general container stack and workflow. Because catalogs are OCI artifacts, image scanning works the same. Signing and provenance use Cosign on catalogs just like images. Harbor, Artifactory, and other registries already have sophisticated access controls. Policy enforcement through OPA applies to catalog usage as it does to container deployments. Your FedRAMP-approved container registry handles MCP catalogs too. Your security team does not need to learn new tools.

From Phone Books and iTunes to Intelligent Platforms and Spotify

Organizations can evolve to dynamic discovery within trust boundaries. An MCP gateway allows the agent to query the catalog at runtime, select the appropriate tool, and instantiate only what it needs. With Docker’s Dynamic MCPs in the MCP Gateway, the agent can also call built-in tools like mcp-find and mcp-add to search curated catalogs, pull and start new MCP servers on demand, and drop them when they are no longer needed, instead of hard-coding tool lists and configs. Dynamic MCPs keep unused tools out of the model’s context, reduce token bloat, and let agents assemble just-in-time workflows from a much larger pool of MCP servers. The longer-term vision goes further. The gateway captures semantic intelligence around how users interact with MCPs, learns which tools combine effectively, and suggests relevant servers based on how similar problems were previously solved.

The longer-term vision goes further. The gateway captures semantic intelligence around how users interact with MCPs, learns which tools combine effectively, and suggests relevant servers based on how similar problems were previously solved. Teams both learn from and add to this knowledge feedback loop, Private catalog users discover new MCPs, mix MCPs in useful ways, and develop new ways of doing things,inspired by their own thoughts and by suggestions from the MCP gateway. This process also provides live reinforcement learning, imparting wisdom and context to the system that can benefit and everyone using the gateway.  This is organizational memory as infrastructure, emergent from actual agent work that blends human and machine intelligence in unlimited ways..

The container-native approach using private catalogs, dynamic MCP for runtime discovery, profiles as OCI artifacts, and sandboxed execution builds a composable, secure foundation for this future AI playground. How can we unleash MCP to drive developer creativity from a trusted foundation? Treat it like we treated containers but afford it the privileges that AI deserves as agentic, intelligent systems. Private MCP catalogs endowed with semantic intelligence and context understanding,  built atop OCI versioned infrastructure, running in safe agent sandboxes, are the first step toward that vision.

At the foundation are Docker Hardened Images, which are ultra-minimal, continuously patched containers that cut the attack surface by up to 95% and achieve near-zero CVEs. These images, combined with Docker Scout’s real-time vulnerability analysis, allow teams to prevent, detect, and resolve issues early, keeping innovation and security in sync. The result: 92% of enterprises report fewer application vulnerabilities, and 60% see reductions of 25% or more.

Docker also secures agentic AI development through the MCP Catalog, Toolkit, and Gateway. These tools provide a trusted, containerized way to run Model Context Protocol (MCP) servers that power AI agents, ensuring communication happens in a secure, auditable, and isolated environment. According to theCUBE Research, 87% of organizations reduced AI setup time by over 25%, and 95% improved AI testing and validation, demonstrating that Docker makes AI development both faster and safer.

With built-in Zero Trust principles, role-based access controls, and compliance support for SOC 2, ISO 27001, and FedRAMP, Docker simplifies adherence to enterprise-grade standards without slowing developers down. The payoff is clear: 69% of enterprises report ROI above 101%, driven in part by fewer security incidents, faster delivery, and improved productivity. In short, Docker’s modern approach to DevSecOps enables enterprises to build, ship, and scale software that’s not only fast, but fundamentally secure.

Docker’s impact on software supply chain security

Docker has evolved into a complete development platform that helps enterprises build, secure, and deploy modern and agentic AI applications with trusted DevSecOps and containerization practices. From Docker Hardened Images, which are secure, minimal, and production-ready container images with near-zero CVEs, to Docker Scout’s real-time vulnerability insights and the MCP Toolkit for trusted AI agents, teams gain a unified foundation for software supply chain security.

Every part of the Docker ecosystem is designed to blend in with existing developer workflows while making security affordable, transparent, and universal. Whether you want to explore the breadth of the Docker Hardened Images catalog, analyze your own image data with Docker Scout, or test secure AI integration through the MCP Gateway, it is easy to see how Docker embeds security by default, not as an afterthought.

Review additional resources

• Read more in our latest blog about ROI of working with Docker
• theCUBE Research Report and eBook – economic validation of Docker
• Explore Docker Hardened Images and start a 30-day free trial 
• View Hardened Images and Helm Charts on Docker Hub
• Explore Docker Scout