How to Secure Docker Images with Hardening and Continuous Patching

Aug 28, 2026 · Original article ↗

Summary

The article gives practical Docker image-hardening guidance, including minimizing base images, removing unused packages, running as non-root, keeping secrets out of layers, signing images, generating SBOMs, and continuously patching. It also promotes Aikido’s image-patх

Key points

The article says vulnerabilities commonly enter images through the OS packages and libraries in the base image; unused packages can be removed, but vulnerabilities in required dependencies still need patches.
It recommends minimal or distroless bases, multi-stage builds, and removing build tools and unnecessary utilities from the final image.
Defensive configuration recommendations include running containers as non-root, using a read-only root filesystem, and dropping unused Linux capabilities such as CAP_NET_RAW.
Secrets copied or passed through ARG can remain in image layers even if later deleted; the article recommends build-time secret mounts and runtime injection from a secrets manager.
It recommends pinning base images by digest, generating an SBOM, signing images, verifying signatures before deployment, and continuously checking for newly disclosed vulnerabilities.
The article cites CVE-2023-4911 (Looney Tunables) and the xz-utils backdoor as examples of risks associated with base-image components and release choices.
Aikido says its Images service provides patched builds of existing base-image versions and proposes replacements via pull request; it says builds include an SBOM, VEX, and SLSA provenance.

Article Details

Defense Focus: Reduce Docker image attack surface and continuously detect and remediate vulnerabilities, exposed secrets, and image integrity risks.
Detection Methods: Continuously scan images for vulnerable OS packages and application dependencies, outdated runtimes, malware, and license risks.
Generate an SBOM for each image to inventory its packages and versions and assess newly disclosed vulnerabilities.
Inspect image layers and build inputs for secrets that may remain in image history.
Use upstream changelogs and commit history, in addition to CVE databases, to identify fixes for vulnerabilities not assigned a CVE.
Verify image signatures before deployment and reject unsigned images through an admission controller.
Data Sources: Container image layers and package inventories
SBOMs
Vulnerability disclosures and CVE databases
Upstream package changelogs and commit history
Dockerfile commands and build context
Kubernetes workloads
Platforms: Docker
Kubernetes
Defensive Actions: Use a minimal or hardened base image and remove packages the running application does not need.
Use multi-stage builds so compilers, development headers, and other build tooling are not included in the final image.
Run containers as a non-root user, use a read-only root filesystem where practical, and drop unused Linux capabilities.
Keep secrets out of image layers; use build-time secret mounts and inject runtime secrets from a secrets manager. Exclude local configuration and credentials from the build context with .dockerignore.
Pin base images by digest when reproducibility is needed, and continuously check pinned images for newly disclosed vulnerabilities.
Sign images at build time and verify signatures before deployment.
Treat deployed containers as immutable; build, test, and redeploy patched images rather than modifying running containers.
Apply fixes through patched builds of the existing base-image version when available, reviewing and testing the image update before deployment.