A hardened container image is a minimized base image designed to reduce unnecessary packages and improve supply-chain evidence. Depending on the provider and tier, that evidence may include signatures, SBOMs, provenance attestations, VEX data, and published vulnerability-remediation targets. The base image is the one piece of a containerized application many teams inherit without reviewing closely.
It also influences how much attack surface every higher control, from admission policies to runtime monitors, has to defend.
In many regulated cloud environments, the same migration pattern shows up repeatedly. The hard part is rarely just the FROM-line swap. It is producing the audit table that justifies the swap, and the CI/admission policy that prevents future drift back to public, unsigned, or stale images.
This guide walks a four-phase migration from public base images to hardened equivalents: audit, map, stage, and validate.
up to 95% attack-surface claim and Chainguard's reported 97.6% average CVE reduction for Chainguard Images.dhi.io/python:3.13 with python:3.13 and shows 1 High, 5 Medium, 141 Low, and 2 unspecified CVEs removed, size reduced from 412 MB to 35 MB, and packages reduced from 610 to 80. Docker notes that results may vary as images and CVEs change.Auditing your current base images means producing a scored inventory of the base images your organization runs in production. The inventory should cover CVE counts by severity, KEV exposure, days since the last upstream rebuild, signature and SBOM availability, and compliance posture.
The output is a migration backlog prioritized by risk, not by whichever Dockerfile is easiest to edit first. This aligns with the inventory and scanning discipline in NIST SP 800-190 and with Chainguard's 2024 report, which measures CVE exposure by image ecosystem.
Many organizations discover during this step that Dockerfile references, running workload images, and registry contents are tracked in separate systems. The goal is to create one source of truth for the base images actually running in production.
Run a registry-wide and cluster-wide enumeration, not a single image scan:
crane catalog, crane manifest, or gcrane to enumerate image:tag pairs where the registry supports it.kubectl get pods --all-namespaces -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | sort -u.docker history --no-trunc <image>, docker inspect <image>, or dive to inspect layers and infer the base distribution where the image metadata supports it.The output is a single table with one row per unique base image. Include columns for production workload count, first-introduced date, last upstream rebuild, registry source, and whether the row is backed by scan/SBOM evidence.
The numbers your audit produces may not be small. Chainguard's 2024 report puts the average Debian-based official image in its sample at nearly 280 CVEs and 273 components, Red Hat application images at 190 CVEs on average excluding will not fix, and popular Iron Bank images at nearly 110 CVEs on average.
Snyk has reported that 44% of Docker image scans by Snyk users had known vulnerabilities for which newer and more secure base images were available.
Score by CVE blast radius: severity multiplied by the number of workloads inheriting the image. Do not score by raw CVE count alone. A High CVE in a base image used by 40 services may deserve more urgent treatment than a Critical finding in a single internal tool.
This rubric is meant to prevent a common prioritization failure: treating a single-service Critical finding as automatically more urgent than a High finding inherited by many production workloads.
The following table is illustrative. Replace the values with scanner output from your own registries, clusters, and SBOMs before using it in an audit package.
This backlog table is the deliverable that justifies the migration to security and platform-engineering audiences. It is also the baseline you measure against after migration.
Mapping each public base image to a hardened equivalent is a workload-aware decision. The same image can map differently depending on libc requirements, package-manager behavior, FIPS needs, STIG evidence, patch commitments, or available subscription tiers.
Common production-grade options in 2026 include Docker Hardened Images, Chainguard Containers and Wolfi-based images, Red Hat UBI Micro, Canonical Chiselled Ubuntu, BellSoft Alpaquita, Iron Bank, Google distroless images, and source-built minimal alternatives. Compare them across minimization technique, libc, signing and SBOM support, VEX availability, patch commitments, and compliance posture.
Pick candidates that satisfy your compliance posture first, then optimize for patch commitment, operational fit, and image size.
Docker's December 17, 2025 press release says DHI became free and fully open source under the Apache 2.0 license, with DHI Enterprise available for customization, compliance variants, and SLA-backed updates.
For regulated workloads, compare each vendor's remediation commitments against the FedRAMP vulnerability-management requirements that apply to your authorization boundary and POA&M process.
These are common migration failure modes to test before canary. CA-certificate path issues are especially easy to misdiagnose because the symptom often looks like an upstream TLS or API outage.
A safe rollout is a staged pipeline discipline. Pick a low-risk pilot workload, use multi-stage builds to keep upstream tooling out of production, swap one base at a time, pin the new image by digest, run it through dev -> staging -> canary -> blue-green -> 100%, and keep a written rollback plan for every wave.
A practical sequencing rule is to start with application images before attempting to standardize every shared base image. This reduces coordination overhead and lets service owners validate the change in their own CI/CD path.
A workload is a good pilot when it is stateless, runs a single language runtime with few native extensions, has mature canary or blue-green automation, and has a named on-call rotation that owns it.
A workload is a poor pilot when it is stateful, runs sparse cron or batch workloads, lacks automated rollback, or carries a near-term customer-facing SLA risk.
A gateway or API service can be a strong pilot when it is stateless, well-instrumented, and easy to canary. Avoid starting with stateful workloads or sparse test coverage, because early failures can slow adoption across later waves.
# Builder stage uses the upstream image (or vendor's -dev variant); ephemeral
FROM golang:1.24 AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -trimpath -o /out/server ./cmd/server
# Runtime stage uses the hardened distroless image
FROM <hardened-static-image>:<digest>
COPY --from=builder /out/server /server
USER 65532:65532
ENTRYPOINT ["/server"]The build-time and runtime images should usually be different. Compilers, package managers, and shell utilities belong in the builder stage unless the workload truly needs them at runtime.
FROM nginx:1.27 may pull different bytes over time if the tag is rebuilt. The same is true of hardened-image tags. Pin to an immutable content digest:
# base image: dhi.io/nginx:1.27-alpine
FROM dhi.io/nginx@sha256:<full-digest> Renovate can update Docker digests through pull requests, which makes base-image rebuilds visible instead of silently changing behind a mutable tag.
Use the verification workflow supported by your chosen vendor. A common Cosign pattern is to verify the image signature and, when attestations are expected, verify the attestation with the correct identity, issuer, and predicate policy before inspecting its contents:
cosign verify \
--certificate-identity "$EXPECTED_IDENTITY" \
--certificate-oidc-issuer "$EXPECTED_ISSUER" \
<hardened-image>@sha256:$PINNED_DIGEST
cosign verify-attestation \
--certificate-identity "$EXPECTED_IDENTITY" \
--certificate-oidc-issuer "$EXPECTED_ISSUER" \
--type "$EXPECTED_ATTESTATION_TYPE" \
<hardened-image>@sha256:$PINNED_DIGEST
cosign download attestation <hardened-image>@sha256:$PINNED_DIGEST | \
jq -r '.payload' | base64 -d | jq '.predicate'Sigstore documents cosign verify-attestation for attestation verification. Treat cosign download attestation as inspection, not proof of trust by itself. Verify provenance and SBOM evidence as a build-pipeline gate when the vendor publishes those attestations.
Keep the previous image pinned by digest until the new image has been at 100% production traffic for an agreed observation window.
Docker's Gordon-assisted DHI migration flow and Chainguard's beta Guardener can help translate Dockerfiles toward hardened-image equivalents, but their output still needs build, test, security, and compliance review. Chainguard documents Guardener sessions as taking from five to more than thirty minutes depending on Dockerfile complexity.
Every AI-assisted Dockerfile should be reviewed, tested, scanned, and digest-pinned before the canary opens.
Update GitHub Actions, GitLab CI, Jenkins, or Buildkite to:
docker build where the vendor supports signatures.Where your registry supports it, configure a pull-through cache or mirror for the hardened-image vendor registry. Artifactory, Harbor, ECR, and Google Artifact Registry have registry proxy or remote-cache patterns, but the exact setup and supported upstreams vary.
For workloads that need extra runtime packages and use Minimus, follow the documented Minimus process for requesting a new image type or altered packages. Confirm provenance, support, and SLA terms for any private or customized variant in your Minimus agreement before relying on those terms in an audit package.
Validation means proving with evidence that you reduced CVE count, package count, image size, and remediation latency. Then it means enforcing the win in CI and admission control so future builds cannot drift back to public, unsigned, or stale images.
Most teams should not declare victory after the cutover alone. Without policy enforcement, the next rebuild can accidentally reintroduce a public base image or mutable tag.
Use the Docker quickstart output as an example, and re-run the comparison against the exact tags and platforms in your environment.
For regulated environments, pair this scorecard with scanner output, SBOMs, attestations, image identifiers, scan dates, and POA&M evidence so assessors can trace each claim back to a source artifact.
Cluster-side policies in Kyverno, OPA Gatekeeper, Connaisseur, Ratify, Portieris, or similar tools can reject pods that do not meet your policy: untrusted registry, missing digest, missing signature, missing attestation, stale scan evidence, or disallowed CVE severity.
Do not copy a placeholder policy into production. For Kyverno, use tested verifyImages rules with explicit static imageReferences, verifyDigest, and the correct attestors for your signing model. For registry allow-lists, use a tested validation policy rather than a pipe-separated string inside a single image pattern.
AWS EKS image-security guidance documents this pattern: use minimal images, SBOMs, attestations, vulnerability scanning, and admission controllers to reject images that do not meet policy.
Without automation, a vendor remediation target does not help production if the new digest never reaches CI. For ordinary Dockerfiles, start with Renovate's built-in Docker support and digest pinning:
{
"extends": ["config:recommended"],
"docker": { "enabled": true },
"regexManagers": [
{
"fileMatch": ["(^|/)Dockerfile$"],
"matchStrings": [
"FROM\\s+(?<depName>[^@:]+)(:(?<currentValue>[^@\\s]+))?@(?<currentDigest>sha256:[a-f0-9]{64})"
],
"datasourceTemplate": "docker"
}
]
}After every base-image bump, rebuild, scan, sign, attest, canary, and roll out through the same gates as the initial migration.
Hardened images move you from unbounded CVE firefighting to a smaller, evidence-backed queue. A new CVE alert becomes a workflow: check the SBOM, review VEX or advisory data where available, confirm whether the image is affected, and track the vendor's remediation target.
MITRE ATT&CK T1611 describes container escape-to-host techniques, and its mitigations include removing unnecessary tools and software from containers. Images without shells, package managers, and compilers reduce the tooling available after compromise, but they do not eliminate runtime escape risk.
A hardened base-image migration reduces build-time attack surface and improves audit evidence. It does not replace runtime threat detection, network policy, secrets management, or host/node protection. Treat the hardened base image as the foundation, not the entire stack. Treat admission control and CI policy as the mechanisms that keep the migration from drifting back to public, unsigned, or stale images.
Minimus publishes remediation targets in its Trust Center: KEV active exploits within 1 calendar day after an upstream fix is available, Critical/High vulnerabilities within 2 calendar days after an upstream fix is available, and Medium/Low vulnerabilities within 14 calendar days after an upstream fix is available. Minimus also states that new upstream version releases are incorporated into Minimus images within 7 calendar days, subject to exceptions for defects, breaking changes, or validation needs.
Evaluate compatibility per image family, libc, package manager, UID/GID, and entrypoint before treating a replacement as drop-in. Validate scanner output in your pipeline with the exact tools you rely on, such as Trivy, Grype, Snyk, Docker Scout, AWS Inspector, or Anchore.
For workloads that need extra runtime packages, Minimus documents a process to request a new image type or altered packages. Confirm provenance, support, and SLA terms for any private or customized variant in your Minimus agreement. Use the Minimus catalog or Image Gallery if your account provides access, but do not treat private catalog availability as a public claim unless you can cite it.
Timelines vary by test coverage, compliance scope, native dependencies, and rollout automation. A low-risk single service can often be migrated in days, while a fleet migration should be planned in waves that include audit, mapping, staged rollout, and post-migration policy enforcement.
No. Hardening is the architectural choice to ship only the components your workload needs and to preserve supply-chain evidence such as signatures, SBOMs, and provenance where available. Patching is the operational cadence with which you rebuild and redeploy after vulnerabilities are fixed upstream. Remediation targets vary by vendor, severity, subscription tier, and upstream fix availability.
Common options in 2026 include Docker Hardened Images, Chainguard Containers and Wolfi-based images, Red Hat UBI Micro, Canonical Chiselled Ubuntu, BellSoft Alpaquita, Iron Bank, Google distroless images, and source-built minimal alternatives. They differ on minimization technique, libc, signing/SBOM/VEX support, remediation commitments, and compliance posture.
There are valid reasons to delay a migration. A workload may depend on a shell, package manager, or interactive tool at runtime, such as a CI runner image, a developer sandbox, or software that expects to install packages at startup. A second reason is lack of automation: if you cannot bump digests, rebuild, scan, and redeploy reliably, a vendor remediation target will not reach production.
Start with docker history --no-trunc <image> or a layer-inspection tool such as dive to understand the image layers. Then cross-check docker inspect labels/config, SBOM or provenance metadata, and publisher documentation. docker inspect can expose useful clues, but it usually cannot reliably identify the original base image by itself.
Yes, if you keep the previous image pinned by digest and available until the new image has passed its observation window. The rollback may be a kubectl rollout undo deployment/<service> or the equivalent in your deployment tool. Blue-green and canary patterns are useful because the previous public-image build remains available while the hardened-image build proves itself in production.
Migrating from public to hardened container images is one project with four phases: audit, map, stage, and validate. Run the audit table, build the mapping table, ship the staged rollout, and enforce the result in CI and admission control. The next CVE should become a triage workflow, not a production surprise.
.svg)
.svg)
.svg)
.svg)
