生活分享

GitHub Security Lab 推出 AI 模糊測試流程 Fuzzing Taskflow：讓 AI 代理自動找 C/C++ 漏洞

據 GitHub 部落格 2026 年 9 月 24 日文章，GitHub Security Lab 以 Taskflow Agent 框架打造自主模糊測試流程，由 AI 代理撰寫測試框架、追查覆蓋率缺口並分類當機。本文整理其運作方式、安全警告及對一般讀者的意義。

閱讀時間約 6 分鐘

GitHub Security Lab 推出 AI 模糊測試流程 Fuzzing Taskflow：讓 AI 代理自動找 C/C++ 漏洞
圖片：Mokaair (Original editorial artwork)

GitHub 宣布了甚麼

GitHub 部落格於 2026 年 9 月 24 日刊出由 Antonio Morales 撰寫的文章，介紹一套名為 Fuzzing Taskflow 的新流程。據文章所述，它建基於 GitHub Security Lab Taskflow Agent，這是 GitHub 用來撰寫由大型語言模型驅動的安全自動化框架。作者將 Fuzzing Taskflow 形容為針對 C/C++ 專案的自主模糊測試流程。

模糊測試（fuzzing）是一種以大量自動產生的輸入去測試程式、藉此發現當機與潛在漏洞的方法。「測試框架」（harness）是把這些輸入送進目標程式的一小段程式碼；「覆蓋率」則是指測試實際跑到了程式碼的多少部分。作者在文中指出，持續模糊測試並非萬靈丹：即使參與 OSS-Fuzz（一個持續模糊測試計劃）多年的專案仍可能隱藏嚴重錯誤，原因是仍需要有人監察覆蓋率、為沒有被觸及的程式碼撰寫新的測試框架，並分類跑出來的當機結果。Fuzzing Taskflow 正是嘗試把這部分人手工作交給 AI 代理。

GitHub Security Lab 推出 AI 模糊測試流程 Fuzzing Taskflow：讓 AI 代理自動找 C/C++ 漏洞
Mokaair 編輯查核流程 · 圖片：Mokaair (Original editorial artwork)
閱讀完整文字說明

消息會先蒐集來源、獨立查核，再交由 Jev 判斷。

據 GitHub 描述，使用者只需指向一個 GitHub 儲存庫，流程便會識別合適的進入點、分析建置系統、撰寫測試框架、執行 AFL++、閱讀覆蓋率報告、改進測試框架、分類每個當機，並為每個獨特錯誤撰寫漏洞報告。文章指出工具存放於 GitHubSecurityLab/seclab-taskflows-fuzzing 儲存庫，預設使用 Claude Sonnet 5，原因是它通過了團隊所有內部測試，使用者亦可透過設定檔更換模型。

運作方式：AI 負責決策，工具負責執行

據文章，整個架構分為三層：串連各階段的 shell 驅動程式、每個階段一份的 taskflow YAML（實質上是告訴代理每一步要做甚麼的提示），以及代理呼叫來實際完成工作的 MCP 工具（例如執行 AFL、編譯測試框架、儲存當機、讀取覆蓋率報告等功能）。作者表示，他最重視的設計原則是清楚分工：大型語言模型代理負責決策，MCP 工具負責執行，代理從不直接呼叫 AFL 或 clang。所有狀態都儲存在 SQLite 資料庫中。

文章亦提到，每個測試框架會建置兩次：.afl 版本負責實際模糊測試，.cov 版本則在之後重播 AFL 的測試佇列，以產生真實的原始碼行與分支覆蓋率報告。

覆蓋率回饋迴圈與停止條件

作者表示，檢查覆蓋率與改進覆蓋率這兩步，過去由他人工完成，例如閱讀 LCOV 報告尋找未覆蓋的分支；Fuzzing Taskflow 把兩者都交給代理。據文章，每次迭代中代理可選擇：新增針對未覆蓋分支的種子輸入（作為測試起點的範例輸入）、編輯測試框架以呼叫更多 API、自動擴充 AFL 字典，或略過不值得追查的缺口。

時間預算每次迭代加倍，由 30 秒、60 秒、120 秒、240 秒、480 秒到 960 秒，每個目標約 32 分鐘。流程採用平台期偵測：當連續兩次迭代的增益都低於可設定門檻（預設為 1% 絕對行覆蓋率）時，便判斷已達收益遞減並繼續下一步。

結構感知輸入

文章稱流程提供四種互補機制來產生具結構感知的輸入，即符合檔案格式規則、較能深入程式的測試資料。對於可識別的格式，包括 JSON、XML、正規表示式、PNG 及長度前綴二進位 TLV，流程附有預建的 AFL 字典與自訂變異器（負責改動輸入的程式）；對於無法識別的格式，則會掃描目標專案自身的 .c/.h 檔案，擷取字串常值與 32 位元數值常數作為拼接符號。

人工模糊測試與 Fuzzing Taskflow 的比較（資料來源：GitHub 部落格）
工作環節作者描述的人工流程Fuzzing Taskflow 的做法（據 GitHub）
檢查覆蓋率人工閱讀 LCOV 報告尋找未覆蓋分支代理以 .cov 版本重播佇列後閱讀未覆蓋分支清單
改進覆蓋率人工撰寫新測試框架或製作新輸入代理新增種子、編輯測試框架、擴充字典或略過缺口
何時停止需要人判斷連續兩次迭代增益低於門檻（預設 1%）即停止
當機處理需要人分類分類每個當機並為每個獨特錯誤撰寫漏洞報告

對一般讀者的實際影響

  • 對開源維護者：GitHub 將這類工具定位為減少模糊測試中人工監察與分類工作的方法，但實際成效仍需各專案自行評估。
  • 對一般使用者：模糊測試的目的是在軟件發布前找出錯誤，更多專案能較低成本做測試，長遠或有助提升常用軟件的可靠性，但這是推論，文章並未提供成效數據。
  • 對 AI 安全：GitHub 自己的警告說明，讓 AI 代理直接執行指令本身就帶有提示注入等風險，隔離環境仍是基本要求。
  • 資訊來源：以上內容全部來自 GitHub 自家部落格，屬單一來源，尚未見獨立驗證。

常見問題

Fuzzing Taskflow 是甚麼？

據 GitHub 部落格，它是 GitHub Security Lab 以 Taskflow Agent 框架打造、針對 C/C++ 專案的自主模糊測試流程，由 AI 代理自動撰寫測試框架、追查覆蓋率並分類當機。

它會取代人手安全研究嗎？

文章的出發點是探討有多少人手工作可以交給大型語言模型代理，並未聲稱完全取代人手；作者亦強調持續模糊測試並非萬靈丹。

用哪個 AI 模型？

據文章，預設使用 Claude Sonnet 5，因為它通過了團隊所有內部測試；使用者可透過設定檔更換模型。

在自己電腦執行安全嗎？

GitHub 自己警告，此流程會在主機上直接執行由 AI 選擇的建置指令，沒有容器隔離，建議只在可丟棄的環境中以非提升權限執行。

這些說法經過獨立驗證嗎？

沒有。本文所有資料均來自 GitHub 部落格單一來源，屬該公司自述。

查看同分類最新消息

同主題延伸閱讀

最新旅遊情報攻略

資料來源

生活分享