Where Container Security Actually Breaks Down in Practice

Image scanning catches known CVEs in the packages baked into your image at build time. It says nothing about what the container does after it starts: what it can access on the host, what privileges it runs with, whether it can reach the internet when it has no legitimate reason to.

A perfectly clean scan result can still run as root with a mounted host socket, which is a runtime problem scanning was never designed to catch in the first place. Treat scanning as necessary and clearly insufficient on its own.

A hardened container needs more than a clean scan:

• Image scanning at build time, which catches known vulnerabilities in the packages baked into the image.
• A current, deliberately chosen base image instead of whatever tag was convenient when the image was first built.
• Runtime protection that watches for unexpected process execution, unusual network connections and file access outside expected paths.
• A non-root default user, with any exception documented and reviewed.
• A rebuild process fast enough to meet your patch deadline when the fix means rebuilding an image.

Most vulnerabilities don't come from application code, they come from the base image and its accumulated layers, often pulled from whatever tag was convenient the day someone wrote the Dockerfile and never revisited since. Teams running a dozen services frequently end up with a dozen slightly different base images, each accumulating its own patch lag on its own schedule.

Standardizing on a small number of actively maintained base images, and rebuilding on a schedule rather than only when a scan complains, closes most of this gap on its own without any new tooling.

A simple inventory, which base image and which tag each service actually runs, takes an afternoon to build and immediately surfaces the outliers: the one service still pinned to a tag from two years ago because nobody wanted to risk breaking it during a migration. That inventory is worth repeating quarterly, since sprawl reaccumulates quietly every time a new service gets added without anyone checking what the rest of the fleet is standardized on.

Runtime protection watches what a running container actually does: unexpected process execution, unusual network connections, file access outside its expected paths, the behaviors that indicate a container has been compromised after the fact rather than shipped with a known flaw from the start.

This is a genuinely different capability from scanning, not a more thorough version of it, and skipping it means an exploit of an unknown, unscanned vulnerability runs undetected until it causes damage visible somewhere else in the system.

CISA's directive to federal agencies sets remediation at fifteen calendar days for a critical, internet-facing vulnerability¹, and for a containerized service that clock doesn't stop at "we know about the fix," it stops at "the rebuilt image is actually deployed."

If your image build and deploy pipeline takes days on its own, patching under pressure means that pipeline, not the patch itself, is your real bottleneck. Measuring how long a rebuild-and-redeploy actually takes, before you're under pressure to do one, tells you where that SLA is genuinely at risk.

A vulnerability management platform in this category, such as Tenable, extends image scanning into a continuously updated view of what's exposed across every image you're running, not just a one-time check at build time. An endpoint or cloud workload protection platform in this category, such as CrowdStrike, covers the runtime side, watching container behavior for the compromise signals a static scan can't see.

Treat them as covering different halves of the problem, not as interchangeable options you'd pick one of. A stack with only scanning is exposed at runtime; a stack with only runtime protection is exposed to known issues nobody ever checked for.

A base image pulled from a public registry carries whatever its maintainer shipped, including dependencies you never explicitly chose and have no direct visibility into. Before adopting one, check who maintains it, how recently it was last updated, and whether it's built from a minimal base rather than a full general-purpose distribution carrying tools you'll never use.

Pin to a specific digest rather than a mutable tag once you've vetted an image, so a maintainer's later change to that tag doesn't silently swap in different content than what you actually reviewed. A tag like latest, or even a version tag, can point to different content over time in a way a digest cannot.