AI 在幫你找安全漏洞了，而且越來越不需要你插手

> Meta Shift

Fuzzing 這件事存在幾十年了，原理很簡單 — 塞一堆奇怪的 input 進去，看程式有沒有炸掉。但真正做好 fuzzing 需要的東西不簡單：你要理解程式的架構、要手寫 fuzz harness（就是讓 fuzzer 能跑你的目標函式的那段膠水程式碼）、要判斷 crash 是不是真的有問題、還要知道怎麼寫 PoC。

這整條流程過去都需要資安研究員坐在那邊慢慢搞。GitHub Security Lab 推出的 Taskflow Agent 要做的事情就是 — 把這條流程自動化掉，讓 AI 替你跑完大部分。

我想拆解這個 agent 的原因不是因為它「又是一個 AI 工具」，而是因為它代表的方向很清楚：資安這個領域裡，原本最依賴人類專業判斷的環節，AI 正在一個一個攻破。值不值得認真看？值得。

---

Taskflow Agent 的架構長什麼樣

先講整體設計。Taskflow Agent 的核心概念是把 fuzzing 這個工作拆成一系列有順序的 task，然後讓 LLM 配合工具去逐步完成。這不是一個「你丟程式碼給它然後它回一個 bug 報告」的黑盒子，而是一個 agentic loop — 它會讀 code、規劃、執行、觀察結果、再調整。

整個 flow 大致長這樣：

分析目標 repo
    ↓
識別可 fuzz 的目標函式
    ↓
生成 fuzz harness
    ↓
執行 fuzzing（用 libFuzzer 或 AFL++）
    ↓
分析 crash / coverage
    ↓
生成漏洞報告（或迭代改善 harness）

幾個核心元件：

Task orchestrator：負責拆解整個 fuzzing 任務成子任務，並決定執行順序。這部分是整個系統的大腦，用 LLM 去 plan，然後逐步 dispatch 給下面的 executor。

Code analysis tools：讓 LLM 能夠讀 repo 的工具集。不是直接把整個 codebase 塞進 context，而是提供搜索、跳轉、讀取特定檔案的工具，讓 agent 能自己找它需要的資訊。這個設計很重要，因為真實的 codebase 動輒幾萬行，沒有工具輔助根本沒辦法做。

Harness generator：根據分析結果生成可執行的 fuzz harness。這是最需要技術的一步，生成的 harness 要能 compile、要能跑、要能有意義地覆蓋目標路徑。

Fuzzing runtime：實際執行 fuzzer 的環境，目前支援主流的工具，包含 libFuzzer 和 OSS-Fuzz 整合。跑完之後把 coverage 和 crash 資訊回傳給 agent。

Crash analyzer：拿到 crash 之後，判斷這個 crash 是不是真的安全漏洞、嚴重程度如何、對應的 CWE 是什麼。

資料流走的是 agent loop 的標準模式：LLM → 決定要用什麼 tool → 呼叫 tool → 拿到結果 → 繼續規劃下一步。失敗了（比如 harness compile 失敗）就重新分析錯誤然後修。

---

三個關鍵設計決策

1. Harness 生成是最硬的關卡

傳統上，寫 fuzz harness 是整個 fuzzing 流程裡最花時間的部分。一個好的 harness 要做到幾件事：

• 正確呼叫目標函式
• 處理好 memory allocation 和 cleanup（不然自己就炸了）
• 給 fuzzer 足夠的「攻擊面」而不是太窄的 input 空間

Taskflow Agent 的做法是讓 LLM 先理解目標函式的 signature 和 context，然後生成 harness，compile 一次，如果失敗就拿錯誤訊息繼續修。這個 iterative 的方式比「生成一次就完事」靠譜很多。

比較有趣的 trade-off 是：LLM 生成的 harness 品質跟 coverage 有直接關係。一個爛的 harness 可能只走到很淺的程式碼路徑，找不到深層的 bug。這部分目前還是比人類寫的差，因為 LLM 沒有那種對程式邏輯的直覺 — 它是在猜哪些 path 值得跑，不是真的理解程式在幹嘛。

2. 跟 OSS-Fuzz 整合，不是自己造輪子

GitHub Security Lab 沒有自己重新做一個 fuzzing infrastructure，而是直接整合進 Google 的 OSS-Fuzz 平台。這個決策很務實。

OSS-Fuzz 已經在跑幾百個開源專案的 fuzzing，有現成的 CI、回報機制、triage 流程。Taskflow Agent 生成的 harness 可以直接提 PR 進 OSS-Fuzz，然後跑在已經有的 compute 上。（來源：GitHub Security Lab 官方部落格）

這個整合代表什麼？代表這個 agent 的目的不是取代 OSS-Fuzz，而是降低進入 OSS-Fuzz 的門檻。過去要讓一個開源專案被 OSS-Fuzz 覆蓋到，你要自己寫 harness、自己送 PR、自己等 review。現在 AI 可以幫你做這段。

3. Task 拆分讓 failure 可以局部重試

