AI自动发现并修复漏洞，但管道需要自己搭

基于与多个组织安全团队合作的经验，我们开发了这套使用Claude进行自主漏洞发现与修复的参考实现（自Claude Mythos Preview发布以来）。关于这些经验总结及最佳实践，请参阅随附的博客文章（也提供blog-post.md格式）。如需了解同一“侦察→发现→分类→报告→修补”流程的轻量级SDK-only教程，请参阅配套指南。

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

🔒 需要托管方案？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将其移植到您的语言、检测器或漏洞类别。

⚠️ 安全：/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。

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

# 30秒介绍 + 在canary目标上引导首次运行 > /quickstart

> /quickstart 如何将管道移植到Java？ > /quickstart 如何分类所有这些漏洞？ 延伸阅读

博客文章 · 附带的博客文章，包含经验总结和最佳实践 管道 · 工作原理：图表、阶段、CLI标志 安全 · 沙箱、不应挂载的内容 代理沙箱 · gVisor隔离 + 每个代理的出站白名单 自定义 · 移植到我的技术栈；哪些文件变更及原因 修补 · 为已验证的崩溃生成并验证修复 故障排除 · 重复、速率限制、子代理模型固定 防护措施 · 危险网络工作的阻断

快速上手 我们合作过的最成功的安全团队都是最快动手实践的团队。虽然花数月设计完美管道很诱人，但我们建议从第一天开始小规模起步，随着经验积累逐步构建。以下步骤遵循这一模式，并根据我们的观察设定了雄心勃勃（但合理）的节奏。

步骤1 第一天 构建威胁模型并运行首次静态扫描+分类

步骤2 第二天 在C/C++库上运行参考管道

步骤3 第3-5天 为您的目标自定义管道

步骤4 第二周 开始自主扫描、分类和修补

步骤1（第一天）：构建威胁模型并运行首次静态扫描+分类 第一天专注于端到端查看整个流程。仅使用交互式技能，您将构建威胁模型、运行基于该模型范围的静态扫描、对返回结果进行分类，并草拟候选修复。当天结束时，您将获得威胁模型、静态发现排名列表和候选补丁。 相关技能仅读写仓库中的文件。只要您交互式运行Claude Code并批准每次工具使用，则无需沙箱。 # 将每个子代理固定到您想要的模型 export CLAUDE_CODE_SUBAGENT_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对源代码的静态审查（未构建或运行任何内容），因此对于非canary目标，预计会有更多误报。在步骤2中，您将生成经过执行验证的发现。

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

步骤2（第二天）：在C/C++库上运行参考管道 第二天，您将从交互式技能过渡到使用参考管道进行首次自主运行。您将在环境中对已知存在漏洞的开源库运行完整的侦察→发现→验证→报告流程，然后为其发现生成候选补丁。最终您将获得一组可重现的崩溃、可利用性报告和候选补丁，并了解管道的工作原理。 运行管道很简单： # 一次性设置 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 <模型ID> --runs 3 --parallel --stream --auto-focus # 为每个发现生成候选补丁 bin/vp-sandboxed patch results/drlibs/<时间戳>/ --model <模型ID>

# 或者，让Claude Code启动管道并为您监控运行 claude > 在drlibs上运行管道并解释发现结果 流程结果存储在results/drlibs/<时间戳>/目录中。使用--stream标志，第一份报告将在几分钟内出现在reports/bug_NN/下。

⚠️ run会生成自主代理。管道在gVisor容器内运行每个代理，出站流量限制为Claude API。除非明确覆盖，生成代理的子命令拒绝在容器外启动。更多信息请参阅docs/security.md和docs/agent-sandbox.md。

在底层，管道经历七个阶段：

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

更多详情请参阅docs/pipeline.md。 步骤3（第3-5天）：为您的目标自定义管道 在第3-5天，您将为自有目标自定义工具集。首先，将步骤1技能指向您的代码，然后使用/customize将管道移植到您的技术栈。到本周末，您将拥有一个targets/<您的服务>/目录，管道可针对该目录运行，并通过一次管道冒烟测试验证，准备在步骤4中扩展。 虽然参考管道专为查找C和C++代码中的内存漏洞而设计，但其架构是通用的。将其移植到新的漏洞类别或语言只需为您的目标技术栈回答以下问题：

问题 C/C++参考 您的目标（示例）

什么标志着发现？ ASAN崩溃特征 异常/金丝雀文件/DNS回调

验证概念长什么样？ 崩溃输入文件 HTTP请求序列/tx列表/测试工具

目标如何构建和运行？ Dockerfile（使用clang + ASAN） 容器中您语言的构建

自定义之前，先将步骤1技能指向您自己的代码。提醒一下，它们仅读写，因此可以在无沙箱环境下运行。 claude

> /quickstart 如何为~/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 <模型ID> --runs 1 更多详情请参阅docs/customizing.md。 步骤4（第二周）：开始自主扫描、分类和修补 在第二周，您将使用步骤3中自定义的管道针对自有目标，在内部管道循环之上添加外部循环——运行多次管道扫描、跨这些运行对发现进行分类、基于优先级进行修补，然后重复。 # 扫描 - 对目标运行一波并行扫描 bin/vp-sandboxed run my-service --model <模型ID> --runs 5 --parallel --stream --auto-focus

# 分类 - 使用您的威胁模型跨所有波次去重并排序每个发现 > /triage results/my-service/ --repo ~/code/my-service --auto --votes 5

# 修补 - 从分类排名最高的开始生成并验证修复 > /patch results/my-service/<时间戳>/ --model <模型ID>

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

给定的管道运行已验证并去重其自身发现。/triage可跨多次管道运行工作。当指向results/目录时，它会折叠所有运行中的重复项（以及/vuln-scan中的任何静态发现，如果存在），根据您的威胁模型重新校准严重性评级，并尝试将每个发现路由到组件所有者。 在可能的情况下，快速修补发现有助于保持外部循环尽可能高效。当发现被修复后，模型无法重新发现它们，而是会呈现全新的、通常更深层的问题。随着您运行更多管道波次，发现数量可能会下降，但复杂性可能会上升。如果无法快速修补，即使仅在目标的known_bugs中记录先前的发现，也有助于引导未来运行转向更新的漏洞。 自主分类和修补仍是开放性问题，本参考工具集并未完全解决。/patch中的验证策略有助于提高标准，但严重性和优先级最终是对您环境的判断，且已验证的补丁并不总是可上游合并的。许多合作伙伴报告这些步骤是当前的瓶颈，您应为它们预留实际的工程时间。 更多详情请参阅docs/triage.md和docs/patching.md。

展望未来 在初始快速上手之后，与我们合作的团队倾向于在以下几个方向投入：

审查所有内部仓库和关键开源依赖项，排序哪些最重要进行扫描（例如，基于其暴露面、CVE历史、业务关键性），然后按优先级顺序扫描列表。 建立专用扫描基础设施，将扫描从笔记本电脑或一次性虚拟机迁移出来。最成功的团队在扩展之前会克制构建完美扫描平台的冲动。 将扫描纳入SDLC。一些团队已设置定期扫描（例如每日、每周）或将扫描添加到CI管道中。 测试和实验不同模型，以找到最适合其需求的方案。