💻 computer science

Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images

本文介绍了 ChimangoScan，这是一个通过使用六个独立的扫描器来分析暴露程度最高的 Docker Hub 镜像的大规模流水线，研究揭示了漏洞和配置错误几乎是普遍存在的，扫描结果具有高度的工具依赖性且一致性较低，并且检测到的大多数密钥均为误报。

原作者： Cristhian Kapelinski, Beatriz Machado, Diego Kreutz

发布于 2026-08-05

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Cristhian Kapelinski, Beatriz Machado, Diego Kreutz

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，互联网是一座繁忙、喧闹的大都市，而软件就是这座城市的生命线。在这座城市里，大多数应用程序不再是从零开始构建的，而是像组装乐高积木一样，使用被称为“容器”的预制模块进行组装。这些容器就像标准化的运输箱，里面装载了运行应用程序所需的一切，从代码到工具。每个人存储和获取这些运输箱的中央仓库被称为 Docker Hub。它是软件供应链的核心，每月处理数十亿次的下载。

然而，就像真实的仓库一样，如果一个运输箱是用裂开的砖块（即漏洞）建造的，或者有一个松动的锁扣（即配置错误），那么每一个使用该运输箱构建出的建筑都会继承这个缺陷。更糟糕的是，有些运输箱里还藏着陷阱，比如留在了里面的敞开保险箱（密钥或密码）。多年来，安全专家一直试图统计这些危险运输箱的数量，但他们通常只依赖于一个“保安”（扫描器）来进行检查。这就像试图用只有一双眼睛的人去寻找整座城市所有的坑洼；你可能会漏掉很多，或者看到一些并不存在的问题。大问题在于：这个仓库到底有多危险？仅仅使用一个扫描器是否能让我们看到真实的景象？

伟大的 Docker 侦探行动

来自巴西的一个研究小组，自称为 ChimargoScan，决定通过一场大规模的多层调查来破解这个谜团。他们没有仅仅雇佣一名保安，而是建立了一个超级流水线，部署了 六种不同的扫描器 来检查 Docker Hub 仓库中最受欢迎的运输箱。他们的目标不仅是计算坏掉的运输箱有多少，还要弄清楚哪些运输箱最重要。

“暴露度评分”：为什么有些运输箱更重要

想象一下，一座摩天大楼的地基里有一块裂开的砖，与一个小花园棚里的砖相比，其影响完全不同。摩天大楼的缺陷是一场灾难；而小棚子的缺陷只是个小麻烦。研究人员意识到，仅仅计算一个运输箱被下载了多少次是不够的。他们需要知道有多少其他运输箱是基于它构建的。

他们创建了一个名为 暴露度评分（Exposure Score） 的新指标。把它想象成一个“危险半径”。如果一个基础镜像（例如一个流行的 Linux 版本）被下载了 100 次，但它同时也是另外 1,000 个被下载了 100 次的镜像的基础，那么它的暴露度评分就是巨大的。团队根据这个评分对前 52,895 个镜像进行了排名。这些不仅仅是下载量最高的镜像，更是那些其缺陷会波及最多人的镜像。总计，这些顶级镜像占据了历史上记录的所有 6638 亿次 拉取次数中的 84.7%。

研究结果：一个布满裂痕的城市

当 ChimangoScan 对这些高暴露度的镜像运行其六种扫描器时，结果清晰得令人震惊：几乎所有东西都是破损的。

漏洞无处不在： 96.3% 的镜像携带至少一个已知的软件漏洞。更可怕的是，其中 93.4% 具有“严重（critical）”漏洞，这种漏洞可以让黑客接管系统。
错误的配置是常态： 98.0% 的镜像存在配置错误，例如以“root”用户身份运行（这相当于把建筑物的总钥匙交给了一个陌生人）或缺少安全检查。
密钥问题很棘手： 扫描器在 76.9% 的镜像中发现了“密钥”（如密码或 API 密钥）。然而，当研究人员对这些命中项进行人工检查时，他们发现了一个巨大的陷阱：99.7% 的情况都是误报。这些只是示例密钥、测试数据或公开信息，而非真正的泄露凭据。扫描器之所以大喊“着火了！”，大多是因为闻到了烤焦面包的味道，而不是真正的火灾。

