避免下一个Log4Shell：从Log4j事件中吸取教训的一年后

广泛使用的开源 Java 日志库 Log4j 中的漏洞 Log4Shell，于 2021 年 12 月被披露，大约是在我执掌 OpenSSF（Open Source Security Foundation，开源安全基金会）的两个月后。正如我当时所说的，OSS（open source software，开源软件）的基金会必须共同努力，防止下一次 Log4Shell 的混乱^[1]，今天依然适用。一年后，让我们总结一下，我们还学到了什么：围绕软件供应链安全和漏洞披露的核心问题，保护 OSS 的独特性质，以及提高 OSS 安全性的最佳方法。

不同种类的弱点结合在一起产生深度威胁

Log4Shell 不仅仅是一个供应链安全或漏洞披露故事，而是两者的混合体。这反映了不同类型的弱点组合在一起形成深度威胁的方式。Log4Shell 是来自一系列漏洞（在几周内以一组 CVE^[2]的形式发布），如果以更有序、更协调的方式发现，并修复这些漏洞，就可以避免去年扰乱人们假期的混乱。但它成为了一个供应链故事，因为在生产环境，检测和报告未打补丁的 Log4j 的存在是多么困难。供应链问题进一步推动了最终用户群体（政府、金融服务等），对SBOM^[3]（Software Bill of Material，软件材料清单）的采用，这是更好地了解最终用户软件包含易受攻击的组件的重要一步——包括开放源代码和封闭源代码。但漏洞披露问题——确保在发现漏洞时，及时分发适当的补丁以最大限度地减少利用——也是解决问题的关键，以防止未来出现类似 Log4Shell 的事件。

Log4Shell 也展示了闭源软件对开源软件的依赖有多深。根据 Sonatype 的数据，普通应用程序中的依赖数量，从 2018 年的 298 个增加到 2020 年的 528 个，增长了近一倍^[4]。开发人员管理第三方依赖项的责任持续增长，一般的 Java 应用程序比去年多包含 20 个依赖项，达到 148 个，一般的 Java 项目每年更新 10 次，这导致开发人员每年需要跟踪近 1,500 个潜在的依赖项变化^[5]——针对他们工作的每个应用程序。此外，Synopsys 在其 2021 年开源安全和风险分析报告中发现^[6]，其 98%的商业代码库数据集包含开源代码，其中 84%的代码库包含至少一个 OSS 漏洞。同一项研究发现，典型的闭源软件应用有 78%到 90%是 OSS。

Log4j 已经 20 年了；它已经嵌入到几乎每一个有意义的 Java 应用程序中；Log4Shell 事件，导致了从iCloud^[7]到物理安全系统^[8]受损。此外，恶意软件团体正在继续^[9]利用未打补丁的 Log4j 实例。除非我们解决其根本问题，否则我们可能会看到更多类似 Log4Shell 的事件。

开源的安全失衡

Log4Shell 还揭示了开源软件社区的独特特征。虽然开源软件社区包括有偿和无偿的贡献者，并且某些项目确实需要财务支持才能持续，但是将 Log4j 等软件的贡献者，描述为完全无偿的开发人员是不公平的，他们无偿工作，并且没有自己的切身利益。大型开源项目的维护者和贡献者，通常是技术公司的员工^[10]，他们可能会在雇主的支持下，从事开源软件的工作，雇主可能会在自己的产品中使用 Log4j。

核心问题是动机方面的差距：开发人员经常在追求修复错误或添加功能的过程中，偶然使用 Log4j 等开源软件，这很少导致^[11]他们在降低代码中安全问题风险的功能上投入额外的时间。就像闭源开发者一样，OSS 开发者经常需要与他们的经理，争夺在应用程序安全方面做出实质性改变的权利，从增加额外的测试和采用其他安全最佳实践^[12]，到简单地偿还技术债务和删除未充分使用的功能。典型的例子是：Log4j 中导致 Log4Shell 漏洞的JNDI-LDAP 代码^[13]，并不是必需的，甚至也不是流行的特性，因此它没有得到很好的维护。

