XZ Utils 发布 tarball 后门：软件供应链问责的考验

摘要

• 确认的事件异常精确。XZ Utils 5.6.0 和 5.6.1 发布 tarball 包含后门。部分负载隐藏在提交到源代码仓库的二进制测试文件中，而仅出现在发布 tarball 中的修改后生成文件build-to-host.m4提供了改变构建的触发器。Andres Freund 的2024 年 3 月 29 日原始披露记录了这种差异以及 Debian 或 RPM 构建可能产生恶意liblzma的条件。
• 冲击范围受到时间和发布分发的发行版门控限制，而非证明制品安全。Debian 回滚了受影响的 testing、unstable 和 experimental 包；Red Hat 向 Fedora Rawhide 和 Fedora Linux 40 beta 用户发出警告；openSUSE 回滚了 Tumbleweed 和 MicroOS；已发布的 Ubuntu 版本未受影响。发行商的公开记录并未确认广泛成功的利用，但确认了紧急回滚、重建、重新安装、凭据审查和调查工作。
• 问责不能止于创建和签署 tarball 的恶意账户。XZ 项目控制维护者和发布权限；托管服务控制仓库账户；发行商控制制品接收、补丁组合、包推广和回滚；商业和公共部门消费者控制依赖清单和支持；安全协调员控制披露渠道。各方具有不同的预防和响应能力。
• 持久的考验不是签名是否验证有效。有效签名可以验证恶意创建的制品。更强的考验是独立方是否可以将审阅的源代码修订绑定到发布制品，重新创建或解释每个允许的差异，在推广前验证来源，检测异常生成或二进制输入，并在不依赖一个疲惫的维护者的情况下撤销发布权限。

为何虚惊一场仍会留下问责记录

XZ Utils 是一个压缩项目，而非远程访问产品。其liblzma库却深深嵌入 Linux 软件栈，下游集成创建了一条从压缩库到 SSH 服务器启动的路径。因此，该事件不能仅被评估为恶意提交或巧妙的技术植入。它是整个权力链的失败：谁可以成为维护者，谁可以进行发布，哪些文件被视为生成文件因而正常，发行商信任哪个制品，包如何链接到更大的操作系统，以及当证据变化时谁能停止分发。

项目自己的当前安全记录指出，5.6.0 和 5.6.1 发布 tarball 包含后门，这些 tarball 由使用 Jia Tan 名称的账户创建并签名，且事件仍在调查中。它还记录到，原始维护者控制了主要的tukaani.org基础设施，而恶意共同维护者拥有对 GitHub 托管项目资源的访问权限，包括前项目子域名。这些事实很重要，因为它们比笼统的短语“项目被攻破”更细致地划分了控制权。主网站、Git 仓库、GitHub 组织、发布资产、签名密钥、邮件路由、软件包镜像和发行商仓库是相关但不完全相同的控制面。

这同样是一次特定意义上的虚惊。被篡改的上游版本进入了多个发行版的开发、滚动、测试、实验或测试渠道，但公开记录并未显示它们到达了广泛的稳定 Linux 用户群。Fedora 后来将此次事件描述为“几乎发生”的后门，并表示没有证据表明攻击者已在 Fedora 中使用它。这种限制意义重大。它阻止了潜在危害变为确认的损害。

然而，“几乎”并不意味着没有代价。维护者和安全团队不得不重建发布和提交。发行商不得不识别软件包，暂停或修改存档操作，发布紧急指南，回滚版本，重建快照，并在某些情况下建议重新安装系统。操作员必须确定易受攻击的软件包是否曾安装，SSH 是否曾暴露，凭据是否需要轮换，以及干净的包更新是否足够。响应消耗了稀缺的专家时间，正是因为发布制品不能被信任为被审查仓库的透明衍生品。

