scadastrangelove/rust-in-peace

# rust-in-peace 🦀🤘 **面向 Rust 的 Agentic 安全审查。** 一个自主的 侦察 → 发现 → 分流 → 报告 → 修复循环，专注于真正具有破坏性的 bug Rust：`unsafe`/FFI 中的内存安全性、来自不受信任输入的 panic-DoS，以及 解析器/反序列化信任（完整性检查不是边界检查）。 检测器：**Miri**（未定义行为）、**AddressSanitizer**、**panic/abort**、 和 **hang-timeout** —— 外加用于可达性的 `cargo-fuzz`。 [](LICENSE)   ## 此 fork 新增的内容 - 一个 **profile 注册表**（`harness/profiles.py`）：流水线从目标 `config.yaml` 中的 `profile:` 字段解析其 特定语言/检测器的部分（find 提示词、崩溃检测器、grade/judge/ report/patch 提示词）。 `cpp` 是默认值；**`rust`** 是完整的第二个 profile。 - **`rust` profile**（`harness/rust/`）：一个 Rust find 提示词，一个 Miri/panic/ASAN/hang 崩溃检测器，针对 Rust 调优的 grade/judge/report/patch 提示词，以及交互式技能调整（`/vuln-scan --extra`, `/triage --fp-rules`）。请参阅 [profiles/rust/README.md](profiles/rust/README.md)。 - 一个可运行的 **`rust-canary`** 演示目标（`targets/rust-canary/`）：一个 故意设计存在漏洞的 crate，包含植入的 unsafe-OOB / panic-DoS / 无界循环 bug 和一个安全诱饵（一个分流误报）。 ## 快速开始 交互式技能 —— 只读，无需 Docker，现在即可使用（在 Claude Code 中的仓库根目录下）： ``` /vuln-scan /src --extra profiles/rust/scan-extras.txt /triage VULN-FINDINGS.json --fp-rules profiles/rust/fp-rules.txt ``` 在演示目标上运行自主流水线（执行代码 —— 在沙箱中运行）： ``` docker build -t vuln-pipeline-rust-canary:latest targets/rust-canary # rust-canary/config.yaml 设置 `profile: rust`；针对它运行 pipeline。 ``` 添加另一种语言 = 一个新的 `harness//` 包 + `harness/profiles.py` 中的一个 `Profile` 条目；编排逻辑保持不变。完整详情： [profiles/rust/README.md](profiles/rust/README.md)。 ## 目录 - **Claude Code 技能**: `/quickstart`, `/threat-model`, `/vuln-scan`, `/triage`, `/patch`, `/customize`: 交互式的范围界定、扫描、分流 和修复。在 Claude Code 中打开此仓库并运行 `/quickstart` 以 熟悉环境。 - **`harness/`**: 自主参考流水线（侦察 → 发现 → 验证 → 报告 → 修复），配置为使用 Docker 和 ASAN 查找 C/C++ 内存漏洞。 此 harness 是一个**参考，而非产品**。 其整体结构、提示词和沙箱机制是可重用的，但该 harness 无法开箱即用地在所有代码库上运行。运行 `/customize` 将其移植 到您的语言、检测器或漏洞类别。 - **Profiles** (`harness/profiles.py`): 流水线根据目标 `config.yaml` 中的 `profile:` 字段选择其 特定语言/检测器的部分（find 提示词、崩溃检测器、grade/judge/ report/patch 提示词）。 `cpp` (C/C++ + ASAN) 是默认值；**`rust`** 是针对 Rust 安全的完整实战 fork —— Miri / sanitizer / panic / hang 检测器以及 Rust bug 分类法 (unsafe/FFI, panic-DoS, 反序列化信任)。请参阅 [profiles/rust/README.md](profiles/rust/README.md) 和 `targets/rust-canary` 演示目标。添加另一种语言 = 一个新的 `harness//` 包 + 一个 注册表条目；编排逻辑保持不变。 ## 入门指南 ``` git clone https://github.com/scadastrangelove/rust-in-peace cd rust-in-peace claude # 30秒介绍 + 针对 canary 目标的引导式首次运行 > /quickstart # Rust：使用 rust profile 的 brief / triage 规则扫描 crate > /vuln-scan path/to/crate/src --extra profiles/rust/scan-extras.txt > /triage VULN-FINDINGS.json --fp-rules profiles/rust/fp-rules.txt ``` ## 延伸阅读 - [**博客文章**](docs/blog-post.md) · 包含经验总结和最佳实践的配套博文 - [**流水线**](docs/pipeline.md) · 工作原理：图表、阶段、CLI flags - [**安全**](docs/security.md) · 沙箱机制以及不应挂载的内容 - [**Agent 沙箱**](docs/agent-sandbox.md) · 为每个 agent 提供 gVisor 隔离 + 出站白名单 - [**自定义**](docs/customizing.md) · 移植到我的技术栈；更改了哪些文件及其原因 - [**Rust profile**](profiles/rust/README.md) · 针对 Rust 安全的实战 fork（unsafe/FFI, panic-DoS, 反序列化信任）—— Miri / sanitizer / panic / hang 检测器，通过 `profile: rust` 选择 - [**补丁**](docs/patching.md) · 为已验证的崩溃生成并验证修复 - [**故障排除**](docs/troubleshooting.md) · 重复项、速率限制、子 agent 模型固定 - [**安全防护**](https://support.claude.com/en/articles/14604842-real-time-cyber-safeguards-on-claude) · 针对危险网络工作的阻断机制 ## 快速提升 我们合作过的最成功的安全团队是那些 最快上手实践的团队。虽然花几个月时间 设计完美的流水线很诱人，但我们建议在第 1 天 从小处着手，并随着经验积累逐步构建。以下 步骤遵循该模式，并根据我们的经验设定了雄心勃勃（但合理）的 节奏。 | | | | |-------------------------------------------------------------------------------------|--------------|--------------------------------------------------------------| | [步骤 1](#step-1-day-1-build-a-threat-model-and-run-your-first-static-scan--triage) | **第 1 天** | 构建威胁模型并运行您的首次静态扫描 + 分流 | | [步骤 2](#step-2-day-2-run-the-reference-pipeline-on-a-cc-library) | **第 2 天** | 在 C/C++ 库上运行参考流水线 | | [步骤 3](#step-3-days-3-5-customize-the-pipeline-for-your-target) | **第 3-5 天** | 为您的目标自定义流水线 | | [步骤 4](#step-4-week-2-start-autonomous-scanning-triage-and-patching) | **第 2 周** | 开始自主扫描、分流和修复 | ### 步骤 1（第 1 天）：构建威胁模型并运行您的首次静态扫描 + 分流 第 1 天的重点是查看端到端的整个循环。仅使用 交互式技能，您将构建一个威胁模型，运行由其界定范围的静态扫描， 对返回的结果进行分流，并起草候选修复方案。您将在 这一天结束时获得一个威胁模型、一个排序后的静态发现列表以及候选 补丁。 相关技能**仅读取和写入**您仓库中的文件。只要您 以交互方式运行 Claude Code 并批准每次工具使用，就无需沙箱。 ``` # 将每个 subagent 固定到您想要的 model export CLAUDE_CODE_SUBAGENT_MODEL= claude # 0. 介绍 + 引导式首次运行 > /quickstart # 1. 构建 threat model（先瞄准再射击） > /threat-model bootstrap targets/canary # 2. 运行静态扫描，由该 threat model 确定范围 > /vuln-scan targets/canary # 3. 验证、去重并对返回结果进行排名 > /triage targets/canary/VULN-FINDINGS.json # 4. 为已验证的 findings 生成候选修复 > /patch ./TRIAGE.json --repo targets/canary ``` 此流程会生成 `THREAT_MODEL.md`, `VULN-FINDINGS.{json,md}`, `TRIAGE.{json,md}` 和 `PATCHES/`。 步骤 1 中产生的漏洞候选来自 Claude 对源代码的静态 审查（不构建或运行任何内容），因此预期在任何非 canary 的目标上 会有更多误报。在步骤 2 中，您将产生*经执行验证的*发现。 ### 步骤 2（第 2 天）：在 C/C++ 库上运行参考流水线 在第 2 天，您将从交互式技能过渡到首次使用 参考流水线进行自主运行。您将在您的环境中对一个已知存在漏洞的开源 库运行完整的 侦察 → 发现 → 验证 → 报告 循环，然后针对发现的结果生成一个候选补丁。完成后，您将获得 一组可重现的崩溃、可利用性报告和候选补丁， 同时对流水线的运作方式有所了解。 运行流水线很简单： ``` # 一次性设置 python3 -m venv .venv && .venv/bin/pip install -e . ./scripts/setup_sandbox.sh # installs gVisor, builds the agent images, and verifies isolation; note: requires Docker export ANTHROPIC_API_KEY=sk-ant-... # or CLAUDE_CODE_OAUTH_TOKEN, or Bedrock — see docs/agent-sandbox.md # 运行 recon → find → verify → report 循环 bin/vp-sandboxed run drlibs --model --runs 3 --parallel --stream --auto-focus # 为每个 finding 生成候选 patch bin/vp-sandboxed patch results/drlibs// --model # 或者，要求 Claude Code 启动 pipeline 并为您监控运行 claude > run the pipeline on drlibs and explain findings as they come ``` 循环的结果将落在 `results/drlibs//` 目录中。使用 `--stream` flag，第一份报告将在几分钟内出现在 `reports/bug_NN/` 下。 在底层，流水线分为七个阶段进行： 1. **Build**: 将目标编译为带有 ASAN 的 Docker 镜像（用于 C 和 C++ 的内存 错误检测器）。流水线在首次运行时使用目标的 `Dockerfile` 自动 构建此镜像。 2. **Recon**: 一个轻量级 agent 读取网络隔离 容器内的源代码，并提出一个分区方案，即*“这里有 N 个独立的、值得单独攻击的输入解析 子系统”*，以便并行的 find agent 探索 不同区域，而不是集中在同一个 bug 上。如果没有 `--auto-focus` flag，流水线会使用目标 `config.yaml` 中的 `focus_areas` 列表。 3. **Find**: N 个 agent 并行运行，每个都在自己独立的容器中。 每个 agent 读取源代码，构造畸形的输入，并运行 ASAN 二进制文件，直到给定的输入连续 3 次产生崩溃。 4. **Verify**: 一个独立的 grader agent 在一个 find agent 从未接触过的全新 容器中重现每次崩溃。从 find agent 传递给 grader 的唯一内容就是它生成的概念验证。 5. **Dedupe**: 一个 judge agent 将验证后的崩溃与已报告的 bug 进行比较， 并决定每个崩溃是一个新 bug、一个已知 bug 的更好示例， 还是一个应跳过的重复项。 6. **Report**: 一个 report agent 为 每个独特的 bug 编写结构化的可利用性分析，包括基元类、可达性、升级 路径和严重性等细节。 7. **Patch**（上面的独立 patch 命令）：一个 patch agent 编写提议的 修复，grader agent 确认新代码能构建、原始的 概念验证输入不再崩溃、目标的测试套件仍然 通过，并且新的 find agent 无法找到绕过修复的方法。 有关更多详细信息，请参阅 [docs/pipeline.md](docs/pipeline.md)。 ### 步骤 3（第 3-5 天）：为您的目标自定义流水线 在第 3-5 天，您将为自己的目标自定义 harness。首先，您 将步骤 1 的技能指向您的代码，然后您将使用 `/customize` 将 流水线移植到您的技术栈。到本周末，您将拥有一个流水线可以对其运行的 `targets//` 目录，并通过对流水线的一次冒烟测试验证了该目录，准备好在步骤 4 中扩展规模。 虽然参考流水线是为查找 C 和 C++ 代码中的内存漏洞而设计的，但其结构是通用的。将其移植到新的漏洞类别或语言只需为您的目标技术栈回答以下问题： | 问题 | C/C++ 参考 | 您的目标（示例） | |-----------------------------------------|-----------------------------------|------------------------------------------------| | 什么标志着一个发现？ | ASAN 崩溃签名 | 异常 / canary 文件 / DNS 回调 | | 概念验证是什么样的？ | 崩溃的输入文件 | HTTP 请求序列 / 交易列表 / 测试 harness | | 目标如何构建和运行？ | `Dockerfile`（使用 clang + ASAN） | 您的语言在容器中的构建 | 在自定义之前，将步骤 1 的技能指向您自己的代码。提醒一下， 它们是只读和只写的，因此可以在非沙箱环境中运行。 ``` claude > /quickstart how do I customize this for ~/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` 技能中使用这些技能生成的产物， 它会为您的代码库修改 harness。 ``` > /customize use ~/code/my-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md ``` 当 `/customize` 完成后，您将拥有一个设置好的 `targets/my-service/` 目录。在扩展规模之前，用一次流水线的冒烟测试来验证它。 ``` bin/vp-sandboxed run my-service --model --runs 1 ``` 有关更多详细信息，请参阅 [docs/customizing.md](docs/customizing.md)。 ### 步骤 4（第 2 周）：开始自主扫描、分流和修复 在第 2 周，您将在自己的目标上使用在步骤 3 中自定义的流水线，为内部流水线循环添加一个*外部*循环 —— 运行多次 流水线扫描，对这些运行中的发现进行分流，根据 优先级进行修复，然后重复。 ``` # Scan - 针对您的目标运行一批并行运行 bin/vp-sandboxed run my-service --model --runs 5 --parallel --stream --auto-focus # Triage - 使用您的 threat model 对所有波次中的每个 finding 进行去重和排名 > /triage results/my-service/ --repo ~/code/my-service --auto --votes 5 # Patch - 生成并验证修复，从 triage 排名最高的开始 > /patch results/my-service// --model ``` 给定的流水线运行已经验证并去重了其自身的发现。 `/triage` 可跨多次流水线运行工作。当指向 `results/` 目录时，它会折叠所有运行中的重复项（如果存在，还有来自 `/vuln-scan` 的任何静态发现），根据您的威胁模型重新校准严重性评级，并尝试将每个发现路由给组件所有者。在可能的情况下，快速修复发现有助于保持外部循环 尽可能高效。当发现被修复后，模型无法重新发现 它们，而是会展示全新的、通常更深层次的问题。随着您运行 更多的流水线波次，发现的数量可能会减少， 复杂性可能也会增加。如果无法进行快速修复，即使 只是在目标的 `known_bugs` 中记录先前的发现，也有助于引导 未来的运行趋向于更新的 bug。 自主分流和修复仍然是悬而未决的问题，这个参考 harness 并没有完全解决它们。`/patch` 中的验证策略 有助于提高门槛，但严重性和优先级最终是 对您环境的判断，而且已验证的补丁并不总是 能向上游提交。许多合作伙伴报告称这些步骤是目前的 瓶颈，您应该为它们预留充足的工程时间。 有关更多详细信息，请参阅 [docs/triage.md](docs/triage.md) 和 [docs/patching.md](docs/patching.md)。 ## 展望未来 在初始阶段提升之后，与我们合作的团队倾向于投资于 几个方向： 1. 审查他们所有的内部仓库和关键的开源依赖项， 排列哪些最重要并需要扫描（例如，基于其暴露程度、 CVE 历史记录、业务关键性），然后按照优先级顺序依次扫描列表。 2. 建立专门的基础设施进行扫描，以将扫描任务从笔记本电脑 或一次性虚拟机中转移出来。最成功的团队抵制了在扩展规模之前构建完美 扫描平台的冲动。 3. 将扫描纳入其 SDLC。一些团队设置了定期扫描 （例如，每天、每周），或者将扫描添加到他们的 CI 流水线中。 4. 对模型进行测试和试验，以找出最适合他们的方案。 ## 联系方式 此 fork 的维护者 — **Sergey Gordeychik**: - Email: [scadastrangelove@gmail.com](mailto:scadastrangelove@gmail.com) - X/Twitter: [@scadasl](https://x.com/scadasl) - 博客: [scadastrangelove.blogspot.com](https://scadastrangelove.blogspot.com/) 欢迎在此 fork 上提出 Issues 和 pull requests。有关上游的 C/C++ 参考流水线，请参阅 [anthropics/defending-code-reference-harness](https://github.com/anthropics/defending-code-reference-harness)。 ## License Apache-2.0 — 参阅 [LICENSE](LICENSE)。这是 Anthropic 的 defending-code-reference-harness 的一个 fork；保留了上游的版权和许可。

标签：AI代理, Rust, 云安全监控, 代码安全审计, 内存安全, 可视化界面, 网络流量审计, 自动化漏洞修复, 请求拦截, 逆向工具, 静态分析