Container Security: What Actually Stops an Attacker

Every vulnerability in a base image ships into every container built on top of it, which is why minimal base images, ones stripped of package managers, shells, and anything not strictly required at runtime, matter more than almost any other single hardening decision. A smaller image isn't just faster to pull, it's a smaller attack surface: there's less installed software to carry a vulnerability, and less available to an attacker who does get in, like a shell to move around with. Pin base image versions explicitly and rebuild on a schedule rather than only when a vulnerability is discovered.

Image scanning catches known vulnerabilities in the final artifact, but it doesn't catch a compromised dependency pulled in during the build, or a build step that has more access than it needs, to source code, to signing keys, to the registry it pushes to. Treat the build pipeline itself as a security boundary: scope its credentials to exactly what that specific build needs, verify dependencies against a lockfile rather than pulling the latest version at build time, and log every image that gets pushed with enough detail to trace it back to the exact commit and pipeline run that produced it.

A perfectly scanned, vulnerability free image can still run with a misconfiguration that hands an attacker far more than intended: running as root inside the container, mounting the host's Docker socket, or granting capabilities the workload never actually uses. None of these show up in an image scan, because they're properties of how the container runs, not what's inside it. Default to running as a non root user, drop all capabilities and add back only what's specifically needed, and treat any container that needs privileged mode as a special case requiring explicit justification, not a default convenience.

Check these runtime settings, which an image scan never sees:

• Whether the container runs as root inside the container when the workload doesn't need that.
• Whether the host's Docker socket is mounted into the container, which hands an attacker far more than intended.
• Whether the container is granted capabilities the workload never actually uses.
• Whether the deployment manifest mounts the host filesystem or requests privileged mode.
• Whether runtime detection exists to catch unexpected processes, network connections or file system changes.

Container vulnerabilities don't wait for your next scheduled rebuild, and the gap between a vulnerability becoming known and being actively exploited keeps shrinking. Federal guidance on known exploited vulnerabilities is a useful benchmark: those assigned a CVE since 2021 carry a fourteen day remediation clock, while older, pre-2021 known exploited vulnerabilities get a much longer window of up to 180 days¹. Any container running in production with a known exploited vulnerability past that window is running on borrowed time, and automated rebuild pipelines triggered by new CVE disclosures close that gap far more reliably than a manual, periodic rebuild schedule.

Runtime detection, catching unexpected process execution, unexpected network connections, or file system changes inside a running container, is what catches the compromise that got past every earlier layer. This is where platforms like CrowdStrike and Tenable diverge in focus: CrowdStrike leans toward real time runtime detection and response, Tenable leans toward continuous vulnerability and configuration visibility across the fleet. Neither replaces the earlier layers, a minimal image, a scoped build pipeline, hardened runtime configuration, they catch what gets through despite those layers being in place.

It's common for a team to spend real effort minimizing a base image and locking down the build pipeline, then deploy that same hardened image with a manifest that mounts the host filesystem, requests privileged mode out of habit, or skips setting a non root user because the original manifest never had one. All of that image level work is wasted the moment the deployment configuration hands an attacker a path around it. Review the deployment manifest itself as part of the same hardening pass, not as a separate, later concern owned by a different team: the two layers only protect anything when they're both closed at once.