因此，问责问题比谁键入了恶意代码更广泛。它是：谁在实际能力上能阻止、检测、限制、逆转或验证从贡献者信任到提交权限、从提交到标签、从标签到 tarball、从 tarball 到发行版软件包、从软件包到运行服务的每一个过渡？责任随能力而定。它不应仅仅因为某人的名字出现在项目上就分配给志愿者，也不应被“社区”化直到没有任何机构有可衡量的职责。

一个关于信任、发布、检测和修复的可审计时间线

恶意发布之前的社会历史部分是从公开的邮件列表和仓库记录中重建的。Russ Cox 的记录时间线是一个独立的综合，而非法院事实认定。它支持公开贡献、消息、提交、发布和发行商行动的日期。它并未证明每个在线身份属于同一个人或组织。在将时间线用作问责证据时，这种区分至关重要。

这条时间线展示了两个截然不同的时钟。信任时钟运行了超过两年：贡献、授权维护、直接提交权限和发布权限。遏制时钟运行了数天：异常调查、私下协调、公开披露、降级、存档控制和恢复。第二个时钟令人印象深刻地工作。它不会抹去第一个。持久的问责必须减少耐心的接管者悄然达到发布权限的机会，同时保持像社区在 2024 年 3 月那样快速响应的能力。

技术控制失败是标签与 tarball 之间的距离

核心技术事实并非生成文件本身不安全。基于 Autotools 的项目通常分发生成的configure脚本和 M4 材料，以便用户和发行商不需要完全匹配的工具版本来启动构建。控制失败在于，一个具有安全相关行为的生成文件能够出现在发布 tarball 中，而没有强制执行的、独立审查的关于它如何与标记仓库不同的解释。

Freund 发现修改后的build-to-host.m4行在文件的上游源头中不存在，且 XZ 在 Git 中未使用，但存在于 5.6.0 和 5.6.1 的分发 tarball 中。该脚本从看起来像压缩测试输入的文件中提取更多材料。然后在选定的环境条件匹配时修改liblzma构建。这些条件将执行缩小到使用 GCC 和 GNUld的 x86-64 Linux 环境，以及 Debian 或 RPM 包构建上下文。这种针对性既减少了意外检测，又将结果准确放在发行商将上游源码发布变成受信任二进制文件的地方。

源代码仓库并非在普通意义上是干净的。它包含了伪装在二进制测试文件中的负载材料以及若干准备性更改。但仓库本身缺少组装和注入后门所需的仅发布触发器。这种区分击败了一种常见但薄弱的保证声称：“源代码是开放的，所以有人可以检查它。”哪个源代码？Git 标签、自动生成的 GitHub 存档、上游维护的发布 tarball、发行商导入的源码包以及实际呈现给编译器的文件可能各不相同。检查其中一个并不能验证其他。

XZ 项目的事后审查说明使这种差异可审计。Lasse Collin 审查了仓库提交，识准备了或更新了后门文件的提交，检查了翻译，并将早期发布 tarball 与 Git 进行了比较，记录了如生成翻译和变更日志输出等良性例外。审查还指出提交未签名，直接提交历史未显示提交者欺诈的迹象。这是有用的否定证据，但它缩小了范围而非结案：恶意行动不需要伪造提交身份，因为恶意账户已拥有合法权限。

签名问题直接随之而来。被篡改的发布 tarball 由创建它们的同一账户签名。密码学验证可以建立制品与该签名密钥批准的内容匹配。它无法建立制品与审查过的标签匹配，其生成文件是由批准的构建配方产生的，或者其签名者行为诚实。签名回答了“哪个密钥为这些字节担保？”它没有回答“这些字节应该存在吗？”或“两个独立方从我们审查的源代码修订版重现了它们吗？”

