Anthropic 开源「防御框架」：让 AI 发现自己的代码漏洞

2026年6月4日，Anthropic 在 GitHub 上发布了一个名为 defending-code-reference-harness 的开源框架。顾名思义，这是一个用于 AI 驱动漏洞发现的工具——让 AI 系统主动寻找代码中的安全缺陷。

消息发布当天，在 Hacker News 上获得了 221 个 upvotes，稳居当日热门榜首。这个数字在 HN 的 AI 相关话题中算得上现象级传播。

但热闹之外，这个框架到底能做什么？边界在哪里？中文互联网目前还没有详细的技术解读。本文的目标，就是把这件事说清楚。

这是什么东西

框架的核心定位

Anthropic 给这个项目的定位是 “AI-powered vulnerability discovery”（AI 驱动的漏洞发现）。它不是传统的静态代码分析工具（如 SonarQube、Semgrep），也不是通用的代码搜索引擎。它的核心能力是：利用大语言模型的推理能力，让 AI 主动探索代码库、识别潜在攻击面、生成漏洞假设、并通过自动化测试验证这些假设。

用一句话总结：让 AI 当自己的安全审计员。

技术原理（简化版）

根据 GitHub 仓库的描述，这个框架的工作流程大致分为三个阶段：

第一阶段：攻击面映射（Attack Surface Mapping）

框架首先会对代码库进行结构化扫描，识别出所有外部输入点——API 接口、文件 I/O、数据库查询、环境变量、用户上传内容等。这一步是传统工具也有的，但框架的优势在于它能理解每个输入点的上下文，识别出「这个参数理论上可以控制什么」。

第二阶段：漏洞假设生成（Hypothesis Generation）

这是核心环节。传统工具靠规则匹配（Rule-based），发现的是已知模式。框架用的是 LLM 的推理能力，给定攻击面信息后，让模型生成「这里可能有什么漏洞」的假设——包括注入类漏洞（SQLi、XSS、命令注入）、逻辑类漏洞（越权、竞争条件）、以及大模型特有的prompt注入风险。

第三阶段：自动化验证（Automated Verification）

生成的假设太多了，不可能全部人工审核。框架提供一个测试 harness，允许自动化生成针对每个假设的验证用例，然后用符号执行或模糊测试（Fuzzing）手段验证假设是否成立。

整个流程的关键创新点在于：它把 LLM 的推理能力和传统 Fuzzing 的验证能力做了一个闭环——LLM 生成假设，自动化工具验证假设，验证结果反过来又成为 LLM 的上下文输入，实现多轮迭代。

为什么现在发布

时间节点

选择在这个时间点发布，有几个值得注意的背景：

背景一：AI 代码生成的渗透率已经足够高

2026年，Claude Code、Github Copilot、Cursor 等工具已经被主流开发团队广泛使用。AI 生成代码的渗透率在硅谷一线公司已经超过 40%（Anthropic 内部数据，非公开）。代码生成普及的同时，生成代码的安全问题也开始显现——prompt注入、越权逻辑、训练数据污染等新型风险开始出现在真实攻击案例里。

背景二：开源安全社区需要新的工具范式

传统的代码安全工具（Semgrep、CodeQL）基于规则，发现的是已知漏洞模式。它们在面对「LLM 生成的、上下文感知的漏洞」时，表现明显下降——因为这类漏洞往往没有明显的语法特征，需要理解业务逻辑才能发现。

Anthropic 的赌注是：用 AI 的推理能力来对付 AI 生成代码带来的新问题。

与竞争产品的差异

目前市场上做 AI 安全测试的产品大致分为两类：

第一类：传统安全工具的 AI 增强版

比如 CodeQL 加入了 AI 辅助分析能力，本质还是规则引擎的底子，AI 起到辅助作用。这类工具的优势是成熟、覆盖广，但面对新型漏洞时仍然被动。

第二类：垂直 AI 安全公司

如 HiddenLayer、Securify AI 等，专注做 AI-specific 威胁（对抗样本、模型投毒、prompt注入）的检测。它们在特定场景下效果很好，但覆盖范围有限。

Anthropic 这个框架的差异化定位是：通用代码库 + LLM 推理 + 自动化验证的完整闭环。它的目标不是替代 CodeQL，而是补足传统工具在「上下文感知漏洞」上的短板。

限制与争议

能做到什么

客观说，这个框架在以下场景中表现出色：

• 攻击面清晰的中小型代码库：当代码库结构完整、输入点可以被自动化扫描时，框架能快速生成大量漏洞假设。
• API 安全测试：REST/GraphQL API 的参数注入测试。
• Prompt 注入识别：作为 LLM 原生厂商，Anthropic 对这类漏洞的理解深度是其他工具无法复制的。
• 漏洞假设优先级排序：框架会根据攻击面覆盖度和危害程度，对假设进行排序，让人工复核的效率大幅提升。

做不到什么

也需要清醒地列出边界：

做不到的事一：理解复杂业务逻辑

如果一个漏洞的根因在于「业务逻辑写错了」——比如一个电商系统里「用户能看到其他用户的订单」——这类漏洞没有语法特征，需要理解业务流程才能发现。框架在这种场景下表现一般。

做不到的事二：实时监控系统

这是一个离线的代码审计工具，不是 CI/CD 实时扫描工具。如果你想在每次 commit 时运行安全检测，这个框架不为此设计。

做不到的事三：替代人工安全审计

最终，这个框架的输出是「假设列表」，仍然需要人工审核来判断一个假设是否真的构成风险。安全审计员的价值反而被凸显了——他们不再需要从零开始找问题，而是专注于「判断问题是否真实存在」。

争议点：开源的动机

一个值得追问的问题是：Anthropic 开源这个工具，是否也是为了收集更多真实世界的漏洞样本，来反哺 Claude 的安全训练？Anthropic 没有明确回应这个推测。但从商业逻辑上说，可能性不低。

对开发者意味着什么

对于正在使用或考虑使用 AI 代码生成工具的团队，这个框架提供了几个明确的信号：

信号一：AI 安全将进入工具竞争的下半场

之前大家关注的是「AI 能不能写代码」，现在关注的是「AI 写的代码安不安全」。这个框架的出现，预示着 AI 安全工具赛道将迎来更多资本和人才。

信号二：安全审计的工作方式正在改变

传统安全审计依赖经验和对业务的深度理解。现在，审计员有了 AI 辅助工具，可以更高效地找到攻击面。但工具越强，对使用工具的人的要求也越高——你需要知道框架的边界在哪里，才能真正用好它。

信号三：开源的 AI 安全工具会越来越多

Anthropic 开源这个框架，降低了中小团队获取 AI 安全能力的门槛。接下来会看到更多大厂跟进开源 AI 安全工具，这是整个行业的基础设施升级。

结尾

Anthropic 的这个框架，核心价值不是「发现了多少漏洞」，而是一种新的安全审计范式：让 AI 生成假设，让机器验证假设，让人做最终判断。

这比「给 LLM 一个代码库让它找漏洞」要聪明得多——它把 LLM 的推理能力和自动化工具的执行能力做了分工，各自做自己最擅长的事。

对于普通开发者来说，现在最应该做的是：关注这个方向，但不要期望它能替代人工安全审计。把它放进你的工具箱，知道它的边界在哪里，这才是正确的使用方式。

下一步，HN 上另一个热帖「When AI Builds Itself: Our progress toward recursive self-improvement」也值得追踪——那是另一个维度的 AI 安全话题。

来源：Hacker News / GitHub (Anthropic)
发布日期：2026年6月4日