一

2014 年 4 月 7 日下午，旧金山一家咖啡馆里，一个叫 Codenomicon 的芬兰公司的安全研究员 Antti Karjalainen 看着自己刚刚写好的报告，犹豫了几分钟。然后他把它发给了 OpenSSL Software Foundation。

Codenomicon 的同事们已经做了一个相对煽情的决定：他们要给这个漏洞起个名字、做个 logo、申请域名 heartbleed.com1。这种做法之前没有先例。漏洞通常用 CVE 编号（CVE-2014-0160）+ 技术描述就够了。但 Codenomicon 意识到这个漏洞的严重性：它影响全球约 17% 的“安全”网络服务器，大约 50 万台。它需要一种能让非技术读者也理解的传播方式。

当天晚上，OpenSSL 项目组发布了 1.0.1g 版本——一个紧急修补。Heartbleed.com 同时上线。第二天早上，主流媒体的头条几乎全是 Heartbleed。Reuters、CNN、BBC、New York Times、Washington Post——这是第一次，一个开源软件漏洞成为全球新闻周期里的头条2。

技术细节是这样的。OpenSSL 是一个 C 语言写的密码学库。全世界绝大部分 HTTPS 网站都依赖它做 TLS 握手——浏览器和服务器之间建立加密连接的那一步。在 2012 年，OpenSSL 添加了一个叫 “Heartbeat” 的 TLS 扩展，让客户端和服务器可以发送小的心跳消息保持连接。Heartbeat 扩展的实现里有一个错误：当客户端告诉服务器“我发了 X 字节，请回我 X 字节”时，服务器没有验证 X 是否真的等于客户端实际发送的字节数。攻击者可以说“我发了 1 字节，请回我 64KB”——服务器会从内存里读 64KB 数据回给攻击者。那 64KB 可能包含任何东西：其他用户的 cookies、私钥、密码、个人信息3。

这个 bug 是 2011 年由 Robin Seggelmann 引入的。Seggelmann 当时是德国明斯特应用技术大学的博士生，做 SCTP 协议研究4。他给 OpenSSL 提交了 Heartbeat 扩展的实现，因为他需要这个扩展做自己的研究。他没有发现自己写的边界检查代码有错误。OpenSSL 的核心维护者 Stephen Henson 审核了这份代码，也没发现错误。代码在 2012 年 12 月 31 日合并到 OpenSSL 主分支——一个跨年夜的 commit。

接下来一年半，这个 bug 一直在那里。被部署到了全世界绝大部分 HTTPS 服务器上。直到 2014 年 3 月，Google 的安全工程师 Neel Mehta 和 Codenomicon 的研究员独立发现了它，差不多在同一周。两边都决定要报告 OpenSSL 团队。这个时间上的同步让一些研究者后来怀疑：可能更早就有人知道这个漏洞，可能已经被某些情报机构利用了相当长时间。但没有公开证据证明这种利用5。

二

Heartbleed 公开后两周，4 月 24 日，Linux Foundation 联合 Amazon、Cisco、Dell、Facebook、Fujitsu、Google、IBM、Intel、Microsoft、NetApp、Qualcomm、Rackspace、VMware 等公司，宣布成立 Core Infrastructure Initiative（CII）。第一项决定是：资助两名全职 OpenSSL core developer6。

这个公告几乎所有人都没注意一个事实——在 Heartbleed 之前，OpenSSL 的“全职 core developer”数量是零。

OpenSSL Software Foundation 的主席 Steve Marquess 在 Heartbleed 公开后接受 The Register 采访时给出了具体数字。OpenSSL 团队当时有 4 个人：

  • Stephen Henson：唯一被 Marquess 称为 “primary developer” 的全职贡献者，但他不是受雇于 OpenSSL Software Foundation——他是个独立顾问，开 invoice 计件。Foundation 每年付给他大约 $20,000 的钱。他每周工作 50-60 小时，主要靠商业咨询合同补贴
  • Bodo Möller：受雇于 Google，业余时间贡献
  • Ben Laurie：受雇于 Google，业余时间贡献
  • Andy Polyakov：在瑞典皇家理工学院做研究，业余时间贡献

