GitHub 推出 AI 驅動的模糊測試自動化工具 Fuzzing Taskflow Agent

GitHub Security Lab 發布了 Fuzzing Taskflow Agent，一個由大型語言模型（LLM）驅動的自動化安全測試工具。這工具針對 C/C++ 專案設計，能自主跑完從識別測試入口點到生成漏洞報告的整套模糊測試流程。

核心功能

Fuzzing Taskflow Agent 的運作方式不複雜。使用者只要指向一個 GitHub 儲存庫，工具就會自動執行後續所有步驟：識別合適的入口點、分析編譯系統、寫測試程式碼、跑 AFL++ 模糊測試、讀覆蓋率報告、改進測試程式碼、把所有崩潰分類，並為每個獨特的漏洞生成詳細報告。整個過程不需要人工介入。

這工具是基於 GitHub Security Lab Taskflow Agent 框架打造的，這個框架專門用來寫 LLM 驅動的安全自動化。模糊測試流程被拆成一組任務流，由代理端對端執行。

使用方式與安全考量

使用者可以到 GitHub 上的 seclab-taskflows-fuzzing 儲存庫，啟動 Codespace 來跑這個工具。基本執行指令是 `./scripts/fuzzing/run_fuzzing.sh PROJECT`，PROJECT 是 GitHub 的 owner/repo 標識。例如跑 `./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz` 就能開始對這個專案做模糊測試。

工具預設用 Claude Sonnet 5 模型，因為內部測試中表現不錯。使用者可以改 `src/seclab_taskflows_fuzzing/configs/model_config.yaml` 檔案來換別的模型。

要注意的是，這工具直接在主機上執行 afl-fuzz、clang 和任意編譯指令，中間沒有容器隔離。因此建議只在一次性環境（像 Codespace 或臨時虛擬機）裡跑，也不該用提升過的權限。

架構設計

工具採三層架構。第一層是 shell 驅動程式（run_fuzzing.sh），負責把各個流程階段串起來。第二層是一組任務流 YAML 檔案，本質上是指導 LLM 代理在每個步驟該做什麼的提示。第三層是一組 MCP 工具，代理靠呼叫這些工具來實際執行工作，例如跑 AFL、編譯測試程式碼、儲存崩潰、讀覆蓋率報告。

設計的核心原則是責任分清楚：LLM 代理負責決策，MCP 工具負責執行。代理決定要模糊測試什麼、寫什麼測試程式碼、追蹤哪個覆蓋率缺口，工具則提供執行的基本操作。所有狀態存在 SQLite 資料庫（fuzz_context.db）裡，各階段只透過資料庫交換資料，不透過記憶體。

每個測試程式碼會編譯兩次。一個版本用 afl-clang-lto -fsanitize=address,undefined 編譯成 .afl 二進位檔，用來跑模糊測試；另一個版本用 clang -fprofile-instr-generate -fcoverage-mapping 編譯成 .cov 二進位檔，用來生成人類看得懂的覆蓋率報告。

覆蓋率反饋迴圈

覆蓋率反饋迴圈是整個流程的核心，直接把傳統的手動工作流程自動化。每次迭代中，代理為每個測試程式碼跑一段時間的 AFL、針對 .cov 二進位檔重放隊列拿到真實覆蓋率報告，然後讀取未覆蓋分支的清單。根據發現的結果，代理會選擇以下其中一個動作：加入新的精心設計種子去打到未覆蓋的分支、改測試程式碼源碼去呼叫額外的 API、自動豐富 AFL 字典，或跳過冷門的錯誤路徑或供應商程式碼。

時間預算每次迭代都會加倍：30 秒、60 秒、120 秒、240 秒、480 秒、960 秒（每個目標大約 32 分鐘）。這種做法是在早期做便宜的短輪次（這時候有很多容易拿到的成果），後期做較長的輪次（這時候模糊測試器需要更多時間才能突破困難的保護機制）。

流程用平台檢測來決定何時停止。一旦連續兩次迭代的絕對行覆蓋率增益都低於可設定的閾值（預設 1%），迴圈就判定已達到收益遞減的點，移到下一個目標。這是為了防止代理花好幾個小時去擠最後那幾個百分比的覆蓋率。

