Introduction
When it comes to container security, the easy road often leads to vendor lock-in, opaque processes, and delays in patching critical vulnerabilities. Over the past year, we’ve taken the harder path—building Docker Hardened Images (DHI) from the ground up with openness, multi-distro support, and continuous patching at scale. This guide walks you through the key steps to replicate that approach, whether you’re evaluating a hardened image provider or building your own pipeline. You’ll learn why choosing open source, building from source, and shipping verifiable attestations matter—and how to apply these principles to raise your security baseline.
What You Need
- Docker or any OCI-compatible container runtime
- A CI/CD pipeline (e.g., GitHub Actions, GitLab CI, Jenkins)
- A vulnerability scanner (e.g., Trivy, Grype)
- Access to a public or private container registry
- Familiarity with Linux distributions (Debian, Alpine, Ubuntu)
- Understanding of SLSA (Supply chain Levels for Software Artifacts) principles
- Time commitment: approximately 2–4 weeks for initial setup, then ongoing maintenance
Step-by-Step Guide
Step 1: Assess Your Security Baseline and Choose an Open Approach
Start by evaluating your current container security posture. If you’re relying on vendor-specific images that lock you into a proprietary OS, you incur a “migration tax” every time you need to test or audit. We chose to make our hardened images free and open source under the Apache 2.0 license, so security isn’t a premium feature. For your own pipeline, commit to using images that are freely distributable and allow you to inspect every layer. This ensures your team can raise the baseline without barriers.
Step 2: Adopt a Multi-Distro Strategy (Drop-In, No Migration)
Some vendors create a new “distroless” OS—essentially a proprietary distribution that your teams have never run, tested, or audited. Instead, we built DHI to support multiple established distros (Debian, Alpine, Ubuntu) so adoption is drop-in. In your pipeline, choose hardened images that match the distros you already use. This avoids retooling and keeps your existing monitoring, logging, and compliance processes intact.
Step 3: Build Every System Package from Source
Pre-built binaries from third-party sources can hide tampered dependencies or delayed patches. We compile every OS-level artifact from source in our SLSA Build Level 3 pipeline. For your own hardened images, set up a build process that fetches source code from trusted repositories, applies security patches, and compiles packages. This gives you full control over what goes into your images and ensures transparency at the binary level.
Step 4: Implement Continuous Patching at Scale
After launch, we crossed 500k daily pulls and over 25k continuously patched OS artifacts. Running a million builds regularly is not trivial, but it’s necessary to address CVEs as they emerge. Set up automated triggers that scan your images daily, rebuild affected layers with patches, and push updates to your registry. Use a vulnerability scanner to prioritize patches by severity. This proactive approach keeps your hardened images current without manual intervention.
Step 5: Ship Verifiable Attestations with Every Image
Independent verifiability requires more than an SBOM. We include a wide range of signed attestations—provenance metadata, build SLSA level, and package integrity claims—with each image. In your pipeline, generate and sign attestations using tools like in-toto or cosign. Store them alongside your images in your registry. This allows consumers to verify that the image they’re pulling was built from source, under a known SLSA level, and hasn’t been tampered with.
Step 6: Evaluate Providers with a Critical Eye
Not all hardened image vendors are equal. Look for patterns in their patching timelines, SBOM completeness, and advisory coverage. We’ve observed that many delay critical fixes or omit vulnerable packages to appear “secure.” Ask: Do they build from source? Are their images free and open source? Do they support multiple distros? How frequently do they rebuild? Use the criteria from Steps 1–5 as a checklist. If a provider doesn’t meet these standards, consider building your own pipeline.
Tips for Long-Term Success
- Security is not a premium feature. Make hardened images freely available within your organization to encourage widespread adoption.
- Avoid vendor lock-in. Never migrate to a proprietary OS to get “hardened” images—your teams will pay the price in audit complexity.
- Automate everything. Manual patching doesn’t scale. Use CI/CD triggers and scheduled rebuilds to stay ahead of CVEs.
- Share your pipeline. Open-sourcing your hardening process raises the bar for the entire ecosystem, just as we did with Docker Official Images and DHI.
- Monitor your own metrics. Track daily pulls, patched artifacts, and build counts to validate your pipeline’s effectiveness. We passed 500k daily pulls and a million builds—so can you.
Remember: the harder path—open, multi-distro, built from source, continuously patched—is worth the effort. It gives you independence, transparency, and real security at scale. Start building your hardened image pipeline today.