Anthropic 红队发现 Firefox 漏洞：Agent 驱动的安全测试揭示了自动化漏洞发现的什么

Others 2026-08-24 11:28:33 4

最近折腾了大模型驱动的安全测试，踩了几个坑，这篇把 Mozilla 和 Anthropic 这次合作说清楚。

Mozilla 的 MFSA2026-13 安全公告列出了 14 个高危 Firefox 漏洞，归功于"Anthropic 的 Claude"。这几乎占了 2025 年所有 Firefox 高危 bug 的 20%，而这些漏洞是大模型在两周内发现的。这不是 Demo，是生产级别的 Agent 驱动安全研究，在全球防护最严密的代码库之一里挖出了真实的 CVE。

有意思的不是 AI 找到了 bug，而是 Anthropic 怎么搭建验证流水线、决定上报什么、以及如何在不往 Mozilla 的 bug 追踪器里灌假漏洞的情况下把结果移交给他们。

为什么 Firefox 是个硬骨头

Anthropic 选择 Firefox 因为它代码复杂、经过大量审计、服务数亿用户。浏览器是高价值目标，需要持续解析不可信内容，渲染引擎里的内存安全问题可能导致远程代码执行。

Firefox 已经有了：

持续模糊测试基础设施（OSS-Fuzz、libFuzzer）
静态分析工具（Clang Static Analyzer、Coverity）
专门的安全团队审查每个补丁
几十年的 CVE 历史可供参考

如果 Agent 能在这里发现新 bug，这说明基于 LLM 的安全研究不只是玩具项目，是真能 scale 的。

Agent 架构

Anthropic 的方案把 LLM 推理和传统安全工具结合起来。Agent 不是光读代码瞎猜，而是编排一个多步骤工作流：

假设生成：Claude 分析 Firefox 源码和历史 CVE，识别攻击面（IPC 边界、解析器逻辑、内存管理模式）。
静态分析集成：Agent 使用现有工具（grep、AST 解析器、控制流图）缩小候选函数范围。
漏洞利用构造：Claude 编写概念验证代码来触发疑似漏洞。
验证循环：PoC 在沙箱化的 Firefox 构建版本中运行。如果触发崩溃或 ASAN，Agent 迭代优化漏洞利用代码。
报告生成：只有经过验证的发现才会提交给 Mozilla，附带堆栈跟踪、重现步骤和严重性评估。

关键洞察是 LLM 不需要不安全的执行权限。它生成假设和 PoC 代码，但验证发生在有内存清理工具和崩溃报告的受控环境中。

验证流水线与误报过滤

Agent 驱动安全研究最大的运营挑战是防止幻觉浪费人工时间。如果 Claude 生成了 1000 个潜在漏洞利用代码但 990 个是误报，安全团队就不会再关注了。

Anthropic 的过滤策略：

自动化分类：只有包含确认崩溃、ASAN 违规或异常行为的报告才会进入人工审核。
严重性评分：Agent 按可利用性（内存损坏 vs 逻辑漏洞）和攻击面（远程 vs 本地）对发现进行分类。
去重：对比新发现与已知 CVE 和现有 bug 报告，避免重复提交。

Mozilla 在这里扮演了关键角色。他们帮助 Anthropic 校准什么才算得上可上报的 bug。合作早期，Agent 可能提交了技术正确但不可利用或已知的发现。反馈循环收紧了过滤条件。

攻击面优先级

Agent 如何决定去哪里找？Anthropic 综合使用了：

历史 CVE 模式：Firefox 有公开的 CVE 数据库。Agent 分析过去漏洞找出反复出现的模式（DOM 处理中的 use-after-free、图片解码器中的整数溢出）。
静态分析输出：Clang 的 AddressSanitizer 和 UndefinedBehaviorSanitizer 等工具标记可疑代码路径。Agent 用这些作为起点。
LLM 生成的假设：Claude 根据代码复杂度、外部输入处理和权限边界提出攻击面。

这不是随机 fuzzing。Agent 推理出 bug 可能藏在哪里，然后用具体漏洞利用代码验证这些假设。

对比：Agent 驱动 vs 传统安全测试

