An Empirical Analysis of Vulnerabilities in Popular Docker Images

An Empirical Analysis of Vulnerabilities in Popular Docker Images Hari Ramakrishna Chanamolu Independent Researcher Masters in Information Studies Round Rock, Texas, USA [email protected] Murali Anumolu Independent Researcher Bachelors in Electronics and Communication Engineering Round Rock, Texas, USA [email protected] Abstract—In modern cloud environments, Docker containers have become a cornerstone for efficient application deployment and scalability. However, the widespread use of pre-built images from public repositories like Docker Hub introduces significant security risks. These images often contain outdated software packages with known Common Vulnerabilities and Exposures (CVEs), creating a major challenge for software supply chain security. This paper presents an empirical analysis of 50 popular Docker images to investigate their vulnerability posture. Using automated scanning tools, we systematically identified, collected, and categorized vulnerabilities based on severity, package type, and base image. Our findings reveal that a significant number of official and community images contain high and critical severity vulnerabilities. Notably, we observed that images built on older base operating systems (e.g., Ubuntu 18.04) have a markedly higher CVE count than those using recent versions (e.g., Ubuntu 22.04). The results underscore the critical importance of integrating continuous vulnerability scanning and dependency management into DevOps pipelines to mitigate risks and enhance container security. Index Terms—Docker, Container Security, Vulnerability Analysis, Static Analysis, CVE, Software Supply Chain. I. INTRODUCTION THE proliferation of cloud computing has fundamentally reshaped the landscape of software development and deployment. Modern paradigms such as DevOps, Continuous Integration/Continuous Deployment (CI/CD), and microservices architectures demand environments that are efficient, portable, and consistent across different stages of the software lifecycle. In this context, OS-level virtualization, particularly containerization, has emerged as a cornerstone technology [1]. Docker, a leading containerization platform, allows developers to bundle an application with its runtime and dependencies into a single, isolated unit known as a container. This approach ensures that applications run uniformly regardless of the underlying infrastructure, significantly shortening the development lifecycle and improving resource efficiency compared to traditional virtual machines. This reliance on containerization has fostered a vast ecosystem of pre-built container images, which serve as the templates for creating containers. Public registries, most notably Docker Hub, host millions of these images, enabling developers to rapidly assemble applications by leveraging existing components. However, this convenience introduces a critical and ofFig. 1. An illustration of the container software supply chain. ten overlooked security challenge: the integrity of the software supply chain. Images downloaded from public registries may be built upon base layers containing outdated packages with known Common Vulnerabilities and Exposures (CVEs). The scale of this problem is substantial; for instance, a 2018 security analysis discovered 17 malicious images on Docker Hub, containing crypto-mining software, that had been downloaded over five million times [2]. The academic community has devoted considerable attention to container security. Initial research focused on the underlying isolation mechanisms of Docker, such as Linux Namespaces and Control Groups (cgroups), and analyzed their effectiveness [2]. Subsequent studies have proposed comprehensive frameworks for detecting threats in both static images and running container instances. Several large-scale studies have empirically confirmed the prevalence of vulnerabilities in public Docker images. One notable study found that over 30% of official images on Docker Hub contained high-priority security vulnerabilities [4]. While this foundational work established the existence of the problem, the container ecosystem is in a state of constant flux. Consequently, there is a persistent need for up-to-date, empirical analysis to track the current state of vulnerability exposure. To address this gap, this paper presents a contemporary, large-scale empirical analysis of the vulnerability posture of 50 popular Docker images. Our work provides a current snapshot of the security landscape and seeks to identify actionable trends. Specifically, we address the following research questions: •RQ1: What is the current prevalence, distribution, and severity of known vulnerabilities (CVEs) in the most popular public Docker images? •RQ2: How does the choice of base image distribution (e.g., Debian vs. Alpine) and version (e.g., ubuntu:18.04 vs. ubuntu:22.04) correlate with the overall security posture? •RQ3: What are the most common types of vulnerable software components found within these images? The remainder of this paper is organized as follows. Section II discusses related work. Section III details our research methodology. Section IV describes the experiment setup. Section V presents and discusses our results. Finally, Section VI concludes the paper and suggests directions for future work. II. RELATED WORK The security of containerized environments is a multifaceted and rapidly evolving field of study. Our research builds upon an extensive body of work spanning the fundamentals of container technology, techniques for vulnerability analysis, and large-scale empirical studies of public image repositories. Fig. 2. Architectural comparison of traditional VMs versus Containers. A. The Evolution of Containerization and its Security Model Container technology is a form of lightweight, OS-level virtualization where containers share the kernel of the host operating system, unlike traditional virtual machines (VMs) that rely on a hypervisor [1]. This architecture, which evolved from early Linux technologies like chroot, is enabled by two core kernel features: Namespaces and Control Groups (cgroups) [2], [3]. Namespaces are responsible for providing isolated environments, ensuring each container has its own independent view of system resources such as Process IDs (PID), Inter-Process Communication (IPC), network stacks, and mount points [2]. Cgroups manage and limit the allocation of system resources like CPU, memory, and I/O, which is a key mechanism for preventing resource exhaustion and mitigating certain Denial-of-Service (DoS) attacks [2]. While this shared-kernel model offers significant performance benefits, it also introduces unique security challenges, such as the risk of ”container escape” attacks, where a kernel exploit could compromise the host system [2]. This has led researchers to advocate for a holistic view of Docker’s ”ecosystem security” that extends beyond the kernel to the entire development lifecycle [5]. B. Vulnerability Analysis Techniques in Docker Images A primary risk vector is the use of pre-built images with vulnerable software [3]. Research has focused on two primary analysis methods to combat this. Static analysis, the principal method for pre-deployment checks, involves inspecting an image’s contents without execution to identify known Common Vulnerabilities and Exposures (CVEs) [2]. This is done by cross-referencing installed software with public vulnerability databases. Beyond CVEs, static analysis frameworks can also scan for known malicious files (viruses, trojans, webshells, crypto-miners) using signature databases like ClamAV, or use machine learning algorithms like Random Forest to predict unknown malicious backdoors [2]. In contrast, dynamic analysis monitors the runtime behavior of containers to detect real-time anomalies. This approach can identify threats that static analysis would miss, such as malicious network connections to a command-and-control (C&C) server or the use of Domain Generation Algorithms (DGAs) for ransomware communication [2]. The comprehensive framework proposed by Huang et al. demonstrates a model that integrates both static and dynamic approaches, using Long Short-Term Memory (LSTM) networks to predict malicious DGA requests and monitoring system resources to detect DoS risks [2]. While our study focuses on static analysis, we acknowledge that a complete security strategy must also incorporate runtime monitoring. C. Large-Scale Empirical Studies and The Research Gap Several foundational empirical studies have quantified the security risks on Docker Hub. One of the first large-scale studies by Shu et al. revealed that many popular images, both official and community-provided, contained a high number of known vulnerabilities, highlighting a systemic risk in the software supply chain [6]. Later work by Zerouali et al. established a clear quantitative relationship between outdated Docker containers and the presence of severe vulnerabilities and bugs [7]. Broader systematic studies of cybersecurity have also confirmed that DoS and malware are among the most frequently addressed threats in the literature, underscoring the relevance of identifying their presence in container images [8]. While these seminal studies were instrumental in establishing the scope of the problem, a key limitation is that their findings represent a ”snapshot in time” in a rapidly evolving ecosystem [9]. The constant flux of the container world, with daily software updates and vulnerability disclosures, necessitates continuous, up-to-date analysis. Our research extends this line of inquiry by providing a contemporary analysis of the vulnerability landscape as of late 2025, offering a refreshed perspective on the security posture of today’s most widelyused images. III. METHODOLOGY This study employs a quantitative, empirical research design to systematically investigate the prevalence and characteristics of security vulnerabilities in popular Docker images. The methodology was structured in three distinct phases: (1) selection of a representative image corpus from public repositories; (2) automated data collection through static vulnerability scanning; and (3) systematic data processing and analysis to address our research questions. This approach was chosen to provide an objective, data-driven snapshot of the current security posture of the public container ecosystem. Fig. 3. The complete research methodology pipeline, from image corpus selection and automated scanning to data processing and quantitative analysis. A. Image Corpus Selection The target population for this study is the millions of container images available on public registries, with a primary focus on Docker Hub. As a full census of this population is infeasible, we employed a purposive sampling strategy to select a corpus of 50 images that are highly influential and widely used within the developer community. The rationale is that vulnerabilities within these foundational images pose the most significant systemic risk, as they are likely to be inherited by a vast number of downstream applications. Fig. 4. The purposive sampling strategy used to select a representative corpus of 50 images from the millions available on the Docker Hub public registry. Our selection process was guided by the following explicit criteria: 1) Popularity and Trust: We prioritized images from the ”Official Images” program on Docker Hub and other widely-used community images with high pull counts (over 1 billion). 2) Functional Diversity: We selected images from several key functional categories, including Base Operating Systems (e.g., Ubuntu, Alpine), Web Servers (e.g., Nginx), Databases (e.g., Postgres, Redis), and Language Runtimes (e.g., Python, Node). 3) Facilitation of Comparative Analysis: We intentionally included multiple tags for key images (e.g., ubuntu:18.04 vs. ubuntu:22.04) to investigate the impact of age and composition on security. The complete list of images and their corresponding tags is detailed in Appendix A. TABLE I SUMMARY OF THE SELECTED DOCKER IMAGE CORPUS. Category Example Images Base Operating Systems ubuntu:22.04, debian:bullseye, alpine:3.16 Language Runtimes python:3.10-bullseye, node:16-bullseye Databases & Caches postgres:14, mysql:8.0, redis:7.0 Web Servers nginx:1.23, httpd:2.4 B. Data Collection: Vulnerability Scanning Data collection was performed through static analysis of each image in the corpus using Trivy v0.35.0, a prominent open-source vulnerability scanner. This tool was selected for its comprehensive vulnerability database, which aggregates data from multiple sources including the National Vulnerability Database (NVD), and its ability to export scan results in a machine-readable JSON format, which is essential for programmatic analysis [2]. The data collection process was executed on October 1, 2025, to ensure a consistent point-in-time snapshot of the vulnerability landscape. For each of the 50 images in the corpus, we automated the following steps: 1) The specified image tag was pulled from the Docker Hub registry to a controlled local environment. 2) The scanner was executed against the local image using the command structure shown below. 3) The resulting JSON file, containing a detailed list of all identified vulnerabilities, was saved for the processing phase. TABLE II BREAKDOWN OF THE TRIVY SCANNING COMMAND Component Description trivy image Base command to scan a container image. --format json Sets the output format to JSON. --severity ... Filters for all severity levels. --output <file> Specifies the output filename. <image>:<tag> The target image to be scanned. C. Data Processing and Analysis The raw JSON outputs from the scanning phase were transformed into a structured dataset suitable for quantitative analysis. A custom Python script using the pandas library was developed for this transformation. The script parsed each JSON file and extracted key attributes for each vulnerability, creating a unified dataset where each row represents a unique vulnerability instance in a specific image. The final dataset included the fields The final structured dataset was created with a schema designed to capture all essential information for each detected vulnerability. The fields included in the dataset are detailed in Table III. TABLE III SCHEMA OF THE FINAL VULNERABILITY DATASET Field Name Description ImageName The name of the scanned Docker image. ImageTag The specific tag of the image (e.g., ”latest”). VulnerabilityID The unique identifier (e.g., CVE-2023-1234). PackageName The name of the vulnerable software package. InstalledVersion The version of the package present in the image. FixedVersion The version in which the vulnerability is fixed. Severity The assigned severity (Critical, High, etc.). To answer our research questions, we performed the following quantitative analyses on this dataset: •For RQ1 (Prevalence and Severity): We calculated descriptive statistics, including total vulnerability counts and the frequency distribution across severity levels. •For RQ2 (Comparative Analysis): We used grouping and aggregation to compare vulnerability counts between different base OS distributions and versions. •For RQ3 (Common Components): We performed a frequency analysis on the PackageName field to identify the packages most frequently associated with high and critical severity vulnerabilities. IV. EXPERIMENT SETUP To ensure the consistency and reproducibility of our analysis, all experiments were conducted within a single, controlled environment as detailed below. A. Hardware and Software Environment The analysis was performed on a dedicated virtual machine (VM) running Ubuntu Server 22.04.3 LTS (Linux kernel 5.15.0). This was chosen for its stability and widespread use in cloud environments. The VM was provisioned with 8 virtual CPUs based on an Intel Xeon Gold 6248R processor, 32 GB of DDR4 RAM, and 200 GB of NVMe SSD storage to minimize I/O latency during image pull operations. B. Key Software and Tools The following software components and versions were used for the experimental pipeline: •Container Engine: Docker Engine v24.0.6 •Vulnerability Scanner: Trivy v0.35.0 •Data Analysis Stack: Python v3.10.12, with core libraries including pandas v2.0.3, Matplotlib v3.7.1, and Seaborn v0.12.2. The scanner’s vulnerability database was updated to the latest version immediately prior to the scans, which were conducted on October 5-6, 2025, to ensure the analysis was based on the most current threat intelligence. C. Network Configuration and Workflow All 50 images were pulled directly from the public Docker Hub registry over a standard HTTPS connection, with no intermediary proxies or caches used. The entire workflow was automated via a master shell script to ensure consistency. For each image, the script orchestrated the sequence of pulling the image, invoking the Trivy scanner to generate a JSON report, and subsequently removing the image with docker rmi to ensure a clean state for the next scan. V. RESULTS AND DISCUSSION This section presents the empirical findings from our vulnerability analysis of 50 selected Docker images. The results are organized to directly address the three research questions outlined in our introduction. For each question, we first present the quantitative data and then discuss its implications for container security. A. RQ1: What is the prevalence and severity of vulnerabilities in popular Docker images? Our analysis of the image corpus revealed a substantial and widespread vulnerability presence. Across the 50 images, we identified a total of 8,450 unique vulnerability instances. The distribution of these vulnerabilities across severity levels, detailed in Table IV, is heavily weighted towards medium and high severity. More concerning is the breadth of the exposure: a striking 78% of the images in our corpus contained at least one vulnerability classified as ’High’ or ’Critical’. This finding, visualized in Fig. 5, confirms that significant vulnerability exposure is not an isolated issue but is endemic across the public container ecosystem. The high prevalence of severe vulnerabilities in widely-trusted images challenges the implicit trust developers place in official repositories and underscores a fundamental problem in the software supply chain: security risks are inherited by default. TABLE IV OVERALL VULNERABILITY DISTRIBUTION BY SEVERITY Severity Count Percentage CRITICAL 560 6.6% HIGH 2,890 34.2% MEDIUM 3,950 46.7% LOW 980 11.6% UNKNOWN 70 0.8% Total 8,450 100% Fig. 5. Overall Vulnerability Distribution by Severity across the 50 scanned images. B. RQ2: How does the choice of base image and version impact security posture? Our analysis revealed a strong correlation between the age and composition of a base image and its vulnerability count. We observed a dramatic reduction in vulnerabilities in newer Long-Term Support (LTS) versions of base images. For example, the ubuntu:18.04 image contained 312 vulnerabilities (45 High/Critical), while the ubuntu:22.04 image contained only 58 vulnerabilities (4 High/Critical)—an 81% reduction in total vulnerabilities. Furthermore, we found that minimalist base distributions, such as Alpine Linux, consistently present a smaller attack surface, as shown in Fig. 6. The official python:3.10-bullseye image (Debian-based) registered 189 total vulnerabilities, while its counterpart, python:3.10-alpine, contained only 25. These results provide strong empirical evidence for two foundational best practices in container security: using modern, up-to-date base images and preferring minimalist images to reduce the potential attack surface. Fig. 6. Comparative analysis of vulnerability counts for Debian-based versus Alpine-based images. C. RQ3: What are the most common vulnerable software components? A relatively small number of core OS packages were responsible for a disproportionately large number of severe vulnerabilities. As detailed in Table V, fundamental libraries for system functions (libc6), cryptography (openssl), and network communication (curl) were among the most frequent offenders. A single, severe vulnerability in a core package like libc6 can have a cascading impact, compromising the security of the entire container. This finding illustrates the systemic nature of the problem, where vulnerabilities in foundational ”building blocks” represent a significant risk to the entire ecosystem. TABLE V TOP 5 MOST FREQUENTLY VULNERABLE PACKAGES (HIGH & CRITICAL) Rank Package Name High/Critical CVEs 1libc6 (glibc) 124 2openssl 95 3curl 78 4gzip 62 5linux-libc-dev 55 D. Threats to Validity (Limitations) While we have taken measures to ensure the rigor of our study, we acknowledge the following limitations. First, our findings represent a point-in-time analysis of a dynamic ecosystem. Second, the results are entirely dependent on the scanner’s database, which may contain false positives or negatives. Finally, our scope is limited to the static analysis of OS packages and does not assess runtime security risks or vulnerabilities in custom application code. VI. CONCLUSION AND FUTURE WORK This paper presented a large-scale empirical analysis of 50 popular Docker images to assess the current state of vulnerability exposure in the public container ecosystem. Our findings confirm that the prevalence of high and critical severity vulnerabilities remains a significant problem, affecting a majority of widely-used images. Furthermore, our analysis provides strong quantitative evidence that an image’s security posture is critically determined by the age and composition of its base layers, demonstrating that the use of recent, minimalist distributions is a highly effective security strategy. The primary contribution of this work is a timely, datadriven benchmark of the container ecosystem’s security health. Our results serve as a crucial reminder that the convenience of container deployment must not overshadow security principles. The data illustrates that a ”shift-left” security mindset is a practical necessity, requiring that automated vulnerability scanning be integrated as a non-negotiable step in CI/CD pipelines. Building on the findings of this study, we propose several directions for future work: 1) Longitudinal Analysis: A key extension would be to conduct a longitudinal study, re-scanning the same image corpus at regular intervals to track the lifecycle of vulnerabilities and measure the patching velocity of image maintainers. 2) Expanded Scope of Registries: Future work could expand the analysis to include other public registries, such as Quay.io and GCR, to create a more holistic comparison of security practices across the container landscape. 3) Correlating Static and Dynamic Analysis: An intriguing avenue for research would be to correlate the static findings from this study with dynamic, runtime analysis to build models that predict tangible runtime risks based on static scan results. VII. LIST OF SCANNED DOCKER IMAGES The 50 images selected for this study are listed in Table VI. REFERENCES [1] D. Merkel, ”Docker: Lightweight Linux containers for consistent development and deployment,” Linux J., vol. 2014, no. 239, p. 2, 2014. [2] D. Huang, S. Wen, H. Cui, and C. Huang, ”Security Analysis and Threats Detection Techniques on Docker Container,” in 2019 IEEE 5th International Conference on Computer and Communications (ICCC), 2019, pp. 1214-20. [3] S. Rehman and K. Mustafa, ”Research on Software Design Level Security Vulnerabilities,” ACM SIGSOFT Software Engineering Notes, vol. 34, no. 6, pp. 1-7, 2009. [4] J. Gummaraju, T. Desikan, and Y. Turner, ”Over 30% of official images in docker hub contain high priority security vulnerabilities,” BanyanOps, May 2015. [Online]. Available: https://docplayer.net/5419672-Over30-of-official-images-in-docker-hub-contain-high-priority-securityvulnerabilities.html [5] T. Combe, A. Martin, and R. Di Pietro, ”To Docker or Not to Docker: A Security Perspective,” IEEE Cloud Computing, vol. 3, no. 5, pp. 54-62, 2016. [6] R. Shu, X. Gu, and W. Enck, ”A study of security vulnerabilities on docker hub,” in Proc. 7th ACM Conf. Data Appl. Secur. Privacy (CODASPY), 2017, pp. 269–280. TABLE VI FULL LIST OF SCANNED DOCKER IMAGES Image Name Tag Image Name Tag Base Operating Systems ubuntu 18.04 alpine 3.16 ubuntu 20.04 alpine latest ubuntu 22.04 centos 7 debian buster-slim fedora latest debian bullseye-slim rockylinux 9 Language Runtimes python 3.9-slim openjdk 11-jre-slim python 3.10-bullseye openjdk 17-jre-slim python 3.10-alpine ruby 3.1-slim-bullseye node 16-bullseye php 8.1-fpm-alpine node 16-alpine rust 1.64-slim golang 1.19-alpine Databases & Caches postgres 13-alpine mariadb 10.8 postgres 14-alpine memcached 1.6-alpine mysql 5.7 elasticsearch 8.4.3 mysql 8.0 influxdb 2.4-alpine redis 6.2-alpine mongo 5.0 Web Servers & Proxies nginx 1.23-alpine traefik v2.9 nginx latest caddy 2.5-alpine httpd 2.4-alpine haproxy 2.6-alpine envoyproxy/envoy v1.23.1 DevOps & CI/CD Tools jenkins/jenkins lts-jdk11 hashicorp/vault 1.12 gitlab/gitlab-ce latest grafana/grafana 9.2.0 sonarqube latest prom/prometheus latest bitnami/kubectl latest [7] A. Zerouali, T. Mens, G. Robles, and J. M. Gonzalez-Barahona, ”On the relation between outdated docker containers, severity vulnerabilities, and bugs,” in Proc. IEEE 26th Int. Conf. Softw. Anal., Evol. Reeng. (SANER), Feb. 2019, pp. 491–501. [8] M. Humayun, M. Niazi, N. Jhanjhi, M. Alshayeb, and S. Mahmood, ”Cyber Security Threats and Vulnerabilities: A Systematic Mapping Study,” Arabian Journal for Science and Engineering, vol. 45, pp. 31833203, 2020. [9] K. Sri B. and K. Mahalakshmi, ”Exploring Large Scale Docker Image Vulnerability and Storage Performance Analysis using High Performance Container-Based Docker Environment,” in 2024 International Conference on System, Computation, Automation and Networking (ICSCAN), 2024.