来自 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%）得到了修复。