Introduction
One year ago, we launched Docker Hardened Images (DHIs) with a commitment to a harder—but better—path for container security. Today, with over 500,000 daily pulls and a catalog of 2,000+ artifacts, the results speak for themselves. But success isn't about the numbers; it's about the deliberate choices we made: free access, multi-distro support, building from source, and full verifiability. This guide shows you how to replicate that approach for your own infrastructure—step by step. Whether you're a DevOps engineer or a security lead, you'll learn how to evaluate, adopt, and maintain hardened images that raise your security baseline without imposing migration taxes.
What You Need
- A container runtime (Docker, Podman, or containerd) installed on your development or production system.
- Access to a registry that supports hardened images (e.g., Docker Hub, GitHub Container Registry, or your own private registry).
- Basic familiarity with Dockerfiles, CI/CD pipelines, and vulnerability scanning tools (e.g., Trivy, Grype).
- A willingness to embrace open source and multi-distro strategies—no proprietary OS lock-ins.
- Optional: A project with existing containers that you want to secure.
Step 1: Choose a Multi-Distro Foundation (Don't Reinvent the Wheel)
Some vendors create a custom “distroless” OS and call it innovation. In reality, that’s a proprietary distribution your team has never tested, audited, or run in production. Instead, select a hardened image provider that supports established distributions like Debian, Alpine, or Ubuntu. Our DHI catalog covers multiple distros and continuously patches every OS-level artifact—over 25,000 packages in a SLSA Build Level 3 pipeline. By sticking with distributions your team already knows, you avoid migration taxes and can drop in hardened images with zero code changes.
Step 2: Use Free and Open Source Hardened Images (Security Is Not a Premium Feature)
Security shouldn’t be gated behind a paywall. We made DHIs available under the permissive Apache 2.0 license, and you should demand the same from any provider. Hardened images must be freely accessible to raise the baseline for everyone. Start by pulling a community-tier image (e.g., docker.io/chainguard/nginx:latest) and test it in your staging environment. You’ll get the same patches, attestations, and coverage as any paid tier—no hidden costs.
Step 3: Verify Attestations and SBOMs (Don't Trust, Verify)
A hardened image is only as trustworthy as its provenance. Every image should come with signed attestations: SBOMs (Software Bill of Materials), SLSA provenance, and vulnerability scan results. We ship these with every DHI build. To verify: use cosign verify-attestation or integrate with your CI/CD to check signatures before deployment. This gives you independent verifiability that the image hasn’t been tampered with and that every layer comes from known sources.
Step 4: Build a Continuous Patching Pipeline (Patches Don't Stop at Release)
One-off hardening is not enough. You need a pipeline that continuously rebuilds images as new CVEs are disclosed. Our system runs over a million builds regularly, covering every combination of distro, package, and version. To replicate:
- Integrate your image registry with a CVE feed (e.g., NVD, OSV).
- Automate rebuilds on a schedule (daily or hourly).
- Push updated images with new attestations automatically.
- Use a tool like Renovate or Dependabot to update your deployments.
This ensures your production images are always patched—without manual intervention.
Step 5: Integrate into Your CI/CD with Drop-In Ease
Hardened images should be a drop-in replacement for your existing base images. No Dockerfile rewrites, no new configs. Because we build multi-distro, you can swap FROM debian:latest for FROM cgr.dev/chainguard/debian:latest and get all the hardening automatically. In your CI/CD (GitHub Actions, GitLab CI, Jenkins):
- Set your pipeline to pull the hardened image tag.
- Enable signed attestation verification as a gate.
- Run vulnerability scans on the final image to confirm no new issues.
This approach has scaled to 2,000+ artifacts, including MCP servers, Helm charts, and extended lifecycle support (ELS) images—all continuously patched.
Step 6: Monitor and Iterate (The Hard Work Never Ends)
After deployment, track key metrics: pull counts, CVE remediation time, and build frequency. We crossed 500k daily pulls and 25k continuously patched packages—but the real success is in the process. Set up dashboards to monitor:
- Number of images that are up-to-date vs. lagging.
- Time to patch critical CVEs.
- Attestation validity.
Iterate by expanding your catalog coverage—add new Debian packages, ELS images, or newer artifact types as they emerge. We’re doing the same, and the impact grows with every new artifact.
Tips for Success
- Start small: Pick one critical service and replace its base image with a hardened one. Validate thoroughly before rolling out to all services.
- Embrace open source: Demand Apache 2.0 or similar permissive licenses—avoid proprietary lock-ins that limit your ability to audit or fork.
- Verify everything: Even if the image is from a trusted provider, always check attestations and SBOMs in your pipeline.
- Automate patching: Manual CVE fixes are error-prone. Invest in a pipeline that rebuilds and retests automatically.
- Don’t skip the “harder path”: The easiest choices often lead to vendor lock-in or incomplete security. Do the extra work—build from source, support multiple distros, and keep everything verifiable. It pays off.
By following these steps, you’ll replicate the same principles that drove our DHI growth: accessibility, verifiability, and continuous improvement. Your containers will be more secure, your teams will stay productive, and you’ll contribute to raising the security baseline for everyone.