GitHub Security Lab 開源 Fuzzing Taskflow讓 LLM 智能體自己跑完 C/C 模糊測試原文GitHub Blog - AI-powered fuzzing with the GitHub Security Lab Taskflow Agenthttps://github.blog/security/application-security/ai-powered-fuzzing-with-the-github-security-lab-taskflow-agent模糊測試做安全研究的人都懂寫 harness、跑 AFL、盯覆蓋率、分診崩潰每一環(huán)都枯燥且重復。GitHub Security Lab 的 Antonio Morales 最近開源了 Fuzzing Taskflow把這條流水線整個交給 LLM 智能體只要指向一個 GitHub 倉庫它就能自動識別入口點、分析構建系統(tǒng)、編寫 harness、運行 AFL、讀取覆蓋報告、改進 harness、分診每一個崩潰并為每個唯一 bug 寫出漏洞報告全程無需人盯著。一、三層架構決策與執(zhí)行分離這個項目最值得 Agent 開發(fā)者看的不是模糊測試本身而是它的架構。整個系統(tǒng)分三層Shell driverrun_fuzzing.sh 腳本把各個 pipeline stage 串起來。Taskflow YAML每個 stage 對應一份 YAML本質上是告訴 LLM 智能體每一步該做什么的 prompt。MCP tools智能體實際調用的工具集比如運行 AFL、編譯 harness、存儲 crash、讀取覆蓋報告。官方強調的設計原則是一句話LLM agent owns the decisions, and the MCP tools own the execution。智能體決定 fuzz 什么、寫什么 harness、追哪個覆蓋缺口但它從不直接調用 AFL 或 clang只能調用工具暴露的原語。另一個容易被忽略的細節(jié)所有狀態(tài)存在 SQLite 數(shù)據庫 fuzz_context.db 中各 stage 之間通過數(shù)據庫交互而不是靠內存?zhèn)鬟f。這意味著流水線可以斷點續(xù)跑stage 之間徹底解耦。二、全流程拆解1. 雙二進制構建每個 harness 會被編譯兩次各干各的活.afl 二進制用 afl-clang-lto 加 -fsanitizeaddress,undefined 編譯負責實際跑 fuzzing.cov 二進制用 clang 加 -fprofile-instr-generate -fcoverage-mapping 編譯負責事后重放 AFL 隊列生成真實的源碼行和分支覆蓋報告。一個跑性能一個跑精度這個拆分思路在覆蓋率敏感的場景里可以復用。2. 覆蓋反饋循環(huán)這是整條管線的核心把工程師手動的跑一輪、看覆蓋、改一改循環(huán)自動化了。每輪迭代中智能體對每個 harness 在時間預算內運行 AFL用 .cov 二進制重放隊列拿真實覆蓋報告讀出未覆蓋的分支列表然后自主選擇行動造一個專門命中未覆蓋分支的新種子修改 harness 源碼讓它多調用一個 API把守衛(wèi)比較的 magic constants 自動補進 AFL 字典如果是冷錯誤路徑或第三方 vendor 代碼直接跳過。時間預算按 30s → 60s → 120s → 240s → 480s → 960s 逐輪翻倍每個目標累計約 32 分鐘早期短輪次抓低垂果實后期長輪次突破硬守衛(wèi)。停止條件是 plateau 檢測——連續(xù)兩輪迭代各自增益低于閾值默認 1% 絕對行覆蓋就判定收益遞減移步下一個目標。3. 結構感知模糊測試針對常見格式管線提供四種互補機制生成結構化輸入預建的 AFL 字典和 LLVMFuzzerCustomMutator 變異器覆蓋 JSON、XML、正則、PNG、長度前綴 TLV掃描目標源碼提取字符串字面量和 32 位數(shù)值常量的源碼級字典覆蓋驅動的動態(tài)字典——每輪覆蓋后檢查 strncmp、memcmp、case 分支等守衛(wèi)并追加新 token數(shù)值常量同時給出大小端兩種表示以及把語料目錄文件隨機拼接子區(qū)域的 corpus-splice 算子。4. 語料庫演進與崩潰分診每個 harness 擁有穩(wěn)定的語料目錄跨迭代、跨 campaign 保留。每輪結束把 AFL 隊列合并進語料并用 afl-cmin 去重限大小。fuzzing 結束后自動進入三階段分診先用 afl-tmin 最小化每個崩潰輸入在 ASan 下重放捕獲?；厮莅礆w一化棧頂幀哈希去重再對已知崩潰在新二進制上重放檢測上游是否已修復最后智能體閱讀 harness 源碼與崩潰函數(shù)回溯到公開 API 調用鏈為每個崩潰寫 markdown 報告。報告的 verdict 分為 vulnerability、library_hardening、harness_bug、OOM、timeout、assertion_failure、duplicate 幾類內容包括 file:line 級別的根因分析、可達性論證、可利用性評估以及 unified diff 形式的修復建議和回歸測試草案。三、怎么跑起來最簡單的方式是打開官方倉庫 seclab-taskflows-fuzzing 的 Codespace然后./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz ./scripts/fuzzing/run_fuzzing.sh DaveGamble/cJSON參數(shù)就是 GitHub 的 owner/repo 名。啟動 campaign 后8765 端口會自動開放一個實時儀表板展示每個 harness 的運行狀態(tài)、帶迷你走勢圖的覆蓋率表格、崩潰熱力圖和迭代時間線Codespace 會自動轉發(fā)端口。必須原樣轉述官方的安全警告這個 taskflow 直接在宿主機上運行 afl-fuzz、clang 和 LLM 選定的任意構建命令中間沒有任何容器隔離。一個被 prompt injection 的智能體原則上可以做你的用戶賬號能做的一切。所以務必只在一次性環(huán)境Codespace 或臨時虛擬機中、以非特權身份運行。四、模型選擇與局限默認模型是 Claude Sonnet 5原因是它通過了全部內部測試部分前沿模型因為對輸出施加安全護欄反而不適合這個 taskflow。想換模型可以改 src/seclab_taskflows_fuzzing/configs/model_config.yaml以倉庫最新文檔為準未驗證最新版本。局限也要說清楚目前只支持 C/C 項目智能體的分析受限于模型對目標代碼的理解確實會出錯作者建議所有補丁標記 review requiredverdict 只是人工分析的起點而非結論fuzzing 仍然需要 human in the loop這套工具只是把最重復的勞動交了出去。五、給 Agent 開發(fā)者的四個可復用模式拋開模糊測試這個項目里有四個模式值得搬回你自己的 Agent 項目決策與執(zhí)行分離。智能體只做決策工具只暴露原語出問題時邊界清晰也更容易做權限收斂。狀態(tài)外置到數(shù)據庫。stage 之間靠 SQLite 而不是內存?zhèn)鳡顟B(tài)長任務天然獲得斷點續(xù)跑能力。預算遞增加 plateau 檢測。時間預算逐輪翻倍、連續(xù)低增益就止損換目標這是 Agent 長循環(huán)里很通用的停止條件設計。輸出帶 unified diff。讓智能體給出可 diff、可 review 的建議而不是一段散文人工介入成本會低一個數(shù)量級。