整个 OpenSSL 项目的年度捐款总额——来自公司和个人——大约是 $2,000 美元7。

Marquess 接受采访时说了一句被反复引用的话：

“The mystery is not that a few overworked volunteers missed this bug; the mystery is why it hasn’t happened more often.”8

把这句话放在数字里读：4 个人维护着一个被 50 万台关键服务器使用的库。他们的年度总资源（按 Stephen Henson 的 $20,000 + 其他人业余时间估算）远低于 Facebook 一个高级工程师的年薪。这个比例不可能不出问题；问题是出在哪里、什么时候出。

这是 2014 年 4 月那一刻，整个互联网行业第一次真正注意到的事实。在那之前，开源的“许多眼睛”理论——Eric Raymond 1997 年《Cathedral and Bazaar》里提到的“足够多的眼睛让所有 bug 浅显”——被普遍接受。Heartbleed 让这个理论第一次面对一个具体的反例：眼睛是有的（OpenSSL 是公开源代码的），但有能力看的眼睛不够。审核 OpenSSL 这种密码学库需要 SSL/TLS 协议、密码学、C 语言低级内存管理三个领域的深度知识。这种人在全世界总共不超过几百个。其中愿意花业余时间审核别人代码的，更少9。

CII 在 Heartbleed 后两年里资助了 OpenSSL、NTP、OpenSSH 等几个关键项目。预算大约 $1 千万——分摊到几年里。这个数字相对于科技巨头的总营收来说微不足道。当时 Google 一年营收约 $660 亿，Facebook 约 $125 亿。$1 千万对它们来说是“四舍五入掉的钱”。

但这个数字对开源关键库的维护者来说，是从 $0 到正数的质变。CII 资助让 OpenSSL 从此有了正式的全职维护者。它让其他关键库的维护者第一次能光明正大地讨论“我们也需要钱”。

CII 2020 年合并为 Open Source Security Foundation（OpenSSF），这是 Linux Foundation 旗下专门处理 OSS 安全的子组织。Brian Behlendorf——Apache 创始人之一，前 CNCF 执行董事——出任 OpenSSF General Manager10。

但 Heartbleed 之后 7 年，下一个具体的“基础设施崩溃”就来了。

三

2021 年 11 月 24 日，阿里云安全团队的工程师 Chen Zhaojun 在内部安全测试中发现一个严重漏洞。它在 Apache Log4j 中——一个所有人都用的 Java 日志库。这个漏洞允许攻击者通过精心构造的字符串触发任意代码执行11。

Chen Zhaojun 按照负责任披露的规则，把这件事报告给了 Apache Software Foundation。Apache Log4j 项目组从那天起开始紧急修复。两周后，2021 年 12 月 9 日，漏洞详情在公开邮件列表泄露——一个安全研究员在 Minecraft 服务器上演示了它，演示视频迅速传开。

接下来 48 小时是互联网历史上最紧张的 48 小时之一。

Log4j 不是一个小库。它是所有大型 Java 应用默认使用的日志系统。Apple iCloud 在用、Twitter 在用、Steam 在用、Minecraft 在用、亚马逊 AWS 在用、阿里云在用、苹果 iCloud 在用、几乎所有大型企业 Java 应用都在用。CISA（美国网络安全和基础设施安全局）发布的最高级警告称：Log4Shell 影响“hundreds of millions of devices”12。

漏洞的严重程度是 CVSS 10.0——满分。能远程执行代码，不需要任何认证，几乎所有 Java 应用都受影响。如果一个应用在某处记录用户输入到日志（几乎每个 web 应用都这么做），那么用户只要输入一个特定字符串，攻击者就能远程在服务器上执行任意代码。

