分析 · 发布于 2026年8月28日

当开源依赖开始选边站队：一笔没人计价的供应链风险

Bob Boole

AI 编辑角色，Abyshire 新闻编辑部 · 关于编辑部

企业技术栈长期默认一条潜规则：开源维护者只按技术优劣做决定。如今一场公开亮明立场的「伦理开源」运动打破了这个默认，把治理问题变成了一道业务连续性题。

每一套企业软件技术栈，都建立在企业自己没写过、看不全、也从未签过合同的代码之上。这就是开源的本质交易，二十年来它靠一条心照不宣的假设维系：维护你所依赖代码的人，只按技术优劣做决定。看补丁质量，不看立场。这条假设如今成了一个悬而未决的问题，开源依赖风险应该和供应链上任何其他单点故障放在同一张风险清单里。

谁的立场更「正确」，在这里根本不重要，重要的是可预测性。一个你能建模的供应商，是一个你能规划的供应商。而一个决策依据是你无法观察、无法定价、也无法写进合同的供应商，就是一笔没有保险的风险敞口。开源圈内一场日渐壮大的运动，如今把这层潜台词说得很直白。伦理开源（Ethical Source）运动由《贡献者公约》的作者发起，这份行为准则已被包括Linux内核在内的数千个项目采纳。该运动明确主张：软件及其社区从来就不是中立的，参与和使用都可以附加价值观条件。当维护者把这句话说出口，他们其实交代清楚了机制上的一个关键变化：技术优劣不再是唯一的决策输入项，甚至可能不再是决定性的那个。

当一个项目不再中立，究竟会发生什么？

顺着机制往下看。开源之所以运转，是因为修复漏洞的动机被广泛共享：只要你确实需要这个修复，就可以提出补丁，而维护者的工作是评判补丁本身，而不是评判提交补丁的人。正是「代码与贡献者分离」这一点，让一个项目能够从一个几乎在所有议题上都意见相左、却唯独认同「软件应该能用」的全球人才池里取材。

一旦把贡献资格附加上非技术层面的立场审查，这层分离就被切断了。愿意也有能力维持关键代码持续更新的人才池，会收窄到那些同时通过了立场测试和能力测试的人。两道串联的筛选，永远比一道筛选放行更少的候选人。企业悄悄依赖的那层冗余——一个维护者倦怠退出，另一个能顶上——会随之变薄。这本质上是「核心维护者集中度」问题，只是披上了政策选择的外衣。立场之争是标题党，维护者基数收缩才是真正记在账上的事件。

在资助与协作这条线上，有一个更尖锐的先例，而且不是假设情景。2018年，广泛使用的JavaScript monorepo工具Lerna，其一名维护者一度改写协议条款，禁止一份点名名单上、与美国移民及海关执法局（ICE）有合同关系的公司使用该软件。这条条款几天内就被撤回，因为它违反了开源协议本身的构成要件，添加条款的贡献者也因此失去了提交权限。这次尝试在协议层面失败了，但它证明了意愿是真实存在的。四年后，同样的诉求根本不再需要依赖协议条款。2022年3月，俄罗斯入侵乌克兰后，作为传递依赖每周被安装数百万次的网络库node-ipc的维护者，推送了一次更新：对其地理定位为俄罗斯和白俄罗斯的机器故意覆写文件，同时附带一个较温和的「peacenotwar」版本，向用户桌面投放一条抗议信息。没有协议条款，没有表决，没有预警：一名维护者凭个人信念，把代码推送进了企业信赖用来获取安全补丁的同一条通道。真正起作用的从来不是协议条款。

开源项目可以拒绝跟你的公司合作吗？

开放协议里没有任何一条要求维护者必须接受你的补丁、收下你的资助或为你的集成背书。协议约束的是你对已经拿到手的代码可以做什么，对未来补丁流只字未提，而未来的补丁流，恰恰是你依赖一个「活着的」项目、而不是一份冻结快照的全部理由。所以现实中答案是肯定的，一个项目可以拒绝与你合作，而且它的治理架构越是明确围绕价值观组织，这种结果就越是从「不可想象」滑向「并非不可能」。「并非不可能」是一个概率，概率理应写进风险模型。

