Docker introduced Hardened Images, or DHIs, as an official image variant aimed at teams that need more than the standard Docker Hub pull. If you’ve ever deployed a public container image in production and wondered whether the base layer had known vulnerabilities you didn’t catch, DHIs are the answer to that question. They’re not a new image format or runtime. They’re Docker’s attempt to apply software supply chain security practices — signed attestations, immutable digests, minimal attack surfaces — to the images most teams already use.
The announcement flew under the radar for a lot of sysadmins, partly because the container security landscape has been noisy for years. Trivy, Grype, Snyk, Docker Scout — the scanning tools are everywhere. But scanning tells you what’s wrong after you’ve already built or pulled the image. DHIs are designed to prevent the problems from being there in the first place.
What Makes a Docker Hardened Image Different
A standard Docker image from Docker Hub gives you the software you asked for and whatever its maintainer decided to include in the base layer. That might be a full Debian install with systemd, cron, and a package manager you don’t need. A DHI gives you the same software on a distroless base — no shell, no package manager, no utilities that aren’t required for the application to run.
The practical difference is measurable. Fewer packages means fewer CVEs to triage. No shell means an attacker who compromises the container can’t easily spawn a reverse shell or install persistence tools. No package manager means they can’t download additional tooling even if they get code execution. None of this is novel — distroless images have existed for years — but Docker baking them into an official, supported product line changes the calculus for teams that were hesitant to adopt them because of maintenance concerns.
The second major difference is attestation. Every DHI ships with signed metadata that proves where the image came from, what went into it, and whether any component has been tampered with since build time. This is the SLSA framework in practice: a chain of verifiable claims that starts at the source repository and ends at the image digest you pull into your Kubernetes cluster. You can verify these attestations with docker buildx imagetools inspect or integrate them into a CI pipeline that refuses to deploy unsigned images.
Compliance That Ships With the Image
One of the more interesting design decisions in DHIs is that compliance support isn’t an add-on. It’s built into the image metadata. If you’re running infrastructure that needs to meet FIPS 140 cryptographic standards, there’s a DHI variant that uses FIPS-validated cryptographic modules and provides signed attestations you can hand to an auditor. If you’re deploying into a STIG-regulated environment — common in US government and defense contracting — the STIG-ready DHIs come with pre-verified security scan attestations that map directly to DISA requirements.
CIS Benchmarks for Docker are similarly addressed. Rather than asking teams to interpret the CIS Docker Benchmark and manually harden their images, DHIs ship in configurations that already align with the benchmark. This doesn’t eliminate the need for infrastructure-level hardening — your Docker daemon configuration, your host OS, your network policies are all still your responsibility. But it takes the image-level compliance work off the table, and for teams that have been doing that work manually, that’s hours per image that can go back into other tasks.
VEX and the Problem of Noise
Anyone who has run a vulnerability scanner against a production container image knows the problem: you get a list of 300 CVEs, 280 of which are in packages you don’t use, can’t exploit, or have already mitigated through other controls. Triaging that list is a full-time job if you let it be.
DHIs use the Vulnerability Exploitability eXchange standard, or VEX, to address this. VEX is a machine-readable format that says, for each CVE in an image, whether it’s actually exploitable in the context of that specific image. A vulnerability in glibc doesn’t matter if your image uses musl. A vulnerability in a network-facing service doesn’t matter if the image doesn’t expose that port. VEX encodes these judgments so your scanner can filter them automatically instead of dumping the raw CVE list and making you sort through it by hand.
The operational impact is straightforward: your security scanning pipeline produces fewer false positives, which means your team spends less time investigating CVEs that don’t represent real risk. Over a fleet of hundreds or thousands of containers, that time savings compounds.
How to Start Using DHIs Today
Docker Hardened Images are available alongside standard images on Docker Hub. The naming convention appends -dhi to the image name: nginx:latest becomes nginx:latest-dhi, python:3.12 becomes python:3.12-dhi. If you’re using Docker Scout or another scanner that supports attestation verification, you can add an attestation check to your CI pipeline:
docker buildx imagetools inspect nginx:latest-dhi --format '{{json .Provenance}}'This returns the SLSA provenance data for the image, which you can validate against Docker’s public signing key.
For teams using Kubernetes, the migration path is a drop-in replacement. Update your deployment manifests to use the DHI variants, verify that your application works on the distroless base (most do, but anything that shells out to system utilities will need adjustment), and update your security policies to require attestation verification on all production images.
The one operational caveat worth flagging: distroless images don’t have a shell. If your current debugging workflow involves kubectl exec into a container and poking around with bash, you’ll need to adjust. DHIs are designed to be debugged through logs, metrics, and sidecar containers — the same pattern that production Kubernetes clusters should be using anyway, but one that a lot of teams still bypass with shell access.
The CI/CD Pipeline Impact
Integrating DHIs into an existing build pipeline requires a few specific changes. If you’re currently building images from a base like ubuntu:22.04 or debian:bookworm, switching to a DHI base means you lose the package manager. You can’t apt-get install runtime dependencies inside the Dockerfile because there is no apt-get. Dependencies need to be either compiled into the application binary at build time or copied from a multi-stage build.
The multi-stage pattern works well here. Build your application in a standard golang:1.22 or node:20 image with all the build tools you need, then copy the compiled binary into the DHI base:
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o server .
FROM golang:1.22-dhi
COPY --from=builder /app/server /server
EXPOSE 8080
ENTRYPOINT ["/server"]The resulting image has your binary and nothing else. No shell, no build tools, no system libraries beyond what CGO_ENABLED=0 already excluded. This is the pattern that DHIs are optimized for, and it’s worth adopting even if you don’t switch to DHIs immediately — it reduces attack surface regardless of which base image you use.
For teams that deploy pre-built images rather than building their own, the pipeline change is even simpler. Update the image reference in your Kubernetes manifests or Docker Compose files, run your integration tests against the DHI variant, and roll out. Most application-level behavior is identical between standard and DHI images because the runtime libraries are the same. The differences surface in edge cases: scripts that call /bin/sh, monitoring agents that expect a shell, health checks that use curl inside the container rather than Kubernetes HTTP probes.
What DHIs Don’t Solve
It’s worth being clear about what Docker Hardened Images are not. They’re not a replacement for runtime security tooling. A DHI won’t stop a container from making outbound network connections to exfiltrate data if the application has a vulnerability that allows it. They won’t enforce seccomp profiles, AppArmor policies, or read-only root filesystems — those are still configured at the container runtime level. They won’t scan your application code for vulnerabilities, because they operate at the image layer, not the application layer.
What DHIs do is reduce the baseline risk of every container you deploy. A container with no shell, no package manager, and a minimized set of system libraries is harder to pivot from if an attacker gets initial access. A container with signed attestations gives you verifiable proof of its provenance when an auditor asks. A container with built-in VEX support reduces the alert fatigue that causes real vulnerabilities to get lost in the noise. None of this requires you to change your runtime, your orchestrator, or your monitoring stack — it’s a swap at the image level.
For most production deployments, the trade-off is worth it. The migration cost is low — updating image tags and adjusting Dockerfiles that rely on shell access. The security benefit is a permanently reduced attack surface that doesn’t depend on your team remembering to run a scanner or apply a patch. Docker Hardened Images bake security into the image itself, and for teams running containers in production, that’s infrastructure that pays off every day you don’t have to triage another CVE that doesn’t apply to your workload. The next time you start a new project or audit an existing deployment, try pulling the DHI variant and running your usual scan. The difference in the CVE count alone will tell you whether the switch is worth it. For most teams, it will be.
