Hardening Containers Without Slowing Down Builds

Every package in your base image is something that can have a vulnerability, whether or not your application ever uses it. A minimal or distroless base image, containing only what your application actually needs to run, shrinks that surface before you've written a single hardening rule.

This is also the cheapest step to adopt, since it's usually a one-line change to your Dockerfile's base image, not a new process the team has to learn.

A container running as root, combined with a container escape vulnerability, hands an attacker root on the host. Set a non-root user in the image itself rather than relying on runtime configuration to catch it, since a forgotten runtime flag is a common way this protection quietly disappears.

Test that your application actually works as a non-root user before rolling this out broadly, since file permission issues from a root-only default are the most common reason teams roll this back.

Roll it out service by service rather than across every image in one change. A permission failure in one low-traffic internal service is a quick fix; the same failure discovered simultaneously across every production service at once is an incident.

A clean scan result today says nothing about next week, when a new CVE gets disclosed against a package sitting in an image nobody's rebuilt. Federal guidance treats a critical, internet-facing vulnerability as needing remediation within 15 days, and a known exploited one within as little as 14, and that clock starts the moment the CVE is public, not whenever your team next happens to rebuild the image¹.

A scheduled rebuild cadence, even something as simple as a weekly base image refresh, catches most of this automatically, without anyone having to notice the new CVE first.

A Dockerfile that looks clean can still produce a vulnerable image, because the vulnerabilities live in the packages that get installed, not in the instructions that install them. Scan the built image itself, ideally in CI before it ever reaches a registry, so a vulnerable image never gets the chance to be deployed in the first place.

Set the scan to fail the build on critical findings, not just report them. A scan result nobody's required to act on tends to get ignored the same way any unenforced warning does.

A hardened image can still run with a permissive runtime configuration: mounted host directories it doesn't need, capabilities it never uses, network access wider than necessary. Runtime configuration is a separate control surface from the image itself, and hardening one without the other leaves half the job undone.

Review runtime configuration with the same checklist mindset as the image build: least privilege by default, with any broader access requiring a specific, documented reason rather than being the default nobody questioned.

This split is exactly why a clean scan result can create false confidence. A scanner checking the image tells you nothing about how permissively that image is actually being run in production, which is why both checklists need to exist side by side, not as a single combined pass.

A short written checklist for each, reviewed whenever a new service is added, does more for actual security over time than a longer list nobody consistently applies to every service.

Run this short checklist on every image:

1. Start from a minimal or distroless base image that contains only what the application needs to run.
2. Set a non-root user in the image itself, and test that the application works as that user.
3. Rebuild images on a regular schedule, weekly is a reasonable start, so newly disclosed vulnerabilities get caught.
4. Scan the built image in CI, and fail the build on critical findings before it reaches a registry.
5. Review runtime configuration for unneeded mounted host directories, unused capabilities, and network access wider than necessary.