事件背景 - 2025年7月，Google Project Zero宣布试行名为“报告透明化”的新政策，即在发现Bug后一周内公开说明问题所在项目及披露时间点，但不会公布技术细节，厂商或项目仍有标准的90天修复窗口 [1][2] - 该政策旨在缩短“上游补丁滞后”时间，即Bug在上游修复但用户迟迟收不到修补版本的时间差，其实现依赖于Google DeepMind开发的AI安全引擎Big Sleep [2] AI扫描结果与披露 - 2025年8月初，Google公布其AI安全引擎Big Sleep在多个主流开源项目中发现了约20个Bug，其中包括被浏览器、操作系统和各种媒体应用广泛使用的多媒体框架FFmpeg [3] - 根据“透明披露”政策，Google在公共问题追踪器上发布了Bug报告条目，显示部分Bug在8月中旬至9月间已提交给FFmpeg团队，大多数Bug风险等级被标注为“低”或“中等” [3] - 在“透明披露”机制下，FFmpeg维护者被迫在公开监督下修复Bug，但Google并未提供可直接使用的补丁 [3][4] 开源社区反应 - FFmpeg开发者在社交平台公开表达不满，指责Google的AI工具“向开源项目疯狂投递没有修复方案的Bug报告”，让维护者在舆论压力下被迫“义务加班” [5] - FFmpeg认为这不是安全合作，而是一种“企业级倒逼”，即拥有庞大资源的巨头用AI找到漏洞，再把修复责任丢给毫无资金支持的志愿者团队 [5] - 开发者要求Google不应仅炫技，而应直接提交修复补丁 [6] 行业立场分歧 - 安全研究阵营支持Google，认为FFmpeg的规模与影响力使其成为互联网级关键供应商，有义务修复漏洞，不能拿“志愿项目”当借口，并指出安全团队只负责发现问题，不负责修，早披露有利无害 [6] - 开源阵营支持FFmpeg，认为光报不修没意义，Google应该顺带贡献修复代码 [7] 历史矛盾与行业影响 - 类似矛盾并非首次发生，今年早些时候libxml2维护者Nick Wellnhofer也曾表达类似挫败感，指出花费大量时间为第三方报告的问题做漏洞分级却拿不到一分钱，并直接点名Google Project Zero，称面对最顶尖、最富有的安全团队时志愿者感到压力巨大 [9] - Nick Wellnhofer因疲惫退出libxslt维护工作，FFmpeg团队也有一位核心开发者因此离开，这让人联想到2024年XZ Utils后门事件，表明全球关键开源基础设施很多仅靠几个人支撑 [9] - 争论暴露出现代互联网的根基建立在脆弱的善意之上，AI的“高效扫描”反而让志愿者更疲惫，Bug越来越多，修复人手却越来越少 [10][11][12]