What is container hardening? How to harden a container image

In brief

• Container hardening removes what the application does not run and locks down what remains; the CIS Benchmarks, DISA STIGs and NIST SP 800-190 define what good looks like.
• Seven steps: secure base, remove unused packages, non-root user, drop capabilities and use a read-only filesystem, digest pinning and signatures, scan and rebuild on fixes, enforce at admission.
• A "hardened" label does not by itself tell you whether known CVEs in the remaining packages are patched. Pair hardening with a patched base, and decide what to remove from runtime evidence rather than from the package list.

In this guide, container hardening means reducing a container image's attack surface and exposure by removing components the application does not need and applying secure configuration to what remains. The steps are to start from a minimal or vendor-maintained base image, remove unused packages and binaries, run as a non-root user, drop capabilities and use a read-only filesystem, pin and verify image digests, scan and rebuild on fixes, and enforce at admission, with a benchmark such as the CIS Benchmarks or a DISA STIG as the configuration baseline. NIST's general definition of hardening also includes patching vulnerabilities. This guide treats patching as a separate step, because a "hardened" label does not by itself tell you whether known CVEs in the remaining packages are patched, or on what timeline. It covers the standards, the seven steps, and how runtime evidence makes removal safe.

Why container hardening matters

A standard container image ships with far more software than the application runs. A distribution base image carries a shell, a package manager, utilities and libraries that exist for general-purpose use, and every one of them widens the attack surface: NIST defines the attack surface as the set of points where an attacker can try to enter, cause an effect on or extract data from a system. Removing unused components also removes any CVEs they carry, so hardening lowers both the number of ways in and the number of findings your scanner reports. NIST SP 800-190, the Application Container Security Guide, sets out the major risks for five core components of container technologies (images, registries, orchestrators, containers and host operating systems) and countermeasures for each.

The standards that define container hardening

Three standards define it. The CIS Benchmarks are prescriptive, consensus-based configuration recommendations, and the CIS Docker Benchmark is a consensus-driven security guideline for Docker. A DISA STIG is an implementation guide for a specific product and version, based on Department of Defense policy and security controls, published by the Defense Information Systems Agency as a tool to improve the security of Department of Defense information systems. NIST SP 800-190 provides container-specific risks and countermeasures. For FedRAMP, the 2021 Vulnerability Scanning Requirements for Containers state that a cloud service provider must only use containers whose image is hardened, and that where applicable the hardening must be in accordance with relevant benchmarks listed in the National Checklist Program, defined by NIST SP 800-70.

How to harden a container image, step by step

1. Start from a secure base image

The base image is set by the Dockerfile's FROM instruction, and everything built on it inherits its contents and its vulnerabilities. Start from a minimal, maintained base on the distribution your application is tested on, or from a near-zero CVE image that has already been hardened and patched. What are secure base images?

2. Remove packages and binaries the application never runs

Uninstall build tools, documentation, locale files and utilities that production does not need, or use a multi-stage build that copies only the application and its runtime dependencies into the final image. The safe way to decide what to remove is evidence of what actually executes, not a guess from the package list; see the runtime evidence section below.

3. Run as a non-root user

Create a dedicated user in the Dockerfile and set USER before the entrypoint, so a compromised process does not hold root inside the container. In Kubernetes, set runAsNonRoot in the pod security context so the kubelet refuses to start a container that would run as root; the image USER must be a numeric UID, or runAsUser must be set, for the kubelet to verify it.

4. Drop capabilities and use a read-only filesystem

Drop all Linux capabilities and add back only the ones the process needs; run with a read-only root filesystem and a writable tmpfs for scratch space. Docker's engine security documentation describes the capability model.

Steps 3 and 4 in a Dockerfile for a Debian-based image and at run time, with a generic registry path:

FROM registry.example.internal/approved/app:1.0@sha256:<digest>
RUN addgroup --system --gid 10001 app && adduser --system --uid 10001 --ingroup app app
USER 10001

docker run --read-only --tmpfs /tmp --cap-drop=ALL --user 10001 \
  registry.example.internal/approved/app:1.0@sha256:<digest>

In Kubernetes the same controls are set in the container security context: runAsNonRoot, readOnlyRootFilesystem and a capabilities drop list.

5. Pin and verify image digests

Reference base images by digest rather than by a mutable tag, so a rebuild cannot silently change what you ship. Verify signatures at build and at admission: Sigstore records signatures in a tamper-resistant public log, and Cosign signs OCI containers.

6. Scan and rebuild on a schedule

Scan every build and rebuild when a security fix lands for a package in the image, not only when the application changes. Scanners can disagree on the same image: in a 2024 study of 927 Docker images, Trivy and Grype disagreed on both the number of vulnerabilities and the vulnerability IDs in the 865 images that had vulnerabilities (IEEE SCAM 2024), so read findings with that in mind and keep SBOMs for each build.

7. Enforce at admission

Make hardened images the only ones that run. Kubernetes admission controllers intercept requests before a resource is saved, and policy engines such as Kyverno and OPA Gatekeeper run as admission webhooks. Kyverno can reject images from unapproved registries, images that fail signature verification and containers not set to run as non-root. OPA Gatekeeper can reject images from unapproved registries and containers that run as root, and checks signatures through an external data provider.

What container hardening does not do

Removing components and applying a benchmark do not patch known vulnerabilities in the packages that remain. An image hardened to a CIS Benchmark with every unused package removed still carries any known CVEs in its C library, its TLS library and its runtime until those are patched or backported and the image is rebuilt. Hardening does not remove the need for scanning, since new CVEs are disclosed in what remains, and it does not remove the need for runtime security, since production changes after deployment. The difference between a hardened image and a near-zero CVE image is exactly that patching step. What are hardened container images?, What is a near-zero CVE image?

How runtime evidence makes removal safe

The risk in step 2 is removing something the application needs only sometimes. Runtime profiling answers that by observing the application as it runs and recording which packages, libraries and binaries it uses, so removal is based on what executes rather than on what the package manager lists. RapidFort Profiler generates an RBOM® (Runtime Bill of Materials), a continuously updated record of components actually executed during runtime, and distinguishes active code paths from dormant layers. RapidFort Optimizer uses RBOM® runtime intelligence to identify components that never execute and safely remove them while preserving application functionality, with Light, Standard or Aggressive hardening levels, for up to 90% attack surface reduction. Hardening occurs at the container image layer without modifying code, and the optimized images are rebuilt every 24 hours and delivered as drop-in replacements without CI/CD changes.

For the base layer, RapidFort Images are both hardened and patched: hardened against their appropriate STIG or CIS Benchmark, when available, and manually patched and rebuilt by RapidFort engineers, with up to 99.9% CVE elimination across distroless and full images.

Frequently asked questions