这也不仅仅是 XZ 内部的 SSH 缺陷。OpenSSH 并不直接依赖于liblzma。在 Freund 描述的受影响构造中，下游 systemd 集成导致sshd加载了一条达到liblzma的链。注入的代码利用了早期动态链接器行为并重定向了与认证相关的密码函数。这是一个依赖组合失败面：上游 XZ 控制库发布；发行商控制包构造和链接关系；运营商控制由此产生的 SSH 服务是否运行和暴露。没有单一当事方通过仅查看自己的仓库就能看到整个攻击面。

官方生态系统响应保留了这种细微差别。OpenSSF 的初始事件说明描述了针对 x86-64 上使用 GCC 和 GNU 链接器的 DEB 或 RPM 包的针对性，警告用户停止使用 5.6.0 和 5.6.1，并赞扬分阶段发布过程使受影响的人群相对较小。教训不在于预发布渠道是可牺牲的。而在于推广阶段是安全边界，当它们为独立观察创造时间并提供可逆的地方来阻止不良制品时。

谁控制了什么

当控制按功能分离时，问责变得具体。以下分配并非主张同等责备。它标识每个参与者可以在事件之前、期间或之后实际改变什么。

控制图防止了两个分析错误。第一个是替罪羊原始维护者。公开信息显示了有限的能力和压力，但有限的能力不是对秘密后门的同意。将 XZ 纳入创收或公共系统的组织拥有更多资源来资助审查、改进下游验证或减少对单个上游发布渠道的依赖。CISA 的事后可持续性分析明确主张，从开源获利的技术制造商应成为负责任的消费者和可持续的贡献者。

第二个错误是将下游发行商视为被动受害者。他们没有创造后门，但他们控制了从上游 tarball 到安装的操作系统包之间的桥梁。Debian 的源码接收、Fedora 的测试仓库和 openSUSE 的滚动快照不是文职镜像。它们是验证和推广系统。它们的分阶段渠道限制了广泛的稳定部署，它们的紧急控制措施移除了软件包。这种成功的响应是真正下游力量的证据，这意味着下游验证职责也是真实的。

损害、暴露和成本：发生了事与可能发生的事

确认的损害主要是暴露和响应成本，而非有记录的全球入侵。这种区分应在每一次复述中保留。

Debian 声明已知没有稳定版本受影响。其 testing、unstable 和 experimental 用户在包回滚后被告知更新。Red Hat 声明没有 RHEL 版本受影响，而 Fedora Rawhide 用户可能收到了 5.6.0 或 5.6.1，且 Fedora 40 beta 包含了两个受影响的 5.6.0 库包。openSUSE 声明 Tumbleweed 和 MicroOS 在 3 月 7 日至 3 月 28 日期间包含了该版本，但 SUSE Linux Enterprise 和 openSUSE Leap 与该流程隔离。Ubuntu 的 CVE 记录称受影响版本仅出现在noble-proposed中，在迁移前被移除，没有已发布的 Ubuntu 版本受影响。

这些边界不能与受损机器数量互换。安装受影响的源码包、在触发器运行的环境中生成二进制文件、将生成的库加载到目标服务链中、暴露该服务以及接收攻击者精心制作的输入是单独的条件。公开记录没有列举有多少系统满足了所有这些条件。它们也没有确定有多少管理员重新安装了系统、轮换了凭据或进行了取证审查。

同样没有已确认的货币损失总额。要指定一个数字将需要劳工记录、重建和停机成本、云和事件响应费用，以及将预防性工作与已确认的入侵分开的证据。这些数据分散且大多为私人信息。负责任的成本声明是定性的但仍然是实质性的：

• Debian 安全团队和存档团队回滚了软件包，发布了公告，并暂时暂停了存档处理。
• Fedora 和 Red Hat 调查了不同的构建结果，发布了紧急指南，提供了降级包，随后发布了安全确认。Fedora 的4 月 15 日说明仍出于谨慎建议已收到或可能收到错误更新的系统进行完全重新安装。
• openSUSE 生成了安全快照，记录了版本检查，建议面向互联网的 SSH 系统进行全新安装，并在访问可能暴露凭据的情况下推荐轮换凭据。
• 上游维护者和独立审查员在发布干净发布之前检查了多年的提交、发布文件、签名、翻译和基础设施访问。
• 企业和公共运营商不得不盘点版本、检查包历史、评估 SSH 暴露、内部沟通，并在不确定性下保留证据。

