开源软件是关键基础设施:政府资金该怎么花才有效?

一个反复被说、却总没落实的共识
各国政府近年频繁把开源软件称为"关键基础设施"(critical infrastructure),这已经成了政策圈的标准表述。欧盟最新发布的《AI 网络安全计划》再次延续了这一逻辑——其中包含一项专门针对"保护关键开源软件"的行动倡议。
从问题分类上看,这确实抓对了方向。开源软件支撑着从操作系统、加密库到云基础设施的几乎一切。两起标志性事件已将这一风险暴露无遗:2021年底爆发的 Log4Shell(CVE-2021-44228)利用了 Apache Log4j 日志库中的远程代码执行漏洞,而该库被数十亿 Java 应用程序所依赖;2024年的 xz-utils 后门事件则更为隐蔽——一名身份不明的贡献者历时两年通过社会工程学手段逐步获取社区信任,最终在压缩工具的发布版本中植入后门,攻击目标直指 SSH 守护进程。两起事件的共同特征是:极高的依赖广度,叠加极少的维护人力——一个疲惫不堪的独立维护者,可能就是整个数字社会的系统性风险点。
但真正的考验,不在于政府是否喊出这个口号,而在于他们是否愿意为那些**"无聊的日常维护"买单**。
"保护开源"不该变成又一轮审计秀
开源安全治理领域存在一个反复出现的陷阱:"保护开源"这一目标,很容易异化成一轮又一轮的安全审计——这些审计给维护者制造了更多工作量,却没有给他们任何报酬去完成这些工作。
"许多关键项目并不首先需要另一个仪表盘(dashboard)。它们需要的是有报酬的时间。"
这句话点出了当前开源安全治理的核心悖论。政策制定者天然偏爱"可见的产出":一份漏洞报告、一个安全评分看板、一次审计发布会。这些东西便于对外交代,也便于量化政绩。
但对于绝大多数关键开源项目来说,真正短缺的从来不是"发现问题",而是有人有时间、有精力、且被支付报酬去修复问题。审计报告发现了一堆 CVE,然后呢?如果没有配套的修复预算,这些报告只会成为压在维护者身上的又一份无偿劳动清单。
开源安全资金该花在哪些"不性感"的地方
一个真正有效的公共资助项目,应当覆盖以下几类常被忽视的支出方向:
1. 多年期维护者合同,而非一次性奖金
开源维护是长期承诺,一次性的"奖金"或"悬赏"无法让人放心地持续投入。稳定的多年合同才能让核心维护者把项目当作可持续的工作,而不是用爱发电的副业。
2. 可复现构建与签名发布基础设施
供应链攻击(如 xz 事件)的教训表明,构建流程本身就是攻击面。**可复现构建(Reproducible Builds)**是一种工程实践,目标是确保相同源代码在任意环境下编译产生逐字节相同的二进制输出,从而允许第三方独立验证发布包未被篡改——Debian、Tor Project 等项目已推进此实践多年,但大多数开源项目因缺乏工程资源而未能跟进。签名的发布基础设施同样是防御软件供应链投毒的关键,但这类工程投入既枯燥又长期缺乏资金。
3. 协调披露与事件响应能力
当漏洞出现时,谁来协调?谁来在深夜响应?大多数开源项目根本没有专门的事件响应团队,全靠维护者临时上阵,这种状态本身就是风险。
4. 独立审计 + 配套修复预算
审计必须与修复预算绑定。只做审计不给修复经费,等于只诊断不治疗。 这是当前资助模式中最常见、也最致命的缺口。
5. 避免"惩罚"被广泛依赖的项目
依赖关系映射不应反过来"惩罚"那些因被广泛使用而暴露更多问题的项目。越是被依赖的关键开源组件,越应获得更多支持而非更多合规负担。
6. 单一维护者项目的继任计划
对于只剩一个活跃维护者的项目,必须建立传承和接班方案,从制度层面消除**"公交车因子为 1"(Bus Factor of 1)**的系统性风险。Bus Factor 是衡量项目知识集中程度的指标:若某个项目只需失去 N 名核心贡献者即可陷入无人维护状态,其 Bus Factor 即为 N。据 2015 年针对 GitHub 的大规模研究,超过半数活跃开源项目的 Bus Factor 不超过 2——这意味着一次意外、一次倦怠,就足以令无数下游系统失去安全保障。
用什么指标衡量开源安全投入的成效
评价开源安全资助是否有效,需要一次根本性的指标转变:
"重要的指标不应该是一个项目宣布了多少个漏洞,而应该是被资助的项目能多快修复问题,且不至于把懂代码的人累垮。"
当前很多安全项目的成功指标是"发现/披露了多少漏洞",但这本质上是虚荣指标——它衡量的是问题的数量,而非解决问题的能力。
更有意义的评估维度应聚焦于两点:
- 修复速度:从漏洞发现到完成修复的时间窗口有多短;
- 可持续性:核心维护者是否在健康地工作,而非持续处于 burnout(职业倦怠)边缘。
后者尤其值得重视。开源生态最大的隐性风险,正是那些默默支撑关键项目、却长期得不到报酬和承认的维护者。他们的倦怠或退出,往往比任何单一漏洞都更具破坏性。
一个值得认真对待的分配问题
假设一个政府拥有 1 亿欧元用于开源安全,其中多少比例应该投向审计、维护者时间、构建基础设施和应急响应?
这个问题没有放之四海而皆准的答案,但它逼迫我们直面资源分配的优先级。如果大部分预算流向了审计公司和咨询报告,而只有极小一部分真正到达维护者手中,那么这个项目再"合规",也无法触及问题的根源。
合理的分配方向应当大幅向维护者时间和基础设施倾斜——审计发现的问题,最终还是要靠这些人来修复。
口号易喊,账单难付
将开源软件纳入关键基础设施的认知,已经成为跨国政府的共识。但共识本身不解决任何问题。
真正的考验只有一个:当账单摆上桌时,政府是否愿意为那些不上镜、不出报告、却真正维系着数字世界运转的日常维护工作付钱。 这才是区分"政策姿态"与"实质投入"的唯一试金石。
相关推荐

DeepSeek Harness详解:一切皆插件的Agent运行时
深入解析DeepSeek Harness(DSH)的核心设计理念与架构特点。了解Agent=Model+Harness公式、Cordis插件系统、四种运行模式及Trajectory可追踪机制,帮助开发者快速上手模块化Agent开发。

DeepSeek Harness开发者预览版深度解析:自我演化的智能体框架
深度解析DeepSeek Harness开发者预览版,详解其核心理念——智能体框架的自我演化机制、Codis内核的组件化设计、热插拔架构原理,以及与现有Agent工具的本质区别。

DeepSeek Harness架构解析:一切皆插件的AI智能体工程体系
深入解析DeepSeek Harness架构核心理念,揭示为什么同一模型在不同工具中表现差异巨大。详解Harness七大工程模块:工具调用、沙箱环境、记忆系统等,理解模型决定下限、Harness决定上限的AI智能体开发范式。