Anthropic 开源 AI 驱动漏洞发现框架

一个用于自主漏洞发现与修复的参考实现，基于 Claude 构建，源自我们自发布 Claude Mythos Preview 以来与多家组织的安全团队合作所积累的经验。关于这些经验以及最佳实践的详细阐述，请参阅配套博客文章（也可在blog-post.md中获取）。关于同一套侦察 → 发现 → 分诊 → 报告 → 修补循环的轻量级纯 SDK 演练，请参阅配套 cookbook。

本仓库不再维护，也不接受贡献。

🔒 想要托管方案？ Anthropic 提供 Claude Security，这是一款托管产品，可跨多个项目发现并修复源代码中的漏洞。Claude Security 会扫描你的代码仓库以查找漏洞，应用多阶段验证流水线以降低误报，并让你在整个生命周期中管理发现的问题：分诊、修复验证以及快速生成修复方案。

本仓库是一个开源参考实现，基于使用 Claude 查找漏洞的通用最佳实践。你可以用它构建自己的漏洞查找流水线、自定义逻辑，并且它可以配合你拥有的任何 Claude API 访问方式使用（包括 Bedrock、Vertex 或 Azure）。

Claude Code 技能：/quickstart、/threat-model、/vuln-scan、/triage、/patch、/customize：交互式范围界定、扫描、分类和修补。在 Claude Code 中打开此仓库并运行 /quickstart 以快速上手。
harness/：自主参考流水线（侦察 → 发现 → 验证 → 报告 → 修补），配置为使用 Docker 和 ASAN 查找 C/C++ 内存漏洞。此框架是一个参考，而非产品。其整体形态、提示词和沙箱机制可复用，但该框架无法开箱即用地适用于所有代码库。运行 /customize 将其移植到你的语言、检测器或漏洞类别。
检测与响应：/dnr-hunt 和 /dnr-respond 技能，加上 dnr_harness/（它们的自主镜像版本 dnr-pipeline）。此仓库中的其他一切内容都是预防性的；这条路线假设攻击者已经出现在日志中——搜寻语料、界定损害范围并提出响应方案。演示目标：targets/dnrcanary/。参见 docs/detection-response.md。

⚠️ 安全： /quickstart, /threat-model, /vuln-scan，以及/triage仅读取和写入文件。运行/patch针对静态发现（TRIAGE.json或VULN-FINDINGS.json）同样仅限读取和写入。/customize编辑 harness 代码并运行验证命令。只要你在 Claude Code 中审查并批准每次工具使用，这些技能都可以在非沙箱环境中安全运行。自主流水线（vuln-pipeline, dnr-pipeline，以及/patch针对流水线结果）执行目标代码，因此除非显式覆盖，否则它们拒绝在 gVisor 沙箱之外运行。要进行设置，请运行scripts/setup_sandbox.sh一次，然后通过bin/vp-sandboxed调用流水线。检测与响应技能（/dnr-hunt, /dnr-respond）还会在127.0.0.1上运行演示应用以验证 PoC。参见docs/security.md以及docs/agent-sandbox.md了解更多详情。

快速上手

git clone https://github.com/anthropics/defending-code-reference-harness
cd defending-code-reference-harness
claude

# 30-sec intro + guided first run on the canary target
> /quickstart

> /quickstart how do I port the pipeline to Java?
> /quickstart how do I triage all these bugs?

加速推进

与我们合作过的最成功的安全团队，都是那些最快上手实践的团队。尽管花几个月时间设计完美的流水线很诱人，但我们建议从第 1 天开始小步起步，随着不断积累经验再逐步扩展。以下步骤遵循这一模式，并根据我们所见到的实际情况设定了一个雄心勃勃（但合理）的节奏。


第 1 步	第 1 天	构建威胁模型，并运行你的首次静态扫描 + 分诊
第 2 步	第 2 天	在一个 C/C++ 库上运行参考流水线
第 3 步	第 3-5 天	针对你的目标定制流水线
第 4 步	第 2 周	启动自主扫描、分诊与修补
第 5 步	可选	在日志中追踪一次植入的攻击活动（检测与响应）

第 1 步（第 1 天）：构建威胁模型，并运行你的第一次静态扫描 + 分诊

第 1 天的重点是端到端地看清整个闭环。仅使用交互式技能，你将构建一个威胁模型，按其范围运行一次静态扫描，对返回的结果进行分诊，并起草候选修复方案。当天结束时，你将得到一个威胁模型、一份按优先级排序的静态发现列表，以及候选补丁。

相关技能只读写文件，且仅限于你的代码仓库内。只要你以交互方式运行 Claude Code 并逐项批准每次工具调用，就无需沙箱。

# Pin every subagent to the model you want
export CLAUDE_CODE_SUBAGENT_MODEL=<model-id>
claude

# 0. intro + guided first run
> /quickstart

# 1. Build a threat model (aim before you shoot)
> /threat-model bootstrap targets/canary

# 2. Run a static scan, scoped by that threat model
> /vuln-scan targets/canary