反事实损害要大得多。恶意库可能干扰目标配置上的预认证 SSH 处理，并根据后来的公开公告，使持有相关私钥的人能够执行命令。如果受影响的发布跨越到广泛部署的稳定发行版，可能的后果将包括未经授权的特权访问、数据窃取或篡改、横向移动、服务中断、紧急舰队重建以及对软件分发渠道本身的不信任。这些是技术能力支持的风险场景，而非事件的已确认结果。

这种分离影响问责。一方不应因阻止了在其环境中从未成为可能的危害而受到赞扬，也不应因投机性的损失而受到责备，好像它们已经发生。相反，成功的虚惊响应不应被用来忽视控制弱点。适当的记录是：大规模稳定危害被阻止；有限渠道被暴露；紧急成本是真实的；成功利用和总成本仍未证实；潜在严重性证明了紧急行动是合理的。

政府、监管和法律记录

CVE-2024-3094 创建了一个通用技术标识符，而非判决。Ubuntu 根据 CVSS 3.1 将问题评为 10.0，CERT-EU 也报告了 10 分制的得分。政府网络机构和发行版安全团队建议降级或移除。这些行动确立了风险的严重性和合理的操作响应。它们没有确定负有法律责任的自然人或决定损害赔偿。

截至 2026 年 7 月 15 日审查的公开记录不包含针对 Jia Tan 账户已识别操作者的确认刑事归属、公开指控文件、民事判决或监管处罚。这一负面发现故意狭窄。这意味着在引用的项目、发行商、政府、标准和公开时间线材料中没有出现此类官方记录；它并不证明没有机密调查存在。根据工作时间、语言线索、电子邮件域名或植入物的复杂性将活动归因于某个国家、情报机构、雇主或指定个人是不负责任的。

政府指南仍然对问责分析很重要。它显示了公共当局如何将事件转化为对软件生产者和消费者的期望。CISA 可持续性文章将事件与维护者倦怠、负责任的消费、贡献、隔离构建环境、代码审查、扫描和响应规划联系起来。CERT-EU 为机构提供了即时补救立场。这些是政策和操作记录。它们不是证明无偿维护者存在疏忽的追溯性法律标准。

NIST 的安全软件开发框架提供了更持久的控制词汇。它建议保护软件、保护开发环境、收集和共享来源、验证第三方组件以及响应漏洞。该框架广泛适用，对购买者和生产者都有用。将其应用于此处是支持的控制比较，而非声称 XZ 在 2024 年受到每个 NIST 做法的合同约束。

因此，法律边界是诚实报告的一部分。故意插入后门是不当行为，但关于在线账户的公开证据不足以命名背后的人或组织。发行商的预防性重新安装建议不是机器被访问的证据。CVSS 分数在假设下衡量技术严重性；它不是损害数字。官方公告不是判决。文章可以按照控制分配操作职责，而不制造记录中不存在的法律裁决。

修复证据：强遏制，部分机构结案

响应产生的公开修复证据比许多软件供应链事件都多。证据分为四个层次。

第一，权限被撤销，基础设施被恢复。原始维护者记录称，受损账户不再控制邮件路由，之前的 GitHub Pages 子域名被移除，其自己的账户被恢复，项目仓库回到了合法控制之下。撤销阻止了同一账户通过同一渠道发布另一个版本。它并未证明所有历史贡献都是安全的，因此撤销之后必须进行审查。

