一

1984 年 8 月，Ken Thompson 在他获得 Turing Award 时的演讲里，讲了一个让现场观众不舒服的故事1。

Thompson 是 Unix 共同发明者。他描述了一个理论上的攻击：他修改了 C 编译器，让它在编译 Unix 的 login 程序时，自动加入一个后门——一个只有他知道的密码可以让任何账户登入。然后他让这个被修改的编译器能识别自己——当它在编译 C 编译器源代码时，它会自动把那段“加 login 后门”的代码加回去。

效果：

  • 你检查 C 编译器的源代码——干净的，没有后门代码
  • 你用一个“干净”的 C 编译器编译它——得到一个有后门的编译器
  • 你用这个有后门的编译器编译 Unix——所有 Unix 都有 login 后门
  • 你换源代码？没用，因为下一次编译还是会加回去
  • 你重新写编译器源代码？没用，因为编译它的工具仍然是有后门的

Thompson 的核心论点是：你不能信任不是你自己从零写出来的代码。即使你看遍每一行源代码，如果你用的编译器有问题，你的程序也有问题。如果你的编译器是用另一个编译器编译的，那个编译器是用又另一个编译器编译的——信任链不可终结。

这篇演讲题目是 “Reflections on Trusting Trust”。它发表后立刻成为计算机安全经典，但很长一段时间被当作理论思考——一个聪明的智力游戏，但实际上没人这么做。

40 年后，xz Utils 后门发生。Lasse Collin 的源代码 repo 完全干净。问题是 release tarball——通过 m4 配置脚本注入的 build-time hook。打包后的二进制文件在用户机器上运行时执行后门，而源代码看起来无害。

这跟 Thompson 1984 年描述的攻击不完全一样——但信任链的脆弱性是同一种。即使你看遍 xz 源代码，你也发现不了后门——因为后门只在特定的 build 环境下被注入2。

xz 让 Thompson 演讲从理论问题变成具体威胁。开源运动 40 年依赖一个隐藏假设——“如果源代码公开，问题就能被发现”。Thompson 1984 年就告诉过我们这个假设有限度；2024 年 xz 让所有人面对这个限度。

二

要解决“Reflections on Trusting Trust”的问题，理论上需要几样东西：

  • 可验证 build：能证明给定的源代码 + 给定的 build 配置必然产生某个特定的二进制
  • 可追溯 provenance：能证明这个二进制是来自这个源代码，不是其他来源
  • 可信 chain of custody：从源代码到部署的每个环节都可被验证

这三个要素在 1984 年完全是理论。Thompson 当时没有提出怎么实现——他只是描述了问题。直到 2010 年代，开源社区才开始系统性应对。

Reproducible Builds 运动是最早的尝试。它的核心想法很简单：如果两个独立方用相同源代码 + 相同 build 配置，做出 bit-for-bit 一致的二进制，那么 build 没被污染。如果它们结果不同——某一方的 build 工具被污染了3。

实现这个目标需要消除 build 过程中的非确定性——时间戳、文件 ordering、临时路径、随机数等。Debian 项目从 2014 年开始系统性“reproducible-build 化”自己的所有包，到 2023 年已经实现 95%+ 的包可复现。NixOS、Bootstrappable、Guix 等“功能式 Linux 发行版”几乎 100% reproducible4。

但 Reproducible Builds 有个根本限制：它只能检测“工具污染”——如果 build 系统、编译器、链接器被污染，reproducible 检查能发现。它不能检测“源代码污染”——如果源代码本身是恶意的（像 xz），reproducible build 仍然会产生一致的恶意二进制。两个独立方 build 同一个 xz 5.6.0 源代码会得到 bit-for-bit 一致的——都是有后门的——二进制。

Reproducible Builds 解决了 Ken Thompson 的部分问题——能验证 build 工具不是被污染的。但它没解决 Lasse Collin 的全部问题——它不能告诉你这个源代码本身是否值得信任。

三

