GitHub Security Lab研究員Antonio Morales於9月24日發文，公開一套由大型語言模型（LLM）驅動的模糊測試（fuzzing）管線，鎖定C/C++專案，程式碼放在GitHub儲存庫seclab-taskflows-fuzzing下，預設模型是Claude Sonnet 5。
這套工具建立在GitHub自家的Taskflow Agent框架之上，官方對這個框架的定義是「用來撰寫LLM驅動安全自動化的框架」。使用者只要在儲存庫裡開一個Codespace，執行一行腳本、後面接上目標專案名稱，例如tukaani-project/xz，剩下的步驟就交給代理程式處理。
從尋找進入點到產出報告
根據文章描述，這套管線依序執行以下工作：辨識程式碼進入點、自動撰寫測試樁（harness）、呼叫AFL++執行模糊測試、讀取涵蓋率報告、依據涵蓋情況改寫測試樁、對每一次崩潰進行分類，最後產出漏洞報告，並附上統一diff格式的修補建議。
涵蓋率回饋採用時間預算倍增的做法：每一輪給的時間是上一輪的兩倍，從30秒起算，依序為60、120、240、480、960秒，單一目標累計約32分鐘。代理程式每一輪看完涵蓋率後才決定要改哪裡。
為了讓隨機變異更懂輸入格式，這套管線疊加了四層「結構感知」手法：針對檔案格式的字典與自訂變異器、從原始碼裡抽取出來的字典、執行過程中動態產生的AFL字典，以及語料拼接。
崩潰分類的標籤分得相當細：真實漏洞（vulnerability）、函式庫強化建議（library_hardening）、測試樁本身的臭蟲（harness_bug）、記憶體耗盡、逾時、斷言失敗、重複。崩潰會先經過afl-tmin最小化，再依呼叫堆疊去重。執行期間還有一個跑在8765埠的HTML儀表板，可即時查看進度。
Morales為這套設計的分工定了一條原則：
"the LLM agent owns the decisions, and the MCP tools own the execution"
（決策歸大型語言模型代理，執行歸MCP工具）
與OSS-Fuzz路線的對照
把大型語言模型帶進模糊測試，Google起步得更早。OSS-Fuzz從2023年起就在試用LLM自動產生fuzz target，Google於2024年底對外表示，這條路線幫忙找到了包括OpenSSL一處漏洞在內的一批問題。不過那套方案主要解決的是「撰寫測試樁」這一步，專案本身得先接入OSS-Fuzz的基礎設施。
GitHub這次的做法更像一個可以帶著走的工具箱：不要求專案接入任何平台，開一個雲端開發環境就能跑，分診與撰寫報告也一併包辦。文章開頭特別提醒，持續性模糊測試不是萬靈丹，長年掛在OSS-Fuzz上的專案照樣可能藏著嚴重臭蟲，這也是他們選xz當示範對象的背景。xz在2024年曾爆發震撼整個開源圈的後門事件，但那次是蓄意植入的供應鏈攻擊，跟模糊測試能揪出的記憶體錯誤不屬同一類問題。
文章沒有交代的部分
外界最關心的幾項數據，文章並未揭露：在xz、cJSON上各自找到多少崩潰、其中多少被判定為真實漏洞、有沒有取得CVE編號；跑完一個專案要耗費多少token與費用；誤報率有多高。作者自己的用詞相當保守，他寫道，分診結論應當被視為「交給人類的一份準備充分的起點」，不能當成最終結果，修補建議也都標註需要人工複核。
安全面還有一項前提。這套管線執行時不做容器隔離，官方建議只在Codespace或臨時虛擬機這類可拋棄的環境裡跑，也不要給它提升權限。對想在公司內網直接部署的團隊來說，這一條會比選模型更早碰到。
對中國大陸從事開源基礎函式庫維護的開發者而言，門檻主要卡在模型上：預設設定呼叫的是Anthropic的模型，在中國大陸直接連線並不方便。儲存庫是開源的，理論上可以換成其他相容模型，效果能不能維持，目前還沒有公開測試過。
參考來源：GitHub官方部落格、seclab-taskflows-fuzzing開源儲存庫說明、CocoLoop、Google OSS-Fuzz公開資料；管線步驟、時間預算與崩潰分類以GitHub部落格描述為準。