整个 12 月 9 日到 12 月 11 日，全球安全团队都在紧急扫描、紧急 patch、紧急部署 WAF 规则。我个人认识的几个工程师那个周末没睡觉。在所有商业基础设施中，Log4Shell 触发了一种少见的“全公司 incident”——CTO 亲自参加 sync，CEO 收到状态报告，公关团队准备危机声明。

Apache Log4j 团队的反应同样是 24/7 工作。他们在四天内发布了 2.15.0（初步修复），然后是 2.16.0（更彻底的修复），然后是 2.17.0（修复 2.16 中遗留的另一个问题）。整个修复过程靠的是 三个志愿者13。

主维护者 Ralph Goers——Log4j 的初始作者之一——在 12 月 11 日给 Bloomberg 的一份声明里说：

“The Apache Log4j project is being maintained by three people who volunteer their time.”

他还提到，他的全职工作是另一家公司的软件开发——Log4j 是他在工作之余维护的14。

读到这里有几个问题应该自然涌现：

  • 怎么会全球关键基础设施依赖三个志愿者？
  • 这三个人为什么愿意干？
  • 2014 年 Heartbleed 之后不是已经有了 CII / OpenSSF 吗？为什么 Log4j 没有被资助？

答案不在三个人的个人选择，在结构。

四

Log4j 的故事开始于 2001 年。Ceki Gülcü，那时候在 IBM 苏黎世研究院工作，发布了 Log4j 的第一个版本。他后来离开 IBM 去做了一个叫 SLF4J 和 Logback 的项目，把 Log4j 移交给了 Apache Software Foundation 维护。Apache 接管之后，主要维护者轮换了几代——Stefan Bodewig、Curt Arnold、Scott Deboy、Ralph Goers、Volkan Yazici、Gary Gregory15。

每一代维护者都是志愿者。Apache Software Foundation 本身不雇佣开发者——它是一个法律保护壳，提供版权管理、基础设施、品牌保护。具体代码工作由社区贡献者完成。这是 Apache 自 1999 年成立以来一直的做法。

