手把手搭建自动化安全扫描管线

手把手搭建自动化安全扫描管线

每次发版前手动过一遍 SonarQube 和 SAST 扫描结果是什么样的体验？几百条告警堆在一起，真正需要修的可能就十几条，剩下的全是误报。更烦人的是，每次都要重复解释上下文、翻文档确认是否可忽略。

如果你也被这件事折磨过，这篇教程就是为你写的。我会带你用 Anthropic 官方开源的 defending-code-reference-harness，一步步跑通一条完整的安全扫描管线：威胁建模 → 自动扫描 → 智能分诊 → 修复候选生成。整个过程大约花一两天，跑通后你可以直接把这套模式复用到自己的项目里。

本文所有操作均可在本地完成，扫描阶段不涉及生产代码。

环境准备

开始前需要准备好以下环境：

• Claude Code：Anthropic 的 CLI 编码代理，需要 Claude API 访问权限（Direct API Key 或 Bedrock/Vertex/Azure）
• Docker：自主管线需要在隔离容器中运行目标代码
• Python 3.10+：管线调度脚本运行依赖
• gVisor：谷歌沙箱方案，用于隔离自主扫描代理（脚本会自动安装）

你需要能看懂 Dockerfile、理解基本的威胁建模概念（攻击面、信任边界）。不需要是安全专家，普通后端开发者完全跟得上。

克隆项目并安装依赖：

git clone https://github.com/anthropics/defending-code-reference-harness
cd defending-code-reference-harness
python3 -m venv .venv && .venv/bin/pip install -e .
./scripts/setup_sandbox.sh
export ANTHROPIC_API_KEY=sk-ant-...
export CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-20250514

第一步：交互式 Skills 跑通静态扫描回路

先不用自动管线，通过 Claude Code 的交互式 Skills 把流程跑一遍。这一步只读写文件，不需要沙箱环境。

claude

进入 Claude Code 后，执行 /quickstart 了解项目结构。这个 skill 会引导你完成一次完整的端到端体验。

1. 建立威胁模型

扫描前先建立威胁模型，回答「系统的攻击面在哪里、什么算高危」这两个核心问题。

## 在 Claude Code 交互界面中执行
> /threat-model bootstrap targets/canary

这一步会分析目标代码库（targets/canary 是示例目标），生成 THREAT_MODEL.md，标注组件边界、信任边界和高危路径。后续扫描和分诊都会参考这份文档过滤误报。

2. 执行静态扫描

> /vuln-scan targets/canary

扫描是静态的——不编译、不运行，靠 Claude 阅读源码发现潜在漏洞。输出会写入 targets/canary/VULN-FINDINGS.json 和对应的 Markdown 报告。

3. 分诊去重

> /triage targets/canary/VULN-FINDINGS.json

这一步完成三件事：验证（确认是否是真的漏洞）、去重（合并相似发现）、分级（按严重程度排序）。最后产出 TRIAGE.json 和 TRIAGE.md。

canary 目标是故意写有漏洞的演示代码，/triage 会正确地把测试代码中的 bug 标记为误报。想看完整的 confirm/dedupe/false-positive 流程，可以指向自己的代码库试试。

4. 生成修复建议

> /patch ./TRIAGE.json --repo targets/canary

/patch 读取分诊结果，为每个确认的漏洞生成候选修复，输出到 PATCHES/ 目录。这只是候选补丁，不是直接合入的代码，仍然需要人工 review。

跑完这四步，工作目录里应该有了：THREAT_MODEL.md、VULN-FINDINGS.{json,md}、TRIAGE.{json,md}、以及 PATCHES/。交互式流程已经跑通。

第二步：运行自主管线

接下来运行执行验证级别的管线——真正编译、运行目标代码，用 AddressSanitizer (ASAN) 捕获内存错误。

bin/vp-sandboxed run drlibs --model <model-id> --runs 3 --parallel --stream --auto-focus

这条命令并行启动 3 个独立的 find agent，每个都在 gVisor 隔离容器中以 ASAN 模式运行目标库。--stream 实时展示进展，--auto-focus 让 pipeline 自动发现代码中的不同子系统来并行探索。

管线内部的七步流程：

扫描完成后生成修复：

bin/vp-sandboxed patch results/drlibs/<timestamp>/ --model <model-id>

结果输出到 results/drlibs/<timestamp>/ 目录。你也可以在运行过程中让 Claude Code 实时解释发现：

claude
> run the pipeline on drlibs and explain findings as they come

迁移到你的 Java Spring Boot 项目

参考管线默认针对 C/C++ 内存漏洞，但架构是通用的。迁移到 Java 需要回答三个问题：

1. 什么信号算一个发现？ C/C++ 中是 ASAN 崩溃签名；Java 中可以是未捕获异常、Canary 文件被写入、或者特定 DNS callback
2. PoC 长什么样？ C/C++ 是 crash input file；Java 中可以是 HTTP request 序列、事务列表、或测试 harness
3. 怎么编译运行？ 用你的构建工具放进 Docker 即可

操作步骤：

claude

## 先把 Skills 指向你自己的代码
> /threat-model bootstrap-then-interview ~/code/my-spring-service
> /vuln-scan ~/code/my-spring-service
> /triage ~/code/my-spring-service/VULN-FINDINGS.json --repo ~/code/my-spring-service

## 用 /customize 让管线适配你的技术栈
> /customize use ~/code/my-spring-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md

/customize 完成后会生成 targets/my-spring-service/ 目录。用一次冒烟运行验证：

bin/vp-sandboxed run my-spring-service --model <model-id> --runs 1

Java 项目需要准备一个 Dockerfile，包含 Maven/Gradle 构建步骤、JVM 启动参数设置（比如启用安全管理器）、以及你的 PoC 验证脚本。管线会用这个 Dockerfile 在容器中构建目标。

踩坑提醒

1. 沙箱是强制的：run 和 patch 命令会在 gVisor 容器中执行目标代码，没有正确设置沙箱环境命令会拒绝执行。务必先跑 ./scripts/setup_sandbox.sh
2. 子代理模型选择：执行任何管线命令前设置 CLAUDE_CODE_SUBAGENT_MODEL，否则子代理可能使用不合适的模型
3. 重复发现：多次运行管线时 /triage 会跨轮次去重。把已确认的漏洞记录到 known_bugs 中，让后续扫描专注于新发现的问题
4. 扫描不是万能的：即使经过验证，发现结果仍然需要人工 review。严重等级的判断和你的实际部署环境强相关
5. 速率限制：大规模并行扫描可能触发 API 速率限制。建议从 --runs 2 开始，逐步增加

总结

今天我们完成了一整套安全扫描管线的搭建：先用交互式 Skills 走通了威胁建模→静态扫描→分诊→修复建议的端到端流程，再跑了基于执行验证的自主管线，最后讨论了如何把管线迁移到 Java 技术栈。

这套模式的核心价值在于建立了可迭代的安全扫描方法论：先建立威胁模型缩小攻击面，用执行验证过滤误报，通过跨轮次去重聚焦新发现的问题，最后生成候选修复但保留人类 review 的把关权。

选一个你团队内部真实的项目（不需要很大），用 /quickstart 引导把它接入管线。跑完第一轮后，你会对项目的安全面有全新的认识。

项目地址：https://github.com/anthropics/defending-code-reference-harness

Anthropic 在 GitHub 注明该项目不接受贡献，但它本身是一个优秀的参考实现。如果你对自动化安全扫描感兴趣，建议同时关注 Claude Security（Anthropic 的托管安全扫描产品），以及他们配套发布的最佳实践文档。