@_mattata: Anthropic 发布了一个相当简洁的代码审计工具，用于识别具有潜在安全影响的漏洞。它…

Anthropic 发布了一套相当简洁的代码审计工具框架，用于识别具有潜在安全影响的漏洞。虽然它缺少实际漏洞检测所需的大部分关键要素，但它作为通用漏洞检测的模板非常出色！https://t.co/tWpQ7mgAWZ — # anthropics/defending-code-reference-harness 来源：https://github.com/anthropics/defending-code-reference-harness # 防守代码参考框架 基于我们与多个组织安全团队合作（https://www.anthropic.com/glasswing）的经验，自推出 Claude Mythos 预览版以来，这是一套使用 Claude 进行自主漏洞发现与修复的参考实现。关于这些经验以及最佳实践的详细说明，请参见随附的博文（https://claude.com/blog/using-llms-to-secure-source-code）（也提供在 blog-post.md 中）。如需了解同一 reconnaissance → find → triage → report → patch 循环的轻量级 SDK 教程，请参见配套的 cookbook（https://platform.claude.com/cookbook/claude-agent-sdk-06-the-vulnerability-detection-agent）。此仓库不再维护，也不接受贡献。 > 🔒 想要托管方案？ Anthropic 提供 > Claude Security（https://claude.com/product/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++ 内存漏洞。此框架是一个参考，不是产品。整体结构、提示和沙箱是可重用的，但框架不会开箱即用于所有代码库。运行 /customize 将其移植到你的语言、检测器或漏洞类别。 > ⚠️ 安全： /quickstart、/threat-model、/vuln-scan 和 /triage > 仅读写文件。对静态发现运行 /patch（TRIAGE.json > 或 VULN-FINDINGS.json）同样仅读写。/customize 会编辑 > 框架代码并运行验证命令。只要你在 Claude Code 中交互式操作并批准每次工具使用，> 这些技能都可以在没有沙箱的情况下安全运行。> 自主参考流水线（包括对流水线结果运行 /patch）会执行目标代码，> 因此除非明确覆盖，否则它拒绝在 gVisor 沙箱之外运行。> 要开始设置，请运行一次 scripts/setup_sandbox.sh，> 然后通过 bin/vp-sandboxed 调用流水线。详见 docs/security.md > 和 docs/agent-sandbox.md。 ## 快速入门 bash git clone https://github.com/anthropics/defending-code-reference-harness cd defending-code-reference-harness claude # 30 秒介绍 + 对 canary 目标的引导式首次运行 > /quickstart > /quickstart 如何将流水线移植到 Java？ > /quickstart 如何对所有漏洞进行分类？ ## 延伸阅读 - 博文 · 随附博文，包含经验 + 最佳实践 - 流水线 · 工作原理：图表、阶段、CLI 标志 - 安全 · 沙箱、哪些不应挂载 - 代理沙箱 · 每个代理的 gVisor 隔离 + 出站白名单 - 自定义 · 移植到我自己的技术栈；哪些文件更改以及为什么 - 补丁 · 为已验证的崩溃生成并验证修复 - 故障排除 · 重复项、速率限制、子代理模型固定 - 安全防护（https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude） · 阻止危险网络工作 — ## 逐步启动 与我们合作最成功的团队是那些最快上手实践的团队。虽然设计完美流水线很诱人，但我们建议从第一天开始小规模，然后随着经验的积累逐步构建。以下步骤遵循这种模式，并根据我们所见设定了一个雄心勃勃（但合理）的节奏。 | | | | |———————————————————————————––|–––––––|–––––––––––––––––––––––––––––––| | 步骤 1 | 第 1 天 | 构建威胁模型并运行首次静态扫描 + 分类 | | 步骤 2 | 第 2 天 | 在 C/C++ 库上运行参考流水线 | | 步骤 3 | 第 3-5 天 | 针对你的目标自定义流水线 | | 步骤 4 | 第 2 周 | 开始自主扫描、分类和打补丁 | ### 步骤 1（第 1 天）：构建威胁模型并运行首次静态扫描 + 分类 第 1 天的重点是端到端地查看整个循环。仅使用交互式技能，你将构建威胁模型，运行由其范围界定的静态扫描，对返回结果进行分类，并起草候选修复。当天结束时，你将获得威胁模型、静态发现排名列表以及候选补丁。相关技能仅读写你仓库中的文件。只要交互式运行 Claude Code 并批准每次工具使用，就不需要沙箱。 bash # 将每个子代理固定到所需模型 export CLAUDE_CODE_SUBAGENT_MODEL= 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（第 2 天）：在 C/C++ 库上运行参考流水线 第 2 天，你将从交互式技能过渡到使用参考流水线的首次自主运行。你将针对一个已知存在漏洞的开源库，在你的环境中运行完整的 recon → find → verify → report 循环，然后为其发现的漏洞生成候选补丁。当天结束时，你将获得一组可重现的崩溃、可利用性报告和候选补丁，并了解流水线的工作原理。运行流水线很简单： bash # 一次性设置 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；流水线需要在环境中设置 # 运行 recon → find → verify → report 循环 bin/vp-sandboxed run drlibs --model --runs 3 --parallel --stream --auto-focus # 为每个发现生成候选补丁 bin/vp-sandboxed patch results/drlibs// --model # 或者，让 Claude Code 启动流水线并为你监控运行 claude > 对 drlibs 运行流水线，并在发现到来时解释结果 循环的结果会放入 results/drlibs// 目录。使用 --stream 标志，第一份报告会在几分钟内出现在 reports/bug_NN/ 下。 > ⚠️ run 会生成自主代理。 流水线将每个代理运行在 gVisor 容器内，出站流量仅限于 Claude API。> 启动代理的子命令拒绝在容器外启动，除非明确覆盖。> 更多信息，请参见 docs/security.md > 和 docs/agent-sandbox.md。 在内部，流水线遍历七个阶段： 1. 构建：使用 ASAN（C 和 C++ 的内存错误检测器）将目标编译成 Docker 镜像。流水线在首次运行时使用目标的 Dockerfile 自动构建此镜像。 2. 侦察：一个轻量级代理在网络隔离的容器内读取源代码，并建议一个分区，即*“这里有 N 个不同的输入解析子系统值得分别攻击”，这样并行查找代理会探索不同区域，而不是集中在同一漏洞上。如果没有 --auto-focus 标志，流水线会使用目标 config.yaml 中 focus_areas 列表。 3. 发现：N 个代理并行运行，每个在自己的隔离容器内。每个代理读取源代码，构造畸形输入，并运行 ASAN 二进制文件，直到某个输入连续 3 次导致崩溃。 4. 验证：一个单独的评估代理在一个新的、查找代理未曾触及的容器中重现每个崩溃。从查找代理传递给评估代理的唯一内容是它产生的概念验证。 5. 去重：一个裁决代理将已验证的崩溃与已报告的漏洞进行比较，并决定每个是新漏洞、已知漏洞的更好示例，还是应跳过的重复项。 6. 报告：一个报告代理为每个唯一漏洞编写结构化的可利用性分析，包括原语类、可达性、升级路径和严重性细节。 7. 补丁（上面的单独补丁命令）：一个补丁代理编写建议修复，一个评估代理确认新代码构建成功、原始概念验证输入不再导致崩溃、目标的测试套件仍然通过，并且一个新的查找代理无法找到绕过修复的方法。 有关更多详细信息，请参见 docs/pipeline.md。 ### 步骤 3（第 3-5 天）：针对你的目标自定义流水线 在第 3-5 天，你将针对自己的目标自定义框架。首先将步骤 1 的技能指向你的代码，然后使用 /customize 将流水线移植到你的技术栈。到本周末，你将拥有一个 targets// 目录，流水线可以对其运行，并通过流水线的一次冒烟运行进行验证，准备在步骤 4 中扩展。 虽然参考流水线设计用于查找 C 和 C++ 代码中的内存漏洞，但其结构是通用的。将其移植到新的漏洞类别或语言只需为你的目标栈回答以下问题： | 问题 | C/C++ 参考 | 你的目标（示例） | |—————————————–|———————————–|————————————————| | 什么标志着一个发现？ | ASAN 崩溃签名 | 异常 / 标志文件 / DNS 回调 | | 概念验证长什么样？ | 导致崩溃的输入文件 | HTTP 请求序列 / 交易列表 / 测试框架 | | 如何构建和运行目标？ | Dockerfile（使用 clang + ASAN） | 你语言在容器中的构建 | 在自定义之前，先将步骤 1 的技能指向你自己的代码。提醒一下，它们仅读写，因此可以无需沙箱运行。 bash 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 技能，它会为你的代码库修改框架。 bash > /customize use ~/code/my-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md 当 /customize 完成后，你将拥有一个设置好的 targets/my-service/ 目录。在扩展之前，通过一次冒烟运行流水线进行验证。 bash bin/vp-sandboxed run my-service --model --runs 1 有关更多详细信息，请参见 docs/customizing.md。 ### 步骤 4（第 2 周）：开始自主扫描、分类和打补丁 在第 2 周，你将使用在步骤 3 中自定义的流水线处理自己的目标，在内层流水线循环之上添加一个外层*循环——运行多次流水线扫描，对来自这些运行的所有发现进行分类，根据优先级打补丁，然后重复。 bash # 扫描——针对你的目标运行一波并行运行 bin/vp-sandboxed run my-service --model --runs 5 --parallel --stream --auto-focus # 分类——使用你的威胁模型对所有波次中的每个发现进行去重和排名 > /triage results/my-service/ --repo ~/code/my-service --auto --votes 5 # 补丁——从分类排名最高的开始，生成并验证修复 > /patch results/my-service// --model > ⚠️ 遵循与 步骤 2 相同的沙箱指南 给定的流水线运行已经验证并去重了自身的发现。/triage 可以跨多个流水线运行工作。当指向 results/ 目录时，它会跨所有运行（以及 /vuln-scan 的任何静态发现，如果存在）折叠重复项，根据你的威胁模型重新校准严重性评级，并尝试将每个发现路由到组件所有者。 尽快修复发现有助于保持外层循环尽可能高效。当发现被修复后，模型无法再次找到它们，反而会暴露新的、通常更深层的问题。随着你运行更多波次流水线，发现数量可能会减少，但复杂性也可能会增加。如果无法快速打补丁，仅将之前的发现记录在目标的 known_bugs 中也可以帮助引导未来的运行朝着更新漏洞方向进行。 自主分类和打补丁仍是开放问题，此参考框架并未完全解决它们。/patch 中的验证策略有助于提高门槛，但严重性和优先级最终是对你环境的判断，并且已验证的补丁并不总是可上游的。许多合作伙伴报告说这些步骤是当前瓶颈，你应该为此预留实际的工程时间。 有关更多详细信息，请参见 docs/triage.md 和 docs/patching.md。 ## 展望未来 在初始启动之后，与我们合作的团队倾向于在几个方向上进行投资： 1. 审查所有内部仓库和关键开源依赖项，排序哪些最重要进行扫描（例如，基于其暴露面、CVE 历史、业务关键性），然后按优先级顺序扫描清单。 2. 设置专用扫描基础设施，将扫描从笔记本电脑或一次性虚拟机中移出。最成功的团队在扩展之前抵制住构建完美扫描平台的冲动。 3. 将扫描纳入其 SDLC。一些团队设置了定期扫描（例如，每天、每周）或将扫描添加到其 CI 流水线中。 4. 测试和试验模型，以找到最适合他们的方法。