在Maven Central生态系统中，有17,000个已打补丁的Log4j包，这使得Log4Shell漏洞带来了巨大的供应链风险。

通过Java软件供应链，有大量的软件容易受到Log4j漏洞的影响——管理员和安全专家可能甚至不知道到哪里去找它。

Maven Central存储库(开发者可用的Java包的最重要集合)中大约有17000个Java包容易受到Log4j的攻击。据Google Security称，它可能需要“数年”的时间才能在整个生态系统中得到修复。

在CVE更新后，仅Log4j-core受到影响，消除了Log4j-api的易受攻击实例。Google Security确定，截至12月19日，Maven Central中有超过17,000个包易受攻击，约占整个存储库的4%。谷歌补充说，其中只有25%的软件包具有可用的更新版本。

相比之下，谷歌的研究人员在周二的一篇博客文章中解释说，这种软件包的平均bug率在2%到不到0.01%之间。

维护Maven Central的组织Sonatype有一个每天在Log4j上更新几次的仪表盘，该组织报告说，自12月10日以来，超过40%的下载包仍然是脆弱的，总下载量接近500万次。

这些新下载的应用程序和项目容易受到Log4j攻击。

从供应链的最深处开始并逐步完善

谷歌解释说，Log4j潜伏在对有缺陷代码的“依赖”中，无论是直接的还是间接的，都存在于供应链的上下游。

谷歌团队称:“大多数受影响的工件来自间接依赖项(也就是说，一个人自己的依赖项的依赖项)，这意味着Log4j没有明确地定义为工件的依赖项，而是作为传递依赖项引入。”

分析人士补充说，让这些未打补丁的Log4j版本更加难以追踪是“它通常部署在软件供应链的下游”。

报告警告说：“对于超过80%的软件包，漏洞的深度超过一级，其中大多数影响了五个级别(有些甚至多达九个级别)。” “这些包将需要在树的所有部分进行修复，首先从最深的依赖关系开始。”

为什么Java比其他生态系统更棘手

根据谷歌的说法，Java的“软”版本要求增加了发现Log4j错误的难度。

谷歌研究人员表示：“传播修复程序通常需要维护人员采取明确行动，将依赖项要求更新为补丁版本。” “这种做法与其他生态系统形成对比，例如nmp，开发人员通常为依赖项要求指定开放范围。”

面对这些独特的挑战，谷歌报告称，开源维护者和安全团队已经为修补系统做出了很大努力。但要让Log4j永远消失在业界的视野中，还有大量工作要做。

尽管第三方库在软件敏捷开发中起到很重要的作用，但其中存在安全漏洞也为开发团队带来很大的网络风险。当前，多数开发团队离不开第三方代码库或底层框架和一些软件包管理工具，但这也意味着当某个环节出现问题时，很容易发生软件供应链攻击。

因此，目前更提倡DevsecOps建设，从软件需求构建开始将安全考虑进来，在编码期间就关注安全问题，安全建设往往不再是安全团队的主要工作。在开发期间使用静态代码检测工具、SCA等筛查容易出现的代码缺陷和漏洞，从而提高软件安全性，为网络安全防御筑牢基础。

参读链接：

https://threatpost.com/java-supply-chain-log4j-bug/177211/

[课程]FART 脱壳王！加量不加价！FART作者讲授！