Chainguard发布的最新《可信开源现状报告》详细分析了当前业界对容器镜像中的漏洞问题以及开源依赖项所构成的“长尾现象”的看法。该报告基于2025年9月至11月期间观测到的1,800多个容器镜像项目及10,100起漏洞事件,提供了关于生产环境中这些问题的数据驱动分析结果。

Chainguard通过分析来自290,000个容器镜像以及近5亿次构建操作的监测数据,研究了客户在实际使用和维护开源组件的过程中的行为模式。报告指出,Python、Node.js、nginx、Go和Redis等基础语言及基础设施相关的镜像在生产环境中被广泛使用,它们构成了现代人工智能驱动的软件生态系统的核心组成部分。在客户的系统中,大约72%使用了Python,57%使用了Node.js,40%使用了nginx。这些镜像主要应用于模型开发、数据处理、推理计算等工作场景,同时也与相关的监控工具和平台组件密切相关。

然而,报告也提醒人们:这些被广泛使用的镜像仅仅只是整体情况的一部分。排名前20的镜像仅占Chainguard目录中所有镜像的1.37%,但它们却占据了所有容器镜像下载量的大约一半;而剩余的生产环境使用需求则由1,436个“长尾镜像”满足,这些镜像在平均客户的软件配置清单中占比超过了61%。Chainguard强调,这些“长尾镜像”往往是那些对实际运行中的服务和基础设施来说不可或缺的核心组件,而不是某些短暂存在的实验性项目。

漏洞分布情况也明显呈现出“长尾效应”:在报告所涉及的漏洞事件中,只有214起(约占2%)发生在排名前20的镜像中,而剩下的98%(即10,785起漏洞事件)则出现在其他镜像中。这一现象说明,那些最容易受到攻击的部分往往也是最难以进行补丁管理和安全控制的区域。对于每一项在排名前20的镜像中得到修复的漏洞,Chainguard表示他们在不太受欢迎的镜像中也解决了50项类似的漏洞问题——这一数据进一步凸显了处理“长尾安全问题”的重要性。虽然这些漏洞大多数属于中等严重程度,但报告指出,组织们最关心的是如何尽快解决那些在所有镜像中都存在的关键和高严重性漏洞。在这个评估指标上,Chainguard凸显了自己在解决安全问题方面的高效能力。在为期三个月的测试期内,该公司表示,对于那些严重性的安全漏洞,平均修复时间不到20小时;其中63.5%的漏洞在24小时内得到了处理,97.6%在两天内得到解决,所有漏洞都在三天内被彻底修复。对于高严重性漏洞,Chainguard仅需两天多一点的时间就能完成修复;中等严重性的漏洞需要大约两天半;而低严重性的漏洞则需要在三天多一点的时间内才能得到处理。这些修复速度明显快于Chainguard自己所宣称的服务目标——即对严重性漏洞提供7天的响应时间,对其它安全问题提供14天的处理周期。而且,这些数据同样适用于那些流行程度较高以及较少被关注的镜像文件。

从我们的数据中可以得出一个明显的结论:现代软件是由一系列种类繁多、且不断变化的开源组件构成的。其中,大多数这类组件的流行程度并不在前20名之列。开发者们并不会把时间花在开发这些组件上,但恰恰是这些组件积累了大部分安全风险和合规性隐患。

该报告还指出,合规性是推动容器安全领域发生变化的重要因素。报告称,44%的客户在生产环境中至少使用了一个符合FIPS标准的开源组件,这样做往往是为了满足FedRAMP、DoD IL 5、PCI DSS、SOC 2、欧盟网络韧性法案、澳大利亚的“八大关键标准”以及HIPAA等框架的要求。最常被使用的那些符合FIPS标准的开源组件与那些不符合该标准的组件在构成上非常相似,其中最常见的组件包括Python、Node.js、nginx、Go语言相关工具、Redis、Istio以及cert-manager等。Chainguard认为,这种现象说明,监管压力促使人们更加倾向于使用经过加固处理、且其安全性已经通过加密技术得到验证的开源组件,而这些组件的功能往往能与现有的应用需求紧密匹配。

认为风险其实集中在那些并不为人所熟知的项目中的观点,并非Chainguard独有的结论。NetRise在2024年进行的一项研究发现,常用的Docker Hub容器平均含有604个已知的漏洞,其中超过45%的漏洞存在时间已经超过了两年。同一项研究还指出,这些容器中有一小部分关键漏洞或高严重性漏洞实际上已经被利用过了,而且这些漏洞还与一些正在活跃进行的勒索软件攻击活动有关。NetRise的研究还表明,即使某些容器中的组件并不被广泛使用,但那些长期未得到修补的组件仍然会构成持续的安全风险。

学术界也使用了不同的研究方法得出了类似的结论。一项发表在《GigaScience》上的研究分析发现,科学研究的容器图像平均每个包含460个漏洞。该研究的作者指出,许多容器图像中包含了完整的操作系统以及一些很少会被更新的额外软件包,这些因素使得容器的攻击面大大增加。他们还表明,通过仔细压缩容器图像的大小和内容,并定期重新构建这些图像,可以显著减少其中的漏洞数量。这一发现体现了当前业界推崇的最佳实践,即使用最精简的基础镜像,并经常重新构建容器图像。

Sonatype发布的《软件供应链现状报告》进一步揭示了另一个问题:即使已经存在经过修补的版本,人们仍然会频繁使用那些存在漏洞的开源组件。2024年的这份报告指出,恶意开源包的数量正在不断增加,在95%的情况下,当有漏洞的组件被使用时,其实已经存在可供使用的修复版本。Sonatype还强调,许多依赖关系在很长一段时间内都没有得到修补,尤其是那些低严重性的问题。这种既有可用的修复方案却人们更新速度缓慢的现象,进一步印证了Chainguard的观点:通过有针对性的补救措施以及对长期存在的漏洞进行持续关注,确实可以弥补开源软件维护过程中所存在的问题。

来自CheckmarxFaith Forge等机构的回应指出,一些标准化的做法正在被越来越多地采用。安全供应商认为,图像扫描应该是持续集成与部署流程中的必备环节;各组织也越来越倾向于将这些扫描操作与“政策即代码”机制相结合——这类规则能够阻止那些存在未修补的关键漏洞、缺少签名信息或软件成分清单的镜像文件被纳入部署流程。在欧盟网络安全机构ENISA发布的相关分析报告中,该机构也强调了各类监管机构所提出的指导原则。报告特别指出了签名验证、可追溯的构建过程以及将软件成分清单与漏洞信息进行比对的重要性。所有这些趋势其实都在回应同一个根本性问题:即我们不仅需要管理那些最常被使用的镜像文件中的漏洞,还需要关注当代软件系统中使用的所有容器化组件的安全状况。

Comments are closed.