开源意味着不问责，我们准备好应对比 Log4Shell 更大的安全危机了吗？｜Log4j 一周年特别报道

采访嘉宾 ｜ Brian Behlendorf、董国伟

编辑 ｜ Tina

开源安全正在经历一个加速变革的时期。

Log4Shell 爆发后，负责 Log4j 的三位没有酬劳的维护人员一边忍受抨击，一边不眠不休地工作了一个多星期，为这份影响世界的代码打上了补丁。

Log4Shell 再次凸显了在 SolarWinds 攻击后备受关注的供应链安全问题。2022 年本应是“供应链安全元年”，不幸的是，一年后的现在这个漏洞仍然普遍存在，修复版本采用率没有想象中的高，而且数据显示，软件供应链攻击频次反而呈现出急剧上升趋势。

在过去的二十年里，开源软件使得企业软件创新爆炸式增长，对于一个越来越依赖开源软件运行的世界来说，供应链安全是一个巨大的、关乎生存的问题。Log4Shell 成为头条新闻，让大家认识到，“资源相对匮乏、以志愿者为基础的开源社区也存在着安全风险”，那么是否有更严重的“爆发”正在路上？

对 Log4Shell 漏洞的披露也成了开源安全治理的一个好时机，开源和安全社区、企业和 Linux 基金会的 OpenSSF 在这一年里更进一步地联合了起来，出现了多项改善关键开源软件安全状况的举措。在 2022 年结束之际，我们采访了 OpenSSF 总经理 Brian Behlendorf 以及就职于国内头部安全企业的董国伟博士，他们从国际和国内两个视角讲解了开源安全的现状和应对措施。

Brian Behlendorf 完整访谈：https://www.infoq.cn/article/StFg6xtfUMeUwz8kpX5Z

董国伟博士完整访谈：https://www.infoq.cn/article/rrqXAPN3Jk527MI1pmhi

会不会有下一场更严重的“暴雷”？

Linus 法则断言，“只要有足够的眼睛，所有的错误都是浅薄的。” 换句话说，只要有足够多的开发人员，几乎每个编程缺陷都会被快速识别和修复。这观点放在 90 年代，或许是正确的，毕竟 Linux 作为最可靠和最安全的操作系统之一，它的成功可以归功于 Linus 定律的应用。

近年来，随着软件系统的蓬勃发展，开源协作模式使得软件供应链的供应关系愈加庞大复杂, 供应链的管理也愈加困难。然后，Log4j 漏洞爆发了。

Log4Shell 只是一个警钟

作为一个开源日志库，Apache Log4j2 是 Java 应用最广泛的开源日志组件，广泛应用于政府、企业和公共服务机构的平台、应用和业务系统中，该漏洞覆盖范围广而且利用门槛低，对大量系统和机构造成了严重影响。Log4j 漏洞也被称为 Log4Shell，其 CVSSv3 得分为 10.0。用更容易理解的方式来说明就是，严重度评分是从 0.1 到 10.0，Log4Shell 得了个最高分。

对于普及度高的漏洞，其实很难完全修复。漏洞爆发后一年后，大多数组织仍易受到 Log4Shell 漏洞的攻击，在全面修复之后，还有近三分之一软件中再次出现 Log4Shell 漏洞。简单来说，原本的代码确实修复了，但之后有人引入了“新代码”，而新代码里又包含旧的 Log4j 版本。然后，漏洞就不断被复活，就像一场“森林火灾”，花一年的时间还扑不灭。

Log4Shell 的例子也告诉我们，如果一段开源代码在全球范围内被大量采用，要缓解开源软件引入的安全威胁，可能要花费大量成本、修复容易出现错误、甚至可能引入新的安全隐患等。

Log4Shell 仅仅是开源库中被发现和利用的系列漏洞之一。

开源无处不在：Synopsys 公司发布的商业代码库报告发现，商业代码库中 78%的代码来自开源项目。这些产品被应用于各种环境，从民用手机到互联网、再到国家安全及国防系统。出于这个原因，一旦这些被广泛应用的开源库中出现漏洞，则可能影响到大量已部署代码并造成严重后果。