Taskflow 這個名字本身就點出了設計重點 — 它不是一個 monolithic prompt，而是真的把工作流程拆成 task。每個 task 有明確的 input、output、success condition。

這個設計的好處是：如果 harness 生成失敗了，不需要從頭重跑，只要重試那個 task。如果 crash analysis 出了問題，前面跑的 fuzzing 結果還在。

跟其他 AI coding agent 的比較：大部分的 code agent（比如早期的 Devin 或 GitHub Copilot Workspace）傾向於讓 LLM 自己決定怎麼走，缺乏強制的 checkpoint。Taskflow 的做法更像是 workflow engine 配上 LLM，LLM 負責每個 task 的具體執行，但流程控制在外面。這讓整個系統更可預期、更容易 debug，trade-off 是彈性稍低。

附一個簡化的 task 定義概念：

Task(
    name="generate_harness",
    inputs=["target_function", "repo_context"],
    outputs=["harness_code", "build_config"],
    success_criteria=lambda out: compiles_successfully(out["harness_code"]),
    retry_limit=3
)

---

誰在建這個、為什麼現在

GitHub Security Lab 是 GitHub 內部的資安研究團隊，主要工作是找開源軟體的漏洞、做資安研究、跟社群合作提升供應鏈安全。他們過去在 CodeQL 上投入很深 — CodeQL 是用靜態分析找漏洞的工具，也是 GitHub Advanced Security 的核心技術之一。

Taskflow Agent 可以看成是 Security Lab 在 AI 時代的下一步。靜態分析找得到 pattern matching 類型的漏洞，但 fuzzing 能找到邏輯漏洞和 memory corruption — 這是靜態分析的盲區。兩者互補，把它們都 AI 化是很自然的方向。

從商業角度來看：GitHub Advanced Security 是 GitHub Enterprise 的付費功能，這個 agent 讓 GitHub 在資安工具市場的護城河更深。如果 Taskflow Agent 最終整合進 GitHub 的 CI/CD 流程，對 enterprise 客戶來說又多一個不想離開 GitHub 生態的理由。

開源策略部分，Security Lab 的研究通常會開源或公開方法論，這次也不例外。透過開源貢獻給 OSS-Fuzz，等於讓整個開源社群受益，同時也建立了 GitHub 在資安社群的品牌。這是一個典型的「做公益也做行銷」的策略，Google 和 Microsoft 都很擅長。

目前沒有公開數據說明 Taskflow Agent 找到多少個 CVE，或者它的 harness 品質跟人類寫的差距有多大 — 這部分就不得而知了。

---

Meta 判讀：這是真的 Meta Shift 嗎？

我的判斷是：是，但不是今年就全面爆發的那種。

Fuzzing 在資安領域的角色一直很重要，但它的使用率遠低於靜態分析，主要原因就是門檻高、要手寫 harness、要有人判斷 crash。Taskflow Agent 做的事情是把這個門檻大幅拉低。

類比一下：這有點像是 Terraform 對 infrastructure provisioning 做的事。不是說有了 Terraform 就不需要懂 infra，而是讓懂得更少的人也能做到之前要很懂才能做的事。Taskflow Agent 對 fuzzing 的影響大概也是這個方向。

對資安研究員來說，這不是 nerf — 這是 buff。AI 幫你跑掉 60-70% 的機械性工作，你可以專注在它找到的有趣東西上，而不是一直在搞 harness compile 失敗的問題。

但如果你問我它現在能完全取代有經驗的資安研究員嗎？不行。它生成的 harness coverage 還不夠深，對複雜協議的理解也有限。這是一個很強的助手，不是替代品。

---

實戰建議

適合用的場景：

• 你有個開源 C/C++ 專案，想進 OSS-Fuzz 但沒人手寫 harness
• 你是資安研究員，想快速起手對一個陌生 codebase 做初步 fuzzing
• CI 裡想加一層自動化的 fuzzing 覆蓋，不需要人工介入

不適合或要小心的：

• 對 coverage 有很高要求的場景，AI 生成的 harness 不一定能走到深層路徑，可能給你一個「有在跑 fuzzing 」的假安全感
• 不是 C/C++ 的 codebase，目前 fuzzing 工具鏈對其他語言的支援度差很多，agent 的效果也會差
• 如果你的程式碼涉及複雜的狀態機或協議解析，harness 生成會很容易走偏

一個坑要注意： Crash 不等於漏洞，AI analyze crash 的部分還是會有 false positive。找到 crash 之後還是要人去確認 exploitability，不能就這樣直接開 CVE。

整體來說，這是一個值得追蹤的方向。把它加到你的資安工具箱裡，但不要把它當成最後一道防線。

延伸閱讀

• GitHub Copilot 支援 stacked sessions 了 — AI coding 正式進入 agentic 時代
• 為什麼 AI Agent 還取代不了程式設計師 — 約束衰減問題解析
• 拆解 Agent Harness — 你以為的 AI Agent 其實 90% 是 harness