第二，下游分发被停止并逆转。Debian 回退到已知良好的上游代码。Fedora 和 Red Hat 发布了受影响版本和渠道信息，并发布了降级更新。openSUSE 回滚到安全快照。Ubuntu 记录了受影响包从未进入已发布版本。这是可验证的遏制：受影响的发布系列被识别，推广被停止，替换包已可用。

第三，上游项目审查了历史并发布了干净发布。审查说明识别了已知后门准备，区分了恶意和良性更改，检查了翻译和早期发布 tarball，并记录了限制。项目的旧发布记录列出了于 2024 年 5 月 29 日发布的干净发布，排除了恶意 tarball，标识了哪些历史 tarball 由恶意账户签名，并声明那些保留的历史 tarball 已被检查。这种透明度允许发行商理解为何仅签名不足，以及项目当前为哪些制品担保。

第四，项目继续发布软件。当前网站列出了后来的 5.6、5.7 和 5.8 发布，提供了签名，标识了分支维护状态，并允许从匹配的 Git 标签构建。连续性很重要，因为被遗弃的关键软件可能产生不同的风险：用户被困在旧代码上或未经协调地分叉。持续维护是事件未摧毁项目的证据。

然而，结案是部分性的。公共项目页面不提供完整的独立取证报告、已验证的行为者身份、完整的日志历史，或没有恶意使用的证明。引用的页面也不展示常设的多人发布仪式、独立操作的密封构建器、每个发布制品的机器可验证来源，或要求发行商拒绝无法解释的标签到 tarball 差异的已发布政策。其中一些控制可能存在于审查页面之外或演化中。持久的问责需要公开、可重复的证据，而非假设。

openSUSE 打包者的事后教训使下游机会具体化。审查提交揭示了不寻常的测试文件，它们缺乏相应的测试框架或项目代码更新。这一观察并不意味着每个二进制固定都是恶意的。它表明发行商可以在接近发布时围绕新的不透明输入、未使用的测试数据、生成文件差异以及改变沙箱或模糊行为的更改构建异常规则。

最佳的修复标准结合了人工和机械证据。需要人工审查来理解新的维护者、测试语料库、构建特性或发布异常是否有意义。需要机械检查，因为人类无法反复比较数千行生成代码或记住每个允许的制品差异。每一个都弥补了另一方的弱点。

反事实比较：本来可以改变结果的控制

反事实只有在其识别特定控制并避免声称确定性时才有用。几个比较满足这一测试。

发行商从 Git 标签而非上游 tarball 构建。在此事件中，仅发布触发器在 Git 仓库中不存在。检出标签并重新生成构建系统的发行商不会收到那个特定的恶意build-to-host.m4。这很可能破坏了已知的组装路线。它不会使标签变得可信：隐藏的负载文件和准备性更改仍在 Git 中，未来的攻击者也可以将触发器放在那里。“从 Git 构建”是一个有用的事件特定反事实，而非通用治疗方法。

强制性的标签到 tarball 差异比较，并带有允许的生成更改清单。一个解包 tarball、在受控环境中重新生成预期文件并拒绝无法解释的差异的发布门控将暴露出添加的 M4 行为。这是最强的直接反事实，因为决定性的触发器仅存在于 tarball 中。门控需要处理翻译、时间戳、文档和工具版本中的合法变化，而不标准化掉可执行的更改。

独立可重复构建。可重复构建项目将构建定义为当独立方可以使用相同的来源、环境和指令创建比特完全相同的指定制品时。其定义和验证模型本身不会告诉审查者所选的来源是诚实的。它会使无法解释的差异可测量。如果一个构建者使用被审查的标签而另一个使用发布 tarball，不一致将是一个停止信号，而非被接受的打包细节。

可验证来源在推广前检查。SLSA 的来源模型描述了关于制品在何处、何时以及如何产生的可验证信息，包括将构建输出绑定回来源。如果发行商要求来源标识确切的源代码修订版、构建者和构建过程，一个无法由该过程解释的仅发布文件可能违反政策。来源必须独立验证；一个恶意的维护者自签虚假陈述会重演原始的签名问题。

