cargo-fuzz

cargo-fuzz 技能概覽

cargo-fuzz 是給 Rust/Cargo fuzzing 的技能，適合想要用實際可落地的方式建立 libFuzzer harness、搭配正確編譯旗標執行，並找出應用程式程式碼或 unsafe 邊界 crash 的團隊。它特別適合維護者、安全工程師與 Rust 開發者，用在 Security Audit、回歸問題追查，或發佈前強化。

最重要的判斷點是適配度：如果你的程式庫本來就用 Cargo，而且你想要一套低摩擦、支援 sanitizer 的 fuzzing 流程，cargo-fuzz 通常是最快的路徑。若你需要非 Cargo 目標、客製化編排，或偏研究型的環境，這個技能通常不是最好的起點。

cargo-fuzz 最適合的用途

當你需要快速上手、可重現的 harness，以及標準 Rust 工作流程，而不是自己手動拼裝 libFuzzer 時，就該用 cargo-fuzz。它能讓你把注意力放在測試輸入與不變量上，而不是工具鏈的接線細節。

cargo-fuzz 在安全工作中的位置

在 cargo-fuzz 用於 Security Audit 時，它的價值在於找出解析錯誤、panic、unsafe 程式碼中的記憶體安全問題，以及圍繞不受信任輸入的邏輯錯誤。當你能定義一個清楚的函式邊界，接受 bytes，且理論上不應該 crash 時，它尤其有用。

什麼情況下不適合用 cargo-fuzz

如果目標不是基於 Cargo、你先需要分散式 fuzzing 基礎設施，或你的輸入很難縮成一個 byte slice 和 deterministic harness，就先不要選 cargo-fuzz。在這些情況下，一般性的 prompt 或其他 fuzzing 工具可能更合適。

如何使用 cargo-fuzz 技能

安裝並確認預期的工具鏈

依照技能內容中的 cargo-fuzz 安裝路徑進行，接著確認你已透過 rustup 安裝 Rust，並且能使用 nightly toolchain。這裡最重要的限制是 cargo-fuzz 依賴 nightly-only 的行為，所以如果環境只有 stable，會很早就卡住。

把模糊的目標改寫成有用的 prompt

把具體目標、函式或 parser 邊界、輸入型態，以及你在意的失敗模式都提供給技能。好的 prompt 例如：「幫 mycrate::parse_packet 建立 cargo-fuzz harness，重點放在格式錯誤的長度欄位與不發生 panic 的處理，並假設專案已經使用 serde 和 bytes。」這會比「幫我的 Rust app 做 fuzzing」有效得多。

先讀這些檔案

先從 SKILL.md 開始，再查看專案的 README.md、Cargo.toml，以及如果已存在的話，生成的 fuzz/ 目錄。對 cargo-fuzz 來說，最關鍵的是 fuzz/fuzz_targets/ 底下的 harness、fuzz workspace 設定，以及任何定義可接受輸入和錯誤處理的程式碼路徑。

用窄一點的工作流程，結果通常更好

先從一個目標函式、一個 harness、以及一個清楚的不變量開始，例如「不能 panic」、「必須安全地拒絕無效 frame」，或「有效輸入必須能 round-trip」。接著執行 fuzzer、檢查第一個 crash、把 reproducer 最小化，只有在第一條路徑穩定後，才擴展到新的目標。

cargo-fuzz 技能 FAQ

我需要先有 Rust 專案嗎？

需要。cargo-fuzz 是為基於 Cargo 的 Rust repository 設計的，所以如果專案沒有 Rust workspace，或程式碼無法從 Rust harness 呼叫，就不適合。

cargo-fuzz 只能做安全測試嗎？

不是，但安全性確實是最常見的使用原因。你也可以用 cargo-fuzz 來強化 parser、驗證假設，並找出處理不受信任或複雜輸入時的回歸問題。

cargo-fuzz 跟一般性的 prompt 有什麼不同？

一般性的 prompt 可以描述 fuzzing，但 cargo-fuzz 提供的是具體的 Rust 工作流程：怎麼建立 harness、生成檔案放在哪裡，以及哪些工具鏈限制最重要。當你需要的是一個真的能跑起來的東西，這會大幅減少猜測。

cargo-fuzz 適合新手嗎？

如果你已經知道想測試哪段 Rust code path，那是適合的。最難的通常不是工具，而是挑到好的目標函式，並寫出一次只隔離一種行為的 harness。

如何改進 cargo-fuzz 技能

提供更明確的目標邊界

cargo-fuzz 最好的結果，通常來自單一 public API、parser、decoder，或帶有清楚 bytes 型輸入的狀態轉換。如果你直接丟一整個應用程式、卻沒有邊界，harness 會更雜，結果也更難重現。

先把不變量與失敗規則講清楚

直接告訴技能什麼算 bug：panic、hang、越界存取、無效狀態，或非預期的 mutation。對 cargo-fuzz for Security Audit 來說這很重要，因為同一份輸入，依你定義的 contract 不同，可能只是正常拒絕，也可能是真正的問題。

第一輪跑完後，預期還要迭代

第一版輸出通常只是起始 harness，不會是最終版。你可以透過刪掉無關的初始化、加入反映真實流量的 corpus seeds，並進一步縮小目標，讓 crash 變得有意義，而不是只剩一般性的 parser 失敗。

以 repository 證據為準，不要靠猜

如果 repo 裡已經有範例、既有測試、feature flags，或 unsafe code 的熱點，把這些直接提供給 prompt。cargo-fuzz 技能的輸出，在你明確指出真正重要的檔案、函式或錯誤路徑時會好得多，而不是只丟 crate 名稱，讓它自己猜全部內容。