扫描器问题：单一工具是不够的

或许最重要的发现是关于工具本身。研究人员发现，这六种扫描器在观察到的内容上并不一致。

如果你只使用一种扫描器，你看到的危险程度将与使用另一种扫描器得到的结果截然不同。

在查看不同的漏洞时，仅有 2.7% 的漏洞是被三种漏洞扫描器共同发现的。
令人震惊的是，66.8% 的漏洞仅被其中一种扫描器发现。

这意味着，如果一家公司依赖单一的安全工具，他们很可能会错过三分之二的潜在问题。一个镜像的“安全得分”并不是一个绝对的事实；它在很大程度上取决于你使用了哪种工具来进行测量。

“继承”效应

研究还展示了当一个缺陷存在于流行的基础镜像中时，会产生多么危险的影响。他们发现，在像 zlib 或 glibc（几乎在每个基础镜像中都会用到）这样的库中，单个严重缺陷在理论上可以影响整个生态系统中 47.3% 的暴露度。流行基础镜像地基中的一块坏砖，不仅会伤害那一个镜像，还会危及构建在其上的整个应用程序家族树。

这对你意味着什么

研究人员得出结论，我们不能信任来自单一扫描器的单一数字。为了保障软件供应链的安全，我们需要：

使用多种扫描器： 由于没有任何一种工具能捕捉到一切，因此必须运行一系列不同的扫描器，才能获得真实的图景。
按暴露度进行优先级排序： 修复那些最“暴露”的基础镜像（即大家都在其上构建的镜像）中的缺陷，比修复那些晦涩、极少使用的镜像中的缺陷能挽救更多的人。
不要对每一个“密钥”警报感到恐慌： 由于大多数检测到的密钥都是误报，我们需要更好的方法在将其视为紧急情况之前进行验证。

简而言之，Docker Hub 仓库里布满了裂痕，而地基上的裂痕是最危险的。但我们衡量这些裂痕的方式，与裂痕本身一样重要。我们需要更多的眼睛投入工作，才能看到全貌。

技术摘要：高暴露度 Docker Hub 镜像中的漏洞、密钥与配置错误

问题陈述
Docker Hub 作为容器化软件供应链的基础注册表，托管了超过 1400 万个镜像，并促进了数百亿次的下载。然而，对这一生态系统进行大规模安全度量的情况并不频繁，且在历史上往往依赖于单一的漏洞扫描器。这种依赖性造成了难以量化的工具依赖问题，即报告的安全态势可能反映的是检测器的特定局限性，而非注册表的实际状态。此外，先前的研究往往未能考虑到“父子”层级的缺陷传播：例如，基础镜像（如 alpine）中的漏洞会被构建在其之上的每一个镜像所继承，这可能影响数十亿次的拉取；而一个罕用叶子镜像中的缺陷则几乎不产生任何影响。现有的度量研究也难以区分原始检测器命中项与实际可利用的密钥，经常将测试固件（test fixtures）与真实凭据混为一谈。

方法论：ChimangoScan 流水线
为了解决这些差距，作者提出了 ChimangoScan，这是一个旨在爬取 Docker Hub、重建镜像层图谱并使用多种独立工具扫描高暴露度镜像的三阶段流水线。