SBOM（Software Bill of Materials）是一个不同的角度。它的核心想法：给每个软件产品附一份“配料表”——说明这个产品由哪些 components 组成、每个 component 来自哪里、版本是什么。

SBOM 概念在 2017 年左右开始被推广，但真正起飞是 SolarWinds 2020 年事件之后。SolarWinds 让美国政府意识到：“如果我们不知道我们的关键软件依赖什么，我们就没法应对供应链攻击”5。

2021 年 5 月 12 日，Biden 政府发布 EO 14028——“Improving the Nation’s Cybersecurity”。这份行政命令的多个部分中，关于 SBOM 的部分（Section 10(j)）是核心6。EO 14028 要求：

  • 联邦机构采购的软件必须提供 SBOM
  • NIST 制定 SBOM 标准
  • 软件供应商必须遵守“secure software development practices”

NIST 在 2022 年发布 SBOM 相关指南。商务部 NTIA 也参与。可接受的 SBOM 标准格式有三种：SPDX（Linux Foundation 主导）、CycloneDX（OWASP 主导）、SWID tags（ISO 标准）7。

SBOM 的逻辑：你提交一份准确的 SBOM 给联邦机构。机构能审查你的依赖。如果某个依赖被发现有漏洞，机构知道自己受影响。

到 2024 年，SBOM 已经成为大型联邦软件采购的标准要求。多数大公司（Microsoft、Google、Oracle、IBM 等）都给自己产品生成 SBOM。OpenSSF 的工具（特别是 sigstore + slsa）让生成 SBOM 越来越自动化8。

但 EO 14028 在 2026 年初被 Trump 政府撤回部分要求9。具体说，OMB（管理与预算办公室）在 2026 年 1 月发布备忘录，把“必须提供 SBOM”改为“基于风险评估”。这是个软化——不再硬性要求 SBOM，而是让采购方决定哪些项目需要。但 SBOM 实践已经在行业内深度推广，行业不会因为 OMB 备忘录就反向回退。

四

SLSA（Supply-chain Levels for Software Artifacts）是 Google 2021 年提出，后转给 OpenSSF 维护的框架。它是一个 4 级成熟度阶梯10：

  • SLSA 1：基本 provenance——能说明这个 artifact 是怎么 build 的
  • SLSA 2：经过认证的 build 服务（不只是开发者本地 build）
  • SLSA 3：build platform 提供 source 与 provenance 的强保证
  • SLSA 4：hermetic build（封闭、无外部依赖）+ 双人审核

SLSA 的设计意图：让组织能选择自己需要的安全程度。一个小型开源工具可能只需要 SLSA 1；关键基础设施应该到 SLSA 4。

SLSA 已经被 GitHub Actions、GitLab CI、Google Cloud Build 等原生支持。开发者可以在 CI/CD pipeline 中自动生成 SLSA provenance attestation——一个 cryptographically signed 的文档说明“这个 artifact 是用这些源代码 + 这些工具 + 这些步骤 build 出来的”11。

Sigstore 是 SLSA 的 cryptographic 同伴。Sigstore 由 Google、Red Hat、Purdue University 在 2021 年合作启动，现在是 Linux Foundation 项目。它的核心创新：keyless signing——开发者不需要管理自己的 GPG 私钥，而是用 OIDC 短期证书（绑定到 Google、GitHub、Microsoft 等 identity provider）来签名 artifact12。

工具链：

  • Cosign：签名 + 验证工具
  • Fulcio：CA（认证授权机构），发短期证书
  • Rekor：透明日志，所有签名都被记录到只能 append 的日志

Sigstore 解决了一个长期开源痛点——GPG 私钥管理。让每个开源 maintainer 安全持有 GPG 私钥几乎是不可能的——丢失、泄露、忘记密码都是常见问题。Sigstore 的“短期证书 + 透明日志”模式让签名变得对普通 maintainer 也可达13。

