把Bug“曝光”到全网，谷歌逼FFmpeg维护者“按时修复”，遭怒怼：别光用AI找Bug，有本事你自己修啊！

整理 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

最近，开源圈被一场突如其来的“AI 找 Bug 大战”搅得天翻地覆。

一边是坐拥万亿美元资源的 Google Project Zero（PZ）及其 AI 漏洞猎手 Big Sleep；另一边，是由全球志愿者维系、为无数软件和浏览器提供多媒体支持的开源框架 FFmpeg。

这场冲突的核心，并不是 Bug 本身，而是一个更现实的问题：谁该负责修复这些由 AI 发现的 Bug？——当企业用强大的 AI 安全工具扫描开源代码，是否就能理所当然地把修复责任“甩”给无偿维护者们？

一切的导火索：Google 的“Bug 报告透明化”新政

要理解这场纷争，要先回到 2025 年 7 月。那时，Google Project Zero 宣布试行一项名为 “Reporting Transparency”（报告透明化） 的新政策。

按照这一政策，Google 在发现 Bug 后一周内，就会公开说明“发现了哪个项目的问题”，并明确披露时间点和修复期限——即使 Bug 尚未修复。不过，厂商（或项目）仍有标准的 90 天修复窗口。

Project Zero 负责人 Tim Willis 当时写道：“我们在原有流程的最前面，增加了一个公开步骤。在报告 Bug 的一周内，我们会披露 Bug 存在的事实，但不会公布技术细节。”

对此，Google 解释称，这么做是为了缩短所谓的“上游补丁滞后”——也就是 Bug 在上游修复、但用户迟迟收不到修补版本的时间差。而帮助他们实现这一策略的，正是他们的 AI 安全引擎——Big Sleep（由 Google DeepMind 开发）。

Big Sleep 扫描开源项目：FFmpeg 中招

到了 2025 年 8 月初，Google 公布消息称，Big Sleep 在多个主流开源项目中发现了约 20 个Bug，其中就包括 FFmpeg —— 这套被浏览器、操作系统和各种媒体应用广泛使用的多媒体框架。

根据 Google 的“透明披露”政策，他们随后在公共问题追踪器上发布了 Bug 报告条目，显示其中一些Bug在 8 月中旬至 9 月间已提交给 FFmpeg 团队。

虽然大多数 Bug 的风险等级被标注为“低”或“中等”，但事情远未就此平息。

因为在“透明披露”的机制下，FFmpeg 的维护者们被迫“上了时钟”——所有人都在公开监督他们修复 Bug 的速度，而 Google 却并未提供任何可直接使用的补丁。

换句话说，Google 只报告 Bug，却没给修复方案，还倒逼志愿者去“按时修Bug”。

FFmpeg 反击：你不给补丁、只催修复，这不是帮忙

很快，FFmpeg 的开发者们在社交平台 X（前 Twitter）上公开表达了不满。

他们认为，Google 的 AI 工具正在“向开源项目疯狂投递没有修复方案的Bug报告”，让维护者在舆论压力下被迫“义务加班”：

“我们非常重视安全，但这合理吗？一家万亿美元公司用 AI 扫描我们的代码，然后让志愿者无偿修它发现的 Bug？”

对 FFmpeg 而言，这不是安全合作，而是一种“企业级倒逼”——一个拥有庞大资源的巨头，用自家 AI 找到漏洞，再把修复责任丢给毫无资金支持的志愿者团队。

有开发者愤怒地总结道：“找到 Bug 是好事，但你不给补丁、只催修复，这不是帮忙。我们的立场很简单——别光炫技，直接提个 patch 吧。”

双方立场：安全工程师 vs. 开源维护者

关于这件事，在 X 上安全研究员和开源开发者阵营的观点泾渭分明：

（1）安全研究阵营（支持 Google）

● “责任第一”：FFmpeg 的规模与影响力决定了它已是互联网级关键供应商，有义务修复漏洞，不能拿“志愿项目”当借口。

● “修复是维护者的职责”：安全团队只负责发现问题，不负责修。

● “早披露有利无害”：AI 只是比黑客更早发现漏洞。

（2）开源阵营（支持 FFmpeg）

● “光报不修没意义”：发现 Bug 没错，但 Google 应该顺带贡献修复代码。

● “别榨干志愿者”：这种带时限的公开压力会加剧开源开发者的倦怠与流失。

● “别忘了 XZ Utils 的教训”：过度依赖少数志愿者，本身就是一种安全风险。

显然，这场争论已经迅速在社交平台上蔓延成一场“理念大战”。

其实这不是第一次了：开源维护者的疲惫与愤怒

类似的矛盾并不是第一次发生，FFmpeg 也并不是第一个对 Google Project Zero 抱怨的团队。

今年早些时候，libxml2 的维护者 Nick Wellnhofer 也表达过类似的挫败感——他说自己花了大量时间为第三方报告的问题做漏洞分级，却拿不到一分钱。Nick 在发言中直接点名了 Google：

“尤其是面对 Google Project Zero——那些最顶尖、最富有的安全团队盯着你这些志愿者时，你真的会觉得喘不过气。”

后来，Nick 因为疲惫退出了 libxslt 的维护工作。他说这种“被追着修 Bug”的氛围，让开源开发变得一点也不好玩。而此次 FFmpeg 团队也表示，他们内部已经有一位核心开发者因此离开。

这不仅让人想起了 2024 年的 XZ Utils 后门事件——当时，一个维护者被攻击者渗透，导致全球 Linux 发行版几乎被植入供应链后门。这再次表明：全球关键开源基础设施，很多其实只靠几个人在撑。

所以AI发现的Bug，到底谁来修复？

目前，这场争论仍在继续。Google 一方面强调，自己的目标是让Bug在被黑客利用之前修复；FFmpeg 则认为，Google 的做法忽视了开源社区的现实：没人付钱、没人雇人、没人能随叫随到修 Bug。

在 X 上，FFmpeg 继续发文挤兑：“多有意思啊，这些安全研究员在发现 Bug 时言辞凶狠，但当你让他们自己写补丁时，他们立刻就不高兴了。”

这场“AI 找 Bug”的风波，让人重新审视了互联网的底层现实：支撑世界的关键基础设施，往往是由少数志愿者和他们的夜晚时间维系的。而现在，AI 的“高效扫描”反而让这些人更疲惫——Bug 越来越多，修复人手却越来越少。

正如一位开发者在评论中写道：“这场争论其实是必要的。因为它暴露了一个尴尬得真相——现代互联网的根基，建立在极其脆弱的善意之上。”

那么，关于这件事，你的看法又是什么呢？

参考链接：https://piunikaweb.com/2025/11/06/google-vs-ffmpeg-open-source-big-sleep-ai-bugs-and-who-must-fix-them/

【活动分享】2025 年是 C++ 正式发布以来的 40 周年，也是全球 C++ 及系统软件技术大会举办 20 周年。这一次，C++ 之父 Bjarne Stroustrup 将再次亲临「2025 全球 C++及系统软件技术大会」现场，与全球顶尖的系统软件工程师、编译器专家、AI 基础设施研究者同台对话。

本次大会共设立现代 C++ 最佳实践、架构与设计演化、软件质量建设、安全与可靠、研发效能、大模型驱动的软件开发、AI 算力与优化、异构计算、高性能与低时延、并发与并行、系统级软件、嵌入式系统十二大主题，共同构建了一个全面而立体的知识体系，确保每一位参会者——无论是语言爱好者、系统架构师、性能优化工程师，还是技术管理者——都能在这里找到自己的坐标，收获深刻的洞见与启发。详情参考官网：https://cpp-summit.org/