Anthropic 在 2026 年 10 月发布的研究中披露，Claude Opus 4.6 在无专用脚手架、无定制提示的条件下，于多个长期被模糊测试覆盖的开源项目中发现了高危内存破坏漏洞，并已发现并验证超过 500 个高危漏洞，部分漏洞潜伏数十年未被检出。这一事件的核心价值不在于“AI 会找漏洞”这一笼统判断，而在于它展示了一条可复用的 LLM 漏洞挖掘工作流，以及这条工作流在企业落地时必须面对的边界。

工作流拆解：沙箱、推理、验证、人工复核

Anthropic 的方法论可以拆成四个环节。第一，把 Claude 放进一个虚拟机沙箱，提供最新版本的开源项目、标准工具（coreutils、Python）以及调试器和模糊测试器等漏洞分析工具，但不提供任何关于如何使用这些工具的特殊指令，也不提供定制 harness。这意味着测试的是模型的“开箱即用”能力，依赖的是现代大模型作为通用智能体自行推理工具使用方式的能力。

第二，聚焦内存破坏类漏洞。官方给出的理由是这类漏洞相对容易验证：程序崩溃可被监控，address sanitizer 可捕获不崩溃的内存错误。相比之下，逻辑错误不会导致程序失效，验证成本更高。这一选择体现了工程上的取舍——先做可自动验证的漏洞类别，把误报控制建立在可观测信号上。

第三，对崩溃结果做二次筛选。并非所有导致崩溃的输入都是高危漏洞，因此 Claude 会对剩余崩溃进行批判、去重和重新定级。第四，人工验证与补丁编写。初期由 Anthropic 自身安全研究员逐个验证并手写补丁；随着发现量增长，引入外部人类安全研究员协助验证和补丁开发。官方明确表示，这一流程优化目标是减少误报，以便真正帮助维护者处理报告。

三个案例揭示的 LLM 优势

GhostScript 案例中，Claude 先尝试模糊测试和人工分析均未取得显著发现，随后转向阅读 Git 提交历史，快速定位一个安全相关提交，理解改动内容后，再查找该函数在其他调用点的类似未修复漏洞，并构造出可导致崩溃的 PoC 文件。这条路径的关键是“从历史修复中推断同类缺陷”，而非随机输入。

OpenSC 案例中，Claude 在模糊测试和人工分析失败后，改为搜索仓库中频繁出现漏洞的函数调用，识别出连续使用 strcat 的位置。官方指出，该行代码因前置条件多而被传统模糊测试器低频覆盖，而 Claude 能推理哪些代码片段值得关注，把精力集中在高价值位置，而不是对所有代码行平均用力。

CGIF 案例更能说明验证能力。该库假设压缩数据总小于原始数据，而 GIF 使用 LZW 压缩，LZW 维护固定大小符号表，当符号表被填满时会插入特殊“clear”令牌，导致“压缩”后尺寸超过未压缩尺寸，从而触发缓冲区溢出。官方强调，即使 CGIF 达到 100% 行覆盖和分支覆盖，该漏洞仍可能未被发现，因为它需要非常特定的操作序列。传统覆盖率引导的模糊测试器难以触发这类需要概念理解的缺陷。

与 SAST、模糊测试的关系：互补而非替代

从官方描述看，LLM 审计的定位是叠加在现有发现工具之上。模糊测试通过大量随机输入观察崩溃，SAST 通过规则匹配代码模式，而 Claude 的路径是阅读和推理代码：查看历史修复找同类未修复缺陷、识别易出问题的模式、理解逻辑以构造精确输入。三者覆盖的缺陷空间不同：模糊测试擅长高频执行路径上的崩溃，SAST 擅长已知规则模式，LLM 擅长需要跨文件语义理解和特定分支序列的缺陷。企业不应把 LLM 审计当作 SAST 或模糊测试的替代品，而应把它放在“高价值目标定向深挖”的位置。

企业落地的边界与风险

第一，误报控制是流程问题，不是模型问题。Anthropic 的做法是先用可观测信号（崩溃、sanitizer）收敛候选，再由模型去重定级，最后人工验证。企业若直接把模型输出推给开发团队，误报会迅速消耗信任。建议把“模型初筛—可复现 PoC—人工确认”作为强制门禁。

第二，修复接入需要自动化补丁能力。官方坦言，初期补丁由人类研究员手写，随着发现量增长引入外部研究员，同时正在加速补丁开发自动化。企业落地时，发现漏洞只是起点，补丁生成、回归测试和 CI 集成才是闭环。LLM 发现的漏洞若不能进入既有修复流程，只会制造积压。

第三，披露节奏面临压力。官方指出，行业标准的 90 天披露窗口可能无法承受 LLM 发现漏洞的速度和数量，行业需要能跟上节奏的工作流。企业应提前与维护方约定分级响应机制，避免批量报告压垮小型维护团队。

第四，双用途风险需要检测层。Anthropic 随 Opus 4.6 引入了针对网络滥用的探针，通过测量模型生成过程中的激活来大规模检测特定危害，并更新执法流程，可能对判定为恶意的流量实施实时阻断。官方也承认这会给合法研究和部分防御工作带来摩擦。企业使用同类能力时，需在内部建立使用审计和权限边界，防止漏洞挖掘能力被用于攻击面侦察。

可执行建议

把 LLM 审计限定在已有模糊测试覆盖但长期无新发现的项目上，优先内存破坏类漏洞；为模型提供沙箱、调试器和 sanitizer，但不给定制提示，观察其自主工具使用能力；要求每个候选漏洞附带可复现 PoC 和崩溃日志；把模型输出接入人工复核队列而非直接建单；同步建设补丁自动生成与回归测试能力；对披露流程做压力测试，预设批量报告的降级策略。LLM 发现 0-day 已不是假设，企业现在需要决定的是把它放在工作流的哪个位置，以及用什么门禁控制它的输出。