而根据奇安信的分析统计，开源系统中，漏洞的增长速度、安全缺陷和高危安全缺陷的密度，以及典型缺陷的检出率均呈现出增长的趋势；国内企业开发的软件项目中，100%使用了开源软件，存在已知开源软件漏洞的项目占比 86.4%，平均每个项目存在 69 个已知开源软件漏洞，十几年前的古老开源软件漏洞依然存在于多个项目中。并且通过实例分析，也证实了“老漏洞”攻破最新主流产品的情况。同时版本长时间不更新和更新非常频繁的开源项目，比例都在增加；企业开发的软件项目中仍然在使用 20 年前老旧版本的开源软件。此外，在开源生态系统中，更是存在非常多的被大量依赖的开源项目，比 Log4j2 组件依赖数多的项目也不在少数（Log4j 甚至排不到前 50 名），这些作为“底座”的组件一旦爆发严重漏洞，其波及的范围可能比 Log4Shell 更大，完全有可能造成比它更严重的后果。

供应链攻击越来越多

根据安全报告显示，Log4Shell 漏洞披露后的 72 小时，全球出现了超过 80 万次利用漏洞的尝试。

Log4Shell 漏洞的出现，像给“黑客”们竖起了一个靶子，告诉他们开源代码中存在着一些无意间嵌入的、可用于进一步攻击的“秘密”，这让更多的恶意攻击者将注意力转向了软件供应链。

过去这一年里，软件供应链攻击呈急剧上升趋势，自 2019 年以来平均每年增长 742%。

自 2019 年以来，软件供应链攻击有所增加。

根据奇安信的跟踪统计，过去这一年多，几乎每个月都会发生有关开源安全的典型事件，涉及开源软件安全漏洞、开源生态系统安全等方面，例如：

2021 年 11 月，热门 NPM 包 coa 和 rc 连续遭劫持，并被植入恶意代码，影响全球 React 管道。coa 库每周下载量约 900 万，用于 GitHub 上近 500 万个开源库中，rc 库每周下载量达 1400 万。

2021 年 12 月，Apache Log4j2 曝出 Log4Shell 漏洞(CVE-2021-44228)。

2022 年 3 月，俄乌冲突中，NPM 开源包 Node-ipc 的作者 RIAEvangelist 作为反战人士，在代码仓库中进行了“供应链投毒”，添加的恶意 js 文件能够在包使用者的桌面创建反战标语。Node-ipc 使用非常广泛，每周下载量超过 100 万次。

2022 年 4 月，以色列安全公司发现高通和联发科芯片的音频解码器存在三个漏洞（CVSS 评分为 9.8、7.8 和 5.5），来源于 11 年前苹果公司开发的开源无损音频编解码器 Apple Lossless。利用这些漏洞进行攻击，可获取受影响移动设备媒体、音频会话的访问权限及摄像头数据流等，漏洞影响范围包括数百万安卓设备。

2022 年 7 月公开（可追溯至去年 12 月），攻击者通过在 NPM 上发布包时绕过双因子认证（2FA），创建了 1000 多个用户账号，攻击者利用这些账号自动投放 1283 个包含挖矿脚本 eazyminer 的恶意模块，利用数据库、Web 等所在服务器的机器闲置资源进行挖矿。如果开发者安装了这些包，则会在被调用时挖掘门罗币。

......

恶意攻击者继续瞄准开源项目生态系统，没有理由相信 2023 年这些攻击者的表现会有所不同。

对于开源软件漏洞，应不应该问责？

开源软件和自研软件在代码层面并没有本质区别，因此开源软件带来的安全威胁并不会比自研软件少。而当同一段代码被全球范围广泛使用时，一个项目中的一个漏洞可能导致无数关键系统离线。 

开源提供了很多益处，降低壁垒、增加创新，让大家将有限资源投入到其他有价值的工作中。这种资源是免费的，任何人都可以使用它。然而，漏洞也是不可避免的，如果你在使用供应商提供的商业软件的过程中发现安全问题，你可以去找供应商并要求他们修复和承担责任，但开源软件跟商业软件的责任模式不同，自打开源概念诞生以来，开源软件就一直强调“使用者风险自负”。

开源生态之所以像今天这么繁荣，是因为开源软件采用的自由许可协议和一系列免责条款，包括学生、初创公司员工、志愿者乃至大企业技术专家在内的各类开发人员，都会在无需共享代码的情况下针对风险或缺陷开展协作和快速迭代。

有追求的开源软件维护者也有动力修复 bug、编写说明文档并为新用户提供其他形式的辅助，借此增加项目的用户数量，最终吸引到更多技术贡献者。但最终用户要想获得商业级别的支持或安全保障，还是需要跟供应商签订付费协议。既想不花一分钱，又想让免费下载和使用的软件安全可靠，这确实不太现实。