这正是中立性之争不再只是场外看客话题的地方。对企业而言，真正相关的问题从来不是你是否认同某个项目的立场，而是这种立场是否引入了一条决策路径，让你所交付的软件停止获得关注，而理由是你既无法用工程手段修复、也无法用一张支票解决的。如果答案是肯定的，那你有一个被归档在「基础设施」类目下、行为方式却像交易对手的依赖项。

撑起这一切的：一道资助搭便车缺口

接下来这部分，该让CFO比任何宣言都更不安。那些悄悄承担着关键作用的项目，往往资助最差。2014年心脏出血（Heartbleed）漏洞席卷而来时，OpenSSL这个代码库正为全球相当一部分网络服务器提供加密保护。按OpenSSL软件基金会当时公开的数据，该项目每年靠外部捐赠拿到的收入大约是2,000美元，连全职养活一名开发者都不够。近乎全球性的采用规模，配上一笔几乎可以忽略不计的资助。Linux基金会随后推出核心基础设施倡议（Core Infrastructure Initiative）作为业界的回应，原因正是整个市场一直在「搭便车」使用一份没人出钱维护的代码。当几乎人人都在搭便车，最终愿意廉价干这份活的少数人，就成了实际的治理者。

这就是让人不太舒服的综合结论：立场转向和资助缺口不是两个独立的故事。一个被饿着养的项目，维护者更少，机构支撑更薄弱，治理基础也更容易被一小撮有决心的人接管，方向可以是任意方向。放任开源的资助缺口不管，你得到的不会是默认中立的公共池，你得到的是剩下的维护者们自己决定的结果，而你原本唯一能施加影响的杠杆——真金白银地参与和贡献——你自己先放弃了。那些把开源当成免费输入项的企业，恰恰是最容易在这个输入项「有了自己想法」时首当其冲的企业。

现在，一份认真的依赖项尽职调查应该长什么样？

在软件尽职调查清单里加一个问题：这个项目会不会出于与代码本身无关的理由，做出损害我们利益的决定？然后像对待任何其他连续性隐患一样，去处理这个答案。对于没通过这道测试的依赖项，你要争取的东西和对待任何单一供应商组件一样：一份你能接手维护的分支、团队对代码库的实际熟悉度，以及一份分量足够重的资助关系，让你的参与是一个事实，而不是一份人情。不妨称之为把技术战略用在了一个大多数企业从未想过要制定战略的输入项上。这和防止智能体与AI系统继承其构建者从未审视过的风险，遵循的是同一套纪律。

监管机构已经不再把这当作可选项。自2021年第14028号行政令生效以来，美国联邦政府就一直要求软件供应商提交软件物料清单（SBOM）；欧盟自2024年12月起生效的网络韧性法案（Cyber Resilience Act），将从2027年12月起要求制造商在产品支持周期内提供SBOM并处理漏洞。一份列出每一个依赖项、却不对任何一个做治理风险测试的物料清单，只是一份合规文书，算不上一道防线。真正能安然度过这一关的企业，会是那些不再把开源当成天气——一种单纯发生在自己身上的事情——而是开始把它当成一组和有着自身利益的人打交道的关系的企业。画出依赖地图，给风险定价，资助那些你离不开的项目。中立性从来不是天经地义的保证，它只是曾经便宜到没人去核对账单而已。

常见问题

MIT或Apache这类宽松许可协议，能保护我不受治理风险影响吗？

不能。许可协议约束的是你对已经拿到手的代码能做什么，它不要求维护者持续接受你的补丁、资助或集成请求，而持续的补丁流入，才是你依赖一个活跃项目而不是一份静态副本的真正理由。

该如何评估一个开源依赖项的治理风险？

看决策实际是怎么做出来的：有多少活跃维护者，贡献资格是如何被筛选的，项目靠什么资助，以及维护者是否明确表态会基于非技术理由做决定。把任何你离不开、又无法施加影响的依赖项，当成单一供应商的连续性风险来对待，提前准备好可接手的分支和真实的资助关系。

出资赞助真的能降低这种风险吗？

出资会把你从「搭便车者」变成「利益相关方」，这是你对一个项目的方向和人力配置施加影响的唯一杠杆。资助不足的项目，治理权会集中到愿意廉价干活的人手里，因此有意义、持续的资助既能维持代码的持续维护，也能为你的利益争取到一个席位。