Container images are layers: a base (minimal operating system) + dependency layers + application code. Each layer can contain vulnerabilities. A legacy image not updated in 2 years probably has dozens of CVEs.
What is a container
A container is a standalone software unit that packages an application, its dependencies (libraries, runtime), and its configuration in an isolated package. Docker is the most popular container platform. Containers are lighter than virtual machines: they share the host kernel but maintain isolation of processes, network and storage. In modern enterprises, tens or hundreds of containers run in production orchestrated by Kubernetes. From a security perspective, containers introduce new attack surfaces: vulnerable base image, code injected during compilation, secrets exposed in layers, container escapes that compromise the host, abuse of privileges within the container.
Why it matters
For a CISO, containers are both an opportunity and a risk. Opportunity: better isolation than traditional processes, exact reproducibility (what works in dev works in prod), facilitates rapid updates. Risk: exponential operational complexity (100+ containers is common), expanded attack surface (each container is an attack point), complex secret management, legacy vulnerable images running in production without patches. Container hardening requires: image scanning (vulnerabilities in layers), image signing (ensure they were not modified), runtime control (policies for what containers can execute), access audits, secret management. Without these measures, a compromised container scales rapidly if orchestrated by Kubernetes without network controls.
Key points
Secrets (API keys, passwords) should not be in image layers. If in Dockerfile, there is risk of exposure in registries. Injecting secrets at deployment time is the correct practice.
Container escapes (attacks where code inside a container accesses the host) are real. They require misconfigured privileges, vulnerable kernel or misconfiguration. Containers must run without root privileges.
Private container registries (Docker Registry, ECR, Artifactory) must be protected with role-based access. An attacker with registry access can inject malicious code that will be deployed to all clusters.
Example: container security in a SaaS platform
A SaaS startup with 50 microservices in Kubernetes uses internally-compiled Docker images. Initially: (1) Outdated base images (Ubuntu 18.04 from 2020). (2) No vulnerability scanning before deploy. (3) Private registries with shared credentials. (4) Containers run as root. (5) No network policies between containers. An attacker compromises a machine with registry access. They inject cryptocurrency mining code into three images. The images are deployed to Kubernetes. In 2 hours, 50 pods run malicious code, consuming CPU and exfiltrating data. Damage: 50,000 USD cloud bill, customer data at risk. After the incident, they implement: (1) Updated base images automatically (distroless Linux). (2) Mandatory scanning in CI/CD with Trivy: blocks builds with critical CVEs. (3) Image signing with Cosign; Kubernetes only deploys signed images. (4) Containers run without root with SecurityContext. (5) Network policies: containers only communicate with those they need. (6) Registry access with RBAC and audit. A new injection attempt is blocked in the CI/CD pipeline or rejected by Kubernetes at deployment time.
Common mistakes
- Not scanning container images before deploying. An image with 20 vulnerable CVEs in production is a fire. Integrating scanning (Trivy, Grype) in CI/CD and blocking builds is mandatory.
- Using heavy and outdated base images. Full Ubuntu has hundreds of unnecessary packages. Using distroless or alpine images and keeping them updated significantly reduces the vulnerability window.
- Running containers as root. If a process inside the container is compromised, the attacker has full host control. Always execute with non-root user and restricted permissions.
- Not securing the container registry. If the registry is an entry point, an attacker can poison images. RBAC, audit, and image signing are critical.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between a container and a virtual machine?
A virtual machine virtualises all hardware. A container only isolates processes and shares the host kernel. Containers are faster, lighter and more scalable; virtual machines offer stronger isolation. In security, virtual machines are more resistant to escapes, but containers are sufficiently secure if configured correctly.
Why scan container images?
Because they can contain known vulnerabilities (CVEs) in the base or dependency layers. Trivy, Grype and other scanners identify vulnerabilities. Blocking builds with critical CVEs prevents deploying vulnerable code to production.
What is image signing?
Digital cryptographic signature that guarantees an image was not modified since it was built. Tools like Cosign allow signing images. Kubernetes can be configured to only deploy signed images, preventing malware injection in registries.
What is container escape?
An attack where code inside a container accesses the host or other containers. Requires kernel vulnerabilities, excess privileges, or misconfiguration. Running without root, limiting syscall permissions and keeping the kernel updated prevents many escapes.