AREX Viewpoint Article
Mozilla如何用AI代理让漏洞发现量提升8倍
导读
11月5日，OpenAI发布网络安全模型GPT-6 Cyber，并称其在Firefox中发现81个此前未知的漏洞；Mozilla方面表示，该模型帮助发现此前未知的高危问题并推动修复。对浏览器用户而言，这已不只是模型演示，而是一周多后OpenAI与Mozilla这场对话的新闻落点。
这段访谈值得现在看，不是因为它复述了81个漏洞，而是因为它补上了发布公告最容易忽略的一半：漏洞被发现后，团队如何验证、排序、去重并最终把补丁合入。视频中，Mozilla的Brian Grinstead给出的背景是，2025年到2026年，Firefox的漏洞发现和修复数量均增长约8倍；AI带来的不只是单点发现效率，而是整条安全流程的吞吐量变化。
Grinstead把Mozilla的做法描述为一条“代理安全流水线”，起点不是盲目扫描，而是决定把代理指向哪里。代理在独立虚拟机中获得Firefox源码和模糊测试工具链，围绕目标提出假设，再用动态测试不断证伪，直到给出可复现的崩溃样例；第二个代理随后复核它是否通过改代码等方式“作弊”，并依据威胁模型评估严重性。确定性验证加二次审查，把误报压到很低。
这套流程能运转，前提是Mozilla数十年的安全工程积累。视频提到，长期漏洞赏金、模糊测试、消毒器和内部红队，使代理可以直接复用既有工具链；多年积累的技术文档和威胁模型，又让优先级评分贴近Firefox的真实风险。81个漏洞因此不是“把模型接进代码库”就能自动得到的产出，而是组织把领域知识、测试基础设施和人工经验一起交给代理的结果。
更强模型还改变了“旧漏洞”的意义。Grinstead说，过去被判为中低危的问题，在GPT-6 Cyber重新扫描后，可能被发现存在绕过现有架构防护的路径，从而被重新标为高危；当模型证明某项架构加固并未提供预期安全属性时，团队反而获得高回报的反馈，知道该重新加固哪一层防御。这也解释了发布公告为何同时谈到架构改进建议。
发现量放大后，新瓶颈转向分类、去重和修复。Grinstead坦言，优先级排序从过去的非瓶颈变成必须自动化的环节；去重需要代理工具做第一轮筛选，又必须与工程团队保持紧密反馈；AI生成的补丁常因范围过窄或缺少代码库上下文而无法直接合入，仍需资深浏览器工程师审核和走评审流程。8倍增长因此不是终点，而是把“找漏洞”转化为“修得准”的组织考验。
在GPT-6 Cyber发布一周多后，这段对话的价值，是让读者看到Mozilla如何把模型能力装进一套可复核、可迭代的漏洞治理流程：风险选靶、动态复现、独立复核、变体扫描、人工补丁审核，并把运行信号汇入可查询数据库来规划下一轮扫描。需要说明的是，81个漏洞和8倍增长主要由OpenAI与Mozilla在发布材料及访谈中给出，访谈本身并非独立审计；但它公开了决策标准和流程细节，足以帮助读者判断，AI安全竞争为何落在验证、排序与修复速度上。
核心结论
- AI代理将漏洞发现从人工瓶颈转变为可扩展的自动化流水线：Mozilla构建了包含目标选择、代理扫描、确定性验证和二次审查的完整流水线，使漏洞发现量大幅提升且误报率极低，证明AI能系统化嵌入安全流程并产生规模化效果。
- 多年安全工程积累是AI代理发挥效用的前提条件：Mozilla数十年的漏洞赏金、模糊测试、消毒器和内部红队工具链，使代理能直接复用现有基础设施快速迭代，而领域文档与威胁模型则让优先级评分更精准，说明AI成功应用建立在长期安全投入之上。
- 更强模型能重新定级旧漏洞并暴露架构硬化盲点：GPT-6 Cyber等模型在重新扫描时发现绕过现有架构防护的路径，将中低危漏洞提升为高危，并推动防御纵深再加固，表明模型能力提升不仅在于发现新漏洞，更在于更准确地评估已知风险并指导架构改进。
- 变体扫描成为当前发现漏洞的主要手段，且重复率更低：将已知漏洞打包给代理在整个代码库中搜索相似模式，2025年9月变体扫描已成为发现漏洞最多的方式，并能挖掘长期潜伏的相似漏洞，同时减少重复报告，标志着漏洞发现策略从提交扫描向模式泛化的转变。
- 发现量激增后，新瓶颈转向分类、去重和优先级排序，人机协作仍不可替代：漏洞发现与修复量提升约8倍后，优先级排序从非瓶颈变为新瓶颈，去重需代理工具辅助并依赖工程团队紧密反馈；同时AI生成的补丁因范围过窄或缺乏上下文无法直接合入，资深工程师审核仍是必要环节。
观点拆解
1. AI代理将漏洞发现从人工瓶颈转变为可扩展的自动化流水线
-
代理安全流水线以目标选择为起点，而非盲目扫描：Brian Grinstead 将 Mozilla 的架构描述为一条完整的代理安全流水线，其最顶层的问题是“把代理指向哪里”。他明确否定了按字母顺序逐个文件扫描的做法，说明规模化漏洞发现的前提是智能化的目标选择，而非简单堆叠算力。
“所以这就是我们拥有的整体架构，我会把它称为一条整体的代理安全流水线，其中有一个代理安全测试框架的内循环，负责发现漏洞。但实际上远不止这些。从最顶层的全局来看，有一个问题是你打算把代理指向哪里来尝试发现漏洞。我一开始想的是，好吧，你按字母顺序排列文件，然后一个一个地遍历整棵目录树，但你很快就会意识到这行不通。”
-
内循环让代理在隔离环境中自主提出假设并用动态测试自我纠错：代理被放入独立虚拟机，获得 Firefox 源码和模糊测试工具链，并围绕目标反复提出漏洞假设、用动态测试验证或推翻。Brian 强调动态测试工具是关键，因为代理会先产生大量错误理论，再通过模糊测试发现其不成立，从而持续迭代直到获得确定性验证。
“我们让代理运行在它自己的虚拟机里，给它访问 Firefox 源代码和我们整个模糊测试工具链的权限，并给它某个目标或目的，告诉它去找一个漏洞。它能够访问动态测试工具非常重要，因为我们看到它会提出许多漏洞理论，然后在我们的模糊测试工具中测试，并意识到自己错了。”
“但它会继续在这个循环中运行，直到我们获得确定性验证，证明它成功找到了那个东西。”
-
确定性验证加二次审查代理，把误报率压到极低：代理必须证明漏洞真实存在才能退出内循环，例如提供一个加载后导致 Firefox 崩溃的 HTML 文件。Brian 还举例说代理可能通过修改代码库人为制造崩溃来通过验证，因此 Mozilla 引入第二个代理审查工作并评估严重性，最终使误报率极低，避免了工程师浪费时间阅读错误报告。
“确定性验证的例子是，一个 HTML 文件在 Firefox 加载时导致崩溃。”
“所以我们会做的是，在它证明之后，把它交给另一个代理，这个代理负责判断它是否做了奇怪的事情。例如，我见过它写一些代码来修补代码库，引入一个崩溃，造成崩溃，然后通过确定性关卡，我们发现这就是为什么需要第二个代理来检查工作。它还会根据我们的威胁模型对严重性和其他信息进行评级。所以经过这两个代理，我们的误报率非常低。”
-
流水线延伸到修复环节，代理自动生成补丁和测试：在获得经过验证的报告后，Mozilla 让代理在循环内直接编写修复代码，包括代码补丁和测试，并通过简单的云编排环境把结果写回存储桶再拉回本地工作台。这表明代理流水线不仅扩大发现规模，还试图缩短从发现到修复的路径。
“当然，在我们有了经过验证的报告之后，我们想尝试修复它。为了支持我们的工程师，我们在循环内让一个代理实际编写代码来修复它发现的问题，其中包括代码补丁和测试。”
2. 多年安全工程积累是AI代理发挥效用的前提条件
-
数十年安全工程积累为AI代理提供了可直接复用的工具链：Brian Grinstead指出，Mozilla长期运营外部漏洞赏金计划、早期采用地址消毒器和模糊测试，并拥有内部红队，这些积累使团队习惯于处理大量外部报告，工程师也能快速修复和发布。正因如此，AI代理可以直接使用现有的模糊测试和调试工具链，快速测试漏洞假设并迭代。
“我们能够真正利用这一新工具链的原因之一，是我们为此做了数十年的准备。”
“事实证明，为模糊测试器和内部研究员、外部研究员构建了这些工具链后，代理可以直接使用同样的工具。”
-
多年积累的领域文档与威胁模型使AI优先级评分更精准：在LLM驱动的优先级排序中，Mozilla能够将多年编写的技术文档、面向研究人员的材料以及内部扫描产物直接嵌入提示，使评分基于浏览器实际威胁模型。这表明AI的有效性不仅依赖模型本身，更依赖组织长期沉淀的领域知识。
“这实际上回到了多年来积累专业知识的理念。我们的代码库有我们编写并分享给编写代码的工程师的技术文档。”
“因此我们能够将这些接入，确保基于我们实际威胁模型获得正确的相关评分。”
3. 更强大的模型能重新评估已知漏洞的严重性并暴露架构硬化盲点
-
更强模型能重新定级旧漏洞：从“中低危”提升为“高危”：Brian Grinstead 指出，过去被评估为中低危的漏洞，在 GPT-6 Cyber 等更强模型重新扫描时，可能被发现存在绕过现有架构防护的路径，从而被重新标记为高危并优先修复。这说明模型能力提升不仅在于发现新漏洞，也在于更准确地评估已知漏洞的真实风险。
“它会像之前一样发现同一个漏洞，但实际上有信号表明它是安全高危。所以它找到了某种方式绕过一些我们以为坚不可摧的现有架构加固，并向我们证明：不，这个漏洞实际上是高危的，需要重新排定优先级。”
-
模型反馈暴露架构硬化盲点，推动防御纵深再加固：当模型证明某个被认为能消除或降低一类漏洞影响的架构控制或安全护栏实际上可被绕过时，团队就能获得明确反馈，需要重新加固该防护层。这种反馈具有很高的安全投资回报，因为它直接指导防御纵深和架构硬化的改进方向。
“你投资了某种架构选择或安全控制，以为它能消除或降低某类漏洞的影响，然后得到反馈说那个护栏实际上并没有提供你想要的安防属性，你确实需要重新加固它——这是一个好结果。”
-
灵活的目标设定让高危模式快速复用到其他漏洞：Brian Grinstead 强调，整个流水线被设计为具有非常灵活的目标设定能力，一旦发现某个漏洞绕过架构防护的案例，就能快速运行测试任务，将这种模式复用到其他漏洞上。这种灵活性避免了修改测试框架本身的大量代码工作，使团队能迅速扩大排查范围。
“我们试图让整个流水线做到的是拥有非常灵活的目标设定，这样如果我们看到那样的例子，就能快速运行测试任务，尝试将其复用到其他漏洞上。”
4. 变体扫描成为当前发现漏洞的主要手段，且重复率更低
-
变体扫描将已知漏洞打包给代理，在整个代码库中寻找相似模式：Brian Grinstead 解释了变体扫描的核心机制：把已修复或仍开放的漏洞打包成任务交给 AI 代理，让它在整个代码库中搜索相同模式。这种方法不仅能发现邻近代码中的问题，还能跨越整个代码库找到长期潜伏的相似漏洞，显示出代理对模式识别的泛化能力。
“变体扫描的思路是，我们拿一个已知的漏洞——要么是已经修复的，要么是仍开放的——把它打包成一个任务包交给代理，然后让它去整个代码库中寻找相同的模式。”
“我们可以拿漏洞，比如2025年我们修复的每一个安全漏洞，去尝试找到看起来类似的东西。它可能是在代码附近，也可能在代码库的另一端，但都是代理捕捉到的相似模式。”
-
2025年9月变体扫描已成为发现漏洞最多的方式，且重复报告更少：Brian 透露，2025年9月变体扫描发现的漏洞数量已占当月发现总量的多数，成为最主要的漏洞发现手段。他还指出变体扫描倾向于发现更少的重复漏洞，这解释了团队为何将精力集中在这一方向，使其成为当前安全策略的关键组成部分。
“如果看每月发现漏洞的百分比，9月份变体扫描实际上是我们发现的大多数漏洞。原因之一是它倾向于发现更少的重复漏洞，不管什么原因，我们刚开始看到它的成效，所以把精力指向了那个方向，但它现在确实已经成为策略的关键部分。”
-
变体扫描比提交扫描范围更广，能发现长期潜伏的相似漏洞：Brian 对比了提交扫描和变体扫描：提交扫描只关注单个新提交的狭窄代码范围，而变体扫描基于报告和提交，更广泛地搜索相似模式。他惊讶地发现，有些模式在代码库中存活了很长时间仍能被找到，说明变体扫描在挖掘历史遗留漏洞方面具有独特优势。
“你可以回溯很远，仍然能找到那种模式在代码库中存活了相当长的时间。”
“提交的范围非常窄，你看的是这一组确切的代码，而变体则更广泛。我们本质上是拿一份报告和一个提交，更广泛地寻找类似的东西。”
5. 漏洞发现量提升8倍，但新瓶颈转向分类、去重和优先级排序
-
漏洞发现与修复量提升约8倍，规模化成效显著：Brian Grinstead 给出明确数据：从2025年到2026年，漏洞发现和修复均实现约8倍增长，说明AI安全流水线在真实生产环境中已产生可量化的规模效应，而不仅是实验性成果。
“是的，目前从2025年到2026年，我们在发现漏洞方面，更重要的是在修复方面，都实现了大约8倍的增长。”
-
发现量激增后，优先级排序从非瓶颈变为新瓶颈：过去漏洞报告少，团队可立即处理每个高严重性漏洞；但随着发现规模扩大，分类和优先级判断成为必须自动化的新瓶颈，否则无法有效分配安全团队精力。
“这曾经不是瓶颈。以前我们收到的安全漏洞报告很少，所以会立即处理每一个。只要出现熟悉的高严重性信号，基本上就自动定为P1。而随着我们开始扩大发现规模，我们实际上不得不借助团队反馈，让系统中这些新瓶颈变得更加自动化。”
-
去重需代理工具辅助，并依赖与工程团队的紧密反馈来平衡漏报与骚扰：即使有100次扫描结果，判断重复也因崩溃栈相似但根因不同而变得困难；代理工具可做初步筛选，但必须与工程团队保持紧密反馈，否则过松会骚扰工程师，过紧则会漏掉漏洞。
“实际上，连去重都非常困难。如果你有100次扫描结果，你可能会想，这很简单：看测试用例，如果相同就是重复。但存在各种细微差别：崩溃栈相似但实际上是不同漏洞，或者栈相同但漏洞不同。我认为确实需要代理工具来帮忙做第一轮筛选。但你需要与工程团队保持紧密的反馈循环。对吧？如果在提交漏洞前太宽松，你就会用不需要看的东西骚扰非常忙碌且非常有才华的工程团队；但如果太严格，你就会漏掉漏洞跟踪器中的漏洞。”
6. AI生成的修复补丁尚不能直接落地，人机协作仍是必要环节
-
AI生成的补丁通常无法直接合入，存在修复范围过窄和缺乏代码库上下文的问题：Brian Grinstead指出，代理生成的补丁虽然能作为有用的资产附在缺陷报告中，但往往不能直接落地。原因包括补丁本身不正确、只修复了测试用例触发的特定崩溃而未解决更普遍的问题，以及缺乏对代码库整体上下文的了解。这表明当前AI补丁的局限性使其无法完全自动化。
“我们通常发现，那些补丁本身无法直接合入。有时可以，或者非常接近，但有时不行。原因多种多样。”
“有时补丁只是不对。有时它修复的范围非常窄……只修复了测试用例中的那个特定崩溃，但没有解决更普遍的问题。”
“有时它不了解代码库中正在发生的上下文。似乎没有什么诀窍能让这些补丁自动合入。”
-
资深浏览器工程师的审核与修改是人机协作流程中不可或缺的环节：Brian Grinstead描述了实际工作流：由专家级浏览器工程师接收缺陷报告，审阅包括修复补丁在内的所有证据，然后生成补丁、获得另一位工程师的评审并最终合入。这凸显了人类专业判断在确保补丁质量和安全性方面的关键作用，AI目前无法替代这一环节。
“但我们现有的工作流是，有一位专家级浏览器工程师拿到缺陷报告，查看它，查看所有证据，包括修复补丁，然后生成补丁，获得另一位工程师的评审，并使其合入。”
7. 将安全信号集中到可查询数据库，让代理持续优化扫描策略和工具本身
-
将运行记录、漏洞与工程师评论汇入单一SQLite数据库，为自然语言查询奠定基础：Brian Grinstead介绍，Mozilla在项目启动几个月后决定把所有运行信号、关联漏洞以及工程师评论统一摄入红队工程师机器上的一个SQLite文件。这一集中化数据层使得编码代理可以直接用自然语言提问，从而加速安全团队典型工作流的改进，并将改进反馈回测试框架，形成持续优化的闭环。
“几个月后，我们决定开始将所有信号摄入红队工程师机器上的一个SQLite文件。这些信号来自我们所有的运行、与这些运行关联的所有漏洞，以及工程师发来的所有评论。”
“它非常强大，因为你可以直接向编码代理提问。”
-
编码代理通过SQL查询与原始日志自主规划下一轮扫描，替代硬编码规则：过去扫描计划依赖固定规则（如文件多久未扫描、风险评分等），但Brian发现让编码代理直接访问数据库更为有效。代理能根据工程师在Slack上的提示，运行SQL查询找出应扫描的相似代码，必要时拉取原始跟踪记录诊断扫描问题，最终生成下一轮扫描提案供工程师确认。这体现了代理从被动执行规则转向主动数据驱动规划。
“我们之前的方式是有一套严格的规则。比如某个文件多少天没扫描过、风险评分是多少，就把它放进待办堆里。但我们发现，实际上只要让编码代理访问这个数据库就非常有效。”
“它会运行SQL查询来找出一些我们以前用硬编码规则处理的事情。必要时，它还会去拉取文件中的原始跟踪记录。”
-
代理通过blockers.yaml反馈环境阻塞，驱动测试框架与基础设施持续改进：除了规划扫描，代理还被用于改进测试框架本身。当运行出现问题时，代理可以拉取原始日志分析原因；Mozilla要求代理在遇到环境问题时写入blockers.yaml文件，而不是自行采取临时变通方案。这些反馈被摄入工作台后，团队能据此更新虚拟机镜像等基础设施，形成工具自我优化的机制。
“另一个简单例子就是改进测试框架本身。为什么有些运行会出现问题？去弄清楚。它可以拉取原始日志，去查看。”
“我们实际上会要求代理在遇到环境问题时写一个名为blockers.yaml的文件。比如它可能缺少运行测试所需的系统依赖。我们想给它一个直接告诉我们的出口，而不是尝试一些疯狂的变通办法。这些信息可以被摄入回工作台，然后我们就能知道，哦，我们需要更新虚拟机镜像来加入这个依赖。”
8. Pwn2Own等实战演练验证了AI辅助防御的有效性
-
Pwn2Own作为实战演练，为AI辅助防御提供了可控验证环境：Brian Grinstead将Pwn2Own描述为浏览器安全的年度“消防演习”，在可控环境中模拟真实漏洞被利用的场景。这种实战演练让Mozilla能够检验AI辅助发现和修复漏洞的实际效果，为后续的防御优势提供了验证基础。
“Pwn2Own是一项年度黑客竞赛，浏览器是首要目标之一。当然，每年我们都把它当作一次消防演习，模拟如果出现一个我们知道已被利用的真实安全关键漏洞会是什么情况，因为我们知道研究人员会来攻击Firefox。这是一个很好的受控环境，让我们可以练习应对。”
-
OpenAI团队赛前提交的漏洞被快速修复，直接导致多个攻击提交失效：在Pwn2Own前夕，OpenAI网络安全团队向Mozilla提交了若干漏洞，Mozilla迅速修复并推送更新。结果发现，不少参赛队伍的攻击提交正是利用了这些已被修复的漏洞，从而失效。这一连锁反应直接促成了无人攻破Firefox的结果，证明了AI辅助漏洞发现能转化为实际防御优势。
“我们这次取得了很好的结果，没有人能够攻破Firefox。其中部分原因在于，OpenAI网络安全团队在活动前不久提交了几个漏洞，我们修复并快速推送后，发现不少提交的攻击正是利用了那个确切的漏洞。”
-
不同模型能发现不同漏洞，即使代码已被多次扫描：Brian Grinstead指出，这次事件让团队意识到不同AI模型能够发现不同的漏洞，即便代码已经被反复扫描过。这意味着多模型协同的AI辅助防御可以覆盖单一工具遗漏的盲区，形成更全面的安全防护，从而在实战演练中体现优势。
“这让我们意识到，好吧，不同的模型会发现不同的漏洞，即使你已经多次扫描过代码。”
总结
AI代理确实把漏洞发现推向了规模化，但真正的竞争力不在于模型本身，而在于组织能否将长期安全积累转化为可复用的工具链与数据层。当发现量激增，瓶颈会迅速转移到分类、去重与修复环节，人机协作的深度决定了AI安全流水线能否从“找得多”走向“修得准”。
信息源
视频来源
- How Mozilla uses GPT-6 Cyber to find and fix Firefox vulnerabilities：
外部资料
- GPT‑6 Cyber: Advancing the frontier of aligned ...：
- OpenAI's GPT-6 Cyber found 81 Firefox flaws earlier AI ...：
- GPT-6 Cyber Firefox flaws: 81 findings reported：
- How Mozilla uses GPT-6 Cyber to find and fix Firefox ...：