Anthropic 近日在 GitHub 开源了 defending-code-reference-harness，这是一个基于 Claude 的自主漏洞发现与修复参考实现，包含交互式 Claude Code skills 和一套自动化扫描 harness。项目覆盖威胁建模、漏洞扫描、验证、去重、报告和补丁生成等环节。
这件事的重要性不在于 Anthropic 又推出了一款安全产品。仓库首页明确写着：该项目不维护、不接受贡献，是 reference implementation，不是产品。真正有价值的是，它把大模型参与代码安全的流程拆成了可观察、可替换、可沙箱化的工程步骤，给企业安全团队一个“照着改”的样板。
Anthropic 开源的是流程样板，不是商业扫描器
仓库提供两部分能力。一部分是 Claude Code 里的交互式 skills，包括 /quickstart、/threat-model、/vuln-scan、/triage、/patch、/customize，用于引导安全人员做范围界定、静态审查、分诊和补丁草拟。另一部分是 harness/ 目录下的自主 pipeline，默认面向 C/C++ 内存漏洞。
| 项目 | 仓库开源框架 | Claude Security |
|---|---|---|
| 定位 | 开源参考实现 | Anthropic 托管产品 |
| 适用对象 | 自建安全流程、需要定制的团队 | 想采购托管服务的企业 |
| 默认能力 | C/C++ 内存漏洞样板，需改造 | 多项目源码扫描与发现管理 |
| 风险承担 | 用户负责沙箱、适配、运维 | 平台承担更多产品化流程 |
这个区分很关键。企业如果把它当成“下载即用的 AI SAST”，会很快碰到边界：语言、构建方式、漏洞类型、验证信号都要自己接上。它更像一份带代码的安全自动化设计文档。
自动化 pipeline 的价值在验证链条
Anthropic 给出的完整流程包括 build、recon、find、verify、dedupe、report、patch。默认路径是：先用 Docker 构建目标，并用 ASAN 捕获 C/C++ 内存错误；再由 recon agent 阅读源码并划分攻击面；多个 find agent 并行生成畸形输入并运行目标程序；verify agent 在新容器里复现崩溃；随后去重、生成可利用性报告，并由 patch agent 尝试修复。
这比单纯让大模型“看代码找漏洞”更接近企业安全现实。DevSecOps 团队最怕的不是没有告警，而是告警无法复现、重复堆积、修复后没人验证。Anthropic 把 PoC、复现、去重、补丁验证都放进链路里，说明大模型安全工具正在从“审查助手”走向“自动化工作流组件”。
横向看，GitHub CodeQL、Semgrep、Snyk 等工具强调规则、依赖和代码模式；Claude 这类 agent 流程的优势在于可以读上下文、生成输入、解释路径。但代价也更重：成本、运行时间、权限边界和误操作风险都更难控。传统扫描器可预测，agent 更灵活，也更需要管束。
企业团队该先试小范围，而不是直接接入主干流水线
仓库文档对安全限制说得很直白：交互式 skills 主要读写文件，在 Claude Code 里逐次批准工具调用即可；但自动化 pipeline 会执行目标代码，默认要求在 gVisor 沙箱中运行，并限制对外网络访问到 Claude API。Anthropic 还提供 scripts/setup_sandbox.sh 和 bin/vp-sandboxed，没有沙箱就拒绝启动，除非用户显式覆盖。
这背后有一个原文没有展开、但企业必须面对的条件：安全扫描本身会变成高权限自动执行环境。一旦把内部代码、构建脚本、测试样例和 agent 执行权限放在一起，沙箱、凭据隔离、网络出口和挂载目录就不是附加项，而是上线前置条件。
对企业安全团队来说，更稳妥的路径是先选一个 C/C++ 库或内部低风险服务做试点，验证三件事：能否稳定构建，能否复现真实崩溃，生成补丁是否能通过现有测试。等这些条件成立，再考虑把 /customize 改到 Java、Go、Web 服务或特定漏洞类型上。接下来最该观察的也不是 Anthropic 宣称发现了多少漏洞，而是使用者能否把这套参考实现改造成可审计、可回滚、可纳入 CI 的内部流程。