Container hardening is the set of build-time and runtime techniques that reduce the attack surface of a containerized application: minimal base images, dropped Linux capabilities, read-only filesystems, signed images with provenance, and admission policies that enforce all of the above. Done well, hardening turns most "critical" CVE alerts into questions the platform has already answered, instead of tickets a security team has to triage every week.
This guide walks through what container hardening is, the methods that actually move risk down, the controls that map to CIS and NIST SP 800-190, and where source-built minimal images change the economics of the program. The goal is a working hardening checklist, not a vendor pitch.
Container hardening (also called container image hardening) is the process of reducing a container's attack surface by removing unneeded software, dropping kernel privileges, restricting the filesystem and network, and verifying every artifact in the supply chain. It applies at three layers:
A hardened container is one that fails closed. If an attacker reaches the workload, the workload contains nothing useful: no shell to spawn, no compiler to build a payload, no writable root filesystem to drop a file in, no privileged capability to abuse. Hardened image platforms, including Minimus, deliver this configuration as a default rather than a checklist.
The attack surface of a containerized application now extends past application code into the open source packages, base images, and CI/CD systems used to build and ship it. The threat model is no longer hypothetical:
Regulators have responded. NIST Special Publication 800-190 defines container-specific controls, including image minimization and least privilege. The DoD's DevSecOps Enterprise Container Hardening Guide v1.2 lays out the federal baseline that Iron Bank-accredited vendors ship against. U.S. Executive Order 14028 and OMB Memorandum M-22-18 require federal vendors to provide SBOMs. FedRAMP Rev. 5 mandates continuous monitoring of software components. The Center for Internet Security (CIS) publishes Docker and Kubernetes Benchmarks that explicitly require non-root containers, dropped capabilities, and read-only filesystems.
Most container hardening efforts we audit fail in the same way: the team picks the right controls on paper, then loses them to operational drag.
A typical engagement looks like this. The base image is ubuntu:latest or node:20. The Dockerfile starts with a 30-line apt-get install block to add tools the application does not need at runtime but the build did. The container runs as root because somebody added a chown step early on and never came back to fix it. The Kubernetes admission policy is in audit mode, has been in audit mode for nine months, and the dashboard nobody opens shows 4,000 violations per week.
What changes the picture, in our experience, is replacing the input. A minimal, source-built base image with no shell, no package manager, and a signed SBOM removes most of the controls a team would otherwise have to apply by hand. The container is non-root because there is no root account configured. The filesystem is effectively read-only because there is nothing useful to write. The capability set is empty because the image never asked for any. That is the hardening posture Minimus ships by default, and it is why the rest of this guide reads more like a "what to verify" checklist than a "what to build" project plan.
Five techniques do most of the work. They map directly to CIS Docker Benchmark v1.7 sections 4–5, CIS Kubernetes Benchmark v1.10 section 5, and the OWASP Docker Security Cheat Sheet.
Fewer packages mean fewer CVEs and a smaller blast radius if a vulnerability is exploited. A standard debian:12 image carries 50 to 60 Trivy findings before any application code is added; switching to a minimal or distroless base typically cuts that by an order of magnitude.
gcr.io/distroless/* images are the canonical example.In every case, pin the base image to a digest (@sha256:...), not a floating tag. nginx:latest will mean something different next week.
By default, a Docker container inherits a set of Linux capabilities (CAP_NET_RAW, CAP_CHOWN, CAP_SYS_PTRACE, and others) that almost no application needs. Drop them at the container level:
securityContext:
runAsNonRoot: true
runAsUser: 65532
capabilities:
drop: ["ALL"]
allowPrivilegeEscalation: false
This is CIS Kubernetes Benchmark rule 5.2.6 (allowPrivilegeEscalation: false) and rule 5.2.5 (no privileged containers). User-namespace mapping in containerd 1.7+ further isolates the container's UID 0 from the host's UID 0.
Set readOnlyRootFilesystem: true and mount writable paths as named, size-limited volumes. An attacker who lands code execution inside the container loses the ability to drop a binary on disk, edit /etc/passwd, or persist anything past container restart. Combine with seccomp default profiles to block uncommon syscalls.
Cryptographic signing closes the supply chain gap between the build system and the cluster. The standard stack:
A hardened image platform produces these artifacts as part of the build, not as a retrofit. Minimus ships a CycloneDX and SPDX SBOM signed with Sigstore for every image version, plus SLSA Build L3-aligned provenance.
A hardened image with a hard-coded API token in /app/config/.env is not hardened. Three rules:
GitGuardian's 2024 State of Secrets Sprawl report counted 12.8 million new secrets exposed in public GitHub commits during 2023, up 28% year over year.
The following checklist consolidates the controls above into something a platform team can hand to engineering. Each row maps to a recognized benchmark.
Vulnerability scanning is a detective control. It tells you what is broken after the image is built and, in most pipelines, after it has been pushed to production. Hardening is a preventive control. It changes the input so the scanner has less to find.
The practical limitations of scanning-as-hardening:
A complete container security program runs scanners (Trivy, Grype, or Clair) in CI and in the registry, but treats the scanner output as a backstop for the hardening work, not as the work itself.
Hardening that lives only in a wiki page does not survive contact with a release deadline. Five integration points keep the practice in the pipeline:
FROM ubuntu:22.04 with a minimal or hardened base image pinned to a digest. Run a multi-stage build so build-only tools do not ship in the final image.Per the GitLab 2024 Global DevSecOps Report, 67% of developers said workflow disruption is the top reason they bypass security tooling. A hardening pipeline that adds 30 seconds to a build and ships a signed, minimal image will hold. One that adds 10 minutes and a manual approval will not.
Minimus is a hardened, minimal container image platform. It addresses the most expensive part of a hardening program: producing and maintaining minimal, source-built, signed base images that stay current with upstream CVEs without a team of release engineers behind them.
Each Minimus image is built from upstream source against a hardened toolchain, ships with a cryptographically signed CycloneDX and SPDX SBOM, and is rebuilt continuously so newly disclosed CVEs in included packages are remediated under a 48-hour Service Level Agreement (SLA) for critical findings. Replacing a standard public base image with a Minimus equivalent typically removes 95% or more of the CVE noise on day one—the methodology is documented in how Minimus backs the 95% fewer CVEs claim.
Minimus is image- and supply-chain-centric, not a Cloud-Native Application Protection Platform (CNAPP). It pairs with Falco, Tetragon, or Sysdig for runtime detection, with Kyverno or OPA for admission policy, and with Trivy or Grype for ongoing scanning of any non-Minimus images still in use. For federal teams, Minimus images are available on Iron Bank and align with the DoD DevSecOps Container Hardening Guide; for control mapping see how Minimus supports NIST SP 800-190 container security compliance.
Peer hardened image platforms in the same category include Chainguard Images and Docker Hardened Images (DHI). The category-level argument for source-built minimal images is the same in all three cases. The differences are in image catalog scope, rebuild SLA, compliance positioning (FIPS 140-3, STIG, FedRAMP, Iron Bank), and pricing.
Container hardening is not a single product or a one-time project. It is a build-time discipline backed by admission policy and verified by runtime detection. The base image is the decision that decides everything else.
Standard public images ship with 50 to 60 CVEs, full shells, and root by default, and turn every other control into a triage queue. Minimal, source-built, signed images ship with a fraction of that count, no shell, and a non-root user, and make every layer above them cheaper to operate. Treat hardened image platforms as the prevention layer, run scanners and runtime detection as backstops, and a platform team can keep the program maintained instead of fighting it.
Container hardening is the practice of reducing a container's attack surface by removing unneeded software, dropping Linux capabilities, locking down the filesystem and network, and signing images so they can be verified end-to-end. It applies at the image, runtime, and orchestration layers and aligns with controls in CIS Docker, CIS Kubernetes, NIST SP 800-190, and DISA STIG benchmarks.
Start with a minimal, source-built base image pinned to a digest, such as a distroless image or a hardened image from a platform like Minimus. Run the container as a non-root user, drop all Linux capabilities and add back only what is required, set readOnlyRootFilesystem: true, eliminate embedded secrets, and sign the image and its SBOM with Sigstore cosign. Enforce all of the above at admission with Kyverno or OPA Gatekeeper.
Container hardening is preventive. It changes what goes into an image so that fewer vulnerabilities exist in the first place and so that a breached container has limited capability. Vulnerability scanning is detective. It reports CVEs in an image after the image is built. Scanning catches what hardening missed; it does not replace hardening.
No. Hardened images reduce the input. Runtime tools such as Falco, Tetragon, and Sysdig watch what running containers actually do. A complete program uses hardened images as the prevention layer, admission policy as the gatekeeper, and runtime detection as the backstop for what slips past both.
No. Patching applies a fix to a known vulnerability after it is disclosed. Container hardening reduces the surface area where vulnerabilities can exist in the first place by removing unneeded packages, dropping kernel privileges, and locking the runtime configuration. A hardened image still needs patching when CVEs land in the packages it does include, but it has far fewer packages to patch and a shorter remediation window. Platforms like Minimus close the loop by rebuilding hardened images automatically when upstream patches ship, with a 48-hour SLA for critical CVEs.
The Center for Internet Security (CIS) publishes Docker and Kubernetes benchmarks that define non-root, dropped-capability, and read-only-filesystem controls. NIST Special Publication 800-190 defines container-specific controls including image minimization and least privilege. The DoD DevSecOps Enterprise Container Hardening Guide v1.2 and DISA STIG profiles cover federal hardening requirements; Iron Bank serves as the accredited delivery channel for compliant images. SLSA Build L3 defines the provenance bar for the build system itself. Hardened image platforms such as Minimus align to all four out of the box.
.svg)
.svg)
.svg)
.svg)
