事件背景 - 2025年7月，Google Project Zero宣布试行名为“报告透明化”的新政策，在发现Bug后一周内即公开披露问题存在及修复期限，但不会公布技术细节[3] - 该政策旨在缩短“上游补丁滞后”时间，即Bug在上游修复后用户迟迟收不到修补版本的时间差[3] - Google利用其AI安全引擎Big Sleep（由Google DeepMind开发）来实现这一策略[3] 核心冲突 - 2025年8月初，Google公布Big Sleep在多个主流开源项目中发现约20个Bug，其中包括被广泛使用的多媒体框架FFmpeg[5] - 根据透明披露政策，Google在公共问题追踪器上发布了Bug报告条目，显示部分Bug在8月中旬至9月间已提交给FFmpeg团队[5] - 大多数Bug风险等级被标注为“低”或“中等”，但FFmpeg维护者被迫在公开监督下修复Bug，而Google未提供可直接使用的补丁[6][7] - FFmpeg开发者认为这是“企业级倒逼”，万亿美元公司用AI扫描代码后让志愿者无偿修Bug[9] 双方立场分歧 - 安全研究阵营支持Google：认为FFmpeg作为互联网级关键供应商有义务修复漏洞，不能拿“志愿项目”当借口；安全团队只负责发现问题不负责修；早披露有利无害[11] - 开源阵营支持FFmpeg：认为光报不修没意义，Google应贡献修复代码；带时限的公开压力会加剧开源开发者倦怠与流失；过度依赖少数志愿者本身就是安全风险[11] 行业影响与历史先例 - 类似矛盾非首次发生，今年早些时候libxml2维护者Nick Wellnhofer也表达过类似挫败感，因疲惫退出了libxslt维护工作[11][12] - FFmpeg团队内部已有一位核心开发者因此离开，让人想起2024年XZ Utils后门事件，表明全球关键开源基础设施多靠少数人支撑[12] - 争论暴露现代互联网根基建立在脆弱善意之上，AI高效扫描反而让志愿者更疲惫，Bug增多而修复人手减少[14]

事件背景与核心冲突 - 事件核心是围绕AI发现开源软件漏洞后由谁负责修复的争议，一方是谷歌及其AI工具Big Sleep，另一方是开源框架FFmpeg的维护者 [1] - 争议焦点并非漏洞本身，而是企业使用AI工具扫描开源代码后，是否可以将修复责任完全转移给无偿的志愿者维护者 [1] 谷歌的新政策与AI工具应用 - 谷歌Project Zero于2025年7月试行名为"报告透明化"的新政策，在发现漏洞后一周内即公开披露漏洞存在的事实及修复期限，但不会公布技术细节 [3] - 此举旨在缩短"上游补丁滞后"的时间差，即漏洞在上游修复但用户迟迟收不到修补版本的时间 [3] - 帮助谷歌实现此策略的是其AI安全引擎Big Sleep，该工具由谷歌DeepMind开发 [3] - 2025年8月初，谷歌公布Big Sleep在多个主流开源项目中发现了约20个漏洞，其中包括FFmpeg [5] FFmpeg维护者的立场与反击 - FFmpeg开发者公开表达不满，认为谷歌的AI工具在向开源项目大量投递没有修复方案的漏洞报告，迫使维护者在舆论压力下无偿加班 [8] - 维护者指责一家万亿美元市值的公司用AI扫描代码，却让志愿者团队无偿修复漏洞，这是一种"企业级倒逼" [8] - FFmpeg团队的核心立场是要求谷歌不要只展示技术能力，而应直接提交修复补丁 [8] - 类似矛盾并非首次发生，libxml2的维护者Nick Wellnhofer也曾因类似挫败感退出维护工作，FFmpeg内部已有一位核心开发者因此离开 [16] 双方阵营的主要观点 - 安全研究阵营支持谷歌，认为FFmpeg作为互联网关键供应商有义务修复漏洞，不能以"志愿项目"为借口，安全团队只负责发现问题不负责修复 [9][10][11] - 开源阵营支持FFmpeg，认为只报告不修复没有意义，谷歌应贡献修复代码，带时限的公开压力会加剧开发者的倦怠与流失，并提醒勿忘XZ Utils事件的教训 [12][13][14] 事件反映的行业深层问题 - 争议暴露出现代互联网的关键基础设施往往由少数志愿者在业余时间维系，其根基建立在脆弱的善意之上 [18] - AI的高效扫描在发现更多漏洞的同时，也加剧了维护者的疲惫，导致漏洞增多而修复人手减少的局面 [18]

事件背景 - 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]