Anthropic 开源框架:基于 AI 的自主漏洞发现与修复
- #AI安全
- #漏洞挖掘
- #Anthropic
- #开源工具
- #Hacker News
Defending Code Reference Harness
基于 Claude 的自主漏洞发现与修复参考实现,源自我们自推出 Claude Mythos Preview 以来与多个组织的安全团队合作的经验。有关这些经验及最佳实践的详细说明,请参见随附的博客文章(也包含在 blog-post.md 中)。如需同一 recon → find → triage → report → patch 流程的轻量级 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/:自主参考管道(recon → find → verify → report → patch),配置为使用 Docker 和 ASAN 查找 C/C++ 内存漏洞。此 harness 是参考实现,而非产品。通用结构、提示和沙箱是可重用的,但 harness 并非开箱即用于所有代码库。运行
/customize将其移植到您的语言、检测器或漏洞类别。
⚠️ 安全性:/quickstart、/threat-model、/vuln-scan 和 /triage 仅读写文件。对静态发现(TRIAGE.json 或 VULN-FINDINGS.json)运行 /patch 同样仅读写文件。/customize 编辑 harness 代码并运行验证命令。只要您在 Claude Code 中以交互方式运行并批准每次工具使用,这些技能都可以在无沙箱环境下安全运行。自主参考管道(包括对管道结果运行 /patch)会执行目标代码,因此除非显式覆盖,否则它拒绝在 gVisor 沙箱之外运行。要设置,请运行 scripts/setup_sandbox.sh 一次,然后通过 bin/vp-sandboxed 调用管道。更多详情请参见 docs/security.md 和 docs/agent-sandbox.md。
开始
git clone https://github.com/anthropics/defending-code-reference-harness
cd defending-code-reference-harness
claude
在 Claude Code 中,运行以下命令开始:
> /quickstart
> /quickstart how do I port the pipeline to Java?
> /quickstart how do I triage all these bugs?
进一步阅读
- 博客文章:包含经验教训和最佳实践的随附博客文章
- 管道:工作原理:示意图、阶段、CLI 标志
- 安全性:沙箱、不应挂载的内容
- Agent 沙箱:每个 agent 的 gVisor 隔离 + 出口白名单
- 自定义:移植到我的技术栈;更改了哪些文件及原因
- 修补:为已验证的崩溃生成并验证修复
- 故障排除:重复、速率限制、子 agent 模型固定
- 保障措施:阻止危险网络工作
逐步推进
我们合作的最成功的安全团队是那些最快动手实践的团队。虽然花费数月设计完美的管道很诱人,但我们建议从第一天开始小规模启动,随着经验的积累逐步构建。以下步骤遵循该模式,并根据我们的观察设定了一个雄心勃勃但合理的节奏。
第 1 步(第 1 天):构建威胁模型并运行首次静态扫描 + 分类
第 1 天的重点是端到端地查看整个循环。仅使用交互式技能,您将构建威胁模型,运行基于威胁模型范围的静态扫描,对返回的结果进行分类,并草拟候选修复。您将在一天结束时获得威胁模型、静态发现的排名列表和候选补丁。相关技能仅读写您仓库中的文件。只要您以交互方式运行 Claude Code 并批准每次工具使用,就无需沙箱。
# 将每个子 agent 固定到您想要的模型
export CLAUDE_CODE_SUBAGENT_MODEL=<model-id>
claude
> /quickstart
> /threat-model bootstrap targets/canary
> /vuln-scan targets/canary
> /triage targets/canary/VULN-FINDINGS.json
> /patch ./TRIAGE.json --repo targets/canary
此流程生成 THREAT_MODEL.md、VULN-FINDINGS.{json,md}、TRIAGE.{json,md} 和 PATCHES/。第 1 步产生的漏洞候选来自 Claude 对源代码的静态审查(不构建或运行任何内容),因此在非 canary 目标上预期会有更多误报。在第 2 步中,您将生成经过执行验证的发现。
注意:在 canary 目标上,/triage 可能会将扫描的发现视为误报并驳回。entry.c 宣称自己是故意脆弱的演示代码,/triage 正确排除了测试/夹具代码中的错误。要查看完整的确认/去重/误报流程,请在精心策划的夹具上运行(/triage .claude/skills/triage/fixtures/canary-findings.json --repo targets/canary),或将第 1 步技能指向您自己的代码。
第 2 步(第 2 天):在 C/C++ 库上运行参考管道
第 2 天,您将从交互式技能过渡到使用参考管道的首次自主运行。您将在您的环境中对已知脆弱的开源库运行完整的 recon → find → verify → report 循环,然后为其发现的漏洞生成候选补丁。您将获得一组可重现的崩溃、可利用性报告和候选补丁,并了解管道的工作方式。
运行管道很简单:
# 一次性设置
python3 -m venv .venv && .venv/bin/pip install -e .
./scripts/setup_sandbox.sh
export ANTHROPIC_API_KEY=sk-ant-...
# 运行 recon → find → verify → report 循环
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 会生成自主 agent。管道在 gVisor 容器内运行每个 agent,出口仅限 Claude API。生成 agent 的子命令除非显式覆盖,否则拒绝在容器外启动。更多信息请参见 docs/security.md 和 docs/agent-sandbox.md。
在内部,管道经历七个阶段:
- 构建:将目标编译为包含 ASAN(C 和 C++ 的内存错误检测器)的 Docker 镜像。管道在首次运行时使用目标的 Dockerfile 自动构建此镜像。
- 侦察:轻量级 agent 在网络隔离的容器中读取源代码,并提出分区,例如“这里有 N 个值得单独攻击的不同输入解析子系统”,以便并行的发现 agent 探索不同区域,而不是集中在同一个漏洞上。没有
--auto-focus标志时,管道使用目标config.yaml中的focus_areas列表。 - 发现:N 个 agent 并行运行,每个都在自己的隔离容器中。每个 agent 读取源代码,制作畸形输入,并运行 ASAN 二进制文件,直到给定的输入连续 3 次崩溃。
- 验证:一个单独的评分 agent 在发现 agent 未接触过的新容器中重现每个崩溃。从发现 agent 传递到评分 agent 的唯一内容是它产生的概念证明。
- 去重:一个评审 agent 将已验证的崩溃与已报告的漏洞进行比较,并决定每个崩溃是新漏洞、已知漏洞的更好示例,还是要跳过的重复项。
- 报告:一个报告 agent 为每个唯一漏洞编写结构化的可利用性分析,包括原语类、可达性、升级路径和严重性等详细信息。
- 补丁(上面的单独补丁命令):补丁 agent 编写建议的修复,评分 agent 确认新代码构建、原始概念证明输入不再崩溃、目标的测试套件仍然通过,并且一个新的发现 agent 无法绕过修复。
更多详情请参见 docs/pipeline.md。
第 3 步(第 3-5 天):为您的目标自定义管道
在第 3-5 天,您将根据您自己的目标自定义 harness。首先,将第 1 步技能指向您的代码,然后使用 /customize 将管道移植到您的技术栈。到本周末,您将拥有一个 targets/<your-service>/ 目录,管道可以针对该目录运行,并通过一次烟雾测试运行验证,为第 4 步的扩展做好准备。
虽然参考管道是为查找 C 和 C++ 代码中的内存漏洞而设计的,但其结构是通用的。将其移植到新的漏洞类别或语言只需回答以下关于目标技术栈的问题:
| 问题 | C/C++ 参考 | 您的目标(示例) |
|---|---|---|
| 什么信号表示发现? | ASAN 崩溃签名 | 异常 / canary 文件 / DNS 回调 |
| 概念证明长什么样? | 崩溃输入文件 | HTTP 请求序列 / 交易列表 / 测试 harness |
| 如何构建和运行目标? | 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 技能中修改 harness 以适应您的代码库。
> /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 周):开始自主扫描、分类和修补
在第 2 周,您将使用第 3 步中自定义的管道处理您自己的目标,为内部管道循环添加一个外部循环——运行多次管道扫描,对来自这些运行的发现进行去重和排序,根据优先级进行修补,并重复。
# 扫描——针对您的目标运行一波并行运行
bin/vp-sandboxed run my-service --model <model-id> --runs 5 --parallel --stream --auto-focus
# 分类——对每个发现进行去重和排序
# ...
(后续内容原文中未完整提供,但根据上下文应包括分类和修补的进一步命令)
评论