到 2024 年，多数主流开源项目已经在 release 时附加 SLSA provenance + Sigstore 签名。Linux 发行版（Debian、Ubuntu、Fedora）开始集成 Sigstore 验证到 package manager 中。这是过去三年开源供应链安全的最大进步。

五

但这些工具能阻止下一个 xz 吗？

答案是：部分能。

xz 攻击通过四个层面：

  1. Source code level：Jia Tan 提交合理的 patch 进 git repo
  2. Build process level：通过 m4 配置脚本注入后门到 release tarball
  3. Distribution level：催促 Debian/Ubuntu 集成新版本
  4. Runtime level：通过 systemd → liblzma → sshd 链条激活后门

SLSA / Sigstore 主要在第 2 和第 4 层有效：

  • 如果 xz 项目用 SLSA 4 build——hermetic + 双人审核——那么 build 过程异常会被审核者发现
  • 如果 release tarball 有 Sigstore 签名 + Rekor 透明日志，那么追溯异常变更更容易

但 SLSA / Sigstore 不能阻止 第 1 层：如果 Jia Tan 已经是合法的 maintainer，他对源代码的提交本来就是合法的。第 3 层：如果攻击者通过其他渠道催促 distribution 采用新版本（如 Hans Jansen 提 Debian / Ubuntu bug），SLSA 不会自动阻止。

xz 攻击的关键创新是它绕开了所有现有 verifiability 机制——通过 maintainer 权限本身做攻击，而不是攻击 build 系统。SLSA 4 + Sigstore 能让攻击的“操作复杂度”提高（攻击者需要绕开双人审核），但不能从根本上排除攻击14。

这是 xz 给整个 supply chain 安全社区的一个严峻信息：verifiability 工具是必要的，但不充分。如果对手有耐心、有资源、能完成 social engineering，那么 verifiability 工具只能让攻击稍难，不能让攻击不可能。

六

让事情更复杂的是：verifiability 工具本身在被法律分裂。

美国 EO 14028 推动 SBOM。但具体 SBOM 格式有三种（SPDX、CycloneDX、SWID），它们语义略有不同——一个生成 SPDX 的工具不能直接生成 CycloneDX，反之亦然。

欧盟 CRA（Cyber Resilience Act）也要求 SBOM——但具体规范跟美国 EO 14028 不完全一致。CRA 定义了“open source steward”概念，专门给开源基金会一些责任：开源 steward 必须有 cybersecurity policy、必须做 vulnerability response、必须有 incident reporting15。

中国《网络安全法》和《关键信息基础设施安全保护条例》有自己的“安全可控”要求——一种另外的供应链验证方式。它要求关键基础设施用的软件必须通过可信渠道获得（这跟 SBOM 的“知道你用了什么”不完全相同——它要求“知道供应商可信”）16。

这就是 supply chain 工具的“三方监管夹击”。一个想全球分发的开源项目要 同时 满足：

  • 美国 EO 14028 的 SBOM 要求
  • 欧盟 CRA 的 open source steward 责任
  • 中国“安全可控”分类的合规

三种规则没有完全冲突——但也不完全兼容。要做全部合规需要额外工作。这给了“只服务本国市场”的项目相对优势——它们只要满足一种规则。

整个事情有一个让人想停下来的细节。SBOM、SLSA、Sigstore 都是为“提高 supply chain 透明度”设计的。但它们的实际效果包括：让开源项目的国际化变难。一个跨国开源项目要同时遵守三个法域的规则，比“一国合规”困难。这造成了一种逆向的“主权化压力”——技术上你可以国际化，但合规上你被推向区域化17。

七

EU CRA（Cyber Resilience Act）是这一章最长的内容，因为它最复杂，对开源运动影响最深。

CRA 的全称是 Regulation (EU) 2024/2847。它在 2024 年 10 月通过，2024 年 12 月 10 日正式生效，部分条款 2026 年 9 月开始适用，全面适用 2027 年 12 月18。

