你的依赖扫描工具看不到这个风险：维护者一夜消失，代码沦为孤儿
开源供应链真正的风险，不在许可证或代码质量，而在维护者因与代码本身无关的理由被除名的那一天——你的企业将被迫接手这个“孤儿项目”。
你的依赖扫描工具，擅长发现它能看到的东西。它读取版本号，核对许可证，把已知的CVE与数据库比对，生成一份齐整的报告。而这份报告有一个人形大小的盲区。
你技术栈底层的那个组件，是由某个人在打补丁。有时是一个团队，但更多时候，是某个人在业余时间独自维护。你的软件物料清单（SBOM）里，没有任何一项记录这个人是谁、他要向哪个司法管辖区负责，或者如果他在两次发布之间被移出项目，那段代码会发生什么。
这种情况并非纸上谈兵。2024年10月，Linux内核项目将约十一名与俄罗斯企业有关联的维护者除名，并从内核的MAINTAINERS文件中删除了他们的条目。相关提交只给出了简短理由，称这些条目的删除是出于各种合规要求，Linus Torvalds公开为此背书，他指向的是这项决定背后的制裁法律，而不是代码本身的任何问题。触发这一切的，不是代码质量、不是安全事件，也不是治理纠纷，而是一项项目无法拒绝的法律义务。真正重要的是其中的机制：合规审查绕过了代码本身，直接除名了维护代码的人。
这枚硬币的另一面，是2024年3月被曝光的xz-utils后门事件。一名维护者花了大约两年时间，一点点赢得一个人手紧张的志愿者项目的信任（CVE-2024-3094），随后利用这个身份，在一个被绝大多数Linux发行版采用的压缩库中植入了一个隐蔽后门。一起事件是依法除名一名受信任的维护者；另一起，则展示了维护者席位对想要滥用它的人来说价值几何。两者都指向同一个被扫描工具忽略的事实：真正的杠杆掌握在拥有提交权限的人手里，而不是他们提交的语法里。
维护者被除名之后，究竟会发生什么？
顺着这个链条推演。一名维护者负责一个模块，审查补丁、分诊漏洞、为这部分代码签发版本。把他除名，补丁依旧会不断提交上来，但已经没有人拥有权限或掌握上下文去合并它们。模块不会在除名当天就崩溃，它会慢慢腐烂，一次一个未经审查的安全补丁地腐烂下去。
承担这个代价的不是项目方，而是你。这是一个没有合同、没有服务级别协议（SLA）、对你不承担任何义务的志愿者项目。当一个组件失去主人时，使用它的企业就继承了一笔未打补丁、未经分诊的负债——这笔负债不是你选的，也不容易退回去。既然除名是法律要求而非政策选择，治理是否中立已经无关紧要。
为什么扫描工具看不到这种风险？
参与一个基础性项目的规则，由其领导层自行裁量决定。这不是在批评谁，每个项目都需要有人来决定谁能提交代码。但这意味着，你对这个依赖项的风险敞口，悄悄地包含了你无法置喙、也无从知晓的决定：谁能被吸纳，谁会被除名，依据又是什么。许可证捕捉不到这一点，SBOM捕捉不到，扫描工具更捕捉不到。
剥开这层包装，剩下的是两种熟悉的风险敞口：关键人员风险和治理裁量权风险，而它们就潜伏在你视为固定资产的基础设施之下。当这类风险出现在供应商关系里时，财务部门早已有一套现成的语言来描述它。但它很少被用在三层之下的那个开源库上，因为那个库给人的感觉更像是物理定律，而不是一段可能被要求“离开”的人际关系。
两股压力正在汇合。制裁与出口管制制度如今能够直接触及维护者名单，而且覆盖范围还在不断扩大。与此同时，最关键的依赖项往往人手最为单薄，靠寥寥几名志愿者支撑，2024年的xz-utils险情和2021年12月的Log4Shell应急抢修都证明了这一点。可信赖的人越少，其中一人被一条项目无法申诉的规则除名的概率就越高，未维护代码暴露在外、无人修补的窗口期也就越长。用自动化代理快速拉取、更新依赖的团队，应当把这当作一项设计约束，而不是边缘情况来对待。这正是智能体系统安全中较为棘手的问题之一。
正确的应对方式，不是为某个具名项目而恐慌，也不是幻想自己能把整个依赖关系图都自建自托管。而是在技术尽职调查中加入大多数团队从未问过的一个问题：什么样的法律或裁量事件，可能在一夜之间移除这个组件的维护者？第二天早上，我们对那些沦为孤儿的代码，有什么应对计划？
这个问题能迅速帮你的依赖项分类。大多数没有问题：维护者基础广泛，涉及多个组织，总线因子（bus factor）健康。但少数不是这样——一名维护者，一个司法管辖区，一个没有任何自动化工具会标记出来的单点故障，因为这种失效发生在人和法律层面，而不是语法层面。这少数依赖项值得制定应急方案，无论是资助第二名维护者、封存一个已知可用的版本，还是建立内部能力，在必要时自己动手打补丁。
你的技术栈，不只是你导入的代码。它是一组与人之间的关系，而这些人可能被与你毫无关系的力量除名。该被审计的是人，不只是软件包。
常见问题
SBOM能防范维护者或制裁风险吗？
不能。软件物料清单只清点你交付了哪些组件和版本，以及它们携带的许可证和已知漏洞。它完全不记录谁在维护每个组件、有多少人能审查一次安全补丁，或者某次法律、治理事件是否可能把这些人一并移除。孤儿代码的风险恰恰就藏在这个盲区里，所以SBOM是必要条件，但远远不够。
开源依赖中的关键人员风险是什么？
指的是某个组件的审查与合并工作，依赖于极少数甚至单一个人。一旦这个人离开、因合规原因被除名，或者只是不再贡献代码，补丁依然会被提交，却没有人合并它们。代码会悄悄退化，而使用它的企业最终继承了这个无人维护的结果。
如何评估开源依赖中的治理风险？
不要只看许可证和代码本身，要看背后的人和规则。检查活跃维护者数量和总线因子，贡献者是否分布在多个组织和司法管辖区，以及谁有权裁量吸纳或除名提交者。然后问自己：哪一次法律或领导层事件可能在一夜之间移除维护权？对那些答案让人不安的组件，写下你的应急方案。
相关阅读
- Ubuntu 26.04 LTS的coreutils依赖名没变，代码已经换了作者
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 商业秘密官司的胜负,早在辞呈递交前就已写定:一桩鸡肉公司积案的启示
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。