当你的Agent发现了一个安全漏洞

Anthropic研究科学家Nicholas Carlini将Claude Code对准Linux内核源码，让它寻找漏洞。整个配置极为简单：一个10行bash脚本加上一个带ASAN插桩构建的Docker容器。逐个遍历源文件，让模型查找bug，然后处理下一个文件。¹³

Michael Lynch在其演讲报告中详述了结果：²一个存在于NFSv4 LOCK重放缓存中的远程可利用堆缓冲区溢出，自2003年3月起便已存在——比Git本身还早。两个协作的NFS客户端可以通过用1,024字节的锁所有者ID溢出112字节的缓冲区来读取敏感内核内存。Carlini在同一轮扫描中至少又发现了四个内核漏洞。此外，同样的方法产生了122个发送给Mozilla的崩溃输入，其中22个获得了CVE编号。³他提到还有”数百个崩溃”尚未来得及验证和报告。²

这些都是已确认并报告给维护者的漏洞，由使用Opus 4.6的Agent发现——与开发者日常用于代码审查、重构和功能开发的同一模型系列。Carlini于2026年4月在[un]prompted AI安全会议上发表了这些研究成果。¹

摘要

Carlini的方法极其精简：遍历源文件，提示Claude在每个文件中查找漏洞，用ASAN断言验证命中结果。Opus 4.6发现的漏洞数量远超Opus 4.1（早8个月发布）和Sonnet 4.5（早6个月发布），表明某个能力阈值在近期被突破。²现在的瓶颈是人工验证，而非AI发现。这对从业者构建安全钩子、执行代码审查以及思考Agent辅助审计都有直接影响。

核心要点

• 安全工程师：这种能力是真实的，而且在快速提升。如果你正在使用Agent辅助代码审查，你的PreToolUse安全钩子比以往更加重要——不是为了阻止Claude，而是为了控制它在发现问题后能做什么。
• 工具架构构建者：验证瓶颈（”数百个崩溃我还没来得及验证”）是一个架构问题。自动化分类、去重和严重性分级是下一层基础设施。
• 其他所有人：同一个模型既会引入446倍的性能退化，也能找到人类审查23年都遗漏的bug。两者同时为真。

方法论

Carlini的方法不需要定制安全框架、微调模型或专门的提示词。他将其描述为”一个10行bash脚本加Docker容器”：³

1. 使用ASAN（AddressSanitizer）插桩编译目标程序
2. 遍历源文件，利用模型评估安全相关性
3. 对高相关性文件，以夺旗赛（capture-the-flag）的框架向Claude Code提问
4. 对每个目标执行多轮扫描（5-20轮，视代码库而定）
5. 使用自动化评审Agent在披露前验证发现

夺旗赛框架至关重要。告诉模型”这段代码有一个bug”与”审查这段代码是否有问题”激活的是完全不同的模式。开发者在日常使用中也注意到了同样的规律——当你告诉Claude问题确实存在时，它比你询问是否可能存在问题时能发现更多bug。²

这轮扫描的成本以API token计量，而非以人月计。Carlini使用一个普通的Agent CLI发现了五个已确认的Linux内核漏洞和22个Firefox CVE。³与编写单元测试和格式化导入语句的是同一个工具。

能力阈值

最引人注目的发现是模型代际差距。Carlini尝试用更早期的模型重现结果：²

• Opus 4.6（演讲前约2个月发布）：发现了堆溢出漏洞及多个其他漏洞
• Opus 4.1（早8个月）：仅发现极少量漏洞
• Sonnet 4.5（早6个月）：仅发现极少量漏洞

在模型迭代之间，某个阈值被跨越了。在上下文中保持对复杂代码库的理解、跨函数边界推理数据流、识别细微的规范不匹配——这种能力似乎是突然涌现的，而非逐步提升。

Carlini坦言：”我这辈子从没找到过这种漏洞。这件事非常、非常、非常难做到。但有了这些语言模型，我手头有一大堆。”²

悖论

