Anthropic 近日在 GitHub 开源了 defending-code-reference-harness，一个基于 Claude 的漏洞发现与修复参考实现。项目覆盖 recon → find → verify → report → patch 流程，并提供 Claude Code skills，包括 /threat-model、/vuln-scan、/triage、/patch、/customize 等命令。
这件事真正重要的地方，不在于 Anthropic 发布了一个可直接采购替代现有 SAST、DAST 或 AppSec 平台的工具。它公开的是一套 AI 参与代码安全工作的组织方式：让模型不只“看代码提建议”，而是参与范围识别、发现、复现、去重、报告和候选修复。对安全工程团队来说，这比单个扫描命令更有参考意义。
Anthropic 开源的是参考实现，不是维护中的安全产品
该仓库页面写得很直白：这是 reference implementation，项目不维护，也不接受贡献。Anthropic 同时把托管产品 Claude Security 放在说明中，两者必须分开看。Claude Security 是商业化托管产品，面向多项目代码扫描、漏洞生命周期管理和快速修复；GitHub 上这个仓库则是开放给团队自建和改造的样板。
| 项目 | 定位 | 关键能力 | 现实判断 |
|---|---|---|---|
| defending-code-reference-harness | 开源参考实现 | recon、find、verify、report、patch | 可学习、可改造，但不能按产品预期使用 |
| Claude Security | Anthropic 托管产品 | 多项目扫描、验证、生命周期管理 | 更接近企业采购对象 |
| 传统 SAST/DAST 工具 | 商业或开源安全扫描 | 规则、污点分析、动态测试 | 稳定性和集成经验更成熟，但自主修复链路较弱 |
这也是当前 AI 安全工具市场的一个缩影。GitHub CodeQL、Semgrep、Snyk、Checkmarx 等工具长期围绕规则、数据流和依赖风险构建能力；大模型带来的新变量，是它能阅读上下文、生成 PoC、写报告、尝试补丁。但模型越接近“自治”，越需要工程护栏，而不是只看演示效果。
默认场景是 C/C++ 内存漏洞，跨语言落地要重做不少工程
Anthropic 给出的默认 harness 面向 C/C++ 内存漏洞，依赖 Docker、ASAN 和 gVisor 沙箱。流程会先构建带 ASAN 的目标镜像，再由多个 agent 分区探索输入解析路径，寻找可重复崩溃；随后由独立验证 agent 在新容器里复现，去重后生成结构化报告，最后由 patch agent 尝试修复并验证测试是否通过。
这条链路的技术含义很清楚：它更适合有可执行目标、可构造输入、可用崩溃信号验证的场景。要迁移到 Java、Go、Web 服务、业务逻辑漏洞或云配置风险，团队需要重新定义“什么算发现”“PoC 长什么样”“如何构建和运行目标”“验证信号来自哪里”。仓库提供 /customize，但这不等于自动支持所有语言和漏洞类型。
原文里还有一个容易被忽略的限制：自治 pipeline 会执行目标代码。Anthropic 要求使用 gVisor 沙箱，并限制网络出口到 Claude API；相关命令默认会拒绝在非沙箱环境运行，除非用户显式覆盖。这对企业内部代码尤其关键。安全团队不能把它当普通脚本丢进 CI，至少要先处理代码访问权限、构建依赖、密钥隔离、网络出口和日志留存。
安全团队应把它当作流水线蓝图，而不是替代人手的按钮
最受影响的是 AppSec、DevSecOps 和平台安全团队。它们真正要评估的不是“Claude 能不能找漏洞”这样笼统的问题，而是能否把模型放进已有流程：扫描结果如何进入工单系统，误报由谁复核，补丁是否经过代码 owner 审查，模型运行成本怎样计入 CI/CD，沙箱是否符合内部安全基线。
Anthropic 建议从 Day 1 的威胁模型和静态扫描开始，再到 Day 2 跑 C/C++ 示例库，Days 3-5 定制目标，第二周再进入多轮自治扫描。这个节奏比营销语言克制，也暴露了真实门槛：AI 代理要产生稳定价值，前提是目标工程化程度足够高，构建可复现，测试可运行，漏洞信号可验证。
接下来最该观察的变量，不是这个仓库会不会流行，而是企业是否愿意把“发现—验证—修复”中的一部分责任交给模型。短期看，AI 更可能先成为安全团队的扩音器：提高初筛、复现和补丁草拟效率。要走到自治流水线，还需要组织流程、权限治理和可审计性一起补上。