CRA 的适用对象是“带数字元素的产品”（products with digital elements）。这包括几乎所有联网软件和硬件。CRA 定义了几个角色：

  • manufacturer：产品直接生产者，承担主要合规责任
  • importer / distributor：二级合规责任
  • open source steward：一个专门为开源软件创造的新角色

最后一个角色是 CRA 关于开源的核心争议点。

CRA 把 “open source steward” 定义为：

“a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.”19

这个定义覆盖了 Eclipse Foundation、Linux Foundation、Apache Software Foundation 等大型开源基金会。它不覆盖：

  • 单独的开源 maintainer（个人，不是“legal person”）
  • 纯非商业开源项目（“not intended for commercial activities”）
  • 没有持续 stewardship 的小项目

Open source steward 的责任：

  • 制定 cybersecurity policy
  • CVE 响应义务
  • Vulnerability 上报义务
  • 产品生命周期 stewardship

这相对个人开发者已经轻——但对开源基金会来说是真实负担。Eclipse、Apache、Linux Foundation 等都需要建立 incident response 团队、CVE 协调流程、定期 security audit。

八

CRA 推出过程中开源社区进行了激烈 push back。

2023 年 4 月，13 个开源组织（Eclipse Foundation、OSI、Document Foundation、Apache、Linux Foundation Europe 等）联合发表公开信，要求欧盟重新考虑 CRA 对开源的影响20。

公开信的核心担忧：

  • CRA 可能让上游开源 maintainer 为下游产品的安全缺陷承担“间接责任”
  • 个人维护者面对欧盟合规可能选择“放弃欧盟用户”
  • “chilling effect”——maintainer 会避免在敏感领域贡献

EFF（Electronic Frontier Foundation）也发表声明支持，担心 CRA 会损害开源运动21。

欧盟立法者听到了反弹。2024 年最终版本对纯开源 maintainer 做了豁免（“open source stewards” 责任不传递给个体 maintainer），并且给商业开发与非商业开发做了区分。Pure open source development without commercial intent 基本免于 CRA 大部分要求22。

但 Debian 等小型基金会仍然批评最终版本对中小再分发者不友好。OpenSSF 在 2025 年 6 月发了一份指南，专门帮助 OSS 项目判断自己是 “manufacturer” 还是 “steward” 还是纯个人 maintainer23。

到 2026 年初，CRA 的实际执行还在准备阶段——多数条款 2026 年 9 月才开始生效。但已经有项目宣布“不向欧盟用户提供”——以规避未来合规风险。这是 CRA 设计者没预见的副作用：他们想保护欧盟消费者，但部分小型开源项目宁可放弃欧盟市场也不愿合规24。

九

把美国 EO 14028、欧盟 CRA、中国《网络安全法》放在一起，能看到清晰的 pattern：

法域主要要求主要工具对开源的处理
美国SBOM、安全开发SPDX、CycloneDX联邦采购通道
欧盟CE 标识、漏洞响应open source stewardSteward 责任
中国安全可控、可信渠道国家认证国家可控接入

每个法域都不直接禁止开源——但每个法域都要求开源在某种合规框架下使用。这跟 2014 年之前的状态形成对比——那时候开源是“自由地、随意地、跨国地”使用的，没有任何政府要求合规25。

最让人头疼的是这三种合规要求不完全兼容。一个国际化的开源基金会要 同时 满足三种：

  • 给联邦机构提供 SBOM（美国格式）
  • 注册为 open source steward（欧盟格式）
  • 通过中国国家认证（中国格式）

每种合规都需要专门人力。Eclipse、Apache、Linux Foundation 都已经在为此招聘“合规官”角色——这在 2014 年开源基金会几乎不存在。10 年前 Linux Foundation 的全职员工是工程师和市场，2024 年它有专门的法律 + 合规团队。

十

读到这里有人可能会问：为什么不让开源运动自己制定一个统一的合规框架？

答案：没有这个可能。