同一个Agent架构既会引入性能退化——118个函数出现3倍到446倍的减速——也能发现数十年专家人工审查都遗漏的安全漏洞。这是同一能力特征的互补方面。漏洞研究本质上是针对已知类别（缓冲区溢出、释放后使用、整数符号性问题）的模式匹配，恰好是LLM的强项。⁴性能优化则恰恰相反：需要推理特定的执行上下文、缓存行为和算法复杂度。模型能在数百万行代码中识别出缓冲区溢出，却无法判断在你的访问模式下哈希表是否比排序数组更慢。相应地设计你的工具架构——用安全钩子标记发现，用性能钩子在提交前度量。

验证瓶颈

Carlini最发人深省的坦白：”我在Linux内核中发现了太多bug，因为还没验证完所以无法报告。”²

瓶颈已经从发现转移到了分类。找到潜在漏洞现在比确认其真实性更便宜。这为安全团队带来了新的基础设施挑战：

发现已经自动化。Agent可以在数小时内扫描整个代码库。

验证仍然是手动的。每个潜在漏洞都需要概念验证、影响评估和负责任的披露流程。

分类是缺口所在。将数百个Agent生成的发现分为真实漏洞、误报和低严重性噪音——这项工作目前还缺乏好的工具支持。

这与我们在Agent辅助代码审查中看到的模式一致：Agent产出原始结果的速度远超人类评估的速度。价值不在于生成本身，而在于处理、过滤和分发输出的基础设施。

对工具架构构建者而言，下一个高价值钩子不是安全扫描器，而是安全分类系统：去重、严重性分级、误报过滤和自动概念验证生成。治理钩子对Agent输出的把关比扫描能力本身更为重要。

对从业者的启示

如果你在生产代码库上运行Claude Code，你已经在运行一个能够发现真实漏洞的系统。问题不在于这种能力是否存在，而在于你的工具架构是否为处理Agent的发现做好了准备。

三个切实可行的举措：

在审查流程中加入安全扫描。在Write/Edit上设置PostToolUse钩子，可以对变更文件触发针对性安全扫描。钩子从stdin读取文件路径（Claude Code通过stdin将事件JSON传递给钩子）：

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking — runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

这只是起点，并非生产就绪——你还需要添加去重、严重性过滤和速率限制。但核心模式与Carlini的方法一致：循环遍历文件配合针对性提示。³

构建分类基础设施。没有严重性分级的原始漏洞发现只是噪音。如果你的Agent每轮扫描产出50个发现，你需要自动去重和优先级评分，然后才能呈现给人工审阅。这是一个架构问题，不是模型问题。

接受这个悖论。同一个需要性能护栏的模型，在安全模式匹配方面确实出色。设计你的工具架构，既要发挥其优势，也要弥补其不足。安全钩子负责扫描，性能钩子负责度量，质量钩子负责验证。各司其职，互相补位。

那个23年前的Linux漏洞并非隐藏得很深。它就在那里，明明白白，在一个数千名工程师都读过的文件中。模型发现它，是因为大规模模式匹配正是这类系统的专长。这里的教训不是Agent在安全方面优于人类。教训是Agent覆盖的是不同的面——而协调两者的工具架构才是使这种组合可靠的关键。

参考来源

常见问题

我能用Claude Code重现Carlini的方法吗？

该方法论已在播客访谈中详细记录。³核心循环：用ASAN编译，遍历源文件，以夺旗赛框架向Claude提问，验证命中结果。Carlini报告称Opus 4.6发现的漏洞数量远超早期模型——使用其他代际模型的结果可能有所不同。

这是否意味着AI Agent在发现安全漏洞方面优于人类？

并非如此。这意味着Agent覆盖的是不同的面。Agent擅长在大型代码库中针对已知漏洞类别进行模式匹配。人类擅长理解新型攻击向量、业务逻辑缺陷和依赖上下文的安全属性。两者结合比任何一方单独使用都更强大。

我是否应该担心攻击者利用这种能力？

Carlini明确警告”一场大浪即将到来”。帮助防御者发现漏洞的同一种能力，攻击者同样可以使用。不对称之处在于：防御者可以自动化分类和修补流程，而攻击者仍需开发利用代码——但发现能力的差距正在缩小。