Paper deep dive
Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images
Cristhian Kapelinski, Beatriz Machado, Diego Kreutz
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 8/5/2026, 3:59:45 AM
Summary
This paper introduces ChimangoScan, a pipeline that crawls Docker Hub to reconstruct image layer graphs and rank repositories by an exposure score combining pull counts and downstream inheritance. It scans the top 52,895 highest-exposure images with six independent scanners, revealing that vulnerabilities are near-universal (96.3% of images) but inter-scanner agreement is low (only 2.7% of vulnerabilities flagged by all three vulnerability scanners). The study highlights that single-tool measurements are largely artifacts of the specific scanner used and that exposure does not predict vulnerability prevalence.
Entities (12)
Relation Signals (14)
TruffleHog → detects → secrets
confidence 95% · hardcoded secrets across 700+ detectors (TruffleHog)
OSV-Scanner → detects → vulnerabilities
confidence 95% · package vulnerabilities from three databases (...OSV-Scanner...)
Grype → detects → vulnerabilities
confidence 95% · package vulnerabilities from three databases (...Grype...)
Trivy → detects → vulnerabilities
confidence 95% · package vulnerabilities from three databases (Trivy...)
Dockle → detects → misconfiguration
confidence 95% · misconfiguration against the CIS (Center for Internet Security) Docker Benchmark (Dockle)
Docker Hub → hosts → images
confidence 95% · Docker Hub hosts over 14 million images
ChimangoScan → uses → Trivy
confidence 95% · Stage III serves the exposure-ordered queue to workers that pull each image pinned by digest and run six static scanners... Trivy
ChimangoScan → uses → Syft
confidence 95% · software inventory (Syft)
ChimangoScan → uses →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Docker Hub is the registry underneath most container deployments, and a flaw in a widely reused base image is inherited by every image built on it. Prior ecosystem-scale measurements each rely on a single detector, leaving the tool-dependence of their counts unquantified, while the studies that do compare scanners use samples of tens to hundreds of images. We present ChimangoScan, a pipeline that crawls the Docker Hub namespace (12,716,568 repositories, 663.8 billion cumulative pulls), reconstructs the image layer graph (54.4 million IS_BASE_OF edges), ranks images by an exposure score that folds an image's own pull count and those of its entire downstream subtree into one scalar, and scans the 52,895 highest-exposure repositories (84.7% of all recorded pulls) with six independent scanners, yielding 170.4 million findings. Vulnerabilities are near-universal: 96.3% of images carry a known package vulnerability, 93.4% a critical one, and 98.0% at least one CIS Docker Benchmark misconfiguration. The posture a single tool reports is largely an artifact of that tool: of 80.7 million distinct (vulnerability, package) groups, 66.8% are flagged by only one of the three vulnerability scanners and just 2.7% by all three, and the best single scanner recovers 66.9%. TruffleHog flags a secret in 76.9% of images, yet hand-labeling 1,100 random detections finds 99.7% are non-credentials. A single zlib CVE reaches images carrying 47.3% of total corpus exposure and propagates to 1.13 million distinct downstream images, but exposure does not predict how vulnerable an image is. We release the pipeline and the 283 GB dataset.
Tags
Links
- Source: https://arxiv.org/abs/2608.02669v1
- Canonical: https://arxiv.org/abs/2608.02669v1
Trouble viewing inline? Open PDF directly →
Full Text
46,587 characters extracted from source content.
Expand or collapse full text
Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images Cristhian Kapelinski ∗ , Beatriz Machado ∗ , Diego Kreutz ∗ ∗ AI Horizon Labs, Federal University of Pampa (UNIPAMPA), Alegrete, Brazil cristhianavila, beatrizmachado.aluno@unipampa.edu.br, diegokreutz@unipampa.edu.br Abstract Docker Hub underpins containerized software, yet large-scale security measurements of its images are infrequent and rely on a single scanner. We present ChimangoScan, a pipeline that crawls Docker Hub and ranks images by a layer-graph exposure score: its pull count plus those of every image inheriting its layers. From a 12.7 million-repository crawl we scanned the 52,895 highest-exposure images, covering 84.7% of all 663.8 billion recorded pulls, with six open-source scanners (170.4 million findings). Known vulnerabilities are near-universal. 96.3% of images carry one, 93.4% carry a critical one, and 98.0% carry a misconfiguration. Yet the reported posture depends heavily on the scanner. Of the distinct vulnerabilities the three vulnerability scanners find, only 2.7% are reported by all three and 66.8% by one. Secrets show the opposite pattern. TruffleHog flags 76.9% of images, yet 99.7% of its hits are non-credentials by hand-labeling. A lone scanner’s count is thus largely an artifact of that scanner. Index Terms Docker Hub, Container Security, Software Supply Chain, Vulnerability Scanners, Empirical Measurement. I. INTRODUCTION Software supply chain attacks are projected to cost USD 60 billion in 2025, up from USD 46 billion in 2023; Gartner estimated 45% of organizations would face one by 2025, and over 700,000 malicious open-source packages have now been cataloged. 1 Containers sit on that supply chain, and Docker Hub is the registry underneath: 92% of IT professionals report using containers, and over half of organizations run most or all of their applications in containers. 2 Docker Hub hosts over 14 million images and advertises “11B+ monthly image downloads”; 3 cumulatively, our crawl sums 663,779,362,551 historical pulls (about 663.8 billion) across 12,716,568 public repositories (Section I-A). When a developer writes FROM python:3.12, what runs in production is pulled unmodified from an image someone else published, and a flaw in that base is inherited by every image built on it. The reach can be enormous; alpine draws 11.8 billion pulls of its own, but images built on its layers add roughly 71 billion more, so one critical vulnerability in alpine reaches about 83 billion inherited pulls. This parent-to-child propagation, first documented by Shu et al. [17], makes the registry a software-supply-chain attack surface [9] whose reach varies widely. A critical flaw in alpine:latest reaches the whole ecosystem, while the same flaw in an unused leaf image reaches almost nothing. ChimangoScan captures this with an exposure score (Section I-C). Since images also leak credentials and ship insecure defaults, a faithful measurement must look beyond CVE (Common Vulnerabilities and Exposures) counts. Yet prior ecosystem-scale measurements each rely on a single detector: Shu on Clair [17], Liu on one bespoke tool [10], Dahlmanns on one secret-detection pipeline [5], and Dr. Docker on one SCA (Software Composition Analysis) engine over 3,000 of its 33,952 images [16]. Each count thus carries unquantified tool-dependence. The studies that do compare scanners use small samples (Kaur et al., a pairwise Jaccard overlap of 0.59 to 0.80, on a 0-to-1 scale where 1 is identical, over 44 images [8]; Churakova et al., best pair 0.69 over 48 images [3]; Javed and Toor, 59 images [7]; Mills et al., 380 images [12]). No prior work crosses the two axes at ecosystem scale. This paper addresses that gap with ChimangoScan, a pipeline that crawls the Docker Hub namespace, reconstructs the image layer graph, ranks images by downstream exposure, and scans the highest-exposure ones with six independent scanners. Its contributions are (i) the exposure score E(I) (Section I-C), the first to fold an image’s own pull count and those of its entire downstream subtree into one scalar; (i) a six-scanner measurement of all 52,895 top-ranked repositories (170.4 M findings), two orders of magnitude more images than prior multi-scanner studies (Section IV-A); (i) an ecosystem-scale measurement of inter-scanner disagreement (Section IV-C), showing that the posture a single tool reports is substantially an artifact of that tool (only 2.7% of distinct vulnerabilities are flagged by all three vulnerability scanners, and 99.7% of TruffleHog’s hits, found in 76.9% of images, are non-credentials by hand-labeling); and (iv) a public dataset (Section I-E) released with the pipeline (metadata for 12,716,568 repositories, the layer graph, and the multi-scanner reports for the 52,895 scanned images). 1 Cybersecurity Ventures, 2023, Sonatype, 2024 2 Docker, 2025 survey, CNCF, 2024 3 Docker Hub arXiv:2608.02669v1 [cs.CR] 2 Aug 2026 I. RELATED WORK Table I positions ChimangoScan against three lines of prior work: large-scale security measurements of Docker Hub, studies of inter-scanner agreement, and studies of secrets and misconfiguration in container images. Table I: Positioning against prior work. WorkYearImagesScannersVuln.Misconfig.Secrets Cross- scanner Shu et al. [17]2017356,2181✓✗ Zerouali et al. [20]20197,3801✓✗ Liu et al. [10]20202,227,2441✓✗ Wist et al. [19]20212,5001✓✗ Dahlmanns et al. [5]2023337,1711✗✓✗ Dr. Docker [16]202533,9521✓✗ Kaur et al. [8]2021444✓✗✓ Mills et al. [12]20233806✓✗✓ ChimangoScan (this work)202652,8956✓ Large-scale Docker Hub measurements. Docker Hub has been measured periodically since Shu et al. [17], whose DIVA tool scanned 356,218 images with Clair, found >180 vulnerabilities/image, and traced parent-to-child propagation. Liu et al. [10] scaled to 2.2 million images and found 42 malicious ones, and Zerouali et al. [20] measured technical lag (how far a package trails its latest fixed version) in 7,380 Debian-based images. All three used a single detector. A complementary line reconstructs ecosystem structure: Opdebeeck et al. [13] build an inheritance network from 636,625 images, the closest prior work to our layer graph but at a fraction of the scale and without multi-scanner measurement. The closest work. Dr. Docker [16] crawls 12,079,309 repositories, 637,259 fewer than our 12,716,568, builds an ancestry-hashed layer graph, selects influential images, and scans 33,952 images for five threat classes. ChimangoScan adopts two of its ideas, the cap-refining keyword crawl and the ancestry-hashed layer identifier, and forks its open Go codebase (Section I): we implement Stage I, an unimplemented stub upstream, and re-engineer Stage I for distributed, resumable operation. It departs in two respects: (i) scale and tooling: Dr. Docker scans only 3,000 sampled images for vulnerabilities with one SCA engine, whereas ChimangoScan runs six scanners on all scanned repositories; (i) reproducibility: its malware verdicts use a corporate antivirus, whereas ChimangoScan uses only open-source scanners. Further related lines. Scanner agreement has been measured only on small samples (four scanners, 44 images, Jaccard 0.59 to 0.80 [8]; six scanners, 380 images [12]). We revisit this question at the scale of our corpus. For secrets and misconfiguration, Dahlmanns et al. [5] found secrets in 8.5% of images and over 52,000 private keys, building on repository secret-leakage work [11]. Rosa et al. [14] and Cito et al. [4] study Dockerfile smells, and Ahamed et al. [1] derive audit use cases that align image checks of this kind (content trust, HEALTHCHECK, non-root user) with the NIST SP 800-190 and OWASP container-security guidelines. ChimangoScan covers secrets (TruffleHog) and misconfiguration (Dockle) in the same pipeline. I. THE CHIMANGOSCAN MEASUREMENT PIPELINE ChimangoScan is a three-stage pipeline (Figure 1). Stage I discovers Docker Hub repositories; Stage I resolves each into concrete images and reconstructs the image layer graph; Stage I scans images, prioritized by the layer graph, with six independent scanners. Stages I and I are written in Go, Stage I in Python. Two methodological ideas are adopted from Dr. Docker [16] and credited where used: the keyword crawl that recursively refines any query saturating the API’s result cap (Stage I) and the ancestry-hashed layer-node identifier (Stage I). We fork Dr. Docker’s open Go codebase, implementing the crawl (a stub upstream) ourselves and re-engineering the layer-node builder for distributed operation (Sections I-A and I-B). The new pipeline elements are the exposure-based prioritization of the scan queue (Section I-C) and the six- scanner consolidation pipeline of Stage I (Section I-D). a) Terminology.: We use four distinct nouns throughout. A repository is a namespaced bucket on Docker Hub (e.g. library/alpine); the Hub reports a single pull count per repository. A tag (e.g. latest, 3.18) is a mutable label inside a repository pointing to a specific image. An image is identified by a content-addressed sha256 digest; two repositories or tags may share a digest when byte-identical, and every aggregate statistic in this paper deduplicates by image digest. A layer is one filesystem slice inside an image, identified by its own digest and shared across images built from the same base; the IS_BASE_OF layer graph of Section I-B captures that sharing. Stage I enumerated 12,716,568 repositories; Stage I resolved the most-pulled repositories (the popularity head) in decreasing pull-count order, down to roughly 72 pulls (44.05% of the crawl, Section I-B), so the layer graph and the downstream-propagation counts built on it (Section IV-G) are lower bounds over the full namespace. 1 Dockerhub API 23 Crawler (Go) Repository discovery via prefix search (12,716,568 repositories) Builder (Go)Multi-scanner scan Pull → Extract, Layer Forest, Exposure E(I) (6 scanners per image) (84.7M nodes & 54.4M edges) Figure 1: The three-stage pipeline. A. Stage I: Repository Discovery Stage I enumerates the Docker Hub namespace through the public Search API. Because the API caps any query at 10,000 results, a crawler must refine any keyword whose query saturates the cap (the cap-refining idea of Dr. Docker [16]); we realize this as a prefix-trie traversal of repository names, seeding 38 single-character prefixes (a to z, 0 to 9, -, _) and expanding any prefix that returns the 10,000-result ceiling into its 38 children (py→ pya, pyb, . . . ), shortest-first. The crawler is a distributed, resumable Go system and ran over several months in 2026. One caveat bounds exhaustiveness: the API’s ElasticSearch backend treats the hyphen as a token separator, so repository names with a hyphen in the middle are explored only best-effort; we are not aware of repositories missed this way but cannot rule it out. By scan time the crawler had indexed 12,716,568 repositories from 2,051,801 prefix queries (all in 2026), recording each one’s pull count, stars, and last-updated timestamp. Docker advertises “14M+ container images”; our 12.7 million repositories (each holding many tags) cover very nearly the entire public namespace, since every cap-saturated prefix was expanded. The 663.8 billion pulls of Table I are a cumulative historical total, not Docker’s “11B+ monthly”. The pull-count distribution (reproducing Dr. Docker [16]) is extremely heavy-tailed: a median of 62 pulls but a 99th percentile of 20,781 and a maximum of 2.4×10 10 , with 113 repositories drawing 60.6% of all pulls and 95% pulled fewer than a thousand times (Table I 4 ). The layer graph shows the same concentration structurally: only a small minority are base images, with heavy- tailed downstream counts. A uniform sample would thus spend almost all its effort on images the ecosystem barely uses; the exposure score (Section I-C) exploits exactly this imbalance. Table I: Repository pull-count distribution over the crawl. Pull countRepos% pullsPull countRepos% pulls ≥1 B11360.6%100 k–1 M42,1452.1% 100 M–1 B46120.1%1 k–100 k572,6620.8% 10 M–100 M2,59511.1%<1 k12,050,759<0.1% 1 M–10 M11,8565.3%Total12,680,591100% B. Stage I: Image Resolution and the Layer Graph A repository is not an image: it is a set of tags, each resolving to one or more architecture-specific image digests. The Stage I builder claims each repository exclusively from the crawl pool (so none is processed twice), queries the Docker Hub API for each one’s tags and manifests, then pulls each image and extracts the ordered list of filesystem layers that compose it. The builder consumes repositories in decreasing pull-count order, so the popularity head is processed first; at the dataset freeze used in this paper Stage I has resolved 5,601,045 of the 12.7 M crawled repositories (44.05%) into 6,399,608 tags and 7,416,671 image digests, with the remaining tail of rarely pulled repositories still pending. Layers are the unit of reuse: an image built FROM python:3.12 physically shares that base’s layers, and ChimangoScan reconstructs this sharing as a directed graph. For the layer-node identifier we adopt Dr. Docker’s ancestry-hashed scheme [16], instantiated with SHA-256: id = sha256(parent_id∥ sha256(layer_digest)), so the identifier encodes the layer’s full ancestry and identical-content layers with different histories stay distinct. Our builder is a distributed Go service: each worker atomically claims the next unbuilt repository from a shared MongoDB pool (resumable after crashes, stale claims released), pulls its recent tags and manifests, extracts the ordered layer list, and inserts IS_BASE_OF edges from each layer to the one above 4 The distribution covers the 12,680,591 repositories with a recorded pull count; 35,977 of the 12,716,568 crawled lack one. it. Repositories deleted between crawl and build are retired rather than stalling the queue. The deterministic identifier gives each layer at most one parent, so the graph is a forest of out-trees (disjoint trees with all edges pointing away from the root), stored in Neo4j with 54,382,383 IS_BASE_OF edges over 84.7 M nodes. A flaw in a reused base layer is therefore inherited by its whole subtree. The exposure prioritization on this forest (Section I-C) is specific to this work: Dr. Docker ranks by dependency weight, its count of downstream images, whereas ChimangoScan folds an image’s own pull count and its downstream reach into the single score E(I). C. Exposure-Based Prioritization Scanning all 6.7 M images is infeasible, and they are not equally worth scanning: a flaw in a base image thousands inherit risks far more than one in a rarely pulled leaf. ChimangoScan ranks the queue by an exposure score that rewards downstream reuse. Prior work ranks bases by descendant count [17] or by dependency-graph weight [16]; exposure instead folds an image’s own popularity and that of its entire downstream subtree into a single scalar (the container-layer analog of dependency-graph impact scoring [15]), linearly ordering the queue by total ecosystem reach. For an image I , write R I for the repository publishing I , p(R) for the pull count of a repository R, L I for I ’s top layer, and D(L I ) for the set of images whose top layer is a strict descendant of L I in the forest; a descendant image D ∈D(L I ) is published by repository R D . Because bases nest, we attribute each image to a single owner, the image of greatest own pull count among it and its ancestors, so no downstream pull is double-counted. Exposure is then I ’s own pull count plus those of every image it owns: E(I) = p(R I ) + X D∈D(L I ) owner(D) = I p(R D ).(1) The queue is sorted by E(I), with ties broken by the downstream image count |D(L I )| (Dr. Docker’s dependency weight [16]). Single-owner attribution credits each downstream pull to the most-pulled base in its lineage, and a daemon recomputes the scores in a near-linear pass as the crawl grows, placing alpine:latest first (E ≈ 8.3 × 10 10 ). Two rules guard against misplaced credit. A byte-identical republication (a bare FROM) is credited to the canonical most-pulled reference, and a generic metadata-only layer (LABEL, CMD) recurring under many parents is barred from owning downstream images; both rules only move credit toward the more-pulled base. Because Stage I resolves only recent tags, a subtree’s owner is occasionally a less-pulled repository pinning the same base; this occurs only among the least-pulled repositories Stage I resolved. The ranking head has two kinds of image. General-purpose bases (alpine, ubuntu, debian) draw 72% to 86% of their exposure from downstream images. Heavily pulled application images (nginx, memcached, busybox, Istio) are seldom used as a base, so their exposure is almost all their own pulls. D. Stage I: The Multi-Scanner Scan Pipeline Stage I serves the exposure-ordered queue to workers that pull each image pinned by digest and run six static scanners covering four dimensions: software inventory (Syft); package vulnerabilities from three databases (Trivy, Grype, OSV-Scanner, over the National Vulnerability Database (NVD)/OSS-Index, the Anchore VulnDB, and Google’s Open Source Vulnerabilities (OSV) database respectively, so each detects CVEs the others miss); misconfiguration against the CIS (Center for Internet Security) Docker Benchmark (Dockle); and hardcoded secrets across 700+ detectors (TruffleHog). The queue is keyed by each repository’s latest tag, so the reported posture is one of latest tags, not all published tags. A per-scanner adapter normalizes each output to a common six-level severity scale; TruffleHog secrets are marked critical only when verified live, otherwise medium. Findings are then consolidated per image but not deduplicated across scanners, so a CVE found by three scanners counts three times. That non-deduplication is what makes inter-scanner agreement measurable (Section IV-C). E. Dataset The scan ran on 13 commodity x86-64 workers (Debian 12 or Ubuntu 24.04, 8 to 32 threads, 32 to 128 GB of RAM, no GPU), each scanning linux/amd64 images. The unit is the repository reference, one latest image per repository; the campaign scanned the 52,895 highest-exposure ones (84.7% of all 663.8 billion recorded pulls), and deduplicating by content digest to 51,751 distinct images leaves the results essentially unchanged. The reports total 170,373,044 findings (141.7 M package vulnerabilities, 23.2 M inventory components, 4.96 M secrets, 0.58 M misconfigurations; Trivy’s built-in secret and misconfiguration checks feed the latter two categories alongside TruffleHog and Dockle); we release the full dataset with the pipeline (Table I). IV. RESULTS ChimangoScan scanned the 52,895 highest-exposure repositories, a census of the most consequential images on Docker Hub, not an upper bound over the whole registry. Exposure does not predict vulnerability (Section IV-F). Table I: Dataset summary. Crawl and layer graph Repositories crawled12,716,568 Repositories Stage I-resolved5,601,045 Prefix queries issued2,051,801 Tags resolved6,399,608 Image digests resolved7,416,671 Layer nodes84.7 M IS_BASE_OF edges54,382,383 Images in scan queue6.7 M last_updated coverage (crawl)95.7% Scan campaign (Stage I) Repositories scanned52,895 Distinct images by content51,751 Scanners per image6 Worker machines13 (Debian/Ubuntu) Median scan time / image117 s Distinct CVEs detected52,624 Per-image reports (DB)192 GB MongoDB crawl24.9 GB Neo4j layer graph65.9 GB Total dataset283 GB Merged findings by category(52,895 repositories, total 170,373,044) CategoryFindingsShare Scanners Img.≥1 Package vulnerabilities141,683,960 83.2%396.3% Software-inventory components23,151,449 13.6%196.3% Embedded secrets4,955,8922.9%276.9% Misconfigurations581,7430.3%298.0% A. Vulnerability Prevalence Known vulnerabilities are pervasive. Of the scanned repositories, 96.3% carry at least one known package vulnerability (only 3.7% are clean), 93.4% ship a critical-severity one and 95.5% a high-severity one; the per-image count is heavily right-skewed (Figure 2(a)): the median image carries 885 merged findings, the mean is 2,679, the 99th percentile 20,109, and the maximum 113,166. These counts are merged, not deduplicated across scanners, which inflates the mean (Section IV-C). Across the 141.7 million package-vulnerability findings (Table IV), 5.2% are critical and 25.2% high, a combined 43.1 million; because a base image’s layers are inherited by every image built on it (Section I-B), each critical finding in a widely reused base propagates across its entire downstream subtree. Table IV: Package-vulnerability findings by severity. CriticalHighMediumLowInfo.UnratedTotal Findings7,377,35535,740,34365,727,71319,418,0029,927,5893,492,958141,683,960 % of findings5.225.246.413.77.02.5100 Images≥149,39250,53450,87249,95133,70837,39350,957 % of images93.495.596.294.463.770.796.3 05k10k15k20k Vulnerabilities per image 0.00 0.25 0.50 0.75 1.00 Cumulative fraction median 885 (a) Syft Trivy Grype OSV Dockle TrufHog Scanner 0 20M 40M 60M Findings (b) criticalhighmediumlowinfounknown Syft Trivy Grype OSV Dockle TrufHog Scanner 0 20 40 60 80 Wall time per scan (s) (c) Figure 2: Per-image: (a) cumulative vulnerability distribution, (b) by scanner/severity, (c) scan time. B. Per-Scanner Output, Reliability and Cost The six scanners measure different things, and their volumes are not comparable across categories (Table V, Figure 2(b)): among the three vulnerability scanners Grype emits the most findings (59.1 M), followed by Trivy (45.0 M) and OSV- Scanner (38.0 M). Syft inventories 23.2 M software components, TruffleHog reports 4.9 M secret findings and Dockle 0.24 M misconfigurations. Reliability varies sharply. The share of images scanned without error was 94.6% to 98.8% for five scanners but only 79.9% for Trivy (10,614 invocations errored). The failures are specific to Trivy, not to the infrastructure. All six scanners run against the same locally exported image archive (Section I-D), yet Syft and Grype error on only about 1,200 to 1,900 images each. Four in five of Trivy’s error messages report a timeout acquiring the tool’s local cache lock (“cache may be in use by another process”), a concurrency limitation of the scanner under parallel operation rather than a property of the images scanned. A measurement that relied on Trivy alone would therefore silently miss roughly one image in five. Table V: Findings by scanner and severity. ScannerFindingsCriticalHighMediumLowRun OK Syft23,151,449–97.7% Trivy44,957,5611,478,6799,813,22425,275,0778,069,52579.9% Grype59,061,3362,163,55211,733,73325,802,1469,354,13596.4% OSV38,046,3733,741,59514,304,38314,738,7002,169,97494.6% Dockle235,02945,411–42,587147,03198.0% TruffleHog4,921,2962,20904,919,087098.8% The measurement is also costly. Grype is the slowest at 35.1 s per image, and running all six on one image took a median of 117 s (Figure 2(c)); the mean of 197 s is inflated by a tail reaching 9,433 s. Syft found a median of 205 components per image (mean 438, maximum 51,021; Figure 3(c)), dominated by npm (33.7%) and deb (28.2%), then Java, Go and .NET (Figure 3(a)). 02M4M6M8M SBOM components python apk rpm dotnet go-module java-archive deb npm 718k 809k 910k 1.6M 1.8M 2.0M 6.5M 7.8M (a) 0500k1M1.5M2M Secret detections FixerIO Confluent Alchemy GitHubOauth2 BingSubscrip.. PrivateKey URI Box 98k 103k 150k 190k 209k 281k 559k 2.1M (b) 01k2k3k Components per image 0.00 0.25 0.50 0.75 1.00 Cumulative fraction median 205 (c) Figure 3: (a) Components by ecosystem, (b) secrets by detector, (c) components per image. C. Inter-Scanner Divergence Running three vulnerability scanners on every image lets us quantify how much the measurement depends on the tool. We group the package-vulnerability findings within each image by (vulnerability, package). Of the 80.7 million distinct groups, 66.8% are reported by only one scanner and just 2.7% by all three (Figure 4(a)); even the closest pair, Grype and Trivy, co-detect only 22.2 M. The divergence also shows in the aggregate counts. Grype reports 59.1 M findings against OSV’s 38.0 M, a 1.55× spread (Table V). The best single scanner recovers only 66.9% of distinct groups (Figure 4(a)), so a one-tool measurement misses about one distinct vulnerability in three. Figure 4(b) shows the marginal gain of each added scanner, and Figure 4(c) contrasts merged findings with distinct groups per severity. This is consistent with the small-sample scanner- agreement literature [8, 12], here at the scale of our full corpus: a single Docker Hub vulnerability count reflects, in large part, the scanner used to obtain it. 16.4M28.3M 9.2M 22.2M 1.0M1.4M 2.2M TrivyGrype OSV-Scanner (a) scanner agreement 123 Number of vulnerability scanners 0 25 50 75 100 Distinct vulns recovered (%) 45% 78% 100% (b) marginal Nth-scanner gain cumulative marginal gain Crit. High Med. Low Info Unr. 10 6 10 7 10 8 Vulnerability count (c) all vs distinct, by severity all findings distinct (CVE, pkg) Figure 4: Inter-scanner divergence: (a) groups by subset, (b) N th-scanner gain, (c) all vs. distinct by severity. D. Secrets and Misconfiguration Beyond vulnerabilities, ChimangoScan measures two further dimensions. Dockle flagged at least one misconfiguration from the CIS Docker Benchmark in 98.0% of images (51,853 of them); the most frequent (Table VI) are a missing content-trust configuration, a missing HEALTHCHECK instruction, and the container running as root. Of Dockle’s findings, 45,411 are at its FATAL checkpoint level, which we treat as critical severity. These flag concrete security faults: the most consequential is a credential stored in an environment variable or file (check CIS-DI-0010), which Dockle raised for 10,303 images, and others include an empty user password and the presence of sudo in the image. These counts rest on structural properties of the image rather than on verdicts from a vulnerability database, so they are less tied to any single scanner’s vulnerability feed, though we do not measure their scanner-to-scanner stability directly. The near-universal prevalence is in line with studies of Dockerfile authoring practice, which find Dockerfile smells in a large share of images [6]. TruffleHog flagged at least one embedded secret in 76.9% of images (40,667 images, 4.9 M secret findings). This raw prevalence must be read with care. It counts detector hits, that is, strings matching a detection pattern, not exploitable credentials. As Dr. Docker and Dahlmanns et al. [16, 5] document, the large majority of TruffleHog hits are example keys, test fixtures, or already-public material; Dr. Docker found 99.3% of its raw detections invalid after filtering. We confirm this directly on our corpus. We drew a uniform random sample of 1,100 detections (95% confidence, ±3% margin) and classified every one by hand, rather than only the residual left after rule-based filtering. Just three were plausible live credentials: an application service-account key, an SSH host key, and an access token captured in an application log. The other 1,097 (99.7%, Wilson 95% CI 99.2 to 99.9%) are non-credentials. About 60% are package checksums and OS metadata; the rest are test fixtures, dependency caches, documentation examples, placeholders, and binary or locale artifacts. Every PrivateKey detection but the service-account key fell in a crypto-library self-test, an SSH/TLS test fixture, or a shared object. The 76.9% detector-hit prevalence is therefore an upper bound dominated by false positives: only about 0.3% of detections are plausible credentials, so the prevalence of validated secrets is far lower. Active validation of these residual candidates is left to future work (Section V). The detector mix (Figure 3(b)) corroborates this. Generic URI and private-key patterns dominate, exactly the categories most prone to false positives from example values. Beyond prevalence, the distribution of how many secrets an image carries is itself heavy-tailed (Figure 5). The median image carries 13 detector hits, but the 99th percentile reaches 1,230 and the image with the most hits reports 19,856. Official images, although slightly more likely to carry at least one secret (Section IV-E), carry far fewer of them; their per-image count tops out at 1,251 against the community tail above 19,000. This is consistent with Dahlmanns et al. [5], who likewise found that a minority of images account for most embedded secrets; here the distribution makes that concentration explicit. Table VI: Top Dockle misconfiguration checks. Misconfiguration checkImages% Content-trust off (CIS-DI-0005)51,84798.0 No HEALTHCHECK (CIS-DI-0006)49,79294.1 No dedicated user (CIS-DI-0001)41,86379.1 setuid/setgid files (CIS-DI-0008)31,78560.1 Credential in env/file (CIS-DI-0010)10,30319.5 Empty user password (DKL-LI-0001)4,8679.2 sudo present (DKL-DI-0001)4,1687.9 Figure 5: Secret detections per image (CDF): official vs. community. 10 0 10 1 10 2 10 3 10 4 TruffleHog secret detections per image 0.00 0.25 0.50 0.75 1.00 Cumulative fraction Community Official E. Official versus Community Images Splitting the corpus by namespace (official images occupy library) reproduces Liu et al.’s [10] official-versus-community comparison (Figure 6(a)). The 130 official images carry a median of 455 merged vulnerability findings, the 52,765 community images 886 (means: 1,046 official, 2,683 community), and 50.0% of community images sit above the corpus median against 32.3% of official ones: community images remain the more vulnerable population, as Liu reported, though both now sit far higher in absolute counts. Secrets show the reverse ordering (Figure 6(b)): TruffleHog flags a secret in 86.9% of official against 76.9% of community images, but these are raw hits and the gap is modest. The same ordering held in Shu et al. [17] (community median 158 in 2017), so it persists across nine years even as counts rose. F. Popularity, Exposure and Security Posture A natural question for a popularity-ranked corpus is whether the images the ecosystem most depends on are better maintained. They are not. Raw pull count is essentially uncorrelated with distinct vulnerability count (Spearman rank correlation ρ =−0.01, OfficialCommunity 1 10 100 1k 10k 100k Vulnerabilities per image med. 455 med. 886 (a) 0255075100 Images (%) Vuln. above corpus median 1 secret 32% 87% 50% 77% (b) OfficialCommunity Figure 6: Official vs. community: (a) vulnerabilities per image, (b) secret prevalence and share above median. Figure 7(a)); our exposure metric (Section I-C), which adds the pulls flowing through an image’s downstream layer subtree, gives the same verdict. Across exposure deciles (Figure 7(b)) the median vulnerability count shows no clear trend (369 in the highest-exposure decile), with ρ =−0.02 for exposure against vulnerability count and ρ =−0.04 against critical-vulnerability count, both negligible. Critical prevalence stays near 93% across the higher-exposure deciles, so even the most heavily reused base images almost all ship a critical finding, echoing a Maven Central study where dependency centrality is not a safeguard against vulnerability [18]. 10010k1M100M10B Repository pull count 1 10 100 1k 10k Distinct vulnerabilities per image Spearman ρ = −0.008 (a) pull count 12345678910 Exposure decile (1 = lowest) 0 500 1000 1500 2000 Distinct vulnerabilities per image (b) exposure decile (ρ = −0.016) IQR median vuln. critical prev. 10 0 10 1 10 2 10 3 Images per bin 0 20 40 60 80 100 Images with a critical vuln. (%) Figure 7: (a) Vulnerabilities vs. pull count; (b) by exposure decile. G. Exposure-Weighted Vulnerability Risk Counting the images a CVE affects treats a flaw in alpine and a flaw in an abandoned image with no dependents as equal. Because every image in the corpus carries an exposure score, we can instead weight each CVE by the ecosystem reach of the images it affects. We sum exposure over the images that carry each CVE, which ranks vulnerabilities by the share of the ecosystem they can affect rather than by raw image count. In Table VII, “% expo.” is the share of total corpus exposure carried by the affected images. The ranking is dominated by recent CVEs in zlib and glibc, the C libraries embedded in nearly every base image, together with the Go standard library (stdlib) that ships inside the many Go-based images in the corpus: the single highest-reach CVE touches images accounting for 47.3% of the corpus’s total exposure while being present in only 44.9% of images by count. This gap between image count and exposure share is the central finding: a CVE in a base library is not just one of many; it endangers a share of the ecosystem far larger than its image count suggests, and the exposure metric makes that quantitatively concrete. The layer graph lets us go one step further and measure how far a vulnerability propagates. For each CVE we count the distinct downstream images that inherit a vulnerable layer. Starting from the images that directly carry the CVE, we take the union of their descendant subtrees in the IS_BASE_OF forest. Each distinct downstream image is counted once (Table VIII). Taking the union, rather than summing each affected image’s downstream count, avoids double-counting the descendants that several affected base images share. The reach is nonetheless large. Each top CVE is inherited by 1.0 to 1.14 million distinct downstream images, a propagation factor (distinct downstream over directly affected images) of 39 to 49, with a single zlib flaw reaching 1,129,391. These counts quantify, on the reconstructed IS_BASE_OF forest, how far a single flaw spreads through the supply chain, and they render per-CVE the parent-to-child vulnerability inheritance that Shu et al. [17] first documented at the level of whole images. The top-reach CVEs sit in libraries that ship with nearly every base image (zlib, Table VII: Highest-reach CVEs by exposure. CVEPackageSev. Images % expo. CVE-2026-27171 zlibHigh23,72647.3% CVE-2026-4046 glibcHigh18,77446.5% CVE-2026-5928 glibcHigh18,59946.2% CVE-2026-5435 glibcCrit.18,54946.1% CVE-2026-5450 glibcCrit.18,08645.6% CVE-2026-33814 stdlib High12,87344.6% CVE-2026-33811 stdlib High12,77843.2% CVE-2026-39820 stdlib High12,77843.2% glibc, libcrypto3), so part of their reach reflects sheer ubiquity rather than the layer hierarchy; the columns of Table VIII separate these effects, with the direct count measuring how widespread the vulnerable library is among the scanned images and the propagation factor measuring the amplification contributed by layer inheritance alone. Direct counts are restricted to images resolved in the Stage I layer graph, so they sit slightly below the affected-image counts of Table VII. One caveat remains. The IS_BASE_OF graph spans only the Stage I-resolved fraction of the crawl, so these distinct-downstream counts are structural lower bounds; the true reach on Docker Hub is at least this large. Table VIII: Per-CVE downstream propagation. CVEPackageDirect Distinct downstr. Factor CVE-2026-28388 libcrypto3 28,3431,144,01040.4 CVE-2026-28390 libcrypto3 27,7681,134,32940.9 CVE-2026-28389 libcrypto3 27,7581,134,31940.9 CVE-2026-27171 zlib23,0131,129,39149.1 CVE-2026-28387 libcrypto3 23,8191,096,28446.0 CVE-2026-22796 libcrypto3 26,2791,033,46139.3 CVE-2025-68160 libcrypto3 26,2791,033,46139.3 CVE-2025-69421 libcrypto3 26,2781,033,45939.3 H. Comparison with Prior Measurements Absolute vulnerability counts are not comparable across studies, since the measurements differ in scanner, sample and elapsed time, and our own data shows a 1.55× inter-scanner spread in finding volume alone (Section IV-C); we therefore compare prevalence and orders of magnitude rather than raw counts. Known-vulnerability prevalence shows continuity, not reversal. Across 2017 to 2025 it has stayed high (Shu: >80% of images; Liu: >64% of community images; Wist: 81.8% of certified images; Mills: 98.4% of images, 374 of 380; Dr. Docker: 93.7% of images; each with a different metric and scanner). Our 96.3% is at the upper end of this range, on par with the most recent multi-scanner study (Mills, 98.4%), so prevalence has not declined over the eight years these studies span (Figure 8). 20172019202120232025 Year of measurement 50 60 70 80 90 100 Images with a known vulnerability (%) Shu 80% Zerouali 100% 64% Liu 82.2% Wist Mills 98.4% 93.7% Dr. Docker This work 96.3% Figure 8: Known-vulnerability prevalence across studies, 2017 to 2026. I. Reproducing Prior Docker Hub Analyses To ground the comparison in method, we reproduced one concrete analysis from each of six prior Docker Hub measurements on our corpus (Table IX; Figures 9 and 10). As above, these comparisons show trends, not exact replications. Table IX: Prior measurements reproduced on our corpus. StudyReproduced analysisReported by the studyThis corpus Shu et al. [17]Worst-severity bucket; community vuln. median high modal; community median 158critical modal (93.4%); median 885 Zerouali et al. [20]Vulnerabilities-per-image distributionmedian 601, mean 1,336, max 7,338median 885, mean 2,679, max 113,166 Liu et al. [10]High/critical prevalence, official vs. comm. ∼30% official, >64% community93.8% official, 95.6% community Wist et al. [19]Severe findings by ecosystem (OS vs. language) severe surface in language ecosystems76.9% OS, 21.7% language Mills et al. [12]Oldest CVE still present; staleness effectCVEs back to 1999CVEs back to 1999; median 414 (recent) vs. 1,085 (old images) Dahlmanns et al. [5]Secret prevalence; private-key category8.5% validated; private keys dominant76.9% hits, 99.7% FP (hand-labeled) a) Shu, Zerouali, Liu.: Shu et al. [17] classified images by worst severity, ranked vulnerable packages, and tracked CVEs by year (Figure 10): the most common (modal) worst severity has shifted from high to critical (Figure 10(a)); the 52,624 distinct CVEs reach back to 1999 but 68.4% are 2020-or-later (Figure 10(b)); and the top vulnerable packages remain operating- system libraries (zlib 44,574 images, openssl 39,209; Table X). Zerouali et al. [20] found essentially every Debian-based container affected; we reproduce this at 96.3% prevalence. Liu et al. [10] split official versus community (Figure 9(a)): the community-above-official ordering holds, but both populations now sit far higher. Official Community Image type 0 25 50 75 100 Images with high/critical vuln. (%) (a) Liu et al.\ 2020 30 64 93.8 95.6 Liu et al.\ 2020This corpus (2026) OS package ecosystems Language ecosystems Other Package ecosystem class 0 20 40 60 80 Share of high/critical findings (%) (b) Wist et al.\ 2021 76.9 21.7 1.5 Figure 9: Reproductions: (a) official vs. community prevalence [10]; (b) severe findings by ecosystem [19]. b) Wist, Mills, Dahlmanns.: Wist et al. [19] found severe vulnerabilities concentrated in language ecosystems; our corpus, ranked by exposure and dominated by OS images, inverts this (Figure 9(b)): of 43.1 million severe findings most are operating- system packages, with Go (5.3 M), npm (1.3 M) and Python (1.0 M) leading the language share. Mills et al. [12] noted CVEs back to 1999 and a staleness effect; both patterns hold in our corpus: images updated within a year carry a median 414 vulnerabilities against 1,085 for older ones (Figure 10(c)), consistent with the rising vulnerability lifespans reported across open-source ecosystems [2]. Dahlmanns et al. [5] found private keys dominant (8.5% validated); TruffleHog flags a private-key pattern in 40.2% of images, but our hand-labeling puts its false-positive rate at 99.7% (Section IV-D). none low medium high critical Most severe vulnerability 0 20 40 60 80 100 Images (%) (a) 3.7 0.6 2.2 93.4 199920032007 2011 2015201920232026 CVE publication year 0 2k 4k 6k Distinct CVEs detected (b) 02468 Image age (years since update) 0 2000 4000 6000 Vulnerabilities per image (c) median 75th pct. Figure 10: Shu et al. [17] reproduced: (a) worst severity, (b) CVEs by year, (c) vulns vs. image age. V. LIMITATIONS AND CONCLUSION Limitations. The corpus is not a random sample but the top of the exposure ranking, so prevalences describe the most consequential images, not the average one, and are not an upper bound (exposure does not predict vulnerability). The 76.9% Table X: Ten most prevalent vulnerable packages. PackageVuln. img. % corpusFindings CVEs Img. w/ crit. zlib44,57484.3%177,5031528,695 openssl39,20974.1% 2,597,92129027,479 tar32,03160.6%499,294270 util-linux28,55554.0%785,3492114 curl28,51653.9% 2,836,30418718,309 coreutils27,89652.7%142,134330 ncurses-base27,67152.3%372,917301,440 systemd27,34351.7% 1,121,059573,476 expat25,88648.9%649,5524716,282 bash25,85748.9%85,0971519 secret figure counts raw detector hits (99.7% non-credentials by hand-labeling), and reported vulnerabilities are likewise static scanner findings, not confirmed exploitable. Per-image counts are merged, not deduplicated (we report medians), and the unit is one latest image per repository (deduplicating to 51,751 digests leaves results unchanged). We scanned linux/amd64 only, and Stage I resolved only the most popular repositories (44%) and recent tags, so the propagation counts are lower bounds. Finally, the scan-reports database is frozen, but the crawl (MongoDB) and layer graph (Neo4j) are snapshots of a pipeline that kept running past the freeze, so the released copies sit a few percent above the counts reported here; every scan-derived result reproduces exactly from the frozen database, and the crawl- and graph-derived counts reproduce to within that margin. Practical implications. Three practices follow from the measurements. First, because the best single scanner recovers only 66.9% of distinct vulnerabilities (Section IV-C), audits and continuous-integration (CI) pipelines should run at least two vulnerability scanners backed by different databases rather than trust a single count. Second, exposure gives registry operators and platform teams a remediation order. It identifies the base images whose flaws reach the most pulls, so addressing those first targets the largest share of downstream inheritance, whereas ranking flaws by raw affected-image count alone would spend the same effort on images the ecosystem barely pulls (Section IV-G). Third, raw secret detections should not gate a deployment. With 99.7% of hits being non-credentials (Section IV-D), a validation step must precede any action on them, while the structural misconfigurations Dockle flags (running as root, missing HEALTHCHECK) are cheap to check and enforce in CI. Conclusion. We measured the security posture of the highest-exposure Docker Hub images, 5 the bases on which 84.7% of all recorded pulls depend, with six independent scanners rather than one. Vulnerabilities, critical ones, and misconfigurations are near-universal, yet the single number a lone tool reports is largely a property of that tool, so ecosystem-scale measurements should report a scanner battery, not a single count. Exposure marks where a flaw does the most damage yet does not predict how vulnerable an image is; resolving Stage I fully and validating the residual secrets are natural extensions. We release the pipeline and dataset for audit and reuse. 6 REFERENCES [1] Waheeda Syed Shameem Ahamed, Pavol Zavarsky, and Bobby Swar. Security audit of Docker container images in cloud architecture. In ICSCCC 2021, pages 202–207. IEEE, 2021. [2] Seyed Ali Akhavani et al. Open source, open threats? investigating security challenges in open-source software. arXiv preprint arXiv:2506.12995, 2025. [3] Yekatierina Churakova et al. Vexed by VEX tools: Consistency evaluation of container vulnerability scanners. In FPS 2025, Lecture Notes in Computer Science, pages 139–156, 2025. [4] Jürgen Cito et al. An empirical analysis of the Docker container ecosystem on GitHub. In MSR 2017, pages 323–333. IEEE, 2017. [5] Markus Dahlmanns et al. Secrets revealed in container images: An internet-wide study on occurrence and impact. In ASIA CCS ’23, pages 797–811. ACM, 2023. [6] Thomas Durieux. Empirical study of the Docker smells impact on the image size. In ICSE 2024. ACM, 2024. [7] Omar Javed et al. Understanding the quality of container security vulnerability detection tools. arXiv preprint arXiv:2101.03844, 2021. [8] Bhupinder Kaur et al. An analysis of security vulnerabilities in container images for scientific data analysis. GigaScience, 10(6):giab025, 2021. [9] Piergiorgio Ladisa et al. SoK: Taxonomy of attacks on open-source software supply chains. In S&P 2023, pages 1509–1526. IEEE, 2023. [10] Peiyu Liu et al. Understanding the security risks of Docker Hub. In ESORICS 2020, volume 12308 of Lecture Notes in Computer Science, pages 257–276. Springer, 2020. [11] Michael Meli et al. How bad can it git? characterizing secret leakage in public GitHub repositories. In NDSS 2019. Internet Society, 2019. [12] Alan Mills et al. Longitudinal risk-based security assessment of Docker software container images. Computers & Security, 135:103478, 2023. [13] Ruben Opdebeeck et al. The Docker Hub image inheritance network: Construction and empirical insights. In SCAM. IEEE, 2023. [14] Giovanni Rosa et al. Fixing Dockerfile smells: An empirical study. In ICSME 2022. IEEE, 2022. [15] Bonan Ruan et al. Propagation-based vulnerability impact assessment for software supply chains. In ASE, 2025. [16] Hequan Shi et al. Dr. Docker: A large-scale security measurement of Docker image ecosystem. In W ’25. ACM, 2025. [17] Rui Shu et al. A study of security vulnerabilities on Docker Hub. In CODASPY ’17, pages 269–280. ACM, 2017. [18] Ehtisham Ul Haq et al. The ripple effect of vulnerabilities in Maven central: Prevalence, propagation, and mitigation challenges. arXiv preprint arXiv:2504.04175, 2025. 5 Code and dataset: https://github.com/ChimangoScan/chimangoscan 6 Generative AI tools assisted with writing and language revision of this manuscript; the authors reviewed all content and take full responsibility for it. [19] Katrine Wist et al. Vulnerability analysis of 2500 Docker Hub images. In Advances in Security, Networks, and Internet of Things, Transactions on Computational Science and Computational Intelligence, pages 307–327. Springer, 2021. [20] Ahmed Zerouali et al. On the relation between outdated Docker containers, severity vulnerabilities, and bugs. In SANER 2019, pages 491–501. IEEE, 2019.