Container security is the set of practices and tools that protect containerized applications across four distinct layers: the base image and its dependencies, the container runtime, the orchestration platform (typically Kubernetes), and the underlying host operating system. Unlike traditional server security, a container's attack surface is assembled at build time from a base image, application dependencies, and configuration — often pulled from public registries — then run with kernel-level access shared across every other container on the same host. Sysdig's 2023 Cloud-Native Security and Usage Report found that 87% of container images running in production contain at least one critical or high-severity vulnerability, and 10% of images run with full root privileges by default. A single misconfigured container escape, like the 2019 runc vulnerability (CVE-2019-5736) that let a malicious container overwrite the host runtime binary, can compromise every workload on that node. Container security exists to catch these issues before, during, and after deployment — whether that's a discipline your team builds in-house or a container security platform you buy to cover all four layers at once.
What Are the Four Layers of Container Security?
Container security spans image security, runtime security, orchestration security, and host security — and a gap in any one layer undermines the other three. Image security covers what's baked into the container: the base OS, installed packages, and application dependencies, scanned for known CVEs before the image ever ships. Runtime security monitors what a container actually does once it's running — unexpected process execution, network connections, or file system writes that deviate from its expected behavior. Orchestration security locks down the Kubernetes control plane itself: RBAC policies, container network security policies that restrict pod-to-pod traffic, a pod's securityContext (commonly called container security context settings — the field that actually enforces non-root users, dropped capabilities, and read-only filesystems at the container level), admission controllers, and the API server that, if exposed, gives an attacker control over every workload in the cluster. Host security hardens the node's operating system and container runtime (Docker, containerd, CRI-O) since every container on that host shares its kernel — a single kernel exploit breaks the isolation model entirely. The 2021 Kinsing malware campaign, which specifically targeted misconfigured Docker APIs exposed to the internet, is a case study in what happens when host-level exposure gets skipped.
Why Do 87% of Production Container Images Have Critical Vulnerabilities?
Because most images inherit vulnerabilities from base images and package managers faster than teams patch them, and few pipelines block a build on scan results. Sysdig's 2023 data showing 87% of production images carrying a critical or high vulnerability lines up with Red Hat's 2023 State of Kubernetes Security survey, which found 67% of organizations had delayed application deployment due to security concerns, yet still shipped known-vulnerable images because a full base-image update risked breaking application compatibility. A common pattern: a team builds on node:18 or python:3.9-slim, which bundles OS packages (glibc, openssl, zlib) that accumulate CVEs over the image's lifetime, but the application team never rebuilds unless a functional change forces it. Distroless and minimal base images cut this exposure by removing shells, package managers, and unused libraries entirely — Google's own distroless images typically ship with 50-95% fewer packages than their Debian-based equivalents, which directly shrinks the CVE-matchable surface. This is the core of the container security vulnerabilities problem: it isn't that teams don't scan, it's that scanning without a rebuild-and-patch pipeline just produces a longer list of known issues nobody acts on.
What Happened in the 2019 runc Container Escape (CVE-2019-5736)?
CVE-2019-5736 was a container escape vulnerability in runc, the low-level runtime underlying Docker, containerd, and other CRI-O-based systems, that let a malicious container overwrite the runc binary on the host and gain root code execution outside the container. Disclosed in February 2019 with a CVSS score of 8.6, the flaw required an attacker to get a victim to run a specially crafted image or attach into an attacker-controlled container — a realistic scenario in multi-tenant CI/CD systems and shared Kubernetes clusters where images from less-trusted sources run alongside sensitive workloads. Because runc sits underneath nearly every major container platform, the vulnerability affected Docker, Kubernetes, and cloud container services simultaneously, forcing a coordinated patch rollout across the ecosystem within days of disclosure. It remains the reference example for why the host and runtime layer — not just image contents — has to be part of any container security program.
Is Kubernetes Itself a Major Source of Container Security Incidents?
Yes — the Red Hat 2023 State of Kubernetes Security survey found that 38% of respondents said a misconfiguration led to a security incident in their Kubernetes environment in the preceding twelve months, more than any other cause including vulnerabilities or runtime attacks. Common culprits include overly permissive RBAC bindings (cluster-admin granted to service accounts that only need namespace-level access), missing network policies that let every pod talk to every other pod by default, and exposed kubelet or API server endpoints with no authentication. The Tesla Kubernetes cryptomining incident in 2018, where an unauthenticated Kubernetes dashboard gave attackers direct access to the cluster and its cloud credentials, remains one of the most cited real-world examples of an orchestration-layer misconfiguration turning into a full cloud account compromise. Tools like OPA Gatekeeper and Kyverno exist specifically to enforce policy at admission time so a misconfigured manifest never reaches a running cluster in the first place. A kubernetes container security scanner that only checks image contents misses this whole layer — cluster misconfiguration is a separate finding category from a vulnerable package, and a program that only runs the former is blind to the more common root cause. The same layering applies on managed platforms: container security on AWS still needs image scanning and runtime controls on top of whatever EKS or ECS enforces by default, since the shared responsibility model stops at the infrastructure layer, not the workload.
How Is Container Security Different from Traditional Server Security?
Container security differs from traditional server security because containers are ephemeral, immutable, and share a kernel — three properties that don't exist on a long-lived virtual machine. A traditional server gets patched in place and monitored for drift over months or years; a container image is typically rebuilt and redeployed within days (Sysdig's data puts the median container lifespan under five minutes in some Kubernetes environments, versus weeks or months for a VM), which means security has to shift left into the build pipeline rather than relying on runtime patching alone. Containers also share the host kernel instead of running their own, so isolation depends on Linux namespaces, cgroups, and seccomp profiles rather than a hardware-level hypervisor boundary — a weaker isolation guarantee that makes host and runtime hardening non-optional. Finally, because container images are built from layered, often public base images, supply chain provenance (where did this layer come from, and has it been tampered with) becomes a first-class security question in a way it never was for a hand-provisioned server.
How Safeguard Helps
Safeguard scans every container image layer for known vulnerabilities and runs reachability analysis to determine which flagged CVEs sit on code paths your application actually executes, cutting the average 87%-vulnerable-image problem down to a short list of exploitable findings. It's delivered as a SaaS container security platform, so a container security assessment against your registry starts within minutes rather than after an appliance install. In any container security tools comparison against Snyk container security or a standalone scanner, the differentiator is reachability: the four layers above are table stakes, and what separates a usable backlog from a 3,000-row export is whether the tool tells you which findings are actually reachable. Griffin AI, Safeguard's reasoning engine, correlates image scan results with your Kubernetes manifests and RBAC configuration to catch orchestration-layer misconfigurations — like the overly permissive bindings behind 38% of reported Kubernetes incidents — before they reach a running cluster. Safeguard generates a CycloneDX or SPDX SBOM for every container image automatically and can ingest SBOMs from base image vendors and registries to extend visibility past your own Dockerfiles. When a fix is available, whether it's a base image bump or a patched package version, Safeguard opens an auto-fix pull request tested against your build so the path from detection to a merged, redeployed image doesn't stall in a backlog.