Containers have changed how applications are built, deployed, and scaled. They provide consistency across environments, speed up deployment, and make application infrastructure more manageable. They also introduce a set of security considerations that differ from traditional virtual machine or bare-metal deployments, and that many development and operations teams have not fully addressed.
The security of a containerised environment depends on the security of the images that containers run from, the configuration of the runtime, the network controls between containers, and the permissions granted to container processes. Weaknesses in any layer affect the security of the whole.
Container Image Security
Container images are built from base images, typically pulled from public registries. Those base images contain operating system components, libraries, and packages that carry their own CVE history. An application container built on an Ubuntu base that has not been updated for twelve months likely contains dozens of known vulnerabilities, many of which are unrelated to the application but nonetheless present on the host.
Minimal base images, such as distroless images that contain only the application and its runtime dependencies, reduce the vulnerability surface significantly. An image with fewer installed components has fewer CVE exposures. Building images from minimal bases and keeping them updated are both practices that reduce container image risk.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
“Container security follows a similar pattern to cloud security. The technology is not inherently insecure, but the defaults are not set up with security as the priority, and the pace of deployment means security reviews happen after the fact rather than during build. The findings we see most consistently are containers running as root and images with years of unpatched vulnerabilities.”
Runtime Configuration
Containers that run as root present an unnecessary privilege level. If an attacker compromises a process running as root within a container, container escape is significantly easier than from a non-root process. Configuring containers to run as non-root users is a simple configuration change with meaningful security benefit.
Privileged containers have access to the host kernel and its resources in a way that standard containers do not. Workloads that require privileged mode should be rare and explicitly justified. Detecting and reviewing all privileged containers in an environment is a basic security hygiene step that is frequently not performed.
Network Security Between Containers
Web application penetration testing of applications running in containers includes testing for vulnerabilities that, if exploited, could allow an attacker to move from the compromised container to others within the same deployment. Network policies that restrict inter-container communication limit the blast radius of a compromised container.
By default, containers within the same network can communicate freely. Network segmentation using Kubernetes Network Policies, Docker network isolation, or similar controls limits communication to only the paths required for the application to function.
Secrets and Credential Management
Embedding secrets directly in container images is a recurring finding in security assessments. API keys, database passwords, and certificates included in image layers are accessible to anyone who can pull the image. Even if the image is stored in a private registry, the exposure risk is significant.
Vulnerability scanning services for containerised environments include image scanning against vulnerability databases, secrets detection in image layers, and configuration auditing for runtime settings. Integrating these into the CI/CD pipeline catches issues before images reach production.
