What Is Container Security?

The gap that container security programs miss

A container image passes every vulnerability scan in CI. The same image clears the registry policy gate. It deploys to staging, runs without issues, and gets promoted to production. Three weeks later, the container is compromised.

This is not a hypothetical. Container security failures in mature engineering organizations routinely trace back to the same structural gap: image scanning treats the container as static, but the container runs in a dynamic environment where the runtime configuration, the Kubernetes RBAC setup, the network policy, and the supply chain integrity of every dependency are all attack surface.

Container security is the practice of protecting containerized applications across the full lifecycle: from the base image chosen in a Dockerfile, through the registry where images are stored, through the Kubernetes orchestration layer, to the runtime where containers execute. It is not a single tool or a single phase. Programs that treat it as image scanning alone leave four other layers exposed.

Tools covering all five layers — Theodolite, Wiz, Prisma Cloud, and others — are compared in our best container security tools 2026 guide. This page covers the underlying concepts: what each layer actually protects, why the gaps between layers matter, and how to evaluate whether a container security program is complete.

The five layers of container security

Container security spans five distinct layers. Each requires separate controls; a gap in any one creates exploitable exposure.

A complete container security program covers all five. Most programs are strong in the first layer and thin or absent in the others.

Image and build-time security

The build phase is where container security starts, and for most teams, where it effectively ends.

Image scanning decomposes a container image layer by layer, inventories installed OS packages and language runtime dependencies, and matches them against vulnerability databases: NVD, vendor advisories, and proprietary threat feeds. The output is a findings list with CVE IDs, severity ratings, and whether a fix exists. Modern scanners also check for secrets embedded in image layers (API keys, private keys, hardcoded credentials) and flag insecure Dockerfile patterns like running as root, unnecessary Linux capabilities, and exposed ports.

Scanning in CI before the image reaches any registry is the correct implementation. Scanning only in the registry catches the same vulnerabilities later, after the image has already been promoted. Organizations that scan at the registry gate instead of at the pull request often maintain a growing exceptions list of known-vulnerable images because removing them requires more disruption than accepting the risk.

Base image selection determines the ceiling of image security. A full Ubuntu base image ships hundreds of packages, each a potential CVE surface. Distroless images ship only the application runtime and its direct dependencies. Scratch images ship only a statically compiled binary. Switching from a full OS base to distroless can reduce a scanner’s finding count by 80-90%: not because the application got more secure, but because unnecessary attack surface was removed.

Container image security is one component of the broader application security best practices picture. The same build pipeline that scans images should also run SAST on the application code and dependency audits on language packages.

Operator note: The most common image security mistake I see isn’t skipping scanning — it’s scanning without enforcing. Teams set up Trivy in CI, it finds critical CVEs, and the pipeline ships the image anyway because nobody configured a blocking policy. The scanner becomes a reporting tool rather than a gate. Effective container image security requires that someone has authority to fail a build over a critical CVE with a fix available, and that this authority is encoded in pipeline configuration — not left to discretion. Without a blocking policy, scanning produces dashboards, not security.

Registry and supply chain security

An image that passes a clean build-time scan can be tampered with between the build system and the production cluster. Registry security closes this window.

Image signing with Sigstore and Cosign generates a cryptographic signature attached to each image. An admission controller in Kubernetes — Connaisseur, Kyverno, or OPA/Gatekeeper — verifies the signature at deploy time and rejects unsigned or invalidly signed images. The result: only images from verified builders can run in production, and any tampering in transit causes a deploy failure rather than a silent compromise.

Supply chain security for containers extends this further. A Software Bill of Materials (SBOM) — generated by tools like Syft in SPDX or CycloneDX format — is a complete inventory of every component in an image: OS packages, language dependencies, transitive dependencies, their versions, and their licenses. When a new critical CVE drops, as Log4Shell demonstrated in late 2021, an SBOM turns “which of our running containers are affected?” from a multi-day investigation into a query that runs in minutes.

SLSA (Supply chain Levels for Software Artifacts) provides a framework for attesting to provenance: where the image was built, from what source, with what tools. A SLSA Level 3 attestation means the build process itself was verified to be tamper-resistant. Few organizations operate at that level today; most start with image signing and SBOM generation and build toward provenance attestation over time.

Runtime container security

A container can have a clean image, a verified signature, and still be compromised after it starts running. Runtime container security is the control layer that detects and responds to active threats during execution.

The mechanism has evolved substantially. Early runtime security relied on seccomp profiles (allowlists of permitted Linux system calls) and AppArmor policies (MAC rules constraining process behavior). These remain valuable hardening layers, but they’re static: you define the policy at deploy time, and deviation causes a policy violation rather than an alert with behavioral context.

Modern runtime security tools use eBPF (extended Berkeley Packet Filter) to observe container behavior at the kernel level in real time. eBPF hooks into kernel events — process creation, system calls, network connections, filesystem operations — with negligible performance overhead. The tool builds a behavioral baseline for each container type: what processes typically run, what network ranges they connect to, what files they read or write. When observed behavior deviates from that baseline — a container starts spawning shells, making outbound connections to unfamiliar IPs, reading credential files — the tool fires an alert or blocks the activity.

This behavioral detection is what separates runtime container security from signature-based threat detection. A novel attack that uses legitimate binaries (living-off-the-land techniques) won’t match a malware signature. It will deviate from the container’s behavioral baseline.

Runtime container security is a core component of the cloud workload protection platform capability set. CWPP tools increasingly cover both container runtime and VM workloads under a unified agent and policy framework, reducing the operational cost of managing separate tools for each workload type.

