文 | 局长
出品 | OSC开源社区（ID：oschina2013）

来自 Google Open Source Insights Team 的安全研究人员通过调查 Maven Central 中所有软件包的所有版本，以更好地了解最近曝出的 Log4j 漏洞对整个 JVM 语言生态系统的影响，同时还跟踪了正在进行的缓解受影响软件包的作业，

研究人员发现，截至 2021 年 12 月 16 日，来自 Maven Central 的 35,863 个可用软件包依赖于存在漏洞的 log4j 代码，这意味着 Maven Central 上超过 8% 的软件包至少有一个版本受漏洞影响（此数字不包括所有 Java 软件包，例如直接分发的二进制档案）

就生态系统影响而言，8% 是相当巨大的数字，因为对 Maven Central 生态的平均影响数值为 2%，中位数则低于 0.1%，

如记录漏洞的 CVE 所述，大多数受影响的软件包来自间接依赖项（即自身依赖项的依赖项），也就是说它们没有将 log4j 明确定义为依赖项，而是作为传递依赖项被引入进来，

这正是 JVM 生态整体上修复此漏洞例外困难的原因，安全研究人员称，在撰写文章时，只修复了近五千个受影响的软件包，还有 30000 多个软件包会受到漏洞的影响，

简单来说就是，漏洞在依赖关系链中嵌套得越深，修复漏洞所需的步骤就越多，下图显示了受影响的 log4j 包（核心或 api）首次出现在依赖图中的深度的直方图，对于超过 80% 的软件包，该漏洞的深度超过一级，其中大多数受影响的级别下降了 5 个级别（有些甚至下降了 9 个级别），这些包将需要在依赖树的所有部分进行修复，而且首先从最深处的依赖关系开始，

修复漏洞的另一个困难之处由决议算法 (resolution algorithm) 和需求规范约定中生态系统层级的选择引起，

在 Java 生态中，开发者通常的做法是指定软件版本方面的“软”要求——假设没有其它版本的相同包出现在依赖关系图中，决议算法会使用指定的明确版本，对于此类修复，通常需要维护者采取更加明确的行动，以将依赖需求更新为修补后的版本，这种做法与其它生态形成了鲜明的对比，例如在 npm 软件包中，开发者通常会为依赖项指定开放范围，开放范围允许决议算法选择满足依赖性要求的最近发布的版本，从而引入新的修复，

最后，对于整个生态需要耗费多少时间来完成漏洞修复，目前也很难评估，在查看了所有公开披露的受影响 Maven 软件包中，安全人员发现只有不到一半（48%）得到了修复，

参考：https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html

近期热文推荐：

1.1,000+ 道 Java面试题及答案整理(2021最新版)

2.劲爆！Java 协程要来了，，，

3.玩大了！Log4j 2.x 再爆雷，，，

4.Spring Boot 2.6 正式发布，一大波新特性，，

5.《Java开发手册（嵩山版）》最新发布，速速下载！

觉得不错，别忘了随手点赞+转发哦！