Hardened vs minimal vs distroless container images

In brief

• Minimal: fewer packages, shell and package manager usually still present. Distroless: application and runtime dependencies only, no shell, no package manager. Hardened: configured to a CIS Benchmark or DISA STIG. Near-zero CVE: known CVEs in the remaining packages patched on a published timeline.
• The three labels describe different properties and can apply to the same image; none of them is a patching commitment.
• Choose by what the application needs at runtime, how your team debugs, and which benchmark your auditors name, then ask how known CVEs are fixed and how fast.

Minimal images reduce what is installed, distroless images also remove the shell and package manager, and hardened images add a configuration standard such as a CIS Benchmark or a DISA STIG. None of the three removes the known vulnerabilities in the packages that remain; a near-zero CVE image does that by patching them. The right choice for production depends on what your application needs at runtime, how you debug, and which benchmark your auditors ask about.

What is a minimal container image?

A minimal container image is a standard distribution image with as little installed as the application allows: the slim variants of Debian and Ubuntu, or Alpine. Alpine Linux is built around musl libc and BusyBox (https://alpinelinux.org/about/), which is why Alpine images are small and why software compiled for glibc can behave differently on them. A minimal image still has a package manager and usually a shell, so it is easy to extend and debug, and it still carries whatever CVEs its remaining packages carry.

What is a distroless image?

A distroless image contains only the application and its runtime dependencies. In the words of the project that popularized the term, distroless images "do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution" (https://github.com/GoogleContainerTools/distroless). Removing those tools reduces image size and attack surface and leaves an attacker who lands in the container with little to work with. The trade-off is operational: you cannot exec into the container and run a shell, and you cannot apt or apk install anything inside it.

What is a hardened container image?

A hardened container image is secured by removing unneeded components and applying a security configuration standard such as the CIS Benchmarks (https://www.cisecurity.org/cis-benchmarks) or a DISA STIG (https://csrc.nist.gov/glossary/term/security_technical_implementation_guide). Hardening covers configuration: non-root users, dropped capabilities, file permissions, disabled services. A hardened image can also be minimal or distroless; the terms describe different properties, not competing products. What are hardened container images?

None of the three removes known CVEs on its own

Removing a package removes the CVEs that lived in it, so a smaller image usually scans cleaner than a full one. But the packages that remain, such as the C library, OpenSSL and the language runtime, keep their CVEs until someone patches or backports a fix and rebuilds the image. That patching step is what makes a near-zero CVE image a fourth category rather than a synonym. What is a near-zero CVE image?

Side by side

Choosing for production

Choose by the questions your team and your auditors will ask. If the application needs a shell, scripts or runtime package installs, a hardened full image on the distribution you already run is the lowest-risk move. If the application is a static binary or a single runtime with no operational dependencies, a distroless variant removes the most attack surface. If auditors ask about a benchmark, the image must be hardened to that benchmark whatever its size. And in every case, ask the vendor or your platform team how known CVEs in the remaining packages get fixed and how fast; that question is independent of the three labels.

Debugging a distroless container

In Kubernetes, kubectl debug attaches an ephemeral debug container to a running pod, so you can inspect processes and files without adding a shell to the image (https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/). Outside Kubernetes, run a second container that shares the first container's process namespace and mounts its filesystem. Both approaches keep the production image free of tools while giving engineers a shell when they need one.

Why switching between Alpine and a glibc distribution can break an application

Alpine uses musl libc and most other distributions use glibc, and the two implement the C standard library differently (https://musl.libc.org/about.html). Software compiled against one can fail or behave differently on the other, with known differences in DNS resolution, locale handling and performance. This is the reason a base image change between distribution families needs a full rebuild and test pass even when the application code is unchanged, and the reason drop-in replacements on the same distribution carry less risk.

Where RapidFort Curated Images fit

RapidFort Curated Images are available as full images and as distroless images, with up to 99.9% CVE elimination across both. They are built on all major LTS releases of Ubuntu, Debian and Red Hat, which use glibc, plus Alpine, which uses musl, so teams keep the distribution they already run. The images are hardened against their appropriate STIG or CIS Benchmark, when available, and RapidFort engineers manually patch and rebuild them, so every CVE in the remaining packages for which a patch is available is eliminated rather than carried. They are pin-for-pin compatible with no re-baselining: the same distributions and tags, with environment variables and paths unchanged.

Frequently asked questions

Is a distroless image automatically secure?

No. Removing the shell and package manager reduces the attack surface and limits what an attacker can do inside the container, but the runtime dependencies that remain keep their known vulnerabilities until they are patched and the image is rebuilt.

Can a hardened image also be distroless?

Yes. Hardened describes configuration against a benchmark; distroless describes what is left inside. An image can be hardened to a CIS Benchmark and ship without a shell or package manager.

Does a smaller image always mean fewer CVEs?

Usually fewer, not zero. Every removed package removes its CVEs, so smaller images scan cleaner. The CVE count that remains depends on the versions of the packages still inside and whether they have been patched, not on size alone.

How do I add a package to a distroless image?

You do not add it inside the running container, because there is no package manager. You add it at build time, in a multi-stage build that copies the needed files from a full image into the distroless one, and then rebuild.

Should I pick Alpine or Debian for a secure base?

Pick the distribution your application and its dependencies are already tested on. Alpine is smaller and uses musl; Debian and Ubuntu use glibc and have long-term support releases with 5 years of security maintenance (https://www.debian.org/lts/, https://ubuntu.com/about/release-cycle). Security comes from how the image is patched and configured, not from which distribution it starts on.