Kubernetes security

Kubernetes security is a distinct discipline from container security, but the two are inseparable in practice. A container with a clean image, strong runtime protection, and signed provenance is still exploitable through a misconfigured Kubernetes environment.

RBAC over-permission

Service accounts accumulate permissions over time. A container running with a service account that has cluster-admin binding can, if compromised, access the Kubernetes API to read secrets, modify workloads, or pivot across namespaces. Minimum-necessary RBAC — scoped to the exact resources and verbs the workload requires — limits blast radius when a container is compromised. Auditing service account permissions is unglamorous work that most teams defer indefinitely.

Missing pod security standards

Kubernetes Pod Security Admission (the successor to PodSecurityPolicy) enforces three profiles: Privileged, Baseline, and Restricted. Most production workloads should run at Baseline minimum; security-sensitive workloads should run at Restricted. Clusters that haven’t configured Pod Security Admission allow containers to request host namespaces, mount arbitrary host paths, and run as root — all of which expand the impact of a container compromise significantly.

Exposed cluster API and dashboard

The Kubernetes dashboard, if publicly accessible without authentication, gives an attacker full cluster control. The cluster API, if reachable from the internet without network policy restriction, is an attractive target. Kubernetes security begins with verifying the control plane is not internet-accessible, then layering authentication and audit logging on top.

Unmanaged secrets

Kubernetes secrets stored as base64-encoded values in etcd are not encrypted at rest by default. Applications that pull credentials from environment variables expose them in crash dumps. Secrets management solutions — HashiCorp Vault, AWS Secrets Manager integrated via CSI driver, the external-secrets operator — keep credentials out of Kubernetes manifests and out of the image entirely.

Kubernetes security connects directly to the decisions made at the infrastructure layer. The network topology, IAM design, and cluster placement choices covered in cloud security architecture determine what’s possible at the Kubernetes layer.

Operator note: I’ve reviewed Kubernetes environments where image scanning was mature and runtime tools were deployed, but every service account had get, list, watch on all resources across all namespaces “for debugging.” That’s effectively cluster-admin for read access. If a container gets compromised, the attacker can enumerate every secret, every workload, and every configuration in the cluster silently — because API enumeration through a legitimate service account looks like normal behavior. No runtime alert fires. RBAC is the layer most teams defer and then never harden because it requires understanding what each workload actually needs. It’s also the layer that turns container compromise into cluster compromise.

Where container security programs go wrong

The most common failure modes, in order of frequency:

1. Treating image scanning as the whole program. Scanning finds known CVEs in images. It does not detect runtime threats, Kubernetes misconfigurations, registry tampering, or supply chain compromise. Organizations that invest heavily in scanning and lightly in the other layers have false confidence that container security is handled.

2. Letting the CVE backlog grow unchecked. Image scanning produces findings continuously. Without a triage process and a remediation SLA, the backlog grows until teams stop trusting the scanner. A pragmatic triage approach: critical CVEs with a fix available are P1 (remediate within 7 days); critical CVEs without a fix get tracked and mitigated at the network or runtime layer; high CVEs with a fix available are P2 (remediate within 30 days). An unmanaged backlog is the failure state, not the backlog itself.

3. Running containers as root. Most default container images run as root inside the container. If a container escape occurs, a root container process can attempt to leverage root on the host. Running as a non-root UID is a one-line Dockerfile change that costs nothing at build time.

4. Not enforcing admission control. Image signing and SBOM generation are only as useful as the admission controller that enforces them. Policy that isn’t enforced is documentation. If unsigned images can reach production anyway, the signing infrastructure provides audit trail but no security.

5. Deploying runtime tools without baseline tuning. Runtime agents that ship with default alert rules produce alert floods on day one. Teams mute the alerts. The tool is technically deployed but effectively disabled. Container runtime security requires a tuning period — typically two to four weeks — to baseline each workload type before alerts become actionable signal rather than noise.

How to evaluate a container security program

Five questions that surface the gaps between a paper program and a working one:

1. Where in the pipeline does container image scanning run — at the pull request stage, the registry gate, or only in periodic batch? (Earlier is better; periodic batch is table stakes only.)

2. Are images signed, and does the Kubernetes admission controller reject unsigned images at deploy time? (Yes or no; there is no partial credit for signing without enforcement.)

3. Is there a runtime agent deployed, and what is its detection mode — alert-only or blocking? What is the false positive rate, and how long did tuning take?

4. What are the RBAC permissions for each service account, and when were they last audited? Can you produce that answer in an hour, or does it require a project?

5. Can you identify all running containers affected by a specific CVE within 30 minutes? (Yes requires an SBOM pipeline; no means relying on scanner re-runs, which take hours and may not cover all environments.)

These questions distinguish programs that are compliant on paper from programs that would actually contain a container compromise. Answering all five with confidence is the practical definition of container security maturity.

Theodolite surfaces container and cloud workload security posture alongside cloud infrastructure and data risk, giving security teams a unified view of exposure across layers rather than separate dashboards for each control domain.

vCSO.ai is the operator-led cybersecurity advisory firm of Nick Shevelyov, former 15-year Chief Security Officer at Silicon Valley Bank. Theodolite, vCSO.ai’s security platform, unifies cloud security posture management with workload protection, data security posture management, and FAIR-based cyber risk quantification. For a vendor-by-vendor comparison of dedicated container security tools, see our best container security tools 2026 guide.