国家合规要求来自国家——它们反映国家利益。美国 EO 14028 反映美国的 supply chain 焦虑，欧盟 CRA 反映欧盟的消费者保护理念，中国“安全可控”反映中国的科技主权诉求。这些利益不是开源运动能“协调”的——它们是开源运动必须应对的外部约束。

开源运动能做的只是适应。具体形式包括：

  • 大型基金会建立合规团队，应对多种法律
  • 小项目选择放弃特定市场（如不向欧盟用户提供）
  • 中间层（如 OpenSSF、ORCWG——Open Regulatory Compliance Working Group）尝试做协调
  • 个别项目主动迁移到中立法域（如 RISC-V 到瑞士）

每一种适应都有代价。大型基金会的合规成本会扩大——这意味着小项目相对更难毕业到大基金会。中间层的协调能力有限——它们能写指南，但不能强制各方接受。中立法域的选择本身需要资源——多数项目没有能力做这种主权迁移26。

到 2026 年，开源世界已经默认“分裂合规”是新常态。一个项目要全球化，它必须接受同时被多种法律约束的现实。这跟 2014 年之前“一个项目，一个全球”的状态完全不同。

十一

Trojan Source 是另一个 verifiability 工具不能解决的问题。

2021 年 11 月，Cambridge 大学的 Nicholas Boucher 和 Ross Anderson 发表论文 “Trojan Source: Invisible Vulnerabilities”。他们描述了一种新的 supply chain 攻击向量：用 Unicode 双向（bidi）字符让源代码“看起来一样，但执行不一样”27。

Unicode 包括一些控制字符——用于支持阿拉伯语、希伯来语等右到左语言。这些字符在源代码中可以改变文本的渲染顺序，让 review 时看到的代码顺序和编译器解析的顺序不同。

具体例子：一段 Java 代码在 GitHub 上看起来是“如果用户是管理员，允许操作”，但编译器实际解析的是“如果用户不是管理员，允许操作”。差异通过 Unicode 控制字符引起，review 工具默认不显示这些字符28。

Trojan Source 影响几乎所有编程语言——C、C++、C#、JavaScript、Java、Rust、Go、Python 都受影响。Red Hat 在 2021 年 11 月发布安全公告 RHSB-2021-007 来应对29。

修复方式：编译器、IDE、code review 工具都加上对 Unicode 控制字符的警告或拒绝。但旧版本的工具不会自动升级，存在大量软件仍可能受影响。

Trojan Source 不是国家级 social engineering，但它代表了另一种“看似公开但隐藏意图”的 supply chain 攻击向量。它跟 xz 后门一起证明：verifiability 工具是个移动的目标。SBOM、SLSA、Sigstore 解决了一些验证问题，但新的攻击向量（如 Trojan Source、build-time hook、social engineering）会绕开这些工具30。

十二

把这一章的所有东西放在一起，会看到一个让人有点沮丧的图景：

Verifiability 工具方面：

  • SBOM 让“知道用了什么”成为可能
  • SLSA 让 build process 可验证
  • Sigstore 让签名可达
  • Reproducible Builds 让 build 工具污染可检测

但 verifiability 工具不能解决的：

  • Maintainer 权限被 social engineering 接管（xz）
  • Source code 中精心隐藏的恶意（Trojan Source）
  • 跨多个法域的合规分裂（三方监管夹击）

法律工具方面：

  • 美国 EO 14028 + SBOM
  • 欧盟 CRA + open source steward
  • 中国“安全可控”+ 国家认证

但法律工具引发的：

  • 不完全兼容的合规要求
  • 大型基金会必须建立合规团队
  • 部分小项目放弃特定市场
  • 加速主权化压力

加起来，到 2026 年初，开源 supply chain 安全是个“做了大量工作但仍然脆弱”的状态。每次新的攻击（xz、Trojan Source）暴露新的弱点。每次新的法律（CRA、SBOM EO）增加新的合规成本。整个系统在变得更“成熟”——同时也在变得更“复杂”。

