What Is Containerization? Security Risks and Controls

A developer pushes an image to a public registry. It runs a single web service, built six months ago on a base image nobody has updated since. Inside it: an AWS access key baked into a layer, a package manager full of known CVEs, and a process running as root. The container starts in two hundred milliseconds, scales to forty replicas, and serves production traffic by lunch. None of that is exotic. It is how most containerized workloads ship, and it is why containers show up in so many cloud incident reports: the speed that makes them useful also makes a bad image spread fast.

Containerization is operating-system-level virtualization that packages an application together with everything it needs to run into a single portable unit. This guide covers what that unit actually is, how containers differ from virtual machines, where the security model leaks, and the concrete controls that close those gaps. NIST published the authoritative reference for this in SP 800-190, the *Application Container Security Guide*, and its five-component risk model is the spine of the security section below. It is written for the people who have to defend these workloads: SOC analysts triaging container alerts, DFIR responders pulling apart a compromised pod, and detection engineers who need to know what normal looks like before they can flag what is not.

What is containerization?

Containerization is the practice of bundling an application, its runtime, its libraries, its configuration, and its system dependencies into one executable package called an image, then running that image as an isolated process on a shared host kernel. The image is the build-time artifact: a read-only, layered filesystem plus the metadata that says how to start it. A container is the runtime instance of that image, a live process with its own view of the filesystem, network, and process tree. One image can spawn many identical containers. That image-to-container relationship is the thing to keep straight, because almost every container risk is either baked into the image at build time or introduced to the container at runtime, and the two have different owners and different fixes.

The isolation comes from the Linux kernel, not from a separate operating system. Namespaces give each container its own view of process IDs, network interfaces, mounts, and users, so it looks like it has the machine to itself. Control groups (cgroups) cap how much CPU, memory, and I/O it can consume. The container sees a private world; the kernel underneath is shared with every other container on the host. That shared kernel is the entire security story in one sentence: it is what makes containers light and fast, and it is what makes a kernel escape catastrophic.

The tooling stack has a few names worth knowing. Docker is the build-and-run toolchain most people start with, and the format it popularized became the OCI image standard. Underneath modern Docker and Kubernetes sits containerd, the container runtime that actually pulls images and manages container lifecycles; it was donated to the CNCF by Docker and graduated as a CNCF project in 2019, and it calls runc to do the low-level work of spawning the isolated process. When you run hundreds of containers across many hosts, you need something to schedule, restart, scale, and network them, which is orchestration. Kubernetes is the dominant orchestrator, and it introduces its own control plane, its own API, and its own attack surface on top of the containers it manages.

Containers vs virtual machines

The cleanest way to understand a container is against the thing it replaced for most workloads: the virtual machine. A VM virtualizes hardware. A hypervisor presents virtual CPUs, memory, and devices, and each VM runs a full guest operating system with its own kernel on top of that virtual hardware. A container virtualizes the operating system. There is no guest kernel and no hypervisor in the path; the container is a process on the host kernel, fenced off by namespaces and cgroups.

That single difference drives every trade-off. A VM carries a whole OS, so it is measured in gigabytes and boots in tens of seconds. A container carries only the application and its dependencies, so it is measured in megabytes and starts in milliseconds. You can pack far more containers onto a host than VMs, which is why containerization underpins microservices and elastic cloud scaling. The cost is isolation. A VM's guest kernel is a hard boundary; breaking out of a VM means defeating the hypervisor, which is a high bar. A container shares the host kernel with its neighbors, so the boundary is only as strong as the kernel's isolation primitives and the configuration around them. A container escape lands the attacker on the host, alongside every other container the host runs.

Neither is strictly better. They are different points on the same isolation-versus-density curve, and real environments run both: VMs as the hardware boundary, often hosting the container runtime, and containers as the application boundary inside them.

The last row is the one defenders underrate. Patching a VM fleet means patching each guest OS. Patching a container fleet means rebuilding one base image and redeploying. That is faster, but it only works if someone is actually rebuilding. An image built once and run for a year accumulates every CVE disclosed against its packages in that time, frozen in place.

The container security model and where it leaks

Containers are not a security boundary in the way a VM is. They are an isolation mechanism that holds only when the kernel, the image, and the configuration all cooperate. NIST SP 800-190 organizes the risks by the component they live in: image, registry, orchestrator, container, and host OS. That model maps cleanly onto how attacks actually unfold, so it is the structure used here.

Image risks. The image is where most problems are born. Vulnerable software is the common case: a base image pulls in an OS distribution and dozens of packages, any of which can carry a known CVE. Embedded secrets are the dangerous case: developers bake API keys, database passwords, and cloud credentials into image layers, where they sit readable by anyone who pulls the image, because a deleted file in a later layer still exists in the earlier one. Misconfiguration is the quiet case: an image that runs as root, or includes a shell and a package manager it does not need, hands an attacker tools and privilege the workload never required.

Registry risks. Images live in registries, and a registry that allows anonymous push or weak authentication is a supply-chain target. An attacker who can write to a registry can poison an image other teams pull and run, turning one compromised credential into code execution across every workload that trusts that registry. Stale images are the slower risk: a registry full of old tags means teams keep deploying versions whose vulnerabilities were patched long ago in a newer build nobody promoted.

