What to Fix in a Container Image Before It Ships

A container running as root doesn't grant root on the host by default, but it removes a layer of defense if a container escape vulnerability is ever found, and it makes a compromised container more useful to an attacker than it needs to be. Set a non-root user explicitly in the image rather than relying on the base image's default, since defaults change between versions and silently reintroducing root is easy to miss in a routine base image bump.

A vulnerability scan that runs after an image is already in production is a detection mechanism, not a prevention one. Scan at build time and block the pipeline on anything matching a known exploited vulnerability, since those carry the shortest remediation clock of any category: federal guidance gives a 14-day window for a known exploited vulnerability with a CVE assigned in 2021 or later¹, and that clock starts whether or not your pipeline caught it before shipping.

Every package in the base image is something that can carry a vulnerability, whether your application uses it or not. A minimal base image reduces that surface directly, and a short, automated cadence for rebuilding on top of an updated base image means a patched vulnerability upstream actually reaches your running containers instead of sitting unaddressed in an image nobody has rebuilt in months.

A secret added in one layer and removed in a later one is still recoverable from the image history, because layers are cumulative, not a clean overwrite. Use runtime secret injection or a secrets manager instead of copying credentials into the build context at any point, and audit existing images for this specific mistake, since it's one of the most common ways a credential ends up somewhere nobody intended.

A container with no CPU or memory limit can consume enough of a shared host's resources to degrade or crash unrelated containers on the same node, turning what should be an isolated problem into a shared outage. Set explicit limits as a default part of your deployment configuration, not an afterthought added after the first incident where one runaway container took down several others.

A checklist that depends on an engineer remembering to run it manually before a release will eventually be skipped, usually during exactly the rushed release where it mattered most. Wire each of these checks into the build pipeline as a required gate: non-root enforcement, vulnerability scan results, a secret-scanning pass over image layers, and a check for explicit resource limits in the deployment manifest. A gate that blocks the pipeline is a check that actually runs every time; a habit is a check that runs most of the time, and the gap between those two is where incidents live.

The first weeks after turning these checks into hard gates usually produce a wave of blocked builds, as existing images catch up to the new bar. Resist the temptation to add a blanket exception list to get releases flowing again; instead, fix the specific images that fail and let the exception list, if you need one at all, stay short, named, and reviewed on a schedule so it doesn't quietly become the new default path around the gate you just built.