专访Brian Behlendorf：Log4Shell 爆发一年多，软件供应链安全领域发生了哪些变化？

采访嘉宾 ｜ Brian Behlendorf

编辑 ｜ Tina

Log4j 已经存在了 20 年，作为一个日志软件，已经被嵌入到几乎所有的 Java 应用程序中，Log4Shell 的爆发则可能导致一些关键软件受到严重损害。并且恶意软件组织一直在继续利用未打补丁的 Log4j 实例进行攻击，除非我们能解决其根本问题，否则我们可能还会看到其他类似 Log4Shell 的事件。

但从另一个角度来说，对 Log4Shell 漏洞的披露也成了应对软件供应链安全挑战的一个好时机，Linux 基金会下的开源安全基金会，简称 OpenSSF，联合开源社区的关键个人和企业，给出了多项改善关键开源软件安全状况的举措，在 2022 年这一年里取得了长足的进展，这些举措也是对过去方法的重要升级。2022 年底，我们借助“年终盘点”之机，采访了 OpenSSF 总经理 Brian Behlendorf，希望更进一步地了解开源安全的现状和应对措施。

InfoQ：您能给中国的读者们讲讲 OpenSSF 的使命以及起源故事吗？

Brian Behlendorf：OpenSSF 是个跨行业组织，汇集了行业内最重要的开源安全项目和相应和个人及企业贡献者。我们与上游及现有社区合作，希望帮助提高开源行业的整体安全性。我们的目标是在未来，让开源生态系统中的每位参与者都能使用和分享更多高质量软件，培养大家主动解决安全问题的主人翁心态，并将这一切视为理所当然。

过去，人们曾做出各种努力来提高开源软件安全性。这些努力包括 Linux 基金会的核心基础设施倡议（CII），由 GitHub 安全实验室建立的开源安全联盟（OSSC），以及由谷歌等企业创立的联合开源软件倡议（JOSSI）。

很明显，如果能把这些努力统一合并起来，安全工作的进展将更令人瞩目。OpenSSF 建立于 2020 年，使命就是将这三大倡议合并为“跨行业协作项目，号召各方领导者齐聚一堂，共同提高开源软件的安全性。”

InfoQ：您如何评价当前的开源安全现状？目前开源安全存在哪些关键问题？

Brian Behlendorf：Log4Shell 等重大安全事件敲响了警钟，让包括行业主导方和政策制定者在内的各利益相关方意识到，必须积极向开源安全投入资源。因此，通过开源软件安全动员计划等举措，我们正呼吁人们积极审视系统性的安全解决方案，而且取得了不错的进展。然而，我们还有很长的路要走。

开源安全中的关键问题包括：供应链安全问题，这要求其中的开源代码用户审查自己的依赖项并保持更新；漏洞披露问题，要求相关方负责任地上报并披露开源软件漏洞，以将危害降至最低；最后就是投资问题，开源软件的用户需要回馈开源社区，以确保其依赖项具有可持续的生命力。

我们认为，要想真正破解这些挑战，必须找到新的方法来衡量开源软件包中存在的种种未被发现的缺陷和风险，还要想办法衡量已经无法升级的依赖项中各已知缺陷可能造成的影响。只要能够客观衡量这种风险，那么每个人都能考量并找到适合自身情况的风险控制思路，高效利用现有资源保护项目本身乃至依赖于它的所有其他开源软件项目。只有这样，我们才能真正利用更好的工具、标准/规范、服务和教育等素材塑造出可靠的安全图景。

InfoQ：如果开源安全性不足，会给大家带来哪些潜在威胁，会有比爆发出来的 Log4Shell 更严重的后果吗？

