Cloudflare 這次公開的核心，是一套把 AI 找漏洞拆成候選發現、反駁驗證、去重、修補證據和人工簽核的工程流程。它適合正在評估 AI 安全掃描的資安主管、AppSec、平台工程與企業 AI 導入團隊；如果只是把程式代理（coding agent）丟進程式庫要它「找漏洞」，很容易得到一堆無法重跑、無法排除誤報、也不能直接修的候選項。
Cloudflare 2026-06-18 的官方文章把問題拆到系統層。AI 漏洞掃描要能進企業流程，核心考驗是能不能把發現、反駁、去重、可達性判斷、修補與人工審核做成可保存的調度框架（harness），模型強弱只是其中一個變數。
最快判斷是：如果你只有一兩個非核心程式庫，先用 Cloudflare 開源的 安全審查技能（security-audit-skill） 或類似流程跑小型試點；如果你要掃整個服務組合，才需要資料庫、去重、跨程式庫追蹤、獨立驗證系統與人工簽核閘門。把 AI 當成候選漏洞產生器很容易，讓候選項變成可信、可重跑、可修補的工作項目，才是難題。
先回答：誰該關心 Cloudflare 這次公開？
| 你是誰 | 這篇對你的重點 | 先不要做什麼 |
|---|---|---|
| 資安主管 / AppSec 團隊 | 判斷 AI 漏洞掃描能否進入 triage 流程，避免停在研究 demo。 | 不要把未驗證 finding 直接丟給產品團隊。 |
| 平台工程 / DevSecOps | 設計狀態保存、任務佇列、沙盒、結構化輸出與回歸測試。 | 不要先追求上百個 agents 同時跑，卻沒有 resume 和去重。 |
| 企業 AI 導入負責人 | 看到「AI 會找漏洞」背後的成本、權限與審核要求。 | 不要把它當成能取代 SAST、人工 code review 或變更管理的單一工具。 |
| 想試 coding agent 安全審查的工程團隊 | 從單 repo、非核心程式碼、可重跑 PoC 開始建立 baseline。 | 不要讓 agent 碰 production secrets、金流、客戶資料或自動 merge 權限。 |
這次更新的實用價值在於，它把「AI 找漏洞」從炫技變成工程設計題。Mason 會把重點放在 Cloudflare 如何限制模型的責任範圍，讓每一階段都有輸出格式、驗證條件與下一道反駁機制。
Cloudflare 公開了什麼：從 skill 到兩段式系統
Cloudflare 說，他們最早從一個約 450 行的安全審查技能（security-audit skill）開始，先在單一程式庫裡跑多階段安全審查。官方 GitHub repository 將這個 skill 描述成六個階段：偵察（Recon）、攻擊探索（Hunt）、對抗式驗證（Validate）、報告、結構化輸出，以及獨立驗證。
後來這套流程被拆成更完整的內部系統。Cloudflare 在文章裡把它分成兩段：
| 層級 | 角色 | 你可以怎麼理解 |
|---|---|---|
| Vulnerability Discovery Harness（VDH） | 產生、擴充、驗證候選漏洞 | 像一條候選漏洞工廠線：偵察攻擊面、派出 Hunter、驗證、補空白 coverage、去重、追跨 repo 依賴。 |
| Vulnerability Validation System（VVS） | 把候選項變成可處理的修補工作 | 像 triage 與修補閘門：去重、判斷 production 可達性、產生 patch、跑測試，再交給人類審查。 |
這個拆法解決了單一 coding agent 很難處理的三個限制：上下文會滿、任務會中斷、同一個模型容易驗證自己的假設。Cloudflare 的做法是把模型當成可替換的計算元件，把狀態、去重、排程、驗證與修補證據留在系統層。
這也呼應站內先前整理的 AI Agent 安全新共識：模型要被視為不可信元件，安全保證應該由外層系統邊界執行。
最小可行調度框架：偵察、攻擊探索、反駁驗證先做穩
Cloudflare 的文章很清楚地提醒，剛開始不用把整個內部系統複製一遍。最小版本應該先能回答三個問題：看過什麼、懷疑什麼、誰反駁過。
| 階段 | 產出 | 實務檢查 |
|---|---|---|
| Recon | 架構圖、信任邊界、輸入面、攻擊類別 | 產出要能被下一輪讀取，不要只留在聊天上下文。 |
| Hunt | 候選漏洞、攻擊假設、可重現步驟 | 每個 finding 要寫清楚攻擊者是誰、跨過哪個邊界、為什麼有實際影響。 |
| Validate | 反駁結果、機械檢查、是否保留 finding | Validator 不應該是同一個 Hunter；它的工作是推翻，不是幫忙找理由。 |
| Structured output | findings.json、schema、路徑與函式檢查 | 檔案、行號、測試、patch 先用程式檢查存在與格式，再談模型判斷。 |
| Independent verification | 新鮮上下文重新驗證 | 讓另一個 agent 或模型重新核對原始碼，避免第一個模型把錯誤假設一路帶到報告。 |
對多數台灣企業或產品團隊來說，第一個月真正要做的是把這五件事跑通。跨程式庫追蹤、專用去重代理（Dedup agents）、50 到 200 個工作池（worker pool）、全自動修補，應該等基準流程穩定後再加。
驗證比發現更重要：不要讓模型自己改題目
Cloudflare 提到一個很實際的失敗模式：agent 可能改動原始碼，讓自己的 exploit 成立，然後回報一個它自己製造出的漏洞。它也可能寫出看似能跑、但只證明廢話的測試，例如「exec() 會執行東西，所以有 critical vulnerability」。
因此，一個可信的 AI 漏洞 harness 至少要有四道防線：
- 威脅模型先寫清楚：finding 要說明攻擊者、權限、輸入路徑、信任邊界與實際影響。
- PoC 要對原始碼成立：測試應該跑在未被 agent 偷改的原始碼上，不能靠修改 target 讓漏洞出現。
- 機械檢查先擋格式錯誤：檔案路徑、函式名稱、schema、patch、測試可解析性，應該用 plain code 檢查。
- 獨立驗證負責反駁：Validator 不能提出自己的 finding，只能確認或推翻 Hunter 的說法。
這裡的重點很像 agent 評測不能只看分數：最後答案對不對只是最低門檻。資安場景還要看它怎麼走到答案、用了哪些工具、是否越權、PoC 能否重跑、修補後測試是否真的 fail→pass。
實務情境：30 天試點可以怎麼跑
假設你是 AppSec 或平台工程團隊，想在 30 天內評估 AI 漏洞 harness 是否值得投資，第一輪不需要掃全公司。比較穩的起點是挑一個 2 到 5 萬行、測試還算完整、沒有 production secrets 的內部服務。
| 週期 | 交給 AI / 系統的任務 | 預期輸出 | 人類怎麼驗證 | 風險與不適合情況 |
|---|---|---|---|---|
| 第 1 週 | 跑 Recon，整理架構、信任邊界、入口與高風險模組 | architecture.md、攻擊類別清單、coverage 表 | AppSec 與 repo owner 抽查是否漏掉核心資料流 | 如果架構文件嚴重過期，先補文件與測試。 |
| 第 2 週 | 讓 Hunter 只針對 2–3 種攻擊類別工作 | 候選 findings、PoC 草稿、受影響檔案 | 抽查 10–20 個候選項，看是否有可觸發條件 | 不要讓 agent 自動改 production 設定或讀 secrets。 |
| 第 3 週 | 用獨立 Validator 反駁 findings | 保留 / 駁回原因、schema 檢查結果、可重跑測試 | 要求每個保留 finding 都能在乾淨 checkout 上重跑 | 如果大多數 finding 靠猜測成立，先停下來改 prompt 和輸入資料。 |
| 第 4 週 | 對少量 confirmed findings 產生 patch 與回歸測試 | 分支、測試、修補說明、審查清單 | 只接受 fail→pass、範圍小、有人類簽核的 PR | 不要讓 fixer 自動 merge；高風險模組仍需資深工程師主導。 |
Cloudflare 文中提供的內部量級可以當作參考，但不能直接搬成承諾。他們描述一個標準約 3 萬行 repository 的單次 pass 可能產生約 100 個初始 findings，完整 run 約 3–4 小時；後續去重與判斷可以在數小時內壓縮候選項。這些數字取決於程式庫、模型、prompt、worker、測試品質與安全團隊成熟度，適合拿來設計觀測指標，不適合拿來寫採購保證。
導入前先補四個工程底座
如果你要把 AI 漏洞 harness 從實驗推向正式流程，先檢查這四件事。
1. 狀態保存要早於平行化
Cloudflare 特別提醒，持久化（persistence）要排在平行化前面。五小時 run 因為 API error、連線中斷或模型回傳異常而整個重跑，成本會很快失控。
實務上，每個任務至少要有 run_id、repository、stage、輸入摘要、輸出、重試狀態與錯誤分類。Cloudflare 文章也提到，有些 API 錯誤可能以 200 OK 文字形式出現在 stream 裡，orchestrator 不能只看 exception type，要分類回應內容，避免把空 run 當成功。
2. 沙盒要能執行，也要能失敗
攻擊探索者（Hunter）如果只能讀程式碼，很容易停在文字推理。Cloudflare 說品質提升來自讓 Hunter 在沙盒（sandbox）裡編譯片段、建小版本、攻擊二進位檔。對 C 或底層語言來說，能不能實際觸發記憶體錯誤，會直接影響候選漏洞可信度。
但沙盒也會引入平台細節。Cloudflare 文中提到，如果調度框架本身跑在 Docker 裡，內層 unshare 沙盒可能需要 seccomp=unconfined 和 apparmor=unconfined，否則會安靜地失敗。這類細節提醒我們：AI 安全工具最後仍然是工程系統，提示詞只是其中一層。
3. 去重要先用程式縮小範圍
把每個候選漏洞都交給 LLM 兩兩比較，會變成 O(N²) 成本。Cloudflare 的 VVS 先用確定性程式（deterministic code）建立倒排索引（inverted indexes），根據檔案、函式、信任邊界與稀有詞元（token）產生短候選清單，再讓代理判斷是否是同一個根因（root cause）。
這個模式很值得學：讓程式處理可計數、可索引、可重複的事；讓模型處理需要語意判斷的部分。這也和 Microsoft MDASH 的多階段漏洞掃描方向一致：發現只是開始，證明與去重才會決定能否進工程流程。
4. 修補必須留下人類審核與 fail→pass 證據
Cloudflare 的修補器（Fixer）不會自行合併變更。文章說修補階段會先跑回歸測試（regression test），要求目標測試有乾淨的 fail→pass 變化；如果修補後測試失敗，或全域測試出現下游回歸，提交（commit）會被擋下並交給人類。
這個閘門很關鍵。AI 產生 patch 的速度可以很快，但安全修補若破壞其他功能，風險會從「找到漏洞」變成「引入新事故」。因此，AI 漏洞 harness 最健康的定位是：加速候選發現、證據整理與修補草稿，不應取代變更管理、code review 與負責任的 release 流程。
和現有 AI 安全工具怎麼接起來？
Cloudflare 的公開內容適合放在三條線一起看：
- Microsoft RAMPART 與 Clarity：把 red-team 發現轉成可重複跑的測試，適合放進 CI 與設計審查。
- Microsoft MDASH：多模型、多代理的漏洞發現與修補系統，重點同樣在流程管線、驗證、去重與證據。
- Cloudflare Agents SDK 與 Flue：如果你要把代理工作流上線，執行環境的持久執行、沙盒、恢復與工具邊界會影響安全調度框架能否穩定跑。
把這些串起來看，2026 年的 AI 資安重點正在從「模型會不會找出一個 bug」轉向「團隊能不能把 AI 產出的懷疑，變成可驗證、可排程、可審核、可回滾的工程資產」。
來源限制與閱讀提醒
Cloudflare 的文章很透明地說，這些 findings 來自隔離、受控的研究實驗，不代表 Cloudflare live production 還有公開未修補漏洞。文中的數字也會因為系統持續運作而快速過期。讀者應把它當成架構與流程案例，不應拿來當成可直接套用的成效保證。
另外，Cloudflare 釋出的 security-audit-skill 是單一程式庫（repository）的起點，不等於完整內部調度框架（harness）。它適合拿來理解階段、提示詞（prompt）、結構描述（schema）與驗證方式；若要進企業級多程式庫掃描，仍要自行設計資料庫、任務佇列、權限、沙盒、去重、生產環境可達性判斷與人工審核。
FAQ
Cloudflare security-audit-skill 可以直接拿來掃公司核心系統嗎？
不建議第一輪就碰核心系統。比較穩的做法是先挑非核心 repository，移除 secrets，限制網路與工具權限，要求所有 finding 都有可重跑 PoC、結構化輸出與獨立驗證。等流程能穩定淘汰噪音，再逐步擴大到更重要的程式庫。
AI 漏洞 harness 會取代 SAST 或人工 code review 嗎？
不會。它比較像新增一條候選漏洞來源和 triage 加速器。SAST 擅長穩定規則與已知模式，人工 review 擅長系統脈絡與產品風險；AI harness 的價值在於探索跨檔案、跨 repo、較難用固定規則描述的疑點，並把證據整理成可審查的工作項目。
什麼時候才需要跨 repo tracing？
當你有多個真正互相依賴的服務、library、API 或部署環境，而且單 repo 分析經常漏掉「外部輸入怎麼流到消費端」時，才值得投資跨 repo tracing。Cloudflare 的建議很務實：如果還沒有多個重要 repository，就先跳過這層，等單 repo 的 Recon、Hunt、Validate 與去重穩定後再加。
官方與參考來源
結論
Cloudflare 這次公開的重點，是把 AI 漏洞掃描從單次 agent 任務，拉回可驗證的工程系統。好的 vulnerability harness 會保存狀態、拆分角色、要求 threat model、用程式做機械檢查、讓獨立 Validator 反駁 finding，最後用 fail→pass 測試和人類審核守住修補閘門。
Mason 的建議是先小後大：用單一非核心 repository 跑 30 天試點，記錄候選數、驗證淘汰率、可重跑 PoC、修補 PR、人工審查時間與誤報類型。當你能穩定把 AI 產生的噪音壓成可信工作項目，再考慮跨 repo tracing、專用去重 agents、worker pool 與更自動化的修補流程。