方法	速度	覆盖率	误报率	人力投入
人工代码审计	慢	定向	低	高
Fuzzing（AFL、libFuzzer）	快	广但浅	中	低（设置）、高（分类）
静态分析（Coverity）	中	广	高	高（分类）
Agent 驱动（Claude）	快	定向且深入	中（带过滤）	中（校准、分类）

Agent 结合了 fuzzing 的速度和人工审计的推理能力。它能读代码、理解上下文、构造传统 fuzzer 漏掉的漏洞利用代码（逻辑漏洞、竞态条件、复杂状态机）。

部署形态与可观测性

Anthropic 的红队 Agent 运行在循环中：

# Simplified agent loop for security research
def security_agent_loop(codebase, known_cves): while True: # Step 1: Generate hypothesis
 hypothesis = claude.analyze( codebase=codebase, historical_cves=known_cves, prompt="Identify high-risk attack surfaces" ) # Step 2: Construct PoC
 poc_code = claude.generate_exploit(hypothesis) # Step 3: Validate in sandbox
 result = run_in_sandbox( target="firefox", poc=poc_code, sanitizers=["asan", "ubsan"], timeout=30 ) # Step 4: Filter and report
 if result.crash or result.sanitizer_violation: severity = claude.assess_severity(result) if severity >= REPORTABLE_THRESHOLD: submit_bug_report( vendor="mozilla", finding=result, severity=severity ) # Step 5: Learn from feedback
 known_cves.append(result)

关键可观测性钩子：

假设日志：跟踪 Agent 探索了哪些攻击面以及原因。
PoC 成功率：衡量生成的漏洞利用代码中有多少真正触发了 bug。
分类耗时：监控 Mozilla 确认或驳回发现需要多长时间（校准的反馈信号）。
重复检测：统计 Agent 重新发现已知问题的频率。

失败模式与缓解措施

Agent 驱动的安全研究有可预见的失败模式：

幻觉漏洞利用：LLM 生成了听起来合理但实际不工作的 PoC 代码。
- 缓解：要求自动化验证（崩溃、清理工具违规）才能进入人工审核。
过度上报低危 bug：Agent 向 bug 追踪器灌入大量小问题。
- 缓解：根据供应商反馈调优严重性阈值。
漏掉复杂漏洞：Agent 聚焦于明显模式，漏掉微妙的逻辑漏洞。
- 缓解：结合传统 fuzzing 和人工审计。Agent 是增强，不是替代人类研究员。
沙箱逃逸：如果 Agent 有执行权限，恶意提示词可能利用研究基础设施。
- 缓解：严格沙箱化、只读源码访问、PoC 执行环境无网络访问。

这对安全基础设施意味着什么

如果 Agent 能在 Firefox 里找到高危 bug，它们也能在你的代码库里找到。运营层面的问题是如何把 Agent 驱动的测试集成到现有 CI/CD 流水线中。

实际部署选项：

Pre-commit 钩子：在每个 PR 上运行 Agent，在代码审查前捕获明显漏洞。
夜间安全扫描：指向主分支，生成每日潜在问题报告。
漏洞奖励计划增强：用 Agent 预筛选提交，或在外部研究员之前发现 bug。

成本模型不同于传统安全测试。Fuzzing 便宜（CPU 时间）但噪音大。人工审计贵（人工时间）但精确。Agent 驱动的测试处于中间：中等成本（LLM API 调用、沙箱基础设施），校准后信噪比高。

技术结论

适合使用 Agent 驱动的安全测试：

有大型复杂代码库，存在已知攻击面。
能承受校准期（预期 2-4 周调优误报过滤器）。
有自动化验证基础设施（清理工具、崩溃报告、沙箱）。
安全团队能提供反馈以提高 Agent 准确度。

不适合的场景：

代码库小或简单（人工审计更快）。
缺乏自动化测试基础设施（Agent 需要验证循环）。
无法容忍任何误报（Agent 输出仍需人工分类）。
威胁模型不优先考虑漏洞发现（先关注其他安全控制）。

Firefox 合作证明了 Agent 能做真实的安全工作，不只是生成代码。工程实现才是关键：验证循环、严重性评分和供应商反馈决定了这是有用的工具还是吵闹的实验。