Brian Behlendorf：开源无处不在：Synopsys 公司发布的商业代码库报告发现，其中 78%的代码来自开源项目。这些产品被应用于各种环境，从民用手机到互联网、再到国家安全及国防系统。出于这个原因，一旦这些被广泛应用的开源库中存在漏洞，则可能影响到大量已部署代码并造成严重后果。Log4Shell 仅仅是其中一例。但正如我们在开源软件安全动员计划中所提到，组织大量高影响力、低成本且切实可用的投资，完全有望系统性消除关键数字基础设施当中的开源软件风险。只要采取适当步骤，我们就能防范、或者至少缓解未来 Log4Shell 这类事件的严重性。

InfoQ：对于开源软件的漏洞所造成的损失，您认为是否应该有相关的问责机制？

Brian Behlendorf：自打这个概念诞生以来，开源软件就一直强调“使用者风险自负”。于是，包括学生、初创公司员工、志愿者乃至大企业技术专家在内的各类开发人员，都会在无需共享代码的情况下针对风险或缺陷开展协作和快速迭代。有追求的开源软件维护者也有动力修复 bug、编写说明文档并为新用户提供其他形式的辅助，借此增加项目的用户数量，最终吸引到更多技术贡献者。但最终用户要想获得商业级别的支持或安全保障，还是需要跟供应商签订付费协议。既想不花一分钱，又想让免费下载和使用的软件安全可靠，这确实不太现实。

这就是开源软件当前的问责模型。即使面对日益增加的网络安全问题，它也仍然发挥着效力。那些打包并支持开源代码的软件供应商需要对客户负责，由他们来保证提供安全可靠的软件使用体验，这一点并不需要政府和监管力量的介入。即使是政府自身，在购买软件支付合同或软件即服务时，也有权要求供应商提供相应的安全保证。

但我们绝不能通过放慢开源软件的迭代速度来追求更高的安全性，这样只会增加开源贡献者的负担，最终提高准入门槛、反而削弱所有参与者的安全信心。

InfoQ：2022 年，对于 OpenSSF 来说，应该是忙碌的一年。总结来说，在这一年里您们有了哪些行动和取得了哪些关键进展？