第一阶段：仓库发现： 该流水线通过公开搜索 API，利用仓库名称的前缀树遍历（prefix-trie traversal）来枚举 Docker Hub 命名空间。这种“容量细化”（cap-refining）方法通过递归扩展饱和的前缀，处理了 API 结果限制（每个查询 10,000 条结果）的问题。该爬虫索引了 12,716,568 个仓库，记录了拉取次数、星标数和时间戳。
第二阶段：镜像解析与层图谱： 系统将仓库解析为具体的镜像摘要（digest），并重建层图谱。通过使用祖先哈希标识符（父 ID 与层摘要的 SHA-256 拼接），它构建了一个包含 8,470 万个节点和 5,440 万条边的有向森林，代表了 IS_BASE_OF（是……的基础）关系。该结构捕捉了层如何在不同镜像间共享。
基于暴露度的优先级排序： 不同于以往通过简单后继计数进行排序的研究，ChimangoScan 引入了 暴露度得分 $E(I)$ 。该标量结合了镜像自身的拉取次数及其下游子树中所有镜像的拉取次数。该指标优先考虑那些其缺陷会传播到更大份额生态系统的镜像。
第三阶段：多扫描器执行： 该流水线使用六种开源扫描器对前 52,895 个高暴露度仓库（覆盖了 84.7% 的所有记录拉取次数）进行扫描（这些仓库覆盖了 84.7% 的总拉取量）：
- 软件清单： Syft。
- 漏洞扫描： Trivy、Grype 和 OSV-Scanner（分别利用 NVD、Anchore VulnDB 和 OSV 数据库）。
- 配置错误： Dockle (CIS Docker 基准)。
- 密钥： TruffleHog（拥有 700 多个检测器）。
  研究结果按镜像进行合并，但不会在不同扫描器之间进行去重，以便测量扫描器之间的分歧。

核心贡献

暴露度得分： 第一个将镜像自身的流行度及其整个下游子树的影响力整合进单一标量的指标，实现了基于生态系统影响而非仅仅基于镜像数量的优先级排序。
规模与广度： 对 52,895 个排名靠前的仓库进行了度量（约 1.704 亿个发现项），其规模比以往的多扫描器研究高出两个数量级。
扫描器分歧分析： 在生态系统规模上量化了安全态势在多大程度上取决于所使用的工具。
公开数据集： 发布了 1,270 万个仓库的元数据、完整的层图谱以及针对已扫描镜像的多扫描器报告。

关键结果

近乎普遍存在的漏洞： 已知漏洞无处不在。96.3% 的被扫描镜像携带至少一个已知软件包漏洞，93.4% 携带一个严重漏洞，98.0% 包含配置错误。中位镜像携带 885 个合并后的发现项。
扫描器依赖性： 报告的安全态势在很大程度上是由扫描器驱动的产物。在检测到的不同漏洞中，仅有 2.7% 被三个漏洞扫描器共同报告，而 66.8% 仅由其中一个报告。单一工具的测量会遗漏大约三分之一的独特漏洞。
密钥 vs. 假阳性： 虽然 TruffleHog 在 76.9% 的镜像中标记了密钥，但对随机样本进行人工标注显示，这些命中项中 99.7% 并非凭据（例如包校验和、测试固件、文档示例）。只有约 0.3% 是合理的实时凭据。
配置错误盛行率： Dockle 在 98.0% 的镜像中标记了配置错误，最常见的是缺失内容信任（content-trust）配置、缺失 HEALTHCHECK 指令以及容器以 root 身份运行。
暴露度 vs. 安全性： 镜像的流行度（拉取次数）或暴露度得分与其漏洞数量之间没有相关性。即使是最广泛使用的基础镜像（如 alpine、ubuntu）也几乎普遍携带严重发现项。
传播影响： 通过暴露度对 CVE 进行加权可以发现，核心库（如 zlib、glibc）中的缺陷所影响的生态系统份额远大于其原始镜像数量所显示的。单个高触达 CVE 影响的镜像占到了整个语料库总暴露度的 47.3%。

意义与主张
本文声称，生态系统规模的安全度量不应依赖于单一扫描器的计数，因为报告的态势在实质上是该工具的产物。相反，审计和 CI 流水线应当采用由不同数据库支持的多种扫描器组合。此外，作者认为应根据暴露度（下游触达范围）而非原始镜像数量来确定修复工作的优先级，因为这能针对那些会将缺陷传播到最大份额供应链中的缺陷。最后，论文强调，如果不进行验证，原始密钥检测率会具有误导性，因为绝大多数命中项都是假阳性。

研究结论指出，虽然在最高暴露度的 Docker Hub 镜像中，漏洞和配置错误几乎是普遍存在的，但描述它们的具体指标具有高度的工具依赖性，因此需要采用多扫描器方法进行准确评估。