这就是开源软件当前的问责模型（当然，主动引入后门、植入恶意代码的行为除外）。即使面对日益增加的网络安全问题，这套问责模型也仍然发挥着效力。那些打包并支持开源代码的软件供应商需要对客户负责，由他们来保证提供安全可靠的软件使用体验。在购买软件支付合同或软件即服务时，我们有权要求供应商提供相应的安全保证。但我们绝不能通过放慢开源软件的迭代速度来追求更高的安全性，这样只会增加开源贡献者的负担，最终提高准入门槛、反而削弱所有参与者的安全信心。

开源社区该如何应对？

自由许可和“免责条款”造就了开源的繁荣，但这种“免责机制”，也使得像针对其他软件开发商那样，对开源社区和开源贡献者进行强约束较为困难。为了保持开源免费的核心精神，开源社区不能对其项目强加条件要求。

去年，开源社区也不断进行尝试，寻找大家可接受的解决办法，还有软件供应商试图通过大量调查问卷征求安全实践认证，但这明显有将安全责任转移给开源维护者的嫌疑，当然会遭到拒绝。

还有比如，在发生多起开源维护者账户被劫持的事件后，为了提高生态系统的总体安全性，最受欢迎的开源项目集合之一 Python Package Index （PyPI）宣布将对“关键”项目（下载项目的前 1%）实施最低安全措施，要求这些项目的维护者使用双因素身份验证来保护他们的帐户，涉及约 3,500 个项目。这引起了社区的强烈抗议，有的威胁要放弃他们的“流行”项目，其中一位说道：“免费的不值得做这些，只有在我真正得到报酬时才担心供应链安全”。对比 2016 年 left-pad 事件，一名开发人员从 npm 注册表中撤回了他的关键 JavaScript 项目，虽然只有 11 行代码，但是后果却严重到出乎意料，几乎破坏了当时的互联网。

而且开源社区中，维护人手匮乏的问题不在少数，大约30% 的开源项目（包括一些最流行的项目）只有一个维护者（负责审查代码贡献、扫描漏洞和解决报告的错误的开发人员）。2014 年的 Heartbleed 攻击——影响了近五分之一的互联网——利用了一个开源库中的漏洞，该库由两名全职开发人员维护，他们单独负责超过 500,000 行代码。也因此，虽然研发作为软件代码安全性的第一责任人，开源安全“左移”是必要的，但开源作为一种开发者的自愿协作活动，一味地提高开源安全的底线必然会遭到抵制，并影响开源社区的正常发展。

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

Linux 基金会认为，要想真正破解这些挑战，必须找到新的方法来衡量开源软件包中存在的种种未被发现的缺陷和风险，还要想办法衡量已经无法升级的依赖项中各已知缺陷可能造成的影响。事实上 Log4Shell 等重大安全事件让包括行业主导方和政策制定者在内的各利益相关方意识到问题严重性。我们国家也于 2022 年 11 月初，立项了国家标准《软件产品开源代码安全评价方法》，着手规范应对此类问题。

如今开源已经成为社会的“高速公路和主要桥梁”，对开源进行的漏洞攻击造成的影响会更大。因此，与其说开源安全是开源开发人员的个人义务，不如说必须有一个组织来联合起个人及企业，共同推动开源安全治理，这也是 OpenSSF 诞生的初衷。

开源安全不能单打独斗

OpenSSF 是一个围绕开源安全建立的组织，联合了行业内最重要的开源安全项目和相应的个人及企业贡献者。

OpenSSF 与上游及现有社区合作，提供安全审计，或对下游提出“警报”，以帮助提高开源行业的整体安全性。其目标是在未来，让开源生态系统中的每位参与者都能使用和分享更多高质量软件，培养大家主动解决安全问题的主人翁心态，并将高质量和主动处理安全问题视为理所当然。

过去，人们曾做出各种努力来提高开源软件安全性。这些努力包括 Linux 基金会的核心基础设施倡议（CII），由 GitHub 安全实验室建立的开源安全联盟（OSSC），以及由谷歌等企业创立的联合开源软件倡议（JOSSI）。OpenSSF 的使命就是将这三大倡议合并为“跨行业协作项目，号召各方领导者齐聚一堂，共同提高开源软件的安全性。”

2022 年，OpenSSF 成员范围扩展到了全球一百多个组织，其中也包含了一些中国企业如信通院、阿里、腾讯等。经历两次美国白宫会议之后，OpenSSF 启动了多项新举措，包括 Alpha-Omega 项目以及开源软件安全动员计划，还提供了多种有助于提高开源软件安全性的工具，包括 Sigstore、SLSA、Scorecards 计分卡，以及给开发人员的免费安全软件开发基础课程。

