Chainguard最新的《可信开源现状报告》详细描述了当前行业对于容器镜像中的漏洞以及开源依赖的长尾问题的看法。该报告基于 2025 年 9 月至 11 月期间观察到的 1800 多个容器映像项目和 10100 个漏洞实例，提供了生产环境的数据驱动视图。
Chainguard 利用来自 29 万个镜像和近 5 亿次构建的遥测数据，检查客户实际如何消费和维护开源组件。它发现，基础语言和基础设施镜像，如 Python、Node、nginx、Go 和 Redis，在生产使用中占主导地位，形成了它所描述的现代 AI 驱动软件生态系统的基础栈。Python 出现在大约 72%的客户环境中，Node 占 57%，nginx 占 40%。这些镜像与模型开发、数据处理和推理工作负载以及周围的可观测性和平台工具相关联。
然而，报告警告说，这些受欢迎的镜像的可见层只是真实景观的一小部分。前 20 个镜像占 Chainguard 编目镜像的约 1.37%，大约是所有容器拉取量的一半。另一半的生产使用来自 1436 个长尾镜像，占平均客户清单的 61%以上。Chainguard 强调，这些长尾镜像通常是绝对需要的现场服务和基础设施的核心组件，而不是短暂的实验。
漏洞的分布高度偏向这个长尾。Chainguard 报告说，在此期间，它修复的 CVE 实例中，只有 214 个出现在前 20 个镜像中，约占 2%。其余的 98%（10785 个 CVE 实例）在该集合之外的镜像中。这一发现表明，最严重的风险暴露在堆栈中最难应用补丁和治理的部分。对于每个在前 20 个镜像中修复的 CVE，公司表示它在不太受欢迎的镜像中解决了 50 个 CVE，这是它用来说明处理安全长尾重要性的比率。虽然这些问题大多数是中等严重性，但报告认为组织最关心的是它们如何快速解决跨其镜像范围的关键和高严重性问题。
在这方面，Chainguard 强调了他们修复安全问题的速度。该公司表示，在三个月的时间窗口内，它实现了对关键 CVE 的平均修复时间低于 20 小时，63.5%在 24 小时内解决，97.6%在两天内解决，所有问题都在三天内解决。Chainguard 在两天多的时间内修复了高严重性漏洞，在两天半的时间内修复了中等严重性漏洞，在三天多的时间内修复了低严重性问题。这些时间明显快于 Chainguard 声明的服务水平目标，即关键 CVE 为七天，其他为十四天，并且适用于流行和长尾镜像。
在我们的数据中，有一点很突出：现代软件由广泛、不断变化的开源组件组合驱动，其中大多数都不在前 20 名最受欢迎的镜像中。这不是开发者花费时间的地方，但却是大量安全性和合规性风险积累的地方。
该报告还指出，合规性是容器安全变化的主要驱动因素。它指出，44%的客户在生产中至少运行一个 FIPS 兼容镜像，通常是为了满足 FedRAMP、DoD IL 5、PCI DSS、SOC 2、欧盟网络弹性法案、澳大利亚的 Essential Eight 和 HIPAA 等框架的要求。最广泛使用的 FIPS 镜像与非 FIPS 组合镜像相镜像，包括 Python、Node、nginx、Go、Redis、Istio 组件和 cert-manager。Chainguard 建议，这种模式显示了监管压力如何鼓励使用与现有工作负载紧密对齐的硬化、经过密码学验证的开源组件。
风险集中在最熟悉的项目之外的想法并不是 Chainguard 工作所独有的。NetRise在 2024 年的一项研究发现，常用的 Docker Hub 容器平均包含 604 个已知漏洞，其中超过 45%的漏洞超过两年未修复。同一研究表明，这些容器中的一小部分关键和高严重性漏洞已经被利用，并与活跃的勒索软件活动有关。NetRise 的研究还表明，即使这些镜像不是最广泛使用的，长期未修补的组件在镜像中也构成了持续的风险。
学术研究使用不同的方法得出了类似的结论。发表在GigaScience上对科学容器镜像的分析报告称，每个镜像平均有 460 个漏洞。这项分析的作者指出，许多镜像包括完整的操作系统发行版和很少更新的其他不必要的软件包，从而创造了更大的攻击面。他们还表明，仔细减少镜像大小和内容，并定期重建它们，可以显著减少漏洞数量。这反映了当前行业的最佳实践，即使用最小的基础镜像，并经常重建容器镜像。
Sonatype 的《软件供应链现状报告》通过跟踪在已经存在修补版本的情况下易受攻击的组件被使用的频率，增加了另一层内容。2024 年的版本突出了恶意开源软件包的增加，并报告称，在 95%使用了易受攻击组件的情况下，已有修复版本可用。Sonatype 还强调，大量依赖关系长时间未打补丁，特别是对于低严重性问题。这种可用修复和缓慢采纳的组合支持了 Chainguard 的观点，即管理性补救和长尾覆盖可以填补开源维护现实留下的空白。
业界的回应，如Checkmarx和Faith Forge，强调了一些标准模式。安全供应商将镜像扫描描述为持续集成和部署流程的标准部分，组织越来越多地将这些扫描与政策即代码规则联系起来，这些规则可以阻止带有未打补丁的关键 CVE、缺失签名或缺失软件物料清单的镜像。在对软件物料清单（SBOM）格局的分析中，欧洲网络安全局（ENISA）也强调了机构和监管机构的指导。它强调了签名工件、可验证的构建来源和将 SBOM 内容与漏洞情报匹配的能力的重要性。这些趋势都响应了 Chainguard 强调的同一结构性问题：需要管理的不仅仅是最受欢迎的镜像中的漏洞，而是当代软件系统中使用的所有容器化组件中的漏洞。
原文链接：
https://www.infoq.com/news/2026/01/chainguard-opensource-vulns/