Brian Behlendorf：2022 年，OpenSSF 将成员范围扩展到了全球一百多个组织。经历两次白宫会议之后，我们启动了多项新举措，包括 Alpha-Omega 项目以及开源软件安全动员计划。我们还在北美奥斯汀、欧洲都柏林和日本横滨的开源峰会上举办了 OpenSSF 日活动，并在深圳单独组织了 OpenSSF 峰会。我们借此机会汇集全球开源社区，讨论 OSS 供应链安全保障方面的成功经验与现实挑战。感兴趣的朋友可以参考我们的年度报告 (https://openssf.org/blog/2022/12/29/openssf-year-in-review/)。

InfoQ：2022 年，您观察到整个行业开源安全有什么样的关键变化？

Brian Behlendorf：2022 年，我们发现从行业到政府的众多利益相关方，都开始更好地理解到开源软件的重要意义和重新投资开源生态系统的迫切性。特别是在 Log4Shell 等开源软件安全事件发生之后，业界对开源软件安全动员计划的支持、围绕开源软件及安全编码实践的培训和教育资源建设都有了长足进步。另外，政府也开始积极资助和支持开源软件安全工作，这一切都令我们备受鼓舞。

InfoQ：您预测 2023 年，开源安全有着什么样的发展趋势？

Brian Behlendorf：2023 年，我们希望看到来自各个政策领域的利益相关方，能继续在 2022 年已经完成的计划和工作基础上再接再厉。我们希望 Alpha-Omega 等在 2022 年刚刚启动的项目和倡议，能够取得制度性进展并在 2023 年落地生效。我们希望传统上不太关注开源的其他行业企业也能意识到自身对于开源成果的依赖，并采取相应行动以改善使用方式。我们还计划继续为开源开发社区及政策制定者提供指导和建议，帮助他们找到更好的开源安全应对计划。

InfoQ：作为 Linux 安全基金会 OpenSSF 的一个重要项目，我们很多人可能是第一次听说 SBOM 这个词。那么 SBOM 是如何帮助保护开源的？目前这个项目的完备程度如何？

Brian Behlendorf：SBOM 代表的是“软件材料清单”，本质上就是构成软件产品的“成分表”，即各个依赖项。SBOM 能帮助消费者更好地了解自己所使用的开源软件到底包含哪些依赖项，从而轻松审查这些依赖项并随时加以更新。这有助于解决我们在 Log4Shell 事件期间发现的一个主要问题：很多企业无法快速判断自己用的 Log4j 版本有没有缺陷，因为没有这样的 SBOM 能确切告诉他们当前使用的是哪个版本。

如今，已经有多种 SBOM 工具可供大家使用，其中最流行的两种 SBOM 格式分别是 SPDX 和 CycloneDX。我们正努力提高工具成熟度，并通过 SBOM Everywhere 特别兴趣小组推广这些工具。更多具体情况，请参考：https://openssf.org/blog/2022/09/13/funding-python-spdx-development-with-the-openssf-and-sbom-everywhere/

InfoQ：什么是 Alpha-Omega 计划？ 

Brian Behlendorf：Alpha-Omega 是 OpenSSF 推动的项目，创立于 2022 年 2 月，其使命是通过直接吸引维护者和专业分析意见，显著提高开源软件的安全水平。“Alpha”代表开端，是指与开源项目的关键维护者合作，帮助他们发现并修复安全漏洞，借此改善安全状况；“Omega”则代表末尾，强调确定至少 1 万个已经广泛部署的开源软件项目，并把自动化安全分析、评分和补救指南等全面推广至开源维护者社区。2022 年，该团队资助并增强了五大关键开源项目的安全性，分别是 Node.js、Eclipse 基金会、Rust 基金会、jQuery 和 Python 软件基金会。关于 Alpha-Omega 项目 2022 年的年度回顾，请参考相关报告： https://openssf.org/blog/2022/12/14/alpha-omega-project-first-year-in-review-plus-new-funding-pledge/

InfoQ：看相关资料提到， “每年对多达 200 个最关键的组件进行第三方代码审查”，并且也对 Node.js 语言提供“安全实践”，那么我们如何衡量“关键组件”重要性和编程语言的优先级的？

Brian Behlendorf：OpenSSF 的保护关键项目工作组正开展各项计划，帮助确定最关键项目的优先级。工作组将来自 Census II 调查的数据与哈佛大学创新科学实验室的数据相结合，整理出一项“关键性评分”，用以评估哪些项目在整个生态系统发挥着更重要的作用。

InfoQ：OpenSSF 是否也会提供“开源安全工具”或建议“安全工具”？这些工具或保证安全的措施会对商业安全企业造成什么影响吗？

Brian Behlendorf：OpenSSF 提供多种有助于提高开源软件安全性的工具，包括 Sigstore、SLSA、Scorecards 计分卡等。

SIgstore 于 2022 年 10 月全面推出，能帮助开发人员验证自己正在使用的软件，是否与声称的加密数字签名及透明日志技术相符。它提供一整套技术组合，包括用于软件工件签名的 Cosgin、证书颁发机构 Fulcio、透明日志 Rekor 和用于 Git 提交签名的 Gitsign。这些工具既可以独立使用，也能作为单独进程使用，由此建立起成体系的整体开源安全方案。

SLSA 的全称是软件工件供应链级别，这是一套安全框架或者说标准与控制清单，强调防止篡改、提高完整性，同时保护项目、业务或企业中的软件包与基础设施。在它的帮助下，用户能在供应链的各个环节上保障理想的安全性和弹性。

Scorecards 计分卡能帮助开源维护者改进其安全最佳实践，并帮助开源消费者以自动化方式判断自己使用的依赖项是否安全。该工具会对涉及软件安全的一系列重要条目进行检查和评估，并打出从 0 到 10 的具体评分。

此外，源自 Alpha-Omega 项目的安全工具工作组和 Omega 分析工具链也都致力于增强开源软件安全。这些工具能帮助我们更好地理解并保护整个开源生态系统，同时也是对安全审计等商业安全工具/服务的有益补充。

InfoQ：我们知道以前开源安全主要靠“Given enough eyeballs, all bugs are shallow” 以及一些零散措施。那么相对以前的方法，OpenSSF 提出的 10 条计划，在哪些方面有升级？

Brian Behlendorf：我们的动员计划建议，应通过观察整个开源供应链和生态系统中最有效的干预点，更直接、更系统地缓解与开源软件使用相关的风险。该计划还明确了执行筛查工作流的具体成本，这样利益相关方就能减轻承诺压力、推进其中的具体工作。

InfoQ：对比在开源项目发布和运行之后进行补救，“ Security by design ”也同样重要。在安全设计方面，OpenSSF 会提供什么措施或指导原则吗？

Brian Behlendorf：OpenSSF 提供免费的安全软件开发基础课程，开发人员可以通过这些课程理解安全软件设计与开发的各项要点。

InfoQ：今年，Python Package Index 宣布他们将实施新的帐户安全政策，反而受到了社区的强烈反对，让开源维护者提供安全性是一个复杂的命题。如果不能强加要求，那么最好的保障措施是什么？

Brian Behlendorf：目前可行的安全改进思路很多，也都能供开发人员轻松应用。如果能把这些成果跟工具关联起来（例如 SBOM 生成），那上手门槛就更低了。当然，并不是所有成果都能实现自动化或者底层化。肯定会有 Scorecards 计分卡、排行榜、基金会政策等因素以更显性的方式融合到基本安全实践中来。

InfoQ：相对于一些企业开源项目，还有相当一部分的开源项目，包括一些最流行的项目，只有个位数的维护者。他们有限的精力在全力维护开源项目的同时，很难再兼顾到安全，那么这种情况有什么样的解决方案？

Brian Behlendorf：不少开源软件项目的人手本来就很匮乏，那就更不应该把安全重任放在维护人员肩上。一种可行的帮助举措，是为项目提供资金以支持安全修复或改进工作。我们还可以努力打造更多更好的开发与部署工具，例如 CI/CD 工作流或开发者工具，立足基本面提升项目的整体安全性。我们也能为开源维护者提供支持，协助开发出更健全的漏洞上报与披露流程。

InfoQ：作为开源软件开发人员，我们应该具备哪些安全知识以及如何有效获取这些知识呢？

Brian Behlendorf：对开源软件开发者和用户来说，最重要的一点就是了解软件安全开发和使用方面的基础知识。OpenSSF 提供免费的安全软件开发基础课程，开发人员可以借助这些资源了解安全软件开发中的各项要点。

InfoQ：OpenSSF 建议的或提供的其他保护开源软件的方法有哪些？

Brian Behlendorf：确保组织了解开源软件究竟是什么，又该如何负责任地加以使用。考虑建立并实施开源战略，保证组织能够高效且安全地使用开源成果，同时将风险降至最低。

InfoQ：未来，OpenSSF 还有哪些计划？

Brian Behlendorf：作为开源社区，我们的未来完全取决于做出贡献的每一个人。过去一年来，我们看到了在 2022 年初时根本无法想象的新产品和新措施。我个人认为，AI 将全面进入开源软件安全领域——既可以作为防御手段，也可能成为建设性工具。我们将继续在 OpenSSF 的旗帜下扩大不同项目和计划的组合，同时将众多项目整合到统一的工具套件当中，让各种安全开发方法和成果融入工具链条。这种融合工作当然难度极大，但在安全领域却至关重要。毕竟在这类领域中，“能用很多办法解决同一个问题”并不一定是好事，强有力的标准和规范往往才是理想之道。