双人发布批准和分离密钥。要求一个受信任的维护者准备发布，另一个批准源到制品的证据，会提高滥用的成本并可能抓住差异。它也会给小型项目带来真实的人员负担。公平的实施不是要求无偿的昼夜劳动。依赖 XZ 的发行商和公司可以提供独立的重建者、审查能力或资金，同时将项目设计决策留给维护者。

立即稳定发布而不是分阶段渠道。这个负反事实显示了哪个现有控制起作用。如果 Debian、Fedora、openSUSE 和 Ubuntu 将最新的 XZ 发布直接推广到广泛的稳定机群，3 月 28 日的检测将发生在更大部署之后。测试和建议的渠道创造了延迟、可观察性和回滚边界。它们的用户仍然值得保护，但分阶段模式阻止了开发渠道事件成为普遍的稳定渠道紧急情况。

将性能异常当作普通噪音忽略。Freund 调查了本可以被视为轻微回归的多余 CPU 使用和 Valgrind 错误。如果他停留在解决方案上，该包可能继续走向稳定推广。这一反事实支持一个不那么光鲜的控制：维护者和工程师需要时间和权限来调查基础软件中的弱信号。只有当有人能够跨包、库、链接器和服务边界追踪异常时，监控才会产生价值。

移除下游依赖路径。在sshd未通过 systemd 相关依赖链加载liblzma的环境中，已知的 SSH 激活路径不存在。减少不必要的特权进程依赖将减少此攻击面。它不会清除恶意库或阻止另一个应用程序加载它。依赖最小化和特权分离是爆炸半径控制，而非发布完整性控制。

这些比较显示为什么没有单一口号是足够的。更多资金不会自动暴露混淆的 tarball。更多签名将认证恶意签名者。更多源代码开放性不会强迫任何人比较正确的制品。更多自动化可以忠实地重现有毒的输入。可信的防御结合了可持续治理、分离的权限、制品透明度、独立验证、分阶段部署和异常调查。

确认的事实、支持的推理和未知数

确认的事实

• XZ Utils 5.6.0 和 5.6.1 发布 tarball 包含后门，项目将恶意共同维护者标识为这些 tarball 的签名者和创建者。
• 仓库中的二进制测试文件包含隐蔽材料，而仅存在于发布 tarball 中的修改后 M4 文件在选定条件下触发了提取和构建操作。
• Freund 在调查 Debian sid 上的 CPU 和 Valgrind 异常时发现了该问题，并在通知发行版安全渠道后于 2024 年 3 月 29 日公开披露。
• Debian testing、unstable 和 experimental；Fedora 开发或测试渠道；以及 openSUSE 滚动渠道收到了受影响或有嫌疑的包。RHEL、Debian stable、已发布的 Ubuntu 版本、SUSE Linux Enterprise 和 openSUSE Leap 被各自发布者报告为不受影响。
• 发行商回滚了包，发布了警告，并重建或重新发布了已知良好的版本。XZ 项目撤销了访问权限，恢复了基础设施，审查了历史，从其正常发布记录中移除了恶意发布制品，并发布了干净发布。
• 政府和生态系统组织发布了 CVE、关键严重性通知、降级指南以及关于开源可持续性和社会工程接管风险的更广泛建议。

支持的推理

• 对原始维护者的公开压力可能有助于将实际权力转移给 Jia Tan。时间、狭窄的在线历史以及后来的行为支持协调的社会工程解释，但并未确立每个角色都由同一操作者控制。
• 选择性的构建条件和反分析行为旨在到达发行版构建的 Linux 包，同时减少发现。技术构造强烈支持故意针对性；预期的受害者组织和战略目的仍然未知。
• 要求的、独立审查的标签到 tarball 比较很可能会在下游采用之前暴露决定性的仅发布触发器。
• 分阶段的发行版渠道通过使受影响的包远离广泛的稳定部署足够长的时间以进行检测和回滚，实质性地限制了爆炸半径。
• 关键开源软件的商业受益者可以通过贡献工程、资金、独立构建能力和事件响应支持来降低风险，而不是将全部保证负担转移给一个志愿者维护者。