Orchestrator risks. Kubernetes and its peers run with broad privilege over the cluster, so the orchestrator's own access controls matter as much as the containers'. Unbounded administrative access, a service account or dashboard with cluster-admin and no scoping, means one stolen token owns the cluster. Unencrypted or unsegmented traffic between containers lets a foothold in one pod reach every other pod. The Kubernetes control plane and its API server are the highest-value target in a container environment for exactly this reason.

Container (runtime) risks. At runtime the threats are behavioral. A container that suddenly spawns a shell, scans the internal network, mounts the host filesystem, or attempts a kernel syscall it never made in testing is exhibiting the runtime indicators of compromise. The worst case is container escape: abusing a kernel vulnerability, an over-privileged container, or a mounted host path to break out of the namespace and reach the host. A privileged container, or one granted dangerous Linux capabilities, makes escape trivial.

Host OS risks. The host kernel is shared, so a single unpatched kernel vulnerability can be the escape route for every container on the box. The most direct host-level mistake is the exposed Docker socket or API: mounting /var/run/docker.sock into a container, or binding the Docker API to a network port without TLS and authentication, gives anything that reaches it full control of the host's containers, including the ability to start a new privileged container and own the machine.

How to secure containers

The controls follow the risk model. None of them is exotic, and the highest-leverage ones happen at build time, before the workload ever runs.

Start from a minimal, trusted base image. Every package you do not ship is a CVE you cannot inherit. Use slim or distroless base images, pin them to a digest rather than a floating latest tag, and pull only from registries you control or trust. A smaller image is both a smaller attack surface and a faster patch cycle.

Scan images, and scan them again. Run a vulnerability scanner in the build pipeline so a known-bad image fails before it ships, and rescan images in the registry continuously, because a CVE disclosed tomorrow against a package you shipped today does not announce itself. Scan for embedded secrets in the same pass; a credential baked into a layer is an image-build finding, not a runtime one.

Run as non-root, read-only, and least-privilege. Set a non-root user in the image and enforce it at runtime so a compromised process does not start with root. Mount the container filesystem read-only where the workload allows it, so an attacker cannot write a payload or modify binaries. Drop every Linux capability the workload does not need, and never run a container as privileged unless you can articulate exactly why. This is least privilege applied to a process instead of an account.

Confine the kernel surface with seccomp and AppArmor. Because containers share the kernel, narrowing what each container can ask of the kernel shrinks the escape surface directly. A seccomp profile restricts which syscalls a container may make; AppArmor (or SELinux) confines what files and capabilities it can touch. The default profiles block a meaningful share of escape techniques, and a tightened profile blocks more.

Sign images and verify signatures. Registry signing closes the supply-chain gap. Sign images at build time and configure the orchestrator to admit only signed images from trusted publishers, so a poisoned image pushed to the registry cannot be deployed even if the push succeeds. This is the control that turns a compromised registry from a cluster-wide incident into a blocked deployment.

Lock down the orchestrator. In Kubernetes, scope every service account with RBAC to the least it needs and never leave cluster-admin lying around. Apply network policies so pods can reach only the pods they must, turning a single compromised pod into a contained one rather than a pivot point. Protect the API server, rotate credentials, and never expose the dashboard or the Docker socket. Treat the control plane as the crown jewels, because compromising it compromises everything it schedules.

Detect at runtime. Build-time controls cannot catch a zero-day exploited in a running container, so you need runtime detection: behavioral monitoring that flags a container doing something its image never did, an unexpected process, an outbound connection to a strange host, a syscall outside its profile, an attempt to read the host filesystem. This is the container equivalent of EDR, and it is the layer that catches the escape attempt the earlier layers missed.

How container security maps to CWPP and CNAPP

Stitching those controls together by hand across hundreds of images and a live cluster does not scale, which is why the tooling consolidated into two categories worth naming.

A cloud workload protection platform (CWPP) secures the workload itself wherever it runs, including containers: image scanning, configuration and compliance checks, runtime threat detection, and protection that follows the container across VMs, Kubernetes, and serverless. If you are looking for one product category that owns the runtime side of the controls above, CWPP is it.

A cloud-native application protection platform (CNAPP) is the broader umbrella. It folds the CWPP's workload protection together with posture management, identity and entitlement analysis, and the build-pipeline scanning that catches a vulnerable or secret-laden image before it ships. The point of a CNAPP is correlation: a single vulnerable image is a finding, but a vulnerable image that is internet-exposed, runs as root, and holds a credential to a sensitive data store is an incident, and only a platform that sees build, configuration, identity, and runtime together can connect those dots. For defenders, that consolidation is the difference between a thousand disconnected container findings and the handful that actually matter.

The bottom line

Containerization packages an application and its dependencies into an image and runs it as an isolated process on a shared host kernel. That shared kernel is the whole trade-off: it makes containers small, fast, and dense compared to virtual machines, and it makes the isolation boundary weaker, because a container escape reaches the host and every sibling on it. Containers are not a security boundary on their own; they are an isolation mechanism that holds only when the image, the configuration, and the kernel all cooperate.

NIST SP 800-190 lays the risks out by component, image, registry, orchestrator, container, and host OS, and the controls follow the same map: minimal trusted base images, scanning at build and in the registry, non-root and read-only and least-privilege runtime, seccomp and AppArmor to shrink the kernel surface, signed images, locked-down orchestrator RBAC and network policy, and runtime detection for what slips through. CWPP and CNAPP exist to run those controls at scale and correlate the findings. For a defender, the leverage is upstream: most container incidents trace to an image or a configuration decision made before the workload ever ran, which is exactly where they are cheapest to stop.