On Security Measures for Containerized Applications Imaged with Docker

Linux containers have risen in popularity in the last few years, making their way to commercial IT service offerings (such as PaaS), application deployments, and Continuous Delivery/Integration pipelines within various development teams. Along with the wide adoption of Docker, security vulnerabilities and concerns have also surfaced. In this survey, we examine the state of security for the most popular container system at the moment: Docker. We will also look into its origins stemming from the Linux technologies built into the OS itself; examine intrinsic vulnerabilities, such as the Docker Image implementation; and provide an analysis of current tools and modern methodologies used in the field to evaluate and enhance its security. For each section, we pinpoint metrics of interest, as they have been revealed by researchers and experts in the domain and summarize their findings to paint a holistic picture of the efforts behind those findings. Lastly, we look at tools utilized in the industry to streamline Docker security scanning and analytics which provide built-in aggregation of key metrics.

💡 Research Summary

The paper provides a comprehensive survey of the current security landscape surrounding Docker, the de‑facto standard for Linux‑based containerization. It begins by tracing Docker’s origins to core Linux kernel features—namespaces, cgroups, and the libcontainer/runc runtime—explaining how these abstractions enable lightweight isolation but also inherit the kernel’s attack surface. The authors then dissect the Docker image format, emphasizing its layered, read‑only filesystem and the JSON‑based manifest that describes each layer. While Docker Content Trust (DCT) offers image signing via Notary v1, the paper highlights several shortcomings: complex key management, limited signature algorithms, and susceptibility to man‑in‑the‑middle attacks during verification. The authors recommend transitioning to newer signing frameworks such as Notary v2 or Sigstore to achieve stronger, more user‑friendly provenance guarantees.

Runtime security receives particular attention. The Docker daemon runs with root privileges and exposes a REST API that, if compromised, can be leveraged for privilege escalation or unauthorized container manipulation. The paper proposes hardening strategies including running the daemon under a non‑root user, enforcing mutual TLS (mTLS) for API access, and applying role‑based access control (RBAC) to restrict command execution. It also stresses the importance of avoiding the default “root” user inside containers by specifying a non‑privileged USER in Dockerfiles and employing user namespace remapping.

Network isolation is examined next. Docker’s default bridge network relies on NAT and does not provide fine‑grained segmentation. The authors evaluate modern CNI plugins—Calico, Cilium, and Weave Net—that leverage eBPF to enforce L3/L4 policies, implement micro‑segmentation, and filter system calls at the kernel level. Real‑world case studies demonstrate that eBPF‑based policies can block malicious lateral movement and reduce exposure to container‑to‑container attacks.

The paper then surveys host‑level security mechanisms: SELinux, AppArmor, and Seccomp. By combining these mandatory access control (MAC) frameworks, administrators can construct a “default‑deny” profile that limits the set of system calls and filesystem paths available to a container. Tools such as Docker Bench for Security, Falco, and Open Policy Agent (OPA) are evaluated for their ability to generate and enforce these profiles automatically within CI/CD pipelines.

A central contribution of the work is the definition of quantitative security metrics. The authors propose measuring image size, layer count, CVE density (vulnerabilities per megabyte), base‑image freshness, runtime system‑call profiles, and network‑policy violation counts. These metrics can be integrated with image‑scanning solutions like Trivy, Clair, Anchore, and with orchestration‑level policy engines to create “security gates” that halt deployments when thresholds are exceeded. Empirical data from industry deployments show that enforcing a “high‑severity CVE block” and a “maximum ten layers per image” rule reduced security incidents in production pipelines by over 70 %.

Finally, the paper outlines future research directions. It advocates for moving toward micro‑VM based runtimes (e.g., Kata Containers) to further isolate the kernel, adopting zero‑trust networking models within container clusters, and leveraging machine‑learning‑driven anomaly detection (e.g., using Falco’s behavioral rules) to identify and automatically quarantine compromised containers at runtime.

In summary, the survey systematically maps Docker’s architectural vulnerabilities, evaluates the state‑of‑the‑art tooling, and proposes a metric‑driven, defense‑in‑depth framework that can be embedded early in the software development lifecycle. This roadmap equips both researchers and practitioners with actionable guidance to harden containerized applications against today’s evolving threat landscape.