未知数

• Jia Tan 账户及相关公开角色背后人员的真实身份、人数、国籍、雇主、赞助人、地点和动机。
• 是否每个可疑的历史更改都是恶意的，每个组件由谁编写，以及是否存在另一个未被发现的植入物或操作目标。
• 有多少系统构建了活动的植入物，有多少暴露了相关的 SSH 配置，攻击者是否成功地使用过后门，以及是否有任何数据或凭据被窃取。
• 发现、协调、平台日志、执法活动以及控制相关账户的人员之间通信的完整私下时间线。
• 调查、回滚、重建、重新安装、凭据轮换、延迟发布和长期治理变更的总财务和人工成本。
• 当前的项目和下游控制是否能够可靠地防止另一个受信任的维护者、受损密钥、有毒构建者或发布服务账户创建类似的差异。

这种分离不仅仅是写作惯例。它是一种控制。夸大归属可能会伤害无辜者并分散对可验证弱点的注意力。低估技术记录可能会让机构将设计好的后门描述为普通错误。一个有用的问责档案保留了这两种真相：故意的不当行为在账户和制品层面得到确认；该行为背后的人类和组织归属仍未解决。

持久的问责测试

持久的测试必须可由未参与 2024 年 3 月的未来维护者或发行商重复。它必须在发布广泛安装之前产生证据，而不仅仅是事件后的叙事。对于 XZ Utils 和类似的基础项目，以下问题创建了该测试。

1. 发布权限是否明确且可分离？项目应发布谁可以合并、标记、创建制品、上传发布、更改托管页面、路由安全邮件和签署发布。高影响行动应要求单独的凭据，最好是独立的人，以便一个受信任的账户不会静默控制每个过渡。发行商应记录他们目前信任哪些上游身份和密钥。

2. 每个制品是否可追溯到一个被审查的源代码修订版？发布应标识确切的提交或标签、构建指令、工具链版本、环境和所有生成输入。如果 tarball 包含不在 Git 中的文件，机器可读的清单应对它们进行分类并解释它们是如何产生的。“生成”必须是来源类别，而非豁免审查。

3. 源到发布差异是否被机械地强制执行？发布过程和下游接收应解包制品、重新生成预期文件，并在无法解释的可执行差异上失败。允许的变化应狭窄、记录在案并经过审查。新的 M4 宏、shell 管道、二进制对象或构建钩子不应消失在大的生成差异中。

4. 独立方能否重现或验证输出？至少一个发布创建者控制之外的构建者应重现指定制品或发布详细比较。当比特完全相同不可行时，项目应标识剩余差异并显示其为何不能改变可执行行为。重新构建者证据应与发布一起保留。

5. 下游政策是否验证来源而非仅收集它？发行商应拒绝其来源身份、构建者身份或预期过程违反政策的制品。来自同一受损发布账户的签名证明是薄弱的。验证应涉及独立密钥、受保护的构建服务或发行商控制的重新构建。

6. 不透明的测试和固定更改是否根据能力处理？压缩、媒体、解析器和协议项目需要二进制固定。控制应标记新的或更改的不透明输入，在可行时要求生成器或记录来源，显示代码是否实际消耗它们，并检查它们产生什么。不应禁止二进制内容；应禁止无法解释的可执行影响。

7. 模糊测试、沙箱和分析异常是否作为安全更改进行审查？禁用 sanitizer 覆盖、更改模糊接触、削弱沙箱检测、改变间接函数行为或抑制诊断的更改应接受明确审查，即使它们修复了合法的兼容性问题。问题不在于提交消息听起来是否合理，而在于更改移除了什么可见性或遏制。