# 3. Verify, dedupe, and rank what came back
> /triage targets/canary/VULN-FINDINGS.json

# 4. Generate candidate fixes for the verified findings
> /patch ./TRIAGE.json --repo targets/canary

此流程会生成 THREAT_MODEL.md、VULN-FINDINGS.{json,md}、TRIAGE.{json,md} 和 PATCHES/。

第 1 步中产生的漏洞候选来自 Claude 对源代码的静态审查（不构建、不运行任何东西），因此在任何非金丝雀目标上，预计会有更多误报。在第 2 步中，你将产生经执行验证的发现。

注意：在 canary 目标上，/triage可能会将扫描结果视为误报而不予理会。entry.c会自我声明为故意存在漏洞的演示代码，而/triage会正确地排除测试 / fixture 代码中的缺陷。要查看完整的确认 / 去重 / 误报流程，请在精心准备的 fixture 上运行它（/triage .claude/skills/triage/fixtures/canary-findings.json --repo targets/canary），或者将 Step 1 的技能指向你自己的代码。

Step 2（第 2 天）：在 C/C++ 库上运行参考流水线

在第 2 天，你将从业交互式技能转向使用参考流水线的首次自主运行。你将在自己的环境中，对一个已知存在漏洞的开源库运行完整的 recon → find → verify → report 循环，然后针对其发现生成候选补丁。你最终将得到一组可复现的崩溃、可利用性报告和候选补丁，并对该流水线的工作方式有所体会。

运行该流水线很简单：

# One-time setup
python3 -m venv .venv && .venv/bin/pip install -e .
./scripts/setup_sandbox.sh   # installs gVisor, builds the agent images, and verifies isolation; note: requires Docker
export ANTHROPIC_API_KEY=sk-ant-...   # or CLAUDE_CODE_OAUTH_TOKEN, or Bedrock — see docs/agent-sandbox.md

# Run the recon → find → verify → report loop
bin/vp-sandboxed run drlibs --model <model-id> --runs 3 --parallel --stream --auto-focus
# Generate a candidate patch for each finding
bin/vp-sandboxed patch results/drlibs/<timestamp>/ --model <model-id>

# Or, ask Claude Code to launch the pipeline and watch the run for you
claude
> run the pipeline on drlibs and explain findings as they come

该循环的结果会落在 results/drlibs/<timestamp>/ 目录中。使用 --stream 标志时，第一份报告将在几分钟内出现在 reports/bug_NN/ 下。

⚠️ run 会生成自主智能体。该流水线会在 gVisor 容器内运行每个智能体，出站流量被限制为仅可访问 Claude API。生成智能体的子命令在该容器之外会拒绝启动，除非显式覆盖。更多信息请参见 docs/security.md 和 docs/agent-sandbox.md。

在底层，该流水线会经历七个阶段：

构建：将目标编译为带有 ASAN（C 和 C++ 的内存错误检测器）的 Docker 镜像。流水线会在首次运行时使用目标的 Dockerfile 自动构建该镜像。
侦察：一个轻量级智能体在网络隔离的容器内读取源代码，并提出一种划分方案，即“这里有 N 个值得分别攻击的独立输入解析子系统”，这样并行的查找智能体就能探索不同的区域，而不是都收敛到同一个 bug 上。如果没有--auto-focus标志，流水线会使用来自目标focus_areas列表config.yaml.
查找：N 个智能体并行运行，每个都在自己独立的容器中。每个智能体读取源代码，构造畸形输入，并运行 ASAN 二进制文件，直到某个给定输入在 3 次运行中有 3 次产生崩溃。
验证：一个独立的评分智能体在一个全新的、查找智能体未曾接触过的容器中复现每个崩溃。从查找智能体传递到评分智能体的唯一内容，就是它生成的概念验证。
去重：一个评判智能体将已验证的崩溃与已报告的缺陷进行比对，并判定每一个是新缺陷、已知缺陷的更好示例，还是应当跳过的重复项。
报告：报告智能体会针对每个唯一 bug 编写一份结构化的可利用性分析，包括原语类别、可达性、提权路径和严重程度等细节。
补丁（上方单独的 patch 命令）：补丁智能体会编写一份建议修复方案，评分智能体则确认新代码能够构建、原始的概念验证输入不再导致崩溃、目标的测试套件仍然通过，并且一个新的发现智能体无法找到绕过该修复的方法。

更多详情，请参阅 docs/pipeline.md。

第 3 步（第 3-5 天）：为你的目标定制流水线

在第 3-5 天，你将针对自己的目标定制这套 harness。首先，你会将第 1 步的技能指向你的代码，然后使用 /customize 将流水线移植到你的技术栈。到本周末，你将拥有一个流水线可以运行的 targets/<your-service>/ 目录，通过一次流水线冒烟运行完成验证，并准备好在第 4 步中扩大规模。

虽然参考流水线是为在 C 和 C++ 代码中查找内存漏洞而设计的，但它的形态是通用的。将其移植到新的漏洞类别或语言，只需针对你的目标技术栈回答以下问题：

