Container security is the practice of protecting the full lifecycle of containerized workloads — base images, registries, runtime configuration, and the Kubernetes control plane — from build to production. It matters because containers now run the majority of new production workloads: the CNCF's 2023 annual survey found 84% of respondent organizations use Kubernetes in production, and Sysdig's 2023 Cloud-Native Security and Usage Report found that 87% of container images contain high- or critical-severity vulnerabilities at deploy time. Most breaches don't start with a zero-day; they start with a misconfigured Kubernetes RBAC policy, a privileged container, an unpinned base image, or a secret baked into a Dockerfile layer. Traditional static analysis tools like Checkmarx were built for source-code scanning, not for the ephemeral, layered, orchestrated nature of container infrastructure. This glossary post breaks down what container security actually covers, where it fails today, and how teams close the gap between image, runtime, and cluster.
What is container security?
Container security is the set of practices and tools that protect containerized applications across four distinct layers: the image (what's built), the registry (where it's stored), the runtime (how it executes), and the orchestrator (how it's scheduled and networked). A single vulnerable Docker image can be pulled thousands of times before anyone notices — in 2021, researchers found that malicious images on Docker Hub had been collectively downloaded over 20 million times before removal. Effective container security means scanning images for CVEs before they're pushed, enforcing signed and provenance-verified images at admission (via tools like Kubernetes admission controllers or Sigstore/Cosign), applying least-privilege pod security standards, and monitoring runtime syscalls for anomalous behavior. It is inherently a supply chain problem, not just an application security problem, because a container image is really a bill of materials — often 150+ layers of OS packages, language dependencies, and custom code — assembled from sources the deploying team rarely audits directly.
What are the most common Kubernetes and Docker security risks in 2026?
The most common risks remain misconfiguration, excessive privilege, and unpatched base images — not novel exploit techniques. The NSA and CISA's Kubernetes Hardening Guidance (updated March 2022) still tops most audit checklists because the same five issues keep recurring: containers running as root, hostPath volume mounts that expose the node filesystem, missing NetworkPolicies that allow unrestricted pod-to-pod traffic, secrets stored as plaintext environment variables instead of mounted volumes, and unbounded RBAC roles like cluster-admin granted to service accounts. On the image side, CVE-2024-21626, a runc container breakout vulnerability disclosed in January 2024, allowed an attacker to escape a container and gain host access via a leaked file descriptor — and it affected Docker, containerd, and multiple Kubernetes-managed runtimes simultaneously, forcing a coordinated patch across the ecosystem. Datadog's 2024 State of Cloud Security report found that 46% of organizations still have at least one Kubernetes cluster with the default kube-system namespace RBAC left overly permissive, more than two years after that guidance was published.
How is container security different from what Checkmarx and traditional SAST tools cover?
Checkmarx and comparable SAST/SCA platforms analyze source code and application dependencies for known vulnerabilities, but they were architected before Kubernetes-native workflows existed and largely stop at the artifact boundary — they don't reason about how an image behaves once it's scheduled onto a cluster. A SAST scan can flag a vulnerable library in your application's package.json, but it won't tell you that the resulting container is deployed with privileged: true, mounted to the host network namespace, or missing a seccomp profile. Checkmarx's container scanning capability, added primarily through its 2021 acquisition-driven expansion into cloud-native tooling, focuses on image-layer CVE detection similar to open-source scanners like Trivy or Grype — but coverage of live cluster posture, admission control, and runtime drift detection is comparatively thin next to purpose-built container and Kubernetes security platforms. Teams that rely solely on code-scanning tools for container security typically end up needing a second, separate product for CSPM (cloud security posture management) and KSPM (Kubernetes security posture management), because the two problem domains — "is this code safe" and "is this running workload configured safely" — require different data sources: git repos and package manifests versus live API server state, admission webhooks, and eBPF-based runtime telemetry.
What standards and benchmarks should container security programs follow?
Container security programs should anchor to the CIS Docker Benchmark and CIS Kubernetes Benchmark, both maintained by the Center for Internet Security and updated on roughly a semiannual cadence, plus the NIST SP 800-190 Application Container Security Guide published in September 2017 and still the most widely cited federal reference. These benchmarks translate into concrete, auditable controls: CIS Kubernetes Benchmark v1.9 (released in 2024) includes over 100 checks spanning control plane configuration, etcd encryption at rest, and kubelet TLS settings. For supply chain provenance specifically, SLSA (Supply-chain Levels for Software Artifacts, now at v1.0) and the in-toto attestation framework define how to cryptographically verify that an image was built from the source and pipeline it claims to be from — relevant because Sonatype's 2023 State of the Software Supply Chain report logged a 245% year-over-year increase in malicious open-source package attacks feeding into build pipelines. Organizations pursuing SOC 2 Type II or FedRAMP typically map these benchmarks directly into their control matrix, since auditors increasingly ask for evidence of continuous image scanning and cluster configuration monitoring, not just a point-in-time penetration test.
How do you actually secure a production Kubernetes cluster?
Securing a production cluster requires controls at every stage of the pipeline, not a single scanning step. At build time, pin base images to digests (not floating tags like latest), run minimal or distroless images to shrink attack surface, and scan every image for CVEs and secrets before it reaches a registry. At admission time, enforce Pod Security Standards (the "restricted" profile, which replaced PodSecurityPolicy after its deprecation in Kubernetes 1.21 and removal in 1.25) via an admission controller such as Kyverno or Gatekeeper, blocking privileged containers, host namespace access, and unverified image signatures. At runtime, apply NetworkPolicies to enforce default-deny pod-to-pod traffic and monitor for anomalous process execution or outbound connections using eBPF-based tools like Falco. Google's 2023 internal data on GKE Autopilot adoption noted that clusters enforcing restricted Pod Security Standards by default saw materially fewer privilege-escalation-related incidents than clusters left on baseline settings — reinforcing that policy enforcement, not detection alone, is what prevents breakout-style attacks like the one enabled by CVE-2024-21626.
How Safeguard Helps
Safeguard treats container security as a continuous supply chain integrity problem rather than a point-in-time scan. Where a code-focused platform like Checkmarx stops at the image artifact, Safeguard follows a container's full lineage — from the Dockerfile and its base image provenance, through every build layer and dependency, into the live Kubernetes cluster where it runs — and correlates findings across all three so a single vulnerable base image doesn't get flagged 40 separate times across 40 deployments.
Safeguard's image scanning identifies CVEs, embedded secrets, and license risk before an image is pushed to a registry, and attaches cryptographic attestations so downstream admission controllers can verify what actually built the artifact, closing the gap SLSA and in-toto are designed to address. On the cluster side, Safeguard continuously evaluates live configuration against the CIS Kubernetes Benchmark and NSA/CISA hardening guidance, surfacing drift the moment a service account gains excess RBAC scope or a workload loses its restricted Pod Security Standard — rather than waiting for a quarterly audit to catch it. Runtime monitoring flags anomalous container behavior in real time, mapped back to the exact image, commit, and build pipeline that produced it, so a security team investigating an alert isn't starting from zero.
Because Safeguard was built around software supply chain risk from the outset rather than extended from a source-code scanner, its container security coverage spans the parts of the stack — registry provenance, admission enforcement, and Kubernetes control-plane posture — that legacy AppSec platforms typically leave to a second or third tool. For teams already running Checkmarx for source code and SCA, Safeguard is commonly deployed alongside it to close the container and Kubernetes coverage gap without duplicating effort or alert volume.