前言¶

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