結構感知的模糊測試

AFL 預設的位元級變異器在二進位格式上表現不錯，但碰到結構化的文字型輸入就不太行。工具提供四種互補機制來生成結構感知的輸入。

首先，對於已識別的輸入格式（JSON、XML、正規表達式、PNG、長度前綴的二進位 TLV），工具提供預先建好的 AFL 字典和自訂變異器 C 檔案。JSON 變異器做令牌拼接和平衡括號複製；XML 變異器認得標籤、實體和十億次笑聲令牌；正規表達式變異器包含真實的 ReDoS 模式。每個變異器會把一半的變異工作委託回 AFL 預設的位元變異器。

其次，工具會掃描目標的 .c/.h 檔案來動態生成自訂變異器。它抓出字串字面值和 32 位數值常數（來自 #define、case 和 enum），過濾掉雜訊後拿來當拼接令牌。

第三，工具提供動態生成、具備覆蓋率驅動豐富功能的 AFL 字典。第一次迭代之前，源令牌集會被輸出成 AFL 經典字典（數值常數以兩種位元組序表示）。之後每次覆蓋率步驟結束，流程會檢查未覆蓋行附近的保護條件（strncmp、memcmp、case 0xN、== 'X'），並把發現的新令牌加進去。字典會逐漸朝模糊測試器還打不到的程式碼發展。

第四，工具有語料庫拼接運算子，能從語料庫目錄載入檔案，把它們的隨機子區域拼接到輸入裡。

語料庫演進與崩潰分類

工具為每個測試程式碼維護一個穩定的語料庫目錄，在迭代之間和整個活動期間都會保留。每次迭代結束時，AFL 的隊列會併入這個目錄，並跑 afl-cmin 讓大小保持在一定範圍。這樣一來，昨天發現的有趣輸入會進到今天的執行，上週活動找到的輸入也會進到本週的活動。

崩潰分類分三個自動階段。第一，每個崩潰用 afl-tmin 最小化，在 ASan 下重放拿到堆疊追蹤，再用堆疊頂部雜湊去重（移除範本、內聯命名空間和 LTO 後綴，讓語意相同的崩潰合併在一起）。第二，之前已知的崩潰會針對當前二進位檔重放，看上游修復是不是已經解決了。第三，代理讀取測試程式碼源碼和崩潰函數，從公開 API 回溯呼叫鏈，為每個崩潰寫一份 markdown 報告。

每份報告會分配以下其中一種判決：vulnerability、library_hardening、harness_bug、OOM、timeout、assertion_failure 或 duplicate。要分辨真正的漏洞（可以透過公開 API 到達、可被利用）和單純的測試程式碼漏洞（問題出在測試程式碼本身，不在庫裡），正是過去需要人工追蹤程式碼才能判斷的事。每份報告包含根本原因分析、可達性論證、可利用性評估、建議的統一差異修復，以及迴歸測試草稿。

值得說明的是，建議的補丁被標記「需要審查」是有原因的。代理的分析受限於模型對目標程式碼的理解程度，確實會出錯。應該把這些判決當成給人類的一個準備充分的起點，而不是最終結論。

實時儀表板與結論

工具會把所有內容發布到實時 HTML 儀表板，在埠 8765 自動啟動。在 Codespace 裡，這個埠會自動轉發，使用者可以在瀏覽器裡開啟，即時看活動進度。儀表板顯示每個測試程式碼的執行脈動、含內嵌迷你圖表的覆蓋率趨勢表、崩潰熱力圖和迭代時間表。

這個專案源自對模糊測試局限性的認識：模糊測試有效，但沒有人工關注就無法擴大規模，而人工關注正是瓶頸所在。Fuzzing Taskflow 想透過把重複性的工作（寫測試程式碼、讀覆蓋率、追蹤缺口、分類崩潰）交給 LLM 代理來鬆開這個瓶頸，同時讓代理的判斷和執行工具之間保持清楚的分工。

這工具的源碼是開源的，使用者如果遇到問題可以建立議題回報，也歡迎貢獻。