自 12 月 9 日 Apache Log4j 2 “惊天漏洞”被曝出后，全球众多科技企业已受到其影响。12 月 17 日，谷歌方面宣布已对该事件进行了调查，并于 12 月 21 日将结果公布在了 Google cloud 官方页面上。
据 Google cloud 页面上 12 月 21 日公布的调查结果显示：面向消费者和付费用户的 Google Workspace 核心服务没有使用 Log4j2，也没有受到 CVE-2021-44228 和 CVE-2021-45046 “漏洞”的影响。谷歌方面表示将为此安全咨询提供工作区核心服务的详细状态。
谷歌方面表示，Google Cloud 正在积极关注开源 Apache“Log4j 2”实用程序（CVE-2021-44228 和 CVE-2021-45046）中的安全漏洞。他们已经注意到了报告的 Apache“Log4j 1.x”漏洞（CVE-2021-4104），并建议用户更新到 Log4j2 的最新版本。
12 月 17 日，在 Google cloud 博客页面上，谷歌开源洞察小组（Open Source Insights Team）解释了他们观察到的关于 Apache Log4J 漏洞的全部情况。他们描述了广泛存在的漏洞以及修复开源 JVM 生态系统的当前进展。
随后，谷歌评估了该漏洞对 Google cloud 产品和服务的潜在影响，并根据正在进行的调查结果，提供开源Apache“Log4j 2”漏洞对 Google cloud 产品和服务的潜在影响做实时更新。谷歌方面表示，这将是一个持续的活动，后续也将继续通过此页面和客户沟通渠道提供更新。
Apache Log4j 漏洞的规模及产生的影响
据悉，此前披露的 Log4j 漏洞共涉及 35000 多个 Java 包，占 Maven 中央存储库的 8% 以上（存储库是最重要的 Java 包存储库，它为软件行业带来了广泛的成果）。专家指出，对于整个生态系统而言，8% 是一个较大的数值了，因为 Maven Central advisories 结果的平均数值为 2%，中位数小于 0.1%。当然，上面提到的数字并未包含所有 Java 包（如直接分发的二进制文件）。
对此，谷歌 Open Source Insights Team 团队的专家们指出了阻碍修复过程的两个重要问题：
一、许多软件包间接依赖于 log4j。直接依赖项受影响软件约 7000 个，在此情况下，任何版本都依赖于 CVEs 中描述的受影响版本的 Log4j core 或 Log4j API（间接依赖或传递依赖是指自我依赖的依赖关系）。
所有依赖项的工作人员，在修复是否使用依赖项链查看时产生了重大障碍：漏洞陷得越深，修复它的步骤就越多。根据该团队的消费者依赖关系图，柱状图结果显示了大量的数据。超 80% 的软件包中，漏洞的深度超过一级。在大多数情况下，受影响的级别下降了 5 级（有些甚至下降了 9 级）。修复的过程需要先到最深的依赖项，然后再到所有分支。
二、依赖解析算法和需求规范约定中的生态系统级选择。这种做法不同于 npm，npm 通常为依赖需求指定开放范围（开放范围提供了选择满足依赖性要求的最新发布版本的机会）。随后它又推出了新的修复方案，修补程序可用后，用户将在下一次生成时收到修补版本，可以更快地生成依赖项。
谷歌 Open Source Insights Team 团队表示，在 Java 生态系统中，通常的做法是指定“软”版本要求——若在依赖关系图中前面没有出现同一包的其他版本，则解析算法使用的确切版本。传播修复通常需要维护人员采取明确的行动，将依赖项需求更新为修补版本。
有了以上这些，谷歌开源洞察团队（Open Source Insights Team）便建议开源社区启用自动依赖项更新并添加安全缓解措施。他们还提供了 500 个受影响包的列表，其中一些包具有极高的可传递性。专家们认为，对这些包进行优先排序将有助于修复工作，并随后清除社区中的更多障碍，并对那些升级了 Log4j 版本的开源维护人员和消费者表达了感谢。
对于究竟需要多长时间才能完全修复所有问题，谷歌 Open Source Insights Team 团队也给出了自己的判断：很难知道。如果所有影响 Maven 软件包的关键建议都是公开披露的，那么这个过程可能需要一段时间。谷歌团队表示，受漏洞影响的软件包中只有不到一半（48%）得到修复。但在 Log4j 方面，大约 13% 的问题已得到解决，前景应该是光明的。
事件回顾：
12 月 9 日，记录请求的常用组件 Apache Log4j2 程序被曝出了一个漏洞，该漏洞可能使得运行 Apache Log4J2 版本 2.15 或以下的系统受到损害，并允许攻击者执行任意代码。
12 月 10 日，NIST 发布了一个关键的常见漏洞和暴露警报——CVE-2021-4228：配置、日志消息和参数中使用的 Java 命名目录接口（JNDI）功能无法防止攻击者控制的 LDAP 和其他 JNDI 相关端点，即启用消息查找替换时，可以控制日志消息或日志消息参数的攻击者可以执行从远程服务器加载的任意代码。
随后的几天，又被发现在 Apache Log4j 2.15.0 版本上存在敏感数据泄露的漏洞，可用于从受影响的服务器下载数据，随后官方并建议用户尽快升级到 2.16.0。
12 月 18 日，Apache Log4j 又被曝出 CVE-2021-45105 漏洞 —— Apache Log4j 2.0-alpha1 到 2.16.0 的版本无法防止自引用查找的不受控递归（Apache 官方已发布 2.17.0 版本修复）。