8. 推广是否创造时间和可逆边界？开发、建议、测试、滚动和稳定渠道应有记录的推广标准和对高影响基础包的最低观察期。紧急回滚必须经过演练。包历史应让操作员证明可疑版本是否曾安装，而不仅仅是当前版本存在。

9. 发行商能否看到危险的运行时组合？清单不仅应显示 XZ 已安装，还应显示哪些特权进程可以通过直接或传递依赖和下游补丁加载其库。SBOM 和链接分析在回答暴露问题时有用。没有运行时上下文的平面组件列表不会解释压缩库为何影响 SSH。

10. 事件指南是否区分更新、重新安装和凭据轮换？响应计划应定义每个行动需要什么证据。干净的包替换可能移除恶意代码；如果利用已经发生，它不会撤销先前的访问。重新安装和凭据轮换成本高昂，因此指南应解释不确定性、暴露条件以及预防措施的理由。

11. 项目的人力能力是否被视为基础设施？关键消费者应知道项目是否依赖一个人，谁可以在生病或缺席时响应，安全工作如何资助，以及维护者在压力下可以寻求帮助而不放弃权力。支持可以包括带薪维护者时间、独立发布审查、基金会服务或发行商工程。它应减少胁迫性工作负担，而非购买对技术决策的控制。

12. 修复是否定期重新证明？一次性干净发布是不够的。项目和发行商应发布持续证据，证明当前发布符合制品、签名、来源、重建和推广规则。失败的检查应阻止发布。异常应过期。独立审计应测试撤销一个维护者或密钥是否实际阻止发布。

通过这一测试并不要求每个小项目变成公司。它要求有能力的一方停止假装基础依赖既可以是关键基础设施又可以仅作为私人爱好，当需要保证工作时。上游项目可以定义源和发布意图。基金会和托管提供商可以提供身份、审查、签名和恢复基础设施。发行商可以重建和验证。商业用户可以为共享控制提供资金和人员。公共机构可以围绕证据而非文书工作调整采购和召集。

门槛也不是完美。坚定的对手可能攻陷多人、构建者或密钥。目标是将一个不透明的信任决策替换为若干可观察、独立控制的决策，并确保一个层次的失败不会自动成为另一层次的特权远程访问路径。当外部者可以检查记录并确定谁批准了什么、哪些字节被构建、它们为何不同、它们运往何处以及系统如何证明恢复时，控制就是持久的。

救援后的问责

XZ 响应展示了开放协作的最佳品质。一位工程师遵循了一个微弱的性能信号。发行版安全团队私下协调足够长时间以准备回滚。公开披露促成了快速分析。开发渠道限制了广泛部署。维护者审查了历史并恢复了发布。这些行动值得赞扬，因为它们改变了结果。

同样的记录证明了为何救援不能是操作模型。决定性的发布制品之所以受信任，是因为一个合法的维护者密钥签署了它，尽管它在安全相关方面与可见来源不同。一个小项目的人力限制成了全球依赖风险。下游组织拥有更强的构建和部署机制，但许多接受了上游 tarball，而没有首先证明其与审查标签的关系。

因此，持久的问责基于一个简单但苛刻的命题：信任必须在每个转换处得到证据。贡献者声誉不是发布证明。标签不是 tarball。签名不是可重现性。包名不是运行时依赖图。降级不是没有先前访问发生的证据。虚惊不是系统安全的证明。

截至 2026 年 7 月 15 日，确认的记录支持成功的遏制和一个正常运作的项目，但不是最终归属或完全的机构结案。持久的标准应该是下一个发布是否可以独立地与审查过的源代码相关联，下游推广是否会在无法解释的差异上停止，维护者是否拥有可持续的支持而不放弃控制，以及每个响应者是否可以证明暴露了什么和修复了什么。这就是 XZ tarball 创造的问责测试。