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

标题：GitHub - anthropics/defending-code-reference-harness：威胁建模、扫描、分诊、补丁修复技能，以及一个可 /customize 的自主扫描框架

URL 来源：https://github.com/anthropics/defending-code-reference-harness

Markdown 内容： 这是一个使用 Claude 进行自主漏洞发现与修复的参考实现，基于我们自发布 Claude Mythos Preview 以来与多家机构安全团队合作所积累的经验。有关这些经验总结及最佳实践的详细说明，请参阅配套博客文章（也可在 `blog-post.md` 中查看）。如需仅使用 SDK 的轻量级演练，体验相同的“侦察 → 发现 → 分诊 → 报告 → 补丁”循环，请参阅配套 Cookbook。

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

🔒 需要托管方案？ Anthropic 提供 Claude Security，这是一款托管产品，可在多个项目中查找并修复源代码中的漏洞。Claude Security 会扫描您的代码仓库以检测漏洞，应用多阶段验证流水线以减少误报，并允许您在整个生命周期内管理发现的问题：包括分诊、修复验证和快速生成修复补丁。

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

目录

[](https://github.com/anthropics/defending-code-reference-harness#contents)

• Claude Code 技能：/quickstart、/threat-model、/vuln-scan、/triage、/patch、/customize：用于交互式范围界定、扫描、分诊和补丁修复。在 Claude Code 中打开此仓库并运行 /quickstart 即可开始熟悉。
• `harness/`：自主参考流水线（侦察 → 发现 → 验证 → 报告 → 补丁），已配置为使用 Docker 和 ASAN 查找 C/C++ 内存漏洞。此框架是参考实现，而非成品。其整体架构、提示词和沙箱机制具有可复用性，但该框架无法直接开箱即用地适用于所有代码库。运行 /customize 可将其移植到您的编程语言、检测器或漏洞类别中。

⚠️安全性：/quickstart、/threat-model、/vuln-scan 和 /triage 仅执行文件读写操作。对静态发现结果（TRIAGE.json 或 VULN-FINDINGS.json）运行 /patch 同样仅限于读写操作。/customize 会编辑框架代码并运行验证命令。只要您在 Claude Code 中审查并批准每次工具调用，这些技能均可在非沙箱环境中安全运行。自主参考流水线（包括对流水线结果运行 /patch）会执行目标代码，因此除非显式覆盖设置，否则它拒绝在 gVisor 沙箱之外运行。要进行设置，请运行一次 scripts/setup_sandbox.sh，然后通过 bin/vp-sandboxed 调用流水线。更多详情请参阅 docs/security.md 和 docs/agent-sandbox.md。

快速入门

[](https://github.com/anthropics/defending-code-reference-harness#getting-started)

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

30 秒介绍 + 在金丝雀目标上的引导式首次运行

/quickstart

/quickstart 如何将流水线移植到 Java？

/quickstart 如何对所有这些 bug 进行分诊？

延伸阅读

[](https://github.com/anthropics/defending-code-reference-harness#further-reading)

• **博客文章** · 包含经验总结和最佳实践的配套博客文章
• **流水线** · 工作原理：架构图、阶段说明、CLI 参数
• **安全性** · 沙箱机制、不应挂载的内容
• **Agent 沙箱** · 每个 Agent 的 gVisor 隔离 + 出站流量白名单
• **自定义** · 移植到我的技术栈；哪些文件需要更改及其原因
• **补丁修复** · 为已验证的崩溃生成并验证修复方案
• **故障排除** · 重复项、速率限制、子 Agent 模型固定
• **安全防护** · 阻止危险的网络攻击操作

• * *

上手指南

[](https://github.com/anthropics/defending-code-reference-harness#ramp-up) 在我们合作过的安全团队中，最成功的往往是那些最快投入实践的团队。虽然花几个月时间设计完美的流水线很有吸引力，但我们建议从第一天起就从小处着手，并在实践中不断积累经验、逐步构建。以下步骤遵循这一模式，并根据我们的观察设定了一个既有雄心又合理的推进节奏。

| | | | | --- | --- | --- | | 步骤 1 | 第 1 天 | 构建威胁模型并运行首次静态扫描 + 分诊 | | 步骤 2 | 第 2 天 | 在 C/C++ 库上运行参考流水线 | | 步骤 3 | 第 3-5 天 | 针对目标定制流水线 | | 步骤 4 | 第 2 周 | 启动自主扫描、分诊和补丁修复 |

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

[](https://github.com/anthropics/defending-code-reference-harness#step-1-day-1-build-a-threat-model-and-run-your-first-static-scan--triage) 第 1 天的重点是端到端地体验完整流程。仅使用交互式技能，您将构建威胁模型，运行基于该模型确定范围的静态扫描，对返回结果进行分诊，并起草候选修复方案。当天结束时，您将获得一份威胁模型、一份按优先级排序的静态发现列表以及候选补丁。

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

将所有子代理固定到您想要的模型

export CLAUDE_CODE_SUBAGENT_MODEL=<model-id> claude

0. 介绍 + 引导式首次运行

/quickstart

1. 构建威胁模型（谋定而后动）

/threat-model bootstrap targets/canary

2. 运行由该威胁模型确定范围的静态扫描

/vuln-scan targets/canary

3. 验证、去重并对返回结果进行排序

/triage targets/canary/VULN-FINDINGS.json

4. 为已验证的发现生成候选修复方案

/patch ./TRIAGE.json --repo targets/canary

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

步骤 1 中产生的漏洞候选项来自 Claude 对源代码的静态审查（未构建或运行任何内容），因此在非金丝雀目标上可能会出现更多误报。在步骤 2 中，您将生成*经执行验证*的发现。

注意： 在金丝雀目标上，/triage 可能会将扫描发现判定为误报而予以排除。entry.c 已声明自身为故意包含漏洞的演示代码，且 /triage 会正确排除测试/固件代码中的缺陷。要查看完整的确认/去重/误报处理流程，请在精选固件上运行该命令（/triage .claude/skills/triage/fixtures/canary-findings.json --repo targets/canary），或将步骤 1 的技能指向您自己的代码。

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

[](https://github.com/anthropics/defending-code-reference-harness#step-2-day-2-run-the-reference-pipeline-on-a-cc-library) 在第 2 天，您将从交互式技能过渡到使用参考流水线进行首次自主运行。您将在本地环境中对一个已知存在漏洞的开源库执行完整的“侦察 → 发现 → 验证 → 报告”循环，然后针对发现的问题生成候选补丁。完成后，您将获得一组可复现的崩溃案例、可利用性报告和候选补丁，并对流水线的工作方式有直观了解。

运行流水线非常简单：

一次性设置

python3 -m venv .venv && .venv/bin/pip install -e . ./scripts/setup_sandbox.sh # 安装 gVisor，构建代理镜像，并验证隔离性；注意：需要 Docker export ANTHROPIC_API_KEY=sk-ant-... # 或 CLAUDE_CODE_OAUTH_TOKEN；流水线需要在环境变量中配置其中之一

运行“侦察 → 发现 → 验证 → 报告”循环

bin/vp-sandboxed run drlibs --model <model-id> --runs 3 --parallel --stream --auto-focus

为每个发现生成候选补丁

bin/vp-sandboxed patch results/drlibs/<timestamp>/ --model <model-id>

或者，让 Claude Code 启动流水线并为您监控运行过程

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。

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

1. 构建（Build）：将目标编译为带有 ASAN（C/C++ 内存错误检测器）的 Docker 镜像。流水线在首次运行时会自动使用目标的 Dockerfile 构建此镜像。
2. 侦察（Recon）：一个轻量级代理在网络隔离的容器内读取源代码并提出分区方案，即 _“这里有 N 个值得单独攻击的不同输入解析子系统”_，以便并行的查找代理探索不同区域，而不是集中在同一个漏洞上。如果未使用 --auto-focus 标志，流水线将使用目标 config.yaml 中的 focus_areas 列表。
3. 查找（Find）：N 个代理并行运行，每个代理都在其独立的隔离容器中。每个代理读取源代码，构造畸形输入，并运行 ASAN 二进制文件，直到特定输入在 3 次尝试中均触发崩溃。
4. 验证（Verify）：一个独立的评分代理在查找代理未触及的全新容器中复现每个崩溃。从查找代理传递到评分代理的唯一内容是生成的概念验证（PoC）。
5. 去重（Dedupe）：一个评判代理将已验证的崩溃与已报告的漏洞进行比较，并判定每个崩溃是新漏洞、已知漏洞的更好示例，还是应跳过的重复项。
6. 报告（Report）：一个报告代理为每个唯一漏洞编写结构化的可利用性分析，包括原语类别、可达性、提权路径和严重程度的详细信息。
7. 修复（Patch）（即上述独立的 patch 命令）：一个修复代理编写建议的修复方案，评分代理则确认新代码可以构建、原始概念验证输入不再触发崩溃、目标测试套件仍然通过，并且新的查找代理无法绕过该修复。

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

第 3 步（第 3-5 天）：针对您的目标自定义流水线

[](https://github.com/anthropics/defending-code-reference-harness#step-3-days-3-5-customize-the-pipeline-for-your-target) 在第 3-5 天，您将针对自己的目标自定义测试框架。首先，您将把第 1 步的技能指向您的代码，然后使用 /customize 将流水线移植到您的技术栈。到本周末，您将拥有一个可供流水线运行的 targets/<your-service>/ 目录，该目录已通过流水线的单次冒烟测试验证，并为第 4 步的规模化运行做好了准备。

虽然参考流水线专为发现 C/C++ 代码中的内存漏洞而设计，但其架构是通用的。将其移植到新的漏洞类别或语言，只需针对您的目标技术栈回答以下问题：

| 问题 | C/C++ 参考 | 您的目标（示例） | | --- | --- | --- | | 什么信号表示发现了漏洞？ | ASAN 崩溃签名 | 异常 / canary 文件 / DNS 回调 | | 概念验证是什么样的？ | 导致崩溃的输入文件 | HTTP 请求序列 / 交易列表 / 测试框架 | | 目标如何构建和运行？ | Dockerfile（使用 clang + ASAN） | 容器内您所用语言的构建流程 |

在自定义之前，请先将第 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。

第 4 步（第 2 周）：启动自主扫描、分诊和修复

[](https://github.com/anthropics/defending-code-reference-harness#step-4-week-2-start-autonomous-scanning-triage-and-patching) 在第 2 周，您将在自己的目标上使用第 3 步中自定义的流水线，在内部流水线循环之外增加一个 _外部_ 循环——运行多次流水线扫描，对这些运行中的发现进行分诊，根据优先级进行修复，然后重复此过程。

Scan - 针对目标运行一波并行任务

bin/vp-sandboxed run my-service --model <model-id> --runs 5 --parallel --stream --auto-focus

Triage - 使用威胁模型对所有波次中的每个发现进行去重和排名

/triage results/my-service/ --repo ~/code/my-service --auto --votes 5

Patch - 生成并验证修复方案，从分诊排名最高的开始

/patch results/my-service/<timestamp>/ --model <model-id>

⚠️ 请遵循与 第 2 步 相同的沙箱指南

单次流水线运行已经会验证并对其自身的发现进行去重。/triage 则跨多次流水线运行工作。当指向 results/ 目录时，它会合并所有运行中的重复项（以及 /vuln-scan 产生的静态发现，如果有的话），根据您的威胁模型重新校准严重程度评级，并尝试将每个发现路由给组件负责人。

在可能的情况下，快速修复发现有助于保持外部循环的高效运转。当发现被修复后，模型将无法再次发现它们，转而会挖掘出全新的、通常更深层的问题。随着您运行更多波次的流水线，发现的数量可能会减少，但复杂性可能会增加。如果无法快速修复，即使只是将之前的发现记录在目标的 known_bugs 中，也有助于引导未来的运行去发现更新的漏洞。

自动化分诊与补丁修复仍是尚未解决的难题，本参考工具链也无法完全解决这些问题。/patch 中的验证策略虽然提高了质量门槛，但严重性评估和优先级排序最终仍需根据您自身的环境进行判断，且经过验证的补丁未必能被上游项目采纳。许多合作伙伴反馈这些环节是当前工作流程中的主要瓶颈，因此建议您为此预留充足的工程开发时间。

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

未来展望

[](https://github.com/anthropics/defending-code-reference-harness#looking-forward) 在度过初期上手阶段后，与我们合作的团队通常会选择在以下几个方向上持续投入：

1. 全面审查内部代码仓库及关键开源依赖项，按重要性（例如基于暴露面、CVE 历史记录或业务关键程度）对扫描目标进行排序，随后按优先级依次完成扫描工作。
2. 搭建专用的扫描基础设施，将扫描任务从个人笔记本电脑或临时虚拟机中迁移出来。最成功的团队往往不会执着于在规模化推广前打造出完美的扫描平台。
3. 将扫描流程融入软件开发生命周期（SDLC）。部分团队已建立定期扫描机制（如每日或每周执行），或将扫描步骤集成至 CI 流水线中。
4. 对模型进行测试与实验，探索最适合自身场景的使用方式。