当Christian Grobmeier去帮助儿子解决Minecraft问题时，他发现游戏显示了一条警告：“我们正遭受Log4J安全漏洞的影响，请立即更新。”
“我盯着屏幕告诉儿子，‘对不起，这是我的错’。” ——Christian Grobmeier，Log4j维护者
这是一个关于一位维护者和Log4j团队如何应对危机的未公开故事，这场危机暴露了我们数字基础设施的关键漏洞，并展示了开源安全性和可持续性的重要性。如今，像GitHub安全开源基金这样的计划正在努力确保这种情况不再发生。
这一切始于11月一个寒冷的日子，当时作为开源项目Log4j维护者的Christian计划与儿子一起玩游戏。相反，他发现自己盯着手机，看着收件箱中的通知堆积如山——10封，然后是20封邮件涌入。当他看到"远程代码执行"这个词时，他的第一个想法是：“也许我进错了邮件列表。”
他并没有。几小时内，Christian就成为了后来被称为Log4Shell的事件中心：这是互联网历史上最严重的漏洞，影响了从财富500强公司到全球Minecraft服务器的数十亿设备。
“我告诉儿子，我五分钟后和你玩，“Christian回忆道，“但他接下来几天都没见到我。”
使Log4Shell成为完美风暴的普遍性
Log4j是基础软件。这个20多年历史的Java日志记录库在全球应用程序中默默地支持系统事件，如用户登录和计算结果。但这个小型软件已悄然成为Java生态系统中数千个项目的依赖项。
“Log4j是一个非常小的库。但每个人都可以在他们的软件中使用它。” ——Christian Grobmeier
这种普遍性使得Log4Shell具有毁灭性。金融服务公司依赖它进行合规审计。电子商务系统使用它来跟踪安全事件。保险公司需要它来监控软件行为。在2022年的Tidelift调查中，49%的开源开发人员报告他们的组织依赖Java——其中大多数人甚至不知道自己在使用Log4j。
当Christian意识到漏洞的范围时，压力立即袭来：“字面上全世界所有的Java应用程序都可能受到影响。即使是10%也将是一个重大问题。这将是灾难性的。”
获得完美10分的漏洞
Log4Shell揭示了一个看似无害的功能如何成为攻击向量。Log4j使用Java的命名和目录接口（JNDI）提供灵活性，允许开发人员从远程服务器加载软件组件。但该库没有验证JNDI查找字符串是否来自受信任的源。
“一个字符串怎么能破坏互联网？“Christian问道。
利用过程简单得令人恐惧。攻击者可以将恶意JNDI字符串输入任何被记录的应用程序字段——用户名字段、搜索框，甚至是Minecraft聊天消息——并在目标系统上执行远程代码。
|
|
“你甚至不需要特殊知识，“Christian指出，“你只需到处推送这个字符串。”
通用漏洞评分系统（CVSS）给Log4Shell打了完美的10分：可能的最高分。
“我第一次听说这个分数时，我想，也许没那么糟，“Christian回忆道，“但几天后，我想，也许我们应该把这个分数扩展到15或20。”
维护关键基础设施的人力成本
Log4Shell危机期间维护者承受的个人损失揭示了软件供应链隐藏的人力成本。Christian和他的团队（主要是志愿者）突然发现自己负责修补影响半个互联网的漏洞。压力巨大且极其个人化。
“我们中的一些人停止了睡眠。我们都觉得要么在接下来几天内修复它，要么关闭这个项目。” ——Christian Grobmeier
修复初始漏洞导致发现了更多问题，Christian描述为"一个有洞的水袋。当你修补一个洞时，你会看到另一个。”
同时，社区反应褒贬不一。“一方面，有人真的恨你，另一方面，有人真的支持你，“Christian解释道。
也许最能说明问题的是：
“没有人停下来关心你。他们关心的是项目。也没有人站出来说，‘嘿，感谢你为解决这个问题所做的出色工作。’” ——Christian Grobmeier
GitHub安全开源基金如何加强安全
Log4Shell事件突显了开源安全的关键差距：维护者往往缺乏将安全构建到项目中的培训和资源。这一认识催生了像GitHub安全开源基金这样的计划，该基金为关键开源项目提供资金和安全培训。
该基金作为一种主动保护形式、汇集资源和分担责任，既有效又高效。可以将其视为开源供应链的"保险”——帮助使数字生态系统更安全，减少可能影响数十亿用户的风险。
Christian参加了GitHub安全开源基金的安全培训计划，影响是变革性的。
培训不仅提供了技术知识——还改变了他的视角。Christian解释说：“通过这次培训，开发人员不再是最薄弱的环节。相反，他们成为了第一道防线。”
这种思维方式的改变至关重要。正如Christian所说：
“无知是迄今为止最糟糕和最严重的安全漏洞。它基本上会破坏所有软件。” ——Christian Grobmeier
当被问及GitHub安全开源基金培训是否可以防止Log4Shell时，Christian直接表示：“如果五年前就有这个培训，也许今天就不会有Log4Shell。”
技术教训：默认构建安全
Log4Shell事件教会了行业几个关于安全开发实践的关键教训：
-
验证所有外部输入：永远不要信任跨越信任边界的数据，特别是在处理用户输入的基础库中。
-
默认禁用危险功能：Log4j现在默认禁用JNDI查找。
-
实施深度防御：现代应用程序需要多层保护，从输入验证到运行时保护。
-
自动化安全扫描：像GitHub的代码扫描和Dependabot这样的工具可以在漏洞进入生产环境之前捕获它们。
-
维护软件物料清单（SBOM）：当Log4Shell来袭时，许多组织无法确定自己是否受到影响，因为他们不知道自己的依赖关系。
“我接到了同事的电话，问我：‘我真的受影响了吗？‘SBOM为你提供了一种技术方式来找出一个项目中使用的依赖关系，“Christian解释道。
可持续开源的行业范围教训
虽然Log4Shell的技术教训至关重要，但技术变革还不够。更深层次的挑战在于我们如何支持维护我们世界所依赖的开源基础设施的人类。这场危机暴露了我们处理开源可持续性和安全性的几个系统性问题：
社区至关重要：“如果你作为单个人维护开源软件，那就是一个风险，“Christian强调。
安全培训需要易于获取：传统安全教育往往无法覆盖最需要它的维护者。
仅资金不够：虽然财务支持有帮助，但Christian发现培训和社区同样重要。当提供资金支付团队成员时，许多人因税务影响或现有工作而拒绝。
善意很重要：“每个小型开源库背后都有一个编写代码的人，“Christian提醒我们，“如果你发现有什么不对，帮忙而不是生气。”
每个项目的安全性都可以改进：在计划期间，Christian实施了多项新的安全改进，包括加固GitHub Actions以防止脚本注入，开发新的威胁模型，以及与ScanCode合作识别第三方代码中隐藏的Log4j工件。
你在保护软件供应链中的角色
Log4Shell故事不仅仅关乎一个漏洞；它关乎我们所有人共同承担维护为现代互联网提供支持的开源生态系统的集体责任。
对于维护者：申请像GitHub安全开源基金这样的计划。启用内置安全工具，如GitHub的代码扫描和Dependabot。导出SBOM以帮助下游用户了解他们的依赖关系，并为项目中发现的所有漏洞发布安全公告。
对于企业：成为GitHub安全开源基金的资助或生态系统合作伙伴。投资工程时间于你依赖的上游项目。不要只是消费开源——通过代码、文档、安全审查和资金做出贡献。
对于个人开发者：仔细选择引入的新依赖项，例如通过检查其安全状况。考虑你处理的数据可能由攻击者控制，并严格验证不受信任的输入以防止意外行为。贡献测试用例和文档。
前进之路
如今，Log4j的OpenSSF得分为8.3，这表明了良好的安全实践。
但更广泛的教训超越了任何单个项目。正如Christian所说：
“学习是无知的唯一解药。所以只需不断学习。” ——Christian Grobmeier
Log4Shell事件向我们展示了我们的数字世界如何因单个漏洞而迅速受到威胁。但它也展示了开源社区响应、适应和改进的力量。问题不在于下一个关键漏洞是否会出现——而在于我们是否准备好应对它。