Alpha-Omega是 OpenSSF 推动的一个核心项目，创立于 2022 年 2 月，其使命是通过直接吸引维护者和专业分析意见，显著提高开源软件的安全水平。“Alpha”代表开端，是指与开源项目的关键维护者合作，帮助他们发现并修复安全漏洞，借此改善安全状况；“Omega”则代表末尾，强调确定至少 1 万个已经广泛部署的开源软件项目，并把自动化安全分析、评分和补救指南等全面推广至开源维护者社区。2022 年，该团队资助并增强了五大关键开源项目的安全性，分别是 Node.js、Eclipse 基金会、Rust 基金会、jQuery 和 Python 软件基金会。

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

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

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

SBOM 很有用

OpenSSF 另一个核心项目是SBOM。

你也许想不到，在 Log4Shell 漏洞爆发后的今天，从 maven central 主动下载的 Log4j 版本中有约30%是易受攻击的版本。那么为什么仍会有人在拉取这些易受攻击的 Log4j 版本？很大一部分原因，是许多组织缺乏成熟的漏洞管理流程，以及缺乏对其软件组件（软件物料清单，称为 SBOM）的可见性，导致大家在不知不觉中仍在使用依赖易受攻击版本的 Log4j 的软件。很多企业也无法快速判断自己用的 Log4j 版本有没有缺陷，因为没有这样的 SBOM 能确切告诉他们当前使用的是哪个版本。

SBOM 本质上就是构成软件产品的“成分表”，即各个依赖项。有许多包括开源软件在内的第三方来源的成分，我们并不知道其具体包括哪些内容，因此对其安全性的了解更无从谈起。SBOM 能帮助企业或开发者更好地了解自己所使用的开源软件到底包含哪些依赖项，从而轻松审查这些依赖项并随时加以更新。

SBOM 很有用，没有它们，即使是最大、最先进的技术公司也需要数周时间才能确定它们容易受到攻击的位置，更不用说修补每个组件了。

奇安信建议将软件物料清单（SBOM）作为软件供应链安全的抓手首先推进落地，通过软件物料清单（SBOM）的推广应用，牵引软件供应链上下游各个环节的协同，在此基础之上再采取更多举措逐步深化，实现软件供应链安全保障的目标。同时，软件安全企业的软件成分分析（SCA）工具能够方便的实现 SBOM 的自动生成功能，在目前软件开发普遍集成开源软件的情况下，对于提升软件透明度、开展安全分析具有重要作用。

如今，已经有多种 SBOM 工具可供大家使用，其中最流行的两种 SBOM 格式分别是 SPDX 和 CycloneDX。OpenSSF 正努力提高工具成熟度，并通过 SBOM Everywhere 特别兴趣小组推广这些工具。

写在最后

2022 年，特别是在 Log4Shell 等开源软件安全事件发生之后，我们可以看到从行业到政府的众多利益相关方，都开始更好地理解到开源软件的重要意义和重新投资开源生态系统的迫切性。

虽然 2023 年里开源软件和软件供应链依然是重要的被攻击领域之一，攻击事件仍然会保持持续高发态势。但另一方面，各行业对开源安全的认知也在不断提升，对这一领域的关注度在不断提高。国家层面也开始积极资助和支持开源软件安全工作，这一切都令人备受鼓舞。企业层面，也正在制定和完善内部的开源软件安全管理规定，规范开源软件的安全使用，减少其引入的风险，相信明年力度将更大。

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

开源为各个组织提供了巨大的价值，是我们今天所看到的创新步伐的核心驱动力，相信只要我们齐心协力，就不会让它失控。

参考链接：

https://twitter.com/yazicivo/status/1469349956880408583

https://mp.weixin.qq.com/s/9qLAPw2omEegzWjG43N0lQ

https://m.freebuf.com/articles/paper/340234.html

https://www.sonatype.com/state-of-the-software-supply-chain/introduction

https://twitter.com/geerlingguy/status/1542589998725300229?s=21&t=qW36lPwdbt-bfR0vvt20Og

https://www.b-list.org/weblog/2022/jul/11/pypi/

https://docs.google.com/presentation/d/18hkLb6CIC49tBFp2nX4prbhKaUiHj_cfXPN95zg4dS0/edit#slide=id.g13347aae6d9_3_0

https://en.wikipedia.org/wiki/Heartbleed

https://openssf.org/blog/2022/09/13/funding-python-spdx-development-with-the-openssf-and-sbom-everywhere/

https://www.infoq.cn/video/9b1ia67t2O8Ll1IZ02wa

https://www.sonatype.com/resources/log4j-vulnerability-resource-center