empirical_analysis_of_image_staleness_and_vulnerability_debt.pdf

Quantifying the Cost of Neglect: An Empirical Study of Image Staleness and Vulnerability Debt in the Docker Ecosystem Hari Ramakrishna Chanamolu∗(hariramakrishna29.c[email protected])a, Murali Anumolu (anumolum[email protected])a aIndependent Researcher, Round Rock Texas USA Abstract In modern cloud environments, Docker containers are a cornerstone for application deployment. However, the use of pre-built images from public repositories like Docker Hub introduces significant risks, particularly from stale images. While developers are advised to use the latest versions, many applications are "stuck" on older, unmaintained images due to legacy dependencies, technical debt, and the high cost of refactoring. This paper presents an empirical analysis to quantify the "vulnerability debt" incurred by this practice. We analyze 50 popular Docker images using two prominent scanners, Trivy and Grype, to provide a robust dataset. We introduce "image staleness" (days since last update) as a key metric. Our findings reveal a strong, statistically significant positive correlation between image staleness and the number of high and critical severity vulnerabilities. This work moves beyond a simple "old vs. new" comparison to provide a quantitative risk model. The results underscore the critical importance of integrating automated staleness policies and multi-scanner strategies into DevOps pipelines to mitigate this accumulated risk. Keywords: Docker, Container Security, Vulnerability Debt, Technical Debt, Image Staleness, Empirical Software Engineering, CVE, Software Supply Chain 1. 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), 1 Figure 1: An illustration of the container software supply chain. 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 prebuilt 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 often 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 mecha2 nisms 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. A common assumption in a rational development model is that developers can simply choose the latest, patched base image (e.g., ubuntu:22.04) over an older one (e.g., ubuntu:18.04). However, this ideal scenario ignores the widespread reality of technical debt and legacy systems. Many organizations use Docker to containerize existing monolithic applications without refactoring them, forcing them to use older base images that support their legacy dependencies. Furthermore, upgrading a base image in a working application can introduce subtle, breaking changes, making the cost and risk of migration prohibitively high. This forces teams to choose between shipping vulnerable software or halting feature development to fix compatibility issues. This problem is so common that entire "legacy registries" (e.g., the Bitnami Legacy Registry) exist to support developers who are "stuck" on unmaintained images. This practice of using stale images creates an accumulating "vulnerability debt." While it is obvious that an unmaintained image will have more flaws, the rate at which this debt grows and its quantifiable risk are not well understood. This paper addresses this gap. Our work provides a current snapshot of the security landscape and seeks to quantify the risk of image neglect, giving managers and developers the data needed to justify the engineering work required to upgrade. 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: What is the quantitative relationship between image staleness (i.e., days since last update) and the accumulated vulnerability count and severity? 3 Figure 2: Architectural comparison of traditional VMs versus Containers. •RQ3: How do different prominent open-source scanners (e.g., Trivy and Grype) compare in their detection of vulnerabilities within the same image corpus? •RQ4: What are the most common types of vulnerable software components found within these images? The remainder of this paper is organized as follows. Section 2 discusses related work. Section 3 details our research methodology. Section 4 describes the experiment setup. Section 5 presents and discusses our results. Finally, Section 6 concludes the paper and suggests directions for future work. 2. 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. 2.1. 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 tra4 ditional 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-ofService (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]. 2.2. 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. 5 2.3. 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]. Furthermore, while studies like Zerouali et al. [7] relate outdated containers to bugs, a specific, quantitative model correlating image staleness (time since last update) to vulnerability debt has not been the focus. Our research extends this line of inquiry by providing a contemporary analysis of the vulnerability landscape as of late 2025, offering a refreshed, quantitative model for assessing the risk of image neglect. 3. 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. 3.1. 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. 6 Figure 3: The purposive sampling strategy used to select a representative corpus of 50 images from the millions available on the Docker Hub public registry. A key part of our strategy was the intentional inclusion of images with a wide range of ages, including those considered "stale" or "legacy" (e.g., ubuntu:18.04, which is over 6 years old). This is not a biased choice, but a deliberate one to model a real-world, high-risk scenario. Academic studies confirm that Docker projects are prone to significant technical debt, where developers are "stuck" on old base images due to legacy dependencies or the high cost of refactoring. Furthermore, a primary use of containerization is to package *old* legacy applications *without* rewriting them, forcing the use of older base images. Our corpus, therefore, is designed to quantify the "vulnerability debt" associated with this common, real-world maintenance challenge. 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. 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 7 Table 1: 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 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. Varied Maintenance Status: We selected images with a wide range of "last updated" dates—from images maintained daily to those abandoned for several years—to enable a correlation analysis of image staleness. The complete list of images and their corresponding tags is detailed in Appendix Appendix A. 3.2. Data Collection: Vulnerability Scanning Data collection was performed using a multi-scanner approach to enhance the validity of our findings and address RQ3. We selected two prominent open-source scanners: Trivy v0.35.0 and Grype v0.73.0. This strategy mitigates the risk of relying on a single tool’s database. Both tools were selected for their comprehensive vulnerability databases and their ability to export scan results in a machine-readable JSON format, which is essential for programmatic analysis [2]. Furthermore, for each image tag in our corpus, we programmatically queried the Docker Hub v2 API to retrieve its last_updated timestamp. This metadata is essential for calculating image staleness to address RQ2. The data collection process was executed on October 1, 2025, to ensure a consistent point-in-time snapshot. 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. g 8 Table 2: Example Scanning Command (Trivy) 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. 2. The last_updated timestamp was retrieved from the Docker Hub API. 3. Both Trivy and Grype were executed against the local image. 4. The resulting JSON files (two per image) were saved for the processing phase. 3.3. 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 the JSON files from both Trivy and Grype and extracted key attributes for each vulnerability. It also calculated a new field, ImageAgeDays, by finding the difference between our scan date (October 1, 2025) and the retrieved last_updated timestamp. The final structured dataset was created with a schema designed to capture all essential information, as detailed in Table 3. 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 (using a union of findings from both scanners). •For RQ2 (Staleness Analysis): We performed a Spearman rank correlation analysis to measure the relationship between ImageAgeDays and the total vulnerability counts. 9 the risk. A relatively small number of core OS packages were responsible for a disproportionately large number of severe vulnerabilities. As detailed in Table 5, fundamental libraries for system functions (libc6), cryptography (openssl), and network communication (curl) were among the most frequent offenders. This finding illustrates the systemic nature of the problem, where vulnerabilities in foundational "building blocks" represent a significant risk to the entire ecosystem. Table 5: Top 5 Most Frequently Vulnerable Packages (High & Critical, based on the 2,264 CVE union dataset) Rank Package Name High/Critical CVEs 1libc6 (glibc) 34 2openssl 26 3curl 21 4gzip 17 5linux-libc-dev 15 5.5. Threats to Validity While we have taken measures to ensure the rigor of our study, we acknowledge the following limitations. First, our findings represent a pointin-time analysis of a dynamic ecosystem. Second, while we mitigated our reliance on a single scanner by using both Trivy and Grype, our findings are still limited to the combined detection capabilities of these two tools and their underlying databases, which may contain false positives or negatives. Finally, our study does not empirically measure how many developers are currently using these stale images; rather, it provides a risk model for those organizations that are, for legacy or other reasons, required to do so. Our scope is limited to the static analysis of OS packages and does not assess runtime security risks or vulnerabilities in custom application code. 6. Conclusion and Future Work This paper presented a large-scale empirical analysis of 50 popular Docker images, focusing on the quantifiable risk of image staleness. Our findings confirm that the prevalence of high and critical severity vulnerabilities remains a significant problem. 16 The primary contribution of this work is the establishment of a strong, statistically significant correlation between image staleness and "vulnerability debt." We move the discussion beyond the obvious "old vs. new" comparison to a practical, data-driven model that quantifies the cost of maintenance neglect. This model provides a crucial tool for developers and managers to assess risk and justify the engineering costs of upgrading legacy systems. Furthermore, our multi-scanner analysis confirms that relying on a single scanner provides an incomplete security picture. The data illustrates that a "shift-left" security mindset is a practical necessity, requiring that automated vulnerability scanning and staleness checks be integrated as non-negotiable steps 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. Usage in the Wild: An important extension would be to conduct a large-scale study of public GitHub repositories to parse Dockerfiles and empirically measure the prevalence of stale image usage, thereby validating the real-world impact of the risk model presented in this paper. 3. 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. 4. 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. Acknowledgments The authors would like to acknowledge the use of Google’s AI assistant, Gemini, for assistance in refining the manuscript’s grammar, improving readability, and helping to structure the revised arguments. All data, analysis, and conclusions are the authors’ own. 17 References References [1] Dirk Merkel, Docker: Lightweight Linux containers for consistent development and deployment, Linux Journal 2014 (239) (2014) 2. [2] Deqing Huang, Sheng Wen, Haibo Cui, Changzhen Huang, Security Analysis and Threats Detection Techniques on Docker Container, In: 2019 IEEE 5th International Conference on Computer and Communications (ICCC), IEEE, 2019, pp. 1214–1220. [3] Shafqat Rehman, Kashif Mustafa, Research on Software Design Level Security Vulnerabilities, ACM SIGSOFT Software Engineering Notes 34 (6) (2009) 1–7. [4] Jayanth Gummaraju, Tarun Desikan, Yoshio Turner, Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities, Technical Report, BanyanOps, 2015. [5] Theo Combe, Antony Martin, Roberto Di Pietro, To Docker or Not to Docker: A Security Perspective, IEEE Cloud Computing 3 (5) (2016) 54–62. [6] Rui Shu, Xiaohui Gu, William Enck, A Study of Security Vulnerabilities on Docker Hub, In: Proceedings of the Seventh ACM Conference on Data and Application Security and Privacy (CODASPY ’17), ACM, 2017, pp. 269–280. [7] Ahmed Zerouali, Tom Mens, Gregorio Robles, Jesus M. GonzalezBarahona, On the Relation Between Outdated Docker Containers, Severity Vulnerabilities, and Bugs, In: Proceedings of the IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER), IEEE, 2019, pp. 491–501. [8] Mamoona Humayun, Muhammad Niazi, Noor Jhanjhi, Mohammed Alshayeb, Saad Mahmood, Cyber Security Threats and Vulnerabilities: A Systematic Mapping Study, Arabian Journal for Science and Engineering 45 (2020) 3183–3203. [9] K. Sri B., K. M. Exploring Large Scale Docker Image Vulnerability and Storage Performance Analysis using High Performance Container-Based 18 Docker Environment, In: 2024 International Conference on System, Computation, Automation and Networking (ICSCAN), IEEE, 2024. Appendix A. List of Scanned Docker Images The 50 images selected for this study are listed in Table A.6. 19 Table A.6: 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 20