In January 2024, researchers disclosed "Leaky Vessels," a set of runc flaws headlined by CVE-2024-21626 — an internal file-descriptor leak in versions up to and including runc 1.1.11 that let an attacker set a container's working directory to /proc/self/fd/N, landing a subsequent process in the host's filesystem namespace. A container that could run runc exec or runc run under the right conditions could break out to the host entirely. runc, the low-level runtime underneath Docker, containerd, and most Kubernetes nodes, patched the flaw in version 1.1.12, but the disclosure was a reminder that container security fails at the layers most teams pay the least attention to: what's actually in the image, what the runtime is allowed to do, and what the network lets it reach once it's running. Vulnerability scanning your base image is necessary but not sufficient — an unpatched runtime, a root-by-default container, and a flat pod network turn one escape into a lateral-movement incident. This post covers five best practices across the three pillars that actually stop that chain: image provenance, least-privilege runtime configuration, and network segmentation.
Why isn't scanning your base image enough?
Scanning tells you what CVEs are present in an image at build time; it says nothing about whether the image was tampered with before it reached your registry, or whether the runtime executing it is itself vulnerable. CVE-2024-21626 illustrates the gap directly: a perfectly clean, zero-CVE application image running on an unpatched runc still handed attackers a host escape, because the vulnerability lived in the container runtime, not the image contents. Image provenance — verifiable evidence of who built an artifact, from what source, using what pipeline — closes a different gap: it stops a compromised build step or a tampered registry push from ever reaching production, regardless of what a point-in-time CVE scan found. SLSA (Supply-chain Levels for Software Artifacts) and Sigstore's cosign tooling are the de facto public standards here: SLSA defines provenance requirements by level, and cosign lets you sign and verify container images and attach that signature to the OCI manifest so a mismatch is detectable before deployment.
What does "least privilege" actually mean for a running container?
Least privilege for containers means the runtime process holds the smallest set of Linux capabilities, filesystem write access, and user permissions it needs to do its job — nothing inherited by default. Concretely, that's four settings: run as a named non-root user (the Dockerfile USER directive, or runAsNonRoot: true in a Kubernetes securityContext); drop all Linux capabilities and add back only the specific ones required (--cap-drop=ALL at the Docker level, or capabilities: {drop: ["ALL"]} in a pod spec) rather than running with the default capability set; mount the root filesystem read-only (readOnlyRootFilesystem: true) so a compromised process can't write a second-stage payload to disk; and apply a seccomp or AppArmor profile to block syscalls the application never legitimately calls. Each of these directly narrows the blast radius of a runtime escape like CVE-2024-21626 — a non-root, capability-dropped, read-only container gives an attacker who lands a shell far less to work with than a root, full-capability, writable one, even before the runtime patch is applied.
Does Kubernetes segment pod-to-pod traffic by default?
No — by default, Kubernetes permits all ingress and egress traffic between every pod in a cluster, regardless of namespace, unless a NetworkPolicy says otherwise. The upstream Kubernetes documentation states this explicitly: if no NetworkPolicy objects exist in a namespace, all traffic is allowed to and from pods in it, and a policy only starts restricting a pod's traffic once at least one policy selects that pod — at which point it becomes default-deny for the traffic types the policy covers (ingress, egress, or both). That means network segmentation is not a hardening extra layered on top of a secure default; the default is flat and open, and every cluster needs explicit default-deny policies to get any segmentation at all. This matters directly for escape and lateral-movement scenarios: a compromised pod with no NetworkPolicy applied can reach the Kubernetes API server, adjacent workloads, and internal services with no additional exploitation required, simply because nothing was denying it.
Which network-segmentation controls should you apply first?
Start with a default-deny-all NetworkPolicy in every namespace, then add narrow allow rules for the specific pod-to-pod paths your application actually needs — this inverts the platform default from open to closed. A minimal default-deny policy selects all pods in a namespace and specifies no allowed ingress or egress rules, which under Kubernetes' policy semantics blocks everything until an explicit allow rule is added elsewhere. From there, add policies scoped by label selector (only the frontend tier can reach backend on port 8080) rather than by IP range, since pod IPs are ephemeral. Native Kubernetes NetworkPolicy objects require a CNI plugin that enforces them — Calico, Cilium, and others all implement the API — so verify your CNI actually enforces policies before relying on them; some CNI plugins historically shipped without policy enforcement, which silently no-ops every policy you write. Cilium additionally supports L7-aware policies (restricting by HTTP method or path, not just port), useful for segmenting service-mesh traffic more precisely than L3/L4 alone.
How does image provenance connect back to runtime and network controls?
Provenance controls decide what's allowed to run at all, while runtime and network controls limit what happens once it's running — they're sequential layers, not substitutes for each other. An admission-time check that verifies an image carries a valid SLSA provenance attestation and a signed SBOM stops a tampered or unsigned image from ever being scheduled, closing the door CVE-2024-21626-style scenarios can walk through when a build pipeline itself is compromised. Safeguard's own attestation pipeline generates SLSA provenance, SBOM, and vulnerability-scan attestations for every build, signs them via Sigstore, and enforces verification at Kubernetes pod admission against a configurable minimum SLSA level (default Level 3) — so an image without valid provenance is denied before it ever reaches a node, independent of whatever least-privilege or network settings apply afterward. Safeguard's runtime rule engine separately maps detected container-escape techniques — namespace breakout, privileged mounts, host-root access — to the MITRE ATT&CK T1611 technique, correlating them against whether the workload is exposed and over-privileged, so a live escape attempt on an under-hardened container is flagged in the same pipeline that verified its provenance at the door.