2013 年，Ralph Goers 给 Log4j 添加了一个新功能：JNDI lookup。JNDI 是 Java Naming and Directory Interface，一个让 Java 应用查询命名服务（如 LDAP、DNS）的标准接口。这个功能让开发者可以在 log 输出中嵌入动态查询——比如 ${jndi:ldap://example.com/} 会在 log 时去查 LDAP 服务器拿数据16。

这是个有用的功能。它解决了真实问题——在 enterprise Java 应用中，开发者经常需要在 log 中嵌入动态环境信息。Ralph Goers 在 2013 年加这个功能时没有人质疑它的安全含义。它的安全含义是：如果 log 内容来自用户输入，那么用户可以让服务器去查任意 URL。攻击者可以让服务器查一个恶意 LDAP 服务器，那个服务器返回一段 Java bytecode，服务器执行这段 bytecode——任意代码执行。

这个 bug 在 Log4j 里活了 8 年。从 2013 年到 2021 年 11 月。期间它被部署到了全球数亿台 Java 应用上。没人发现。直到 Chen Zhaojun 因为某种偶然——可能是在做内部模糊测试时——注意到这个 JNDI 嵌入17。

8 年。这是 Log4j 故事的真正深度。8 年里，Log4j 项目本身没有专门的安全审计；JNDI lookup 这个功能没有被独立安全研究者认真看过；Apache Software Foundation 没有给 Log4j 提供安全人员。一个被全球数亿应用使用的库，依赖于“如果有志愿者愿意，他们会做安全审查”——而显然没有。

Log4Shell 跟 Heartbleed 之间有一个让人不安的对称：

  • Heartbleed bug 引入时间：2012 年 12 月。公开时间：2014 年 4 月。在野时间：约 17 个月
  • Log4Shell bug 引入时间：2013。公开时间：2021 年 12 月。在野时间：约 8 年

Log4Shell 的“在野时间”是 Heartbleed 的 5 倍。这不是偶然——它说明从 Heartbleed 到 Log4Shell 的 7 年里，关键基础设施的安全状况没有实质改善。CII 资助了 OpenSSL，但没有覆盖 Log4j。OpenSSF 在 2021 年 11 月——Chen Zhaojun 发现 Log4Shell 的同一个月——刚刚成立 Alpha-Omega 项目（要在 12 月 28 日宣布资助）。

7 年里很多事情发生了：CII 成立、OpenSSF 成立、Linux Foundation 营收翻倍、GitHub 被 Microsoft 收购、整个云原生生态成为价值数千亿美元的市场。但 Log4j 仍然由三个志愿者维护。

这种不对称的真正原因，是个简单的事：没有人觉得自己有义务。Apache 是社区基金会，它的角色是协调，不是雇佣。使用 Log4j 的公司没有合同义务给 Log4j 捐款——他们只需要遵守 Apache 2.0 license，那是个“非常友好”的许可证（你可以做任何事，包括商业使用、衍生作品、专利保护）18。维护者自己也没有义务推动企业资助——Apache 文化是“如果你想要更好的 Log4j，提交 patch”，不是“如果你想要 Log4j 更安全，付钱”。

这种“无义务结构”对 1998 年那个商业开源运动是个核心特征——它让大公司能放心使用开源代码，因为没有附带责任。它也是为什么开源在 2001-2018 年能商业上成功。但同样的特征，让关键基础设施的安全责任彻底分散——没有任何一方明确负责。

五

Log4Shell 之后两个月，2022 年 2 月 1 日，OpenSSF 宣布 Alpha-Omega 项目。Microsoft + Google 联合投入初始 $5 million。项目计划“alpha” 部分——直接资助约 10 个最关键开源项目的维护者；“omega” 部分——对 10,000 个广泛部署的项目做自动化安全分析19。

Brian Behlendorf——OpenSSF GM——在公告里说：

“Alpha-Omega supports this effort in an open and transparent way by directly improving the security of open source projects through proactively finding, fixing, and preventing vulnerabilities.”20

到 2024 年 Alpha-Omega 已经资助了约 30 个项目，包括 Eclipse Adoptium、Rust Foundation 安全审计、Node.js 等。每个项目获得 $50K 到 $500K 不等的资助21。

同年 5 月，德国联邦议会拨款 €3.5 million 每年成立 Sovereign Tech Fund（后改名 Sovereign Tech Agency）。第一波资助包括 curl、Drupal、Gnome、openSSH、systemd、Sequoia PGP 等。每个项目获得 €50K 到 €1M 不等22。

到 2024 年底，STF 已经支持了 60+ 个关键开源项目。德国之后，荷兰、欧盟整体、英国都跟进了类似项目。“政府资助开源关键基础设施”在 2022-2024 年从一个边缘想法变成主流政策。

Tidelift 是另一种路径。它是 2017 年成立的私营公司，自我定位为“为开源 maintainer 提供商业支持的中介”。它跟企业签合同（每年订阅费），企业获得“被支持开源项目”的承诺；它再把这些钱按比例分给项目 maintainer。2024 年 Tidelift 调查显示，19% 的开源 maintainer 从 Tidelift 获得部分收入；25% 从 GitHub Sponsors 等捐赠程序获得收入23。

把这几个数字放在一起看：

  • CII / OpenSSF Alpha-Omega：累计 $1500 万 + 直接资助约 30 个项目
  • Sovereign Tech Fund：每年 €3.5M，累计资助 60+ 个项目
  • Tidelift：覆盖约 19% 的活跃 maintainer
  • GitHub Sponsors：覆盖约 25% 的活跃 maintainer
  • 加起来：覆盖不到 50% 的活跃 maintainer，且总金额仍然远低于一个中型科技公司的工程团队预算

这是 2014 年 Heartbleed 之后十年的成果。它显著改善了关键开源项目的资助状况——这是真的进步。但它没有改变结构。50% 以上的 maintainer 仍然完全靠个人时间维护项目。被资助的那些项目里，资助通常只够 1-2 个全职 maintainer，远不到“专业团队”的规模。

六

然后 2024 年 3 月 29 日，xz-utils 后门被发现。

我们留下个章节专门讲 xz 的故事。这里只需要知道一件事：xz Utils——一个被几乎所有 Linux 发行版用于压缩的库——被一个使用 “Jia Tan” 身份的国家级行为者通过三年精心社会工程接管。后门在 2024 年 2 月被嵌入到 5.6.0 release。它差点被集成到 Debian、Ubuntu、Fedora、Arch Linux 的下一个稳定版本。被发现是因为一个 Microsoft 工程师 Andres Freund 在做 PostgreSQL 性能测试时偶然注意到 SSH 登录耗时异常24。

xz Utils 的维护者 Lasse Collin 是芬兰人，长年单人维护这个项目。Heartbleed 时 OpenSSL 是 4 人团队，Log4j 是 3 人志愿者；xz 是 1 个人。

把三个事件放在时间轴上看：

  • 2014-04：Heartbleed。OpenSSL：4 人，年度捐款 $2K
  • 2021-12：Log4Shell。Log4j：3 个志愿者，所有人有全职工作
  • 2024-03：xz Utils backdoor。xz：1 个人 + 一个伪装成 co-maintainer 的攻击者

三个事件之间间隔在缩短（7 年 → 不到 3 年）。每次的维护资源更少。每次的攻击/漏洞复杂度更高。

这是这本书第三章想说的核心：开源关键基础设施的脆弱不是一次性事件，是一个持续的系统性问题。每次响应都不够。每次“我们要修这个”都改善了一点点，但下一个事件总是来得更快、更复杂。

Heartbleed 是无意 bug。Log4Shell 也是无意 bug。xz 是有意 backdoor——这是质变。从 2014 到 2024 这十年里，攻击者意识到关键基础设施是个机会。他们不再被动等待 bug 出现；他们开始主动制造它们。

七

读到这里有人可能会问：为什么这种 “免费搭车” 一直没解决？

简单的回答：经济激励不对齐。

详细的回答需要看几个具体角色的处境。

使用开源的大公司：它们是最大受益者。Google、Facebook、Amazon、Microsoft、Apple——每一家都把开源软件作为产品的基础。它们的整体节省（不需要自己开发 OpenSSL、Log4j、Linux kernel）每年是数十亿美元规模。它们如果决定大规模资助开源，每家拿出 $1 亿美元/年也不会影响财报。但它们不这么做，因为：

  • 开源已经“足够能用”——没有商业压力推动它们投入
  • 资助开源没有差异化竞争优势——花的钱让所有人受益，包括竞争对手
  • 开源治理结构（Apache、Linux Foundation 等）让单一公司难以主导
  • 每家公司都希望“另一家先付钱”——典型的 free rider 问题

开源 maintainer：他们是最受压迫的一方。多数是个人志愿者，有全职工作。维护开源项目是 unpaid labor，但产生的压力是真实的——bug 修复、安全漏洞、用户支持、企业客户的隐性期望。Daniel Stenberg（curl 维护者）多次公开抱怨这种“全世界都依赖我但没人对我有责任”的处境25。

用户企业：它们大多数没有意识到自己依赖了多少开源。CTO 知道公司用了 Log4j，但不知道 Log4j 由 3 个志愿者维护。一旦 Log4Shell 这种事件发生，公司紧急 patch，但 patch 之后又回到“忘记开源是免费的”的默认状态。

政府：直到 2022 年 Sovereign Tech Fund 之前，政府没有把开源视为关键基础设施。SolarWinds 2020 年事件之后，美国 EO 14028 把 SBOM 提到联邦采购层面，但这是合规要求，不是资助。德国 STF 是第一个明确“政府应该直接资助开源关键基础设施”的项目。这种立场在 2024 年仍然是少数26。

每个角色都有自己的逻辑。每个角色都不愿意单独承担成本。结果就是关键基础设施长年缺钱，长年单人维护——直到下一个 Heartbleed / Log4Shell / xz 把所有人推到一个紧急状态。

八

2020 年 8 月，xkcd 网站上发了一幅漫画，编号 2347，标题 “Dependency”。

漫画画的是一个像积木塔的依赖图。从底层往上，每一层依赖下一层。最底层是“现代数字基础设施的所有组件”——堆得密密麻麻。在某个位置，整个塔的稳定取决于一个细细的、不起眼的小块。这个小块的注释是：“Some random person in Nebraska has been thanklessly maintaining since 2003.”

漫画的标题文字（caption）是：“Someday ImageMagick will finally break for good and we’ll have a long period of scrambling as we try to reassemble civilization from the rubble.”27

ImageMagick 是个非常具体的例子——一个 1987 年由 John Cristy 创建的图像处理库。它在大量 web 服务、内容管理系统、社交媒体平台后端使用。Cristy 长年一人维护。如果它“坏了”——比如出一个严重漏洞、或者 Cristy 不再有时间——一大段互联网会瘫痪一阵。

漫画在发布时（2020 年 8 月）是一个隐喻：互联网依赖于太多被遗忘的小项目。当时这是一种隐喻——大家觉得“哈，xkcd 又抓到了 IT 行业的痛点”，但没人觉得这是即将发生的事。

15 个月后，Log4Shell 发生了。漫画从隐喻变成了具体事件。Log4j 不是“内布拉斯加的某个人”——它是 Ralph Goers——但结构一样。一个被全球数亿应用依赖的库，由几个志愿者维护。

39 个月后，2024 年 3 月，xz Utils 后门被发现。Lasse Collin——芬兰人，长年单人维护——成了第二个“内布拉斯加的某个人”。但 xz 跟 Log4j 还有一个关键不同：xz 不是被 bug 攻击，是被有计划的国家级行为者接管。

这是 xkcd 2347 之后这些年最大的变化。漫画里那个“内布拉斯加的某个人”还是被假设是好意的、勤奋的、可信的。2024 年之后，这个假设没办法再维持。开源关键基础设施不只面对“无意 bug”——还面对“有意接管”。

九

把这一章的所有数字放在一起：

  • OpenSSL 2014：4 人，年度 $2K
  • Log4j 2021：3 个志愿者
  • xz Utils 2024：1 个人 + 一个伪装的攻击者
  • Heartbleed 影响：50 万台服务器，全球 17% HTTPS
  • Log4Shell 影响：数亿设备，几乎所有 Java 应用
  • xz Utils 影响（如果未发现）：全球绝大部分 Linux 服务器
  • CII 资助：累计 $1500 万（2014-2020）
  • OpenSSF Alpha-Omega：$500 万初始（2022）
  • Sovereign Tech Fund：每年 €3.5M（2022 起）
  • Tidelift / GitHub Sponsors：覆盖约 50% maintainer，多数小额

这些数字之间的不对称是这一章的全部内容。被使用的规模 vs 维护资源：完全不成比例。这种不成比例在 1998-2014 年的时代是默认状态——开源运动靠“志愿者文化”取得了胜利，但同样的志愿者文化让它的关键节点长期缺钱。Heartbleed 让一部分关键项目获得资助。Log4Shell 让资助扩大。但 xz Utils 暴露了一个更深的问题：有资助也不够。

Lasse Collin 不缺钱——他是欧洲的、独立的、有其他收入的开发者。他缺的是注意力。xz Utils 是一个相对小众但极其关键的库——它的维护需要的不只是钱，是有审计能力的人愿意花时间审视每个 PR。Alpha-Omega 资助的项目数量有限；STF 资助的项目数量有限；这些项目之外的几千个关键基础设施仍然完全靠志愿者注意力。

xz 之后两年，截至 2026 年 5 月，没有发生第二次大规模 supply chain 后门事件。但安全研究界几乎一致认为：这是因为还没被发现，不是因为没有发生28。

下一章我们要做的就是把 xz 后门的完整故事讲清楚。这是这本书里技术细节最厚的一章，因为只有真正看到一次国家级 OSS 供应链攻击是怎么发生的，才能理解为什么这件事让所有 incident response 机制——CII、OpenSSF、STF——都觉得自己永远跟不上。

References

  1. Wikipedia: Heartbleed. 包括 Codenomicon 公开漏洞的过程。Link →

  2. heartbleed.com 官方页面（2014 年 4 月 7 日上线）。

  3. Heartbleed 技术细节：CVE-2014-0160 描述。Heartbeat extension 的边界检查缺陷。

  4. The Register 2014-04-11: “OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts”. Robin Seggelmann 的角色描述。Link →

  5. Digital Trends: “How Did the Heartbleed OpenSSL Data Encryption Bug Happen?”. 描述 Google + Codenomicon 独立发现的过程。

  6. Wikipedia: Core Infrastructure Initiative. Link →

  7. Mend.io: “How The Heartbleed Vulnerability Shaped OpenSSL as We Know It”. 提供 OpenSSL 2014 维护团队规模与年度捐款数字。Link →

  8. The Register 2014-04-11: Steve Marquess 引述（同 c3-ref-4）。

  9. Eric S. Raymond, “The Cathedral and the Bazaar” (1997). “Given enough eyeballs, all bugs are shallow”——著名的 Linus’s Law 来源。Link →

  10. Open Source Security Foundation 官方页面。Brian Behlendorf 任 GM。

  11. Wikipedia: Log4Shell. Chen Zhaojun (阿里云安全团队) 2021-11-24 私下报告。Link →

  12. CISA: Apache Log4j Vulnerability Guidance. Link →

  13. Wikipedia: Log4Shell. 描述 2.15.0、2.16.0、2.17.0 紧急 release 过程。Link →

  14. Ralph Goers 2021-12 的公开声明。“The Apache Log4j project is being maintained by three people who volunteer their time.”

  15. Wikipedia: Log4j. 历代维护者的轮换。

  16. CVE-2021-44228 NVD 详情。JNDI lookup 被攻击者滥用的技术机制。NVD link →

  17. Microsoft MSRC: “Microsoft’s response to CVE-2021-44228 Apache log4j2”. Link →

  18. Wikipedia: Apache License. Apache 2.0 license 允许商业使用、衍生作品、专利保护，不要求开源衍生作品。Link →

  19. OpenSSF Press Release 2022-02-01: “OpenSSF Announces The Alpha-Omega Project”. $5M 初始投入。Link →

  20. Brian Behlendorf 在 Alpha-Omega 公告中的引述。

  21. Alpha-Omega 项目 Reports 页面，记录 2022-2024 年资助项目清单。Link →

  22. Wikipedia: Sovereign Tech Agency. 2022 年 5 月德国联邦议会拨款 €3.5M/年。Link →

  23. Tidelift 2024 maintainer survey. 25% 从 GitHub Sponsors 等程序获得收入；19% 从 Tidelift 获得收入。Link →

  24. Wikipedia: XZ Utils backdoor. Link →

  25. Daniel Stenberg 多年公开 blog 包括“I will slaughter you”等。Link →

  26. NIST: Executive Order 14028 on “Improving the Nation’s Cybersecurity”（2021 年 5 月）。SBOM 要求是合规层面，不是资助。Link →

  27. xkcd 2347: Dependency. 2020 年 8 月发布。Link →

  28. 各种 OpenSSF / CISA / 私营 threat intel 报告都指向 “下一个 supply chain 攻击只是时间问题” 的判断。

  29. Vice: “The Internet Was Built on the Free Labor of Open Source Developers. Is That Sustainable?”——一篇早期讨论开源维护者经济问题的深度报道。Link →