{"id":3398,"date":"2026-02-10T14:12:48","date_gmt":"2026-02-10T14:12:48","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/02\/10\/hardened-images-are-free-now-what\/"},"modified":"2026-02-10T14:12:48","modified_gmt":"2026-02-10T14:12:48","slug":"hardened-images-are-free-now-what","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/02\/10\/hardened-images-are-free-now-what\/","title":{"rendered":"Hardened Images Are Free. Now What?"},"content":{"rendered":"

Docker Hardened Images<\/a> are now free, covering Alpine, Debian, and over 1,000 images including databases, runtimes, and message buses. For security teams, this changes the economics of container vulnerability management.<\/p>\n

DHI includes security fixes from Docker\u2019s 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\u2019s how our thinking is evolving at Docker.<\/p>\n

What Changes (and What Doesn\u2019t)<\/strong><\/h2>\n

DHI gives you a security \u201cwaterline.\u201d Below the waterline, Docker owns vulnerability management. Above it, you do. When a scanner flags something in a DHI layer, it\u2019s not actionable by your team. Everything above the DHI boundary remains yours.<\/p>\n

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.<\/p>\n

Vulnerabilities don\u2019t disappear. Below the waterline, you need to pull patched DHI images promptly. Above it, you still own application code, dependencies, and anything you\u2019ve layered on top.<\/p>\n

Supply Chain Isolation<\/strong><\/h2>\n

DHI provides supply chain isolation beyond CVE remediation.<\/p>\n

Community images like python:3.11<\/code> 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)<\/a> demonstrated the consequences when attackers exploit stolen PATs and tag mutability to propagate through the ecosystem.<\/p>\n

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\u2019re not immune to all supply chain risk, but you\u2019ve eliminated exposure to attacks that exploit community image trust models.<\/p>\n

This is a different value proposition than CVE reduction. It\u2019s isolation from an entire class of increasingly sophisticated attacks.<\/p>\n

The Container Image as the Unit of Assessment<\/strong><\/h2>\n

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.<\/p>\n

The container image is where all of this converges. It\u2019s 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<\/code> can be identical to what runs in CI and what gates production deployments.<\/p>\n

This doesn\u2019t 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\u2019re deploying.<\/p>\n

Policy-Driven Automation<\/strong><\/h2>\n

Every enterprise has a vulnerability management policy. The gap is usually between policy (PDFs and wikis) and practice (spreadsheets and Jira tickets).<\/p>\n

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.<\/p>\n

A simple, achievable policy might include the following:<\/p>\n