前言¶

Rust 在基础设施与 ToB 产品里用得越来越多，但「能编译过」不等于「可安全上线」。unsafe、FFI、并发与异步运行时一旦写错，借用检查器帮不上忙；服务端里可触发的 panic 还会变成拒绝服务面。人工按检查清单扫 crate 又慢，且容易漏类。下面介绍 Trail of Bits 在 Claude Code / Codex 插件市场里提供的 rust-review：用编排式多子代理做系统化 Rust 安全审查，并输出 SARIF 与可读报告。

这是什么¶

rust-review 是 Trail of Bits Skills Marketplace 里「Code Auditing」类插件下的 Skill，官方路径为：

https://github.com/trailofbits/skills/tree/main/plugins/rust-review/skills/rust-review

一句话定位：对 Rust 应用、服务或库做全面安全审查，覆盖 safe/unsafe 边界、unsafe 块内内存安全、并发风险、panic 导致的 DoS、FFI 安全与 async 运行时误用；适合审计带 unsafe、FFI 或并发代码的 crate。审查结果以共享输出目录中的 markdown-with-YAML findings 交换，最终生成 REPORT.md 与 REPORT.sarif。

在主对话中通过斜杠命令调用：

/rust-review:rust-review

编排器（orchestrator）负责 Task* 台账与重试；工作者与裁判为命名插件子代理，工具集在 plugins/rust-review/agents/*.md 中声明。

核心功能¶

审查范围（官方 When to Use）¶

• safe/unsafe 边界审计
• unsafe 块内内存安全
• 并发危害
• 服务端 panic 诱导的 DoS
• FFI 安全
• async 运行时相关错误

子代理分工¶

工作者与 fp-judge 通过 Bash 下的 find / rg / grep 做路径与搜索；cluster 种子使用 ripgrep 正则语法时须用 rg（未安装会明确报错，可回退到 grep -E 并改用 POSIX 字符类）。dedup-judge 无 Bash，故使用 Glob。

运行架构（概要）¶

协调器大致流程：写 context.md → 运行 build_run_plan.py → 创建多个 Task → 前台 spawn primer → 并行 spawn 多个 worker → 归类 Phase-7 结果并写 findings-index.txt → dedup-judge → fp-judge → 生成 SARIF 与 REPORT.md 的安全网 → 返回 REPORT.md。

输出目录常见产物包括：context.md、plan.json、worker-prompts/、findings/、findings-index.txt、coverage/、run-summary.md、dedup-summary.md、fp-summary.md、REPORT.md、REPORT.sarif。

作用域约定（审查时须区分）：

• finding_scope_root：用户指定的审计子树；仅能在该子树内登记漏洞位置。
• context_roots：只读上下文根，用于验证可达性、调用方、缓解措施等；默认可为 .，除非用户禁止扩大阅读范围。

插件根目录需解析为 RUST_REVIEW_PLUGIN_ROOT（含 prompts/clusters/unsafe-boundary.md 与 scripts/build_run_plan.py）；后续阶段通过 ${RUST_REVIEW_PLUGIN_ROOT}/scripts/*.py 调用脚本，build_run_plan.py 是 cluster 选择与渲染的唯一权威，不应手写替代计划。

明确不覆盖的能力¶

官方 When NOT to Use 包括：

• 纯 C / 纯 C++ 代码库 → 用 c-review
• Solana / NEAR / Ink! 等智能合约 → 用对应合约类 Skill
• 无用户态分配器的内核态 Rust 驱动 → 覆盖不完整，仅作建议性标注
• 密钥内存清零（Zeroize、secrecy 等）→ 用 zeroize-audit；rust-review 不覆盖内存清零审计

即便 has_unsafe=false，仍应运行始终启用的 cluster（如 panic-DoS、原子竞态等）；memory-safety cluster 由规划器在 has_unsafe=true 时纳入，unsafe-boundary cluster 无 requires 且始终运行。

安装与启用¶

Skill 随 trailofbits/skills 市场安装，而非单独 git clone 某子目录。

Claude Code Marketplace：

/plugin marketplace add trailofbits/skills

浏览并安装插件：

/plugin menu

Codex（支持 Claude 插件市场兼容）：

codex plugin marketplace add trailofbits/skills
codex plugin list
codex plugin add <plugin-name>@trailofbits

本地开发时，在仓库父目录执行：

cd /path/to/parent
/plugins marketplace add ./skills

资料中未给出 Cursor 专用安装步骤；若你在 Cursor 中使用同类插件机制，以当前环境的市场/插件文档为准。

典型用法¶

1. 在 Claude Code 或已加载该市场的 Codex 中安装 rust-review 插件（见上节）。
2. 打开待审计的 Rust 仓库，明确审计子树（对应 finding_scope_root）与是否允许阅读更广上下文（context_roots）。
3. 在主对话执行：

   /rust-review:rust-review

4. 按 Skill 流程完成 context、运行 build_run_plan.py、并行 worker、两轮 judge 与 Phase 8 报告；在输出目录查看 REPORT.md 与 REPORT.sarif，将 SARIF 接入现有 SAST/缺陷跟踪流水线（与团队使用的 SARIF 消费工具配合）。

编排器 allowed-tools 包括：Agent、AskUserQuestion、SendMessage、TaskCreate、TaskUpdate、TaskList、Read、Write、Bash。

适用场景与注意¶

适合：

• 审计 Rust crate、服务或库，尤其含 unsafe、FFI、并发或 async 的代码
• 需要结构化产出（SARIF + 人类可读报告）的 ToB 安全审查或内审
• 与 Trail of Bits 同仓库内的 c-review、zeroize-audit、static-analysis 等 Skill 按语言与主题分工协作

注意：

• 勿用「编译器已过」替代对 unsafe、panic 可达性、FFI ABI、并发序等的审查。
• 任一 Phase-5 cluster 未完成时，不应伪装成全量成功的报告；应在 run-summary.md 与最终回复中突出未完成项。
• 即使零 findings，仍须运行 dedup-judge、fp-judge 与 Phase 8b。
• Worker 并行 spawn 时默认不要对 worker 使用 run_in_background=true，以免破坏 primer 缓存、重复消耗约 15K token 的 primer。

结尾¶

rust-review 把 Rust 里借用检查器管不到的几类风险（unsafe/FFI、并发、panic-DoS、async 误用）做成可编排、可出 SARIF 的审查流程，和纯 C 审查、密钥清零审计等 Skill 边界清晰。官方 Skill 说明与插件结构见：

https://github.com/trailofbits/skills/tree/main/plugins/rust-review/skills/rust-review

市场安装入口：

https://github.com/trailofbits/skills