Container Security: From Image Risk to Runtime Exposure

An image passes its vulnerability scan with no critical findings and ships. In production the pod runs as root, mounts the host’s container runtime socket, and carries a service account token with broad cluster rights. The scan result was accurate. It simply described the wrong layer.

Container security programs often start and stop at the image because images are easy to scan and the results are easy to report. NIST’s application container security guide, SP 800-190, frames the problem more completely, across five areas: images, registries, orchestrators, containers and the host operating system. Real exposure usually appears where those areas meet, and image risk is only the first link in that chain.

Image risk: necessary, and easy to over-read

Scanning finds known vulnerabilities in packages, outdated base images, embedded secrets and malware. It cannot tell you whether a flaw is reachable, whether the container is exposed to the internet, or what privileges it will run with. A critical finding in a batch job with no network access and no credentials is a different risk from a medium finding in a public-facing service running as a privileged container.

Ranking image findings by runtime context turns a thousand-line report into a short list. Useful context includes whether the workload is internet-facing, what identity it carries, what it can reach on the network, and whether the vulnerable component is loaded at all.

Provenance matters as much as content. Where did the base image come from, who built this one, and can the cluster verify that? Pulling unsigned images from public registries into production is a supply chain decision, usually made by default instead of on purpose.

Runtime exposure: the configuration decides the blast radius

A container shares the host’s kernel. It is isolated by namespaces and control groups, which are strong mechanisms but not the hard boundary a separate virtual machine provides. Configuration choices decide how much of that isolation remains.

The kernel is shared, and the runtime is attack surface

The runc runtime, used beneath most container platforms, had a set of vulnerabilities disclosed under the name Leaky Vessels. One allowed a malicious image or build step to reach the host filesystem by exploiting how the runtime handled a working directory setting. No scan of the image’s packages would find that. What changed the outcome was patching the runtime and the node, which is an operations discipline and not an image-scanning one.

Treat that as a general rule. The container runtime, the node operating system and the orchestrator are part of the attack surface and need the same patch and vulnerability handling as the applications on top. Security teams that scope container security to images leave this to platform teams, who may not know it is theirs.

From one compromised container to the cloud account

The attack path worth modeling runs like this. An application flaw gives an attacker code execution in a container. The container’s identity, the service account token or the node’s cloud role, lets the attacker query the orchestrator or cloud APIs. From there the question is what that identity can read, create or assume. In many environments the answer is more than anyone intended.

This is why container security belongs inside cloud security, not alongside it. Each control above is an identity or configuration decision, and the exposure it creates only becomes clear when the container is seen as one step in a path to something valuable.

Detection at runtime

Runtime detection earns its place because configuration and patching will always leave gaps. Signals that carry weight:

• A shell started inside a container that never normally runs one.

• Unexpected outbound connections, especially to new destinations or to the metadata service.

• A process reading the service account token path or other credential locations, then calling the orchestrator API.

• New privileged pods or host-mounting workloads appearing in a cluster that should block them.

• Binaries written to and executed from a running container’s filesystem.

Orchestrator audit logs complete the picture. They show who created what, which roles were bound, and which API calls a stolen token made. Without them, an incident team can see a container behaved oddly and cannot tell what it did next.

Where to start

Order matters more than coverage. Start by enforcing a baseline at admission, so the cluster refuses privileged, host-mounting or unsigned workloads. That removes whole classes of risk with one control and is more reliable than finding them afterwards. Then fix identity: per-workload identities for the cluster and the cloud, with no inherited node role. Then rank image findings by runtime exposure. Add runtime detection and keep the platform patched.

A simple test for leadership: pick your most exposed containerized service and trace what an attacker with code execution inside it could reach, in the cluster and in the cloud account. If nobody can draw that path, the program is measuring images and not exposure.

Teams that run this exercise often find the findings sit between platform, security and cloud teams, with no single owner for the configuration decisions that matter most. Evaluating cloud control and configuration risk across that boundary, and not image by image, is the more useful place to start.

Sources

• NIST. Special Publication 800-190, Application Container Security Guide

• Kubernetes Documentation. Pod Security Standards

• AWS Documentation. Configure the Instance Metadata Service options

• runc project. Security advisory for the container breakout reported as Leaky Vessels