良好的安全工作是艰难的，直到最近，我们还缺乏伟大的工具或其他措施，来展示这项工作的价值，除了“我们又避免了一周的 CVE”。现在，部分由于 OpenSSF 和其他人的工作，我们有工具可以帮助通知最终用户一个开源包相对于另一个的相对风险：OpenSSF 安全记分卡^[14]的风险分数；OpenSSF 最佳实践徽章^[15]的存在；并查找独立第三方对代码执行的最近一次审计。它还可以帮助核心开发人员，了解他们可能会采取什么样的做法，来提高最终用户的安全性，并因此获得好评。例如，云原生社区的“Security Slam^[16]”活动，鼓励项目维护人员将他们的安全得分提高到更高的安全记分卡基线。

避免下一个 Log4Shell

一个有效的、开放的问题是：“Log4J 是不是一种‘百年一遇的洪水’事件，一种我们无法完全预防的事件？我们应该接受威胁基础设施的漏洞，作为创新成本的一部分吗？”我们认为事实并非如此。正如我们在开源软件安全动员计划^[17]中详述的那样，可以进行大量高影响力、低成本和可调节的投资，有系统地从支撑我们关键数字基础设施的 OSS 排除风险，网络安全审查委员会（CSRB）关于 Log4j 的报告广泛引用该计划作为解决 Log4Shell 根本原因的可信方法。我相信独立的第三方代码审查，应该会发现导致 Log4Shell 的漏洞，这样的审查应该不会花费超过 10 万美元。这样的代码审查可以在任何时候完成；然而，没有一家公司或个人站出来资助这项工作。因此，这里存在“市场失灵”，而这正是额外资金可以介入提供帮助的地方。

重点领域

我不能告诉你，下一个导致 Log4Shell 式危机的软件包会是什么。然而，我们正在努力，确定最关键的开放源码软件项目，包括 100 多个项目的第一份草案清单，并努力衡量开放源码软件项目的安全风险。让我们想象一下，我们选择了 100 个项目，进行了一次安全审查（平均花费 10 万美元），并花费相同的金额来修复任何问题。这将花费 100 x（10 万美元+10 万美元），假设这个过程每年重复一次。2000 万美元的年度投资，会消除再次发生此类事件的所有可能性吗？不，但这将大大降低该软件包和其他依赖它的东西的风险..

第二个关注点是，当资源不足的开源项目（甚至可能是那些 100%由志愿者驱动的项目），遭遇重大安全事故时，缺少一种可信的、专家驱动的、对保密性敏感的方法来帮助它们。如果有一个老虎小组，像紧急消防队一样随时待命，开发人员可以信任他们对未披露的漏洞保密，甚至对他们的雇主保密，这可能会大大减少攻击，并导致一组修复程序，以我们今天经常看到的方式严密编排。我们已经为 OSS 开发者（和bug 发现者^[18]），发布了一个协作漏洞披露指南^[19]，并且正在定义和建立一个安全事件响应团队（Security Incident Response Team，SIRT），他们可以成为值得信赖的消防员。

我们在 OpenSSF 一直致力的一些其他举措包括：Sigstore^[20]，一个用于验证和保护软件，以防止软件供应链攻击的关键工具；定义管理认证和交付更安全软件的流程，如SLSA、S2C2F 和 FRSCA^[21]；与主要的 OSS 基金会和软件包管理人员合作，通过诸如Alpha-Omega 项目^[22]这样的计划，为安全工作和安全工具的采用，建立更大的能力。我们也很高兴看到像MavenCentral^[23]，开始使用 Sigstore 作为关键的安全工具。所有这些努力，应该有助于普通软件开发人员，在默认情况下创建更安全的代码，而不必对他们自己的工具或工作流进行实质性的（或者甚至任何）更改。但是，所有这些都需要工具制造商，包括操作系统和他们周围的供应商集中时间和精力。这就是 OpenSSF 正在帮助协调的。此外，OpenSSF 的免费安全软件开发基础课程^[24]，向开发人员传授安全基础知识，以开发能够抵御攻击的软件，以及如何在漏洞被利用时减少损失。该课程特别建议避免导致 Log4Shell 漏洞的构造。如果更多的开发人员接受教育和培训来开发安全的软件，并得到帮助他们这样做的良好工具的支持，那么这种漏洞的风险就会大大降低。

我们 OpenSSF 和许多其他人，正在努力解决导致一年前发现的 Log4Shell 漏洞的系统问题。这种全面的努力需要来自私营部门和政府的投资，以保证我们软件的安全。如果我们不共同努力，投资于适当的安全措施，重大的开放源码软件网络安全事件将继续扰乱我们的世界。

参考资料

文章转载自OpenSSF开源安全。                              作者：Brian Behlendorf