Hardening Containers: The Checks That Actually Stop Real Attacks

This is the single highest-value fix on most hardening lists, and it's often skipped because the base image defaults to root and nobody changes it. A process running as root inside a container that escapes its isolation has root on the host, full stop.

Set a non-root user explicitly in your Dockerfile and verify it in CI, not just at build time on someone's laptop. This is a small change with an outsized effect on what an attacker can do if they get a foothold.

Base images accumulate known vulnerabilities over time as new CVEs get disclosed against the packages inside them. Federal patch guidance treats closing a known exploited vulnerability as a tight-clock obligation, and that same clock is a reasonable bar to hold your own image scanning process to, even without a legal requirement to do so¹.

Scan at build time and block the pipeline on anything critical, not just at deploy time when it's already too late to catch it before the image reaches a registry other services might pull from.

A debugging shell, a package manager, or a compiler left in a production image isn't a functionality most services need, and each one is a tool an attacker can use if they get in. Build from a minimal base image and strip anything the running application doesn't actually need at runtime.

This is the difference between a container that's merely locked from the outside and one that has nothing useful inside it even if someone gets past the lock.

Mounting the container's filesystem as read-only, with explicit writable volumes only where the application genuinely needs to write, blocks a whole category of attack that persists by writing a malicious file to disk. It's a cheap change that most teams skip simply because it's not the first thing anyone thinks of.

In practice, most container compromises come from a known vulnerability in a dependency that was never patched, combined with a process running as root that let the attacker escalate. Fix those two things first, root and patch cadence, before spending time on more exotic hardening steps further down the checklist.

For example, a service image is built on a default base that runs as root and includes a shell, and one dependency inside it has a known exploited vulnerability that was never patched. An attacker who exploits it lands as root with tools already available. Two changes break that chain: switch to a non-root user, and patch or block the image at build time. Neither needs new tooling, only a Dockerfile edit and a CI rule. Do these before spending time on more exotic items further down a long checklist.

Work through these checks in priority order:

1. Set a non-root user explicitly in the Dockerfile and verify it in CI, not just on a laptop.
2. Scan images at build time and block the pipeline on anything critical, then rescan running images on a regular schedule.
3. Build from a minimal base image without a debugging shell, package manager, or compiler.
4. Mount the filesystem read-only, with writable volumes only where the application genuinely needs to write.
5. Apply the same checks to third-party and vendor images running in your deployment.

A hardening pass that happens once, when a security review is scheduled, and never again is a snapshot that starts going stale the day it's finished. New base image versions get published, new CVEs get disclosed against packages you're already running, and a policy that isn't enforced in CI quietly drifts as new services get added without it.

Bake the checks that matter most, non-root, scanning, read-only filesystem, into your CI pipeline as blocking checks, not a checklist someone runs by hand before a compliance deadline. That's what keeps hardening current instead of a one-time exercise.

It's easy to harden the images your own team builds and forget that a base image pulled from a public registry, or a sidecar container from a vendor, carries the same risk if it's running as root or hasn't been scanned recently.

Apply your hardening standards to every image in your deployment, not just the ones your team wrote. A vendor's container is still running on your infrastructure with the same access to your network as anything you built yourself, so pull it into your regular scanning and policy checks rather than treating it as someone else's responsibility to secure just because your team didn't write the original code.