2024 年 3 月，一名工程师因为 SSH 登录异常变慢，最终追踪到 xz Utils 发行包中的恶意代码。受影响版本尚未大范围进入稳定发行版，灾难因此被及时阻止，但整个过程展示了一种比普通漏洞更令人不安的风险：攻击者不是闯入仓库后匆忙改一行代码，而是长期经营身份、建立信任，再利用发布流程植入后门。
xz 事件之所以震动开源社区，是因为它攻击的不是某个函数，而是协作体系本身。
后门为什么藏得这么深
恶意逻辑并没有以醒目的形式直接出现在常规源代码里。复杂的测试文件、构建脚本和发行 tarball 共同参与了注入，最终影响与 SSH 认证路径有关的进程行为。
这利用了一个常被忽略的缝隙：很多项目审查 Git 仓库中的代码，却默认发布包只是同一份源码的压缩结果。如果 tarball 包含仓库里没有的生成文件，或者构建过程会解释难以阅读的数据，审计链条就断开了。
可复现构建的重要性正在这里。多个独立环境如果能从同一源码得到相同制品，就更容易发现发布包与仓库状态不一致。签名只能证明“谁发布了它”，不能证明内容一定安全。
攻击者利用了维护者的疲惫
公开时间线显示，相关身份先在社区中贡献代码，随后逐渐获得维护权限。与此同时，还有账号向原维护者施压，催促项目加速交接。一个被广泛依赖的基础库，背后可能只有极少数志愿者承担长期维护。
这让我意识到，开源供应链最薄弱的环节不一定是密码学，也可能是人的精力。攻击者不需要破解技术系统，只要让一位疲惫的维护者觉得“终于有人愿意帮忙”。
企业免费获得了基础设施，却没有自动分担维护成本。依赖数量越多，组织欠整个生态的隐性债务也越多。
团队可以做哪些具体改进
首先要知道制品从哪里来。锁定版本、保留哈希与签名、记录构建环境，并尽量从源码进行可复现构建。其次，关键依赖不能只看下载量，还要关注维护者数量、发布流程和所有权变化。
构建脚本、测试数据和生成文件也应进入安全审查，它们与业务源码拥有相同执行能力。生产镜像要尽量精简，因为每一个不必要的软件包都会增加无法感知的供应链表面。
最后，应给异常性能留出调查空间。如果发现者把 SSH 多出的几百毫秒当成普通抖动，这次后门可能更晚才被识别。可观测性不仅寻找故障，也能暴露攻击留下的细小偏差。
我的理解：信任必须能被交叉验证
软件开发不可能完全没有信任，我们无法逐行审计所有编译器和依赖。更现实的目标，是避免单点信任：代码评审与制品比对分离，发布权限多人确认，高风险变更由不同维护者复核，异常由独立工具观察。
xz 事件不是“以后不要相信开源”，而是提醒我们不能只消费开源。关键基础设施需要资金、人员与制度支持；组织也应减少无意义依赖，为真正重要的组件建立可追溯链路。
供应链安全的终点不是一张扫描报告，而是任何环节发生异常时，我们都有另一份独立证据可以质疑它。
参考资料
- oss-security：backdoor in upstream xz/liblzma leading to ssh server compromise
- CISA：Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library
本文是 2026 年整理断更期时写下的回顾，发布日期按事件所处阶段归档。