读懂这点能解释为什么很多关于“OSS 安全”的辩论让人感到无解。如果我们只看 verifiability 工具，事情在变好。如果我们只看法律框架，事情也在变好（按各方各自的标准）。但综合起来——既要工具又要合规又要避免国家间冲突的 supply chain 责任——状况是脆弱的、矛盾的、永远不够好的。

下一章我们要看的是这些 supply chain 压力催生的最直接副产品：平行 forge 生态。Gitee、Codeberg、GitFlic——这些非 GitHub 替代品的实际状况，以及“假如 GitHub 不可用”这个 thought experiment 在多大程度上能被现实测试。

References

  1. Ken Thompson, “Reflections on Trusting Trust”, Communications of the ACM, August 1984. Text at aeb.win.tue.nl →

  2. Research!rsc: “Running the ‘Reflections on Trusting Trust’ Compiler”. Russ Cox 实际复现 Thompson 攻击。Link →

  3. Reproducible Builds project. [https://reproducible-builds.org/]

  4. Debian Reproducible Builds project status reports. 2023 年达到 95%+ 覆盖率。

  5. SBOM 概念历史。NIST 与 NTIA 的文档展示发展轨迹。

  6. NIST: Executive Order 14028, Improving the Nation’s Cybersecurity (2021-05-12). Link →

  7. NIST: Software Security in Supply Chains: SBOM. 列出 SPDX、CycloneDX、SWID 三种可接受格式。Link →

  8. Anchore: “Executive Order 14028: Updates for SBOMs & FedRAMP”. Link →

  9. Wiley: “OMB Rescinds Secure Software Development Mandate in Favor of a Risk-Based Approach” (2026). Link →

  10. SLSA spec FAQ. Link →

  11. SLSA Provenance specification. Link →

  12. Sigstore project at Linux Foundation. 包括 Cosign、Fulcio、Rekor 工具描述。

  13. AquilaX: “Software Supply Chain Security Beyond SBOMs: Sigstore, SLSA, and Build Provenance”. Link →

  14. 多个 OpenSSF 后续分析：xz 攻击对 SLSA / Sigstore 设计的影响讨论。

  15. Wikipedia: Cyber Resilience Act. open source steward 角色描述。Link →

  16. 《中华人民共和国网络安全法》（2017）。“安全可控”作为关键政策术语。

  17. OpenSSF: “OSS and the CRA: am I a Manufacturer or a Steward?”. 详细描述合规分类问题。Link →

  18. EU Regulation 2024/2847. CRA 正式文本。

  19. CRA Article 13(8) 定义 open source steward。Eclipse Foundation 的解读。Eclipse blog link →

  20. TechCrunch 2023-04-18: “In letter to EU, open source bodies say Cyber Resilience Act could have ‘chilling effect’ on software development”. Link →

  21. EFF 2023-05: “EU’s Proposed Cyber Resilience Act Raises Concerns for Open Source and Cybersecurity”. Link →

  22. OSI: “The European regulators listened to the Open Source communities!”. Link →

  23. OpenSSF: OSS and CRA whitepaper (2025-06). 同 c9-ref-17.

  24. 2024-2025 多个开源项目宣布不向 EU 用户提供以规避 CRA 风险的报道。

  25. Linux Foundation: “Understanding the Cyber Resilience Act: What Everyone involved in Open Source Development Should Know”. Link →

  26. Open Regulatory Compliance Working Group (ORCWG). 试图协调 CRA 应对。Link →

  27. Wikipedia: Trojan Source. Link →

  28. Krebs on Security: “Trojan Source Bug Threatens the Security of All Code”. Link →

  29. Red Hat: RHSB-2021-007 Trojan source attacks (CVE-2021-42574, CVE-2021-42694). Link →

  30. The Record: “New Trojan Source attack impacts compilers for most programming languages”. Link →

  31. BCLP Law: “The EU Cyber Resilience Act’s obligations: What does it mean for open source software?”. Link →

  32. JFrog: “What is the SLSA Framework?”. Link →