问题	C/C++ 参考	你的目标（示例）
什么信号表明发现了一个漏洞？	ASAN 崩溃签名	异常 / canary 文件 / DNS 回调
概念验证是什么样的？	导致崩溃的输入文件	HTTP 请求序列 / tx 列表 / 测试框架
目标是如何构建和运行的？	`Dockerfile`（使用 clang + ASAN）	你的语言在容器中的构建方式

在自定义之前，将 Step 1 技能指向你自己的代码。提醒一下，它们只有读取和写入权限，因此可以在非沙箱环境中运行。

claude

> /quickstart how do I customize this for ~/code/my-service?

> /threat-model bootstrap-then-interview ~/code/my-service
> /vuln-scan ~/code/my-service
> /triage ~/code/my-service/VULN-FINDINGS.json --repo ~/code/my-service

然后，将这些技能产出的工件用于 /customize 技能中，该技能会针对你的代码库修改测试框架。

> /customize use ~/code/my-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md

当 /customize 完成后，你将拥有一个配置好的 targets/my-service/ 目录。在扩大规模之前，先用一次流水线的冒烟运行来验证它。

bin/vp-sandboxed run my-service --model <model-id> --runs 1

更多详情，请参阅 docs/customizing.md。

Step 4（第 2 周）：开始自主扫描、分类和修补

在第 2 周，你将在自己的目标上使用第 3 步中定制的流水线，为内层流水线循环添加一个外层循环——运行多次流水线扫描，对来自这些运行的发现进行分诊，根据优先级进行修补，然后重复。

# Scan - run a wave of parallel runs against your target
bin/vp-sandboxed run my-service --model <model-id> --runs 5 --parallel --stream --auto-focus

# Triage - dedupe and rank every finding across all waves using your threat model
> /triage results/my-service/ --repo ~/code/my-service --auto --votes 5

# Patch - generate and validate fixes, starting with what triage ranked the highest
> /patch results/my-service/<timestamp>/ --model <model-id>

⚠️ 遵循与第 2 步相同的沙箱隔离准则

一次给定的流水线运行已经会验证并去重其自身的发现。/triage可跨多次流水线运行工作。当指向results/目录时，它会合并所有运行中的重复项（以及来自/vuln-scan的任何静态发现，如果存在的话），根据你的威胁模型重新校准严重性评级，并尝试将每个发现路由到组件负责人。

在可能的情况下，快速修补发现有助于让外层循环尽可能高效。当发现被修复后，模型就无法再次找到它们，转而会浮现出全新的、通常更深层的问题。随着你运行更多轮流水线，发现的数量可能会下降，但复杂度可能也会上升。如果无法快速修补，即使只是将先前的发现记录在目标的known_bugs中，也能帮助引导未来的运行去关注更新的漏洞。

自主分诊和修补仍是未解决的问题，这个参考测试框架并未完全解决它们。/patch中的验证策略有助于提高门槛，但严重性和优先级最终是关于你的环境的判断，而且经过验证的补丁并不总是能向上游提交。许多合作伙伴报告称这些步骤是他们当前的瓶颈，你应该为它们预留真正的工程时间。

更多详情，请参阅 docs/triage.md 和 docs/patching.md。

第 5 步（可选）：检测与响应

以上所有内容都是关于在攻击者之前发现漏洞。检测与响应这条路线则是一个示例，展示当攻击者已经进入你的系统并出现在日志中时，你可以如何使用 Claude：找到他们、评估损害范围，并提出响应方案。

演示目标是 targets/dnrcanary，一个故意留有漏洞的 Web 应用，其中隐藏着一场精心植入的攻击活动，藏在一周生成的日志里。

pip install flask pyyaml               # flask runs the app; pyyaml runs the grader
python3 targets/dnrcanary/generate_logs.py --seed 42   # required first — logs are local-only

> /dnr-hunt                       # no alert in hand: hunt the corpus
> /dnr-respond INC-1              # lead in hand: verdict, blast radius, proposed plan
python3 targets/dnrcanary/grade.py results/dnrcanary/<ts>/INCIDENTS.json   # self-score against ground truth

同样的练习也可以无人值守运行，这与 vuln-pipeline 对应交互式扫描技能的方式一致：

bin/vp-sandboxed dnr-pipeline run targets/dnrcanary --model <model-id>

已确认的漏洞会流入与静态路线相同的 /triage → /patch 循环。

→ 深入了解：docs/detection-response.md

展望未来

在最初的推进之后，与我们合作过的团队往往会在几个方向上投入：

审查他们所有的内部仓库和关键开源依赖项，对哪些是最需要扫描的进行排序（例如，基于其暴露程度、CVE 历史、业务关键性），然后按优先级顺序逐一扫描该列表。
搭建专门用于扫描的基础设施，把扫描任务从笔记本电脑或一次性虚拟机上迁移出来。最成功的团队会克制住先构建完美扫描平台再扩大规模的冲动。
将扫描纳入其 SDLC。一些团队已经设置了定期扫描（例如每天、每周），或者将扫描加入其 CI 流水线。
对模型进行测试和实验，以找出最适合他们的方案。