anthropics/defending-code-reference-harness · 上手攻略
- 仓库：anthropics/defending-code-reference-harness
- 链接：https://github.com/anthropics/defending-code-reference-harness
- 分类：trending
- 作者：Tom
- 更新：2026-07-13
一、这是什么
这是 Anthropic 官方开源的参考实现（Reference Implementation），用于展示如何用 Claude 实现自动化漏洞发现和修复。仓库基于 Anthropic 与多家企业安全团队合作（代号 Glasswing 项目）的实战经验总结而成，提供了从威胁建模到漏洞扫描、分诊、补丁生成的完整流水线原型。
⚠️ 重要说明：仓库 README 明确标注"This repo is not maintained and is not accepting contributions"，是 Anthropic 的参考文档而非商业产品本身。如需托管服务，可关注 Claude Security。
仓库的核心价值在于：把安全团队如何用 LLM 做代码审计的方法论落地成可运行的参考流水线，并开源了所有 prompts、sandbox 配置和编排逻辑。
二、解决什么问题
传统代码安全审计的痛点：
- 人工审计速度慢：大型代码仓库人工审计动辄数周
- 静态扫描误报率高：传统 SAST 工具噪声大，工程师疲于过滤
- 验证成本高：找到疑似漏洞后，需要人工判断是否可利用
- 补丁生成靠人工：即使找到漏洞，修复也要从头写
defending-code-reference-harness 的目标是：用多 Agent 流水线实现"发现 → 验证 → 去重 → 评级 → 生成补丁"的自动化闭环，并通过 gVisor 沙箱保证执行安全。
三、快速安装
前置依赖
- Python 3.x（建议 3.10+）
- Docker（用于构建 ASAN 镜像和运行沙箱）
- Git
- Anthropic API Key（sk-ant-...）
安装步骤
# 1. 克隆仓库
git clone https://github.com/anthropics/defending-code-reference-harness
cd defending-code-reference-harness
# 2. 创建 Python 虚拟环境并安装
python3 -m venv .venv
.venv/bin/pip install -e .
# 3. 初始化沙箱（安装 gVisor + 构建 Agent 镜像）
./scripts/setup_sandbox.sh
# 注意：需要 Docker 正常运行；此脚本需要网络下载 gVisor 等组件
# 4. 配置 API Key
export ANTHROPIC_API_KEY=sk-ant-... # 方式一：直接环境变量
# 或
export CLAUDE_CODE_OAUTH_TOKEN=... # 方式二：OAuth Token（用于 Claude Code CLI）
# 或通过 AWS Bedrock / Vertex AI（详见 docs/agent-sandbox.md）
⚠️ 注意：
setup_sandbox.sh需要 Docker 权限和网络连接。Linux/macOS/Windows（Docker Desktop）均可。
四、核心用法
4.1 Claude Code 交互模式（Day 1，推荐先体验）
在仓库目录下启动 Claude Code：
claude
在 Claude Code 中直接使用斜杠命令（Skills）：
# 0. 入门引导 + 在 canary 目标上跑一遍
> /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/ — 候选修复补丁
💡 在 canary 目标上，
/triage可能会把很多结果标为假阳性（因为 canary 本身就是故意写的有漏洞代码）。想看完整流程可以用 fixtures 目录的示例数据。
4.2 自主运行参考流水线（Day 2，进入全自动化）
# 启动完整流水线：recon → find → verify → report
bin/vp-sandboxed run drlibs \
--model <model-id> \
--runs 3 \
--parallel \
--stream \
--auto-focus
# 参数说明：
# --runs 3 # 运行 3 次（增加覆盖率）
# --parallel # 并行运行多个 find agents
# --stream # 流式输出，第一批报告几分钟后出现
# --auto-focus # 自动为每个 find agent 分配不同的代码攻击面
# 为流水线找到的漏洞生成补丁
bin/vp-sandboxed patch results/drlibs/<timestamp>/ --model <model-id>
# 查看结果目录
ls results/drlibs/<timestamp>/reports/
⚠️ 流水线会启动自主 Agent。出于安全考虑，
vp-sandboxed强制要求 gVisor 沙箱环境，不允许在沙箱外运行。
4.3 流水线七阶段解析
Build → Recon → Find(N个并行) → Verify → Dedupe → Report → Patch
| 阶段 | 说明 |
|---|---|
| Build | 编译目标代码为带 ASAN（AddressSanitizer）的 Docker 镜像 |
| Recon | 轻量 Agent 读取源码，提出代码分区建议（"这里有 N 个独立输入解析子系统"） |
| Find | N 个 Agent 并行，每个攻击不同子系统，构造畸形输入触发 ASAN 崩溃 |
| Verify | 独立的 Grader Agent 在新容器中复现每个崩溃（防止 Find Agent 污染环境） |
| Dedupe | Judge Agent 对比已知漏洞库，决定是新漏洞、已知漏洞的更好示例还是重复 |
| Report | Report Agent 为每个唯一漏洞写结构化可利用性分析 |
| Patch | Patch Agent 生成修复补丁，Grader 验证：编译通过、原 PoC 不再崩溃、测试套件通过 |
4.4 自定义流水线到自己的代码库（Days 3-5）
# Step 1: 用交互技能为目标代码建立基线
> /threat-model bootstrap-then-interview ~/code/my-service
> /vuln-scan ~/code/my-service
> /triage ~/code/my-service/VULN-FINDINGS.json --repo ~/code/my-service
# Step 2: 用 /customize 将流水线适配到自己的栈
> /customize use ~/code/my-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md
# Step 3: 验证自定义后的流水线
bin/vp-sandboxed run my-service --model <model-id> --runs 1
自定义的核心是回答这几个问题（详见 docs/customizing.md）：
- 你的目标语言是什么？（参考实现是 C/C++ + ASAN）
- 什么信号代表一个漏洞？（ASAN 崩溃 vs 异常 vs 其他）
- 你的 PoC 长什么样？（崩溃输入文件 vs HTTP 请求序列）
- 如何构建和运行目标？（参考用 Dockerfile + clang + ASAN）
五、安全说明（必读）
⚠️ 安全边界划分：
- /quickstart, /threat-model, /vuln-scan, /triage → 仅读写文件，安全
- /patch（在静态结果上） → 仅读写文件，安全
- /customize → 编辑 harness 代码并运行验证命令
- 流水线 run + patch → 在 gVisor 沙箱中执行目标代码
沙箱机制：
- 自主流水线强制在 gVisor 容器内运行
- 出站流量仅允许 Claude API（不允许攻击外网）
- 如需覆盖此限制，必须显式 override（详见 docs/security.md）
# 查看安全文档
cat docs/security.md
cat docs/agent-sandbox.md
六、典型适用场景
| 场景 | 说明 |
|---|---|
| 安全团队引入 LLM 辅助审计 | 参考流水线直接可用，或按需定制 |
| 开源 C/C++ 库安全审计 | 参考实现针对内存安全漏洞（ASAN），适合 C/C++ 项目 |
| 学习 AI + 安全交叉技术 | 流水线设计完整，可作为架构参考 |
| CI/CD 集成漏洞扫描 | 自定义到自有代码后，可集成到每日构建流程 |
| 渗透测试/红队辅助 | 用威胁建模 + 自动化扫描快速定位攻击面 |
七、坑与注意
- 非活跃维护：README 明确说不再接受贡献，使用时需有心理准备——遇到问题可能需要自己 fork 修复
- 参考流水线针对 C/C++ 内存漏洞：开箱即用只能找到 ASAN 可检测的内存安全漏洞，其他漏洞类型需大量定制
- gVisor + Docker 依赖：没有 Docker 或沙箱配置不当，流水线无法运行
- 自主 Agent 成本高：一次
--runs 5 --parallel会并发启动多个 Agent 并多次调用 LLM API，成本需注意管控 - Patch 质量不一：自动生成的补丁不一定能 upstream，社区反馈这是当前最大瓶颈
- 假阳性：尤其在非 canary 目标上，静态扫描阶段的误报率较高，需要配合
/triage过滤 - Model ID 配置：需要确认所使用模型的 ID 格式，Bedrock/Vertex/API 平台的 model ID 格式各不相同
八、与同类对比
| 方案 | 类型 | 优势 | 劣势 |
|---|---|---|---|
| defending-code-reference-harness | 开源参考实现 | Anthropic 官方方法论、完整流水线、沙箱安全 | 非活跃维护、仅 C/C++ ASAN |
| Semgrep Rule AI | 商业 SAST+AI | 与 CI 集成好 | 误报仍多、定制需要规则编写经验 |
| Codeant / Snyk DeepCode | 商业 AI 审计 | 托管服务、省心 | 不可私有化、数据外传 |
| OWASP SARIF | 开源标准 | 通用格式 | 不是解决方案，只是输出格式 |
| GPT Security Agent（自定义） | 自建方案 | 完全可控 | 需要从零搭流水线，参考少 |
九、一句话推荐结论
想用 Claude 做代码安全审计，这个仓库是目前公开的最完整方法论参考——先从 Day 1 的交互模式体验起，对流程有信心后再用自定义功能适配自己的代码库；记得它不是商业产品，线上生产环境使用前务必做好充分测试。
信息来源：
- GitHub README（含详细的多日上手指南）
- docs/pipeline.md — 流水线架构文档
- docs/security.md — 沙箱与安全文档
- docs/agent-sandbox.md — Agent 隔离机制
- docs/customizing.md — 自定义流水线指南
- docs/patching.md — 补丁生成与验证
不确定处：
- 仓库最后更新时间：README 未标注时间戳，具体时效性需自行判断
- gVisor 版本要求：脚本 setup_sandbox.sh 未标注版本依赖，建议在具有稳定网络的环境中运行
- Model ID 格式：不同渠道（API、Bedrock、Vertex）的 model ID 格式各异，需参考各平台文档