Cloudflare security-audit skill 是什麼？六階段開源資安稽核與沙盒前提
Cloudflare security-audit skill 讓程式代理分六階段稽核程式碼，再由另一組代理試著推翻每個發現。本文依官方倉庫與部落格，說明安裝方式、沙盒前提、輸出檔案、適用對象，以及導入前要先看清楚的限制與風險。
Cloudflare security-audit skill 在 2026 年 10 月 19 日又在 X 上熱傳，RoundtableSpace 的貼文在查詢時約有 2,400 個讚、22 萬次瀏覽。
貼文大意是，Cloudflare 把自家漏洞獵捕系統的起點開源了，你的程式代理現在也能拿來掃自己的程式碼。
查官方資料後，這個說法大致成立，但時間線要修正。
GitHub 倉庫建立於 2026 年 6 月 18 日，和 Cloudflare 部落格《Build your own vulnerability harness》同一天，所以它不是這週的新發布，而是舊專案被重新翻出來。
skill 是一包寫給程式代理看的指示檔與腳本，教它按固定流程做事。這個 skill 的流程是先畫出程式碼地圖，再分區找漏洞，最後讓另一組代理試著推翻每個發現，因為負責找漏洞的代理很容易對自己的結論過度自信。
但它不是一鍵掃描器。官方要求執行環境有能分派子代理的模型，也要有能隔絕網路的沙盒，沒有沙盒時 skill 不會執行目標程式碼，需要實際執行才能證實的疑似漏洞，只會被標成待驗證。
而且 Cloudflare 自己測過，單次執行只找到多次執行總量的大約一半。
我的判斷是，它適合已經在用程式代理、有隔離環境、也有人力複查結果的小團隊，不適合未先估算成本，就想在每次提交跑完整稽核，或是沒有資安人員驗證結果的團隊。
要判斷自己屬於哪一邊，得先弄清楚這個開源版和 Cloudflare 內部系統是什麼關係。
Cloudflare security-audit skill 是什麼？從 450 行技能到 128 個程式庫
Cloudflare security-audit skill 是 Cloudflare 在 2026 年 6 月 18 日開源的程式代理技能，官方倉庫形容它能把你的代理變成資安稽核員，授權是 MIT。
部落格作者是 Dan Jones、Alexandra Godoi 與 Grant Bourzikas，文中說他們一開始只是一個約 450 行的 security-audit skill，先在單一程式庫上反覆調整提示，直到真的挖出漏洞。
之後他們才補上編排的部分，也就是把多個代理串成流程、把狀態存進資料庫、讓中斷的工作可以續跑。從第一次執行 skill 到能掃 128 個程式庫的系統，官方說大約花了六週。
倉庫 README 說得很清楚：這個 skill 就是內部漏洞發現系統的起點，系統後來長成多階段、跨整個公司的規模，而 skill 是單一程式庫版本的出發點。
部落格表示，開源前只把技能稍微整理過，內容大致維持原樣，完整的 harness（把代理、資料庫與排程接在一起的外層系統）預計稍後釋出。我查證時，官方倉庫公開的只有這個 skill。
開源版和部落格描述的原版並不完全一樣。部落格形容原版是七個步驟，最後一步是把結果送進內部的收件介面，倉庫 README 現在列的是六個階段。
9 月 10 日的一次提交把流程、輸出格式與驗證腳本整個重寫過，官方沒有逐項說明和原版差在哪，所以部落格裡的數字指的是內部系統，不能直接當成這個開源技能的成績。
這也回答了貼文的說法：Cloudflare 沒有說這個 skill 就是它掃自家程式碼的工具，而是說它是內部工具的起點。
既然開源版只是起點，它的價值就在流程設計，也就是誰找漏洞、誰推翻、誰核對，這些都寫在六個階段裡。
六個階段怎麼跑：先畫地圖，再分區獵捕，最後由另一組代理驗證
這個 skill 把一次稽核拆成六個階段，由多個代理分工，其中負責驗證的代理必須和原本找到漏洞的代理不同。
以下我把 README 的流程整理成表格，產出檔案的名稱照官方原文保留。
| 階段 | 做什麼 | 主要產出 |
|---|---|---|
| 1 偵察 | 整理架構、信任邊界、輸入入口與覆蓋清單 | architecture.md、coverage-ledger.json |
| 2 分區獵捕 | 依清單把程式碼分給獨立獵手，再由覆蓋審查員找缺口 | 各獵手的檢查紀錄 |
| 3 候選驗證 | 每個候選漏洞交給全新的驗證員，任務是推翻它 | 驗證結論 |
| 4 結構化輸出 | 寫成記錄並用 JSON 格式規範檢查 | findings.json |
| 5 獨立記錄核對 | 新代理重新核對最終記錄中的原始碼說法 | 修正後的記錄 |
| 6 報告 | 從已驗證的記錄產生報告 | REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md |
表格裡的 coverage-ledger.json 是覆蓋清單，記錄哪些區塊已經有人查過、哪些還沒有。因為有這份清單，下一輪執行可以接著補漏洞，而不必從頭再來。
最後的記錄只有三種結論。confirmed 代表有完整的原始碼追蹤與可觀察的結果，needs_validation 代表還差一個明確的事實，所以不給嚴重度，rejected 則是已被推翻的候選。
這三種結論背後有一個很實際的設計：只確認真正越過信任邊界的缺陷。如果第一層防護擋住攻擊，卻少了第二層，官方的說法是這只算加固建議，不算漏洞。
好處是報告比較不會被一堆「理論上可以更安全」的項目淹沒，但相對地，加固型的問題不會出現在 confirmed 清單，團隊想看這類項目就得另外處理。
獵手的檢查範圍也不是只有一般的網站漏洞。倉庫另附十份依目標類型選用的延伸文件，涵蓋記憶體安全、提示注入與代理工具、HTTP 協定與驗證、前端、供應鏈與發布、雲端部署、訊息與遠端呼叫協定、資源耗盡、資料隔離、桌面與行動應用。
這些文件會依目標選用，所以掃一個純後端服務和掃一個桌面應用，獵手拿到的攻擊清單並不相同。
流程看懂了，下一步是把它裝起來，並決定第一次要問代理什麼。
Cloudflare security-audit skill 安裝與第一次試跑
官方 README 用 Skills CLI 安裝，這是 skills.sh 提供的技能安裝工具，指令如下。
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
加上 --global 會裝到使用者層級，npx skills --help 可以查怎麼選擇要裝進哪個代理。README 沒有指名支援哪些代理，只寫模型要能呼叫工具、能分派平行的子代理，另外要有 Node.js，因為驗證腳本是用 Node 寫的。
安裝後，在要稽核的程式碼目錄啟動代理，直接用自然語言要求，例如「security audit this codebase」或「find security vulnerabilities in ./src」。
它有兩種模式。一般的資安問題、單點檢查或方法討論，用的是指引模式，不會建立輸出資料夾，也不會跑完整六階段。
只有明確要求稽核整個程式庫、做完整檢查或要報告檔案時，才進入完整稽核模式。如果請求兩種都像，SKILL.md 規定代理要先問一個問題再動手。
完整模式沒有指定輸出位置時，預設寫到使用者家目錄下的 security-audit-skill 資料夾。只有你明確選了被版本控制忽略的資料夾，它才會寫進目標程式庫，這可以避免稽核檔案被誤提交。
用一個小任務試跑
第一次試跑，我會選一個自己擁有、規模不大、沒有正式環境資料的專案，而不是公司最核心的服務。
做法是先確認沙盒可用，再讓代理在指定的輸出資料夾跑一次完整稽核，最後先讀 NEEDS-VALIDATION.md，了解有哪些線索卡在什麼事實上。
官方 README 沒有提供開源版的耗時與費用。部落格給的數字屬於內部系統：約 3 萬行的程式庫跑一次完整流程，需要 3 到 4 小時，初步發現約 100 個。
所以第一次試跑最好挑非上班時間，並先在代理的帳單頁設好用量上限。
SKILL.md 另外提供三種規格，可以控制第一次試跑的規模。quick 只跑一輪獵捕和一次覆蓋審查，standard 是預設，deep 則把檢查單位切得更細，給高風險或大型目標用。quick 與限定範圍的稽核，報告裡都必須標示為部分覆蓋。
花費也有明確的上限機制，使用者可以設定代理呼叫的總次數。如果上限連最基本的偵察與驗證都支付不起，規定是一個代理都不啟動，而不是草草跑完，所以第一次試跑，我會選 quick 加上嚴格的次數上限。
試跑完成後，比較重要的是看一件事：被標成 confirmed 的項目，你自己能不能照記錄裡的追蹤重現。重現得了，才算這個流程在你的程式庫上有用。
不過試跑之前，有一個前提不能略過，就是沙盒。
沙盒前提：沒有隔離環境時，skill 不會執行目標程式碼
README 的需求清單裡，最容易被忽略的是作業系統層級的沙盒。官方要求它要關閉對外網路、只放行白名單環境變數、限制資源，而且只能寫入指定的暫存目錄。
SKILL.md 的規則更細。目標程式碼的建置與測試，必須在這種沙盒裡跑，目標與工具鏈是唯讀，CPU、記憶體、行程數、檔案大小、磁碟與時間都要設上限。
它也禁止代理去探測已部署的服務、共用基礎設施或正式環境的身分，不能花付費 API 額度，也不能為了證明漏洞而做超出最小必要的操作。
如果這些控制有任何一項做不到，skill 的規定是不要執行目標程式碼，把線索留在 needs_validation，並附上安全的驗證計畫。
這個設計的意義在於，稽核程式碼本身就有風險。陌生的程式碼被建置、被測試、被當成漏洞證明來執行時，如果沒有隔離，等於讓不可信的程式碼跑在你的開發機上。
Cloudflare 的部落格也提到類似的經驗。他們說獵手最大的品質躍進，來自給它們一個以 unshare 建立的沙盒，讓代理可以真的編譯小片段、讓程式崩潰，而不只是讀原始碼。
部落格另外提醒，如果整套系統本身就跑在 Docker 裡，裡面的沙盒需要把 seccomp 與 apparmor 設成 unconfined，否則會無聲地啟動失敗。
官方只說這樣才能啟動，沒有討論放寬後的風險。我的看法是，放寬前要先想清楚這個容器裡還放了什麼，最好是專用的稽核機器，而不是平常開發用的環境。
另一個值得學的是部落格講到的代理作弊問題。代理會改原始碼讓自己的漏洞證明成立，再宣布找到漏洞，也會寫出自己證明自己的測試。
Cloudflare 的對策是要求獵手先寫出威脅模型，每個確認的發現都要附上一個在未修改程式碼上執行的重現測試，而且驗證員不能自己提報發現。這些是內部系統的做法，開源 skill 把其中的獨立驗證與記錄核對保留了下來。
不過沙盒、預算和複查都需要人與環境，所以下一步要看你的團隊有沒有條件承接。
延伸閱讀：Codex Security Cloud 完整解析：Daybreak Blue、全程式庫掃描與 AI 修復怎麼用？
適合誰、不適合誰：導入前的檢查清單
這個 skill 是方法與提示的集合，不是服務。所以評估它的重點，在於你的團隊有沒有承接它的條件。
| 情境 | 適合嗎 | 原因 |
|---|---|---|
| 小團隊，已在用 Claude Code 這類程式代理 | 適合 | 安裝只要一行指令，也不用另外採購平台 |
| 有專人能複查 confirmed 與 needs_validation | 適合 | skill 只描述修補建議，不會改你的原始碼，優先順序與要不要修仍由人決定 |
| 想在每次合併請求跑完整稽核 | 先不要這樣導入 | 內部大型掃描耗時以小時計；開源版 quick 或局部檢查的耗時仍需用自己的專案驗證 |
| 沒有隔離環境可用 | 先不要用 | 缺少沙盒時，skill 不會執行目標程式碼，需要執行才能證實的線索只能停在待驗證 |
| 想取代滲透測試或法遵稽核 | 不適合 | 官方沒有宣稱涵蓋率，也沒有提供漏報率 |
表格最後兩列是最常見的誤解。官方明確寫了單次執行只找到約一半，所以它是輔助稽核的工具，不能拿來證明程式碼安全。
如果你決定試用，導入前我會先確認五件事。
- 稽核範圍：只放自己有權限的程式庫，第三方或客戶的程式碼要先取得書面同意。
- 資料去向：skill 跑在你的代理裡，程式碼會送到代理背後的模型服務，這部分 README 沒有說明，要回頭看代理與模型供應商的資料條款。
- 沙盒與預算：先確認隔離環境，再決定每一輪能花多少代理呼叫與時間。
- 複查人力：指定誰讀報告、誰決定要不要修，避免報告產生後沒人處理。
- 重跑計畫：既然官方說多次執行才能補足覆蓋，就要預先排好第二輪、第三輪。
這五件事都做得到，才輪到下一個問題：這個 skill 本身有哪些限制，數字能信到什麼程度。
延伸閱讀：OpenVuln 免費找漏洞：4,249 項「潛在發現」之後，維護者真正要處理什麼？
限制與風險：數字屬於內部系統，單次稽核只看到一部分
部落格裡最吸睛的數字是 20,799 個原始候選、約 12,057 個通過驗證、最後有 7,245 個可交給團隊處理的發現。
這些數字屬於 Cloudflare 內部的完整系統，在一組隔離環境裡跑出來，文中自己也說，等你讀到時數字已經過時。把它們當成開源 skill 的預期成績，會高估太多。
官方也坦白說，他們不宣稱漏報率，因為沒有一份標好所有真實漏洞的資料可以拿來比，能觀察的只是重跑時還有沒有新發現、覆蓋範圍有沒有繼續成長。
換句話說，沒有找到問題，不代表程式碼沒有問題。這對決策者尤其重要，因為一份乾淨的報告可能只是代表這一輪的覆蓋有限。
第二個限制是結論的範圍。confirmed 只代表在原始碼與沙盒裡能證明越界，不代表在你的正式環境裡一定打得到。
Cloudflare 內部系統另有一個判斷階段，會用維基、工單、設定檔與部署資訊，確認漏洞在正式環境是否可達。開源 README 沒有提到類似的步驟，所以這部分要由你的團隊補上。
第三個是修補。部落格形容自動修補是整個系統裡最年輕、最慢的部分，每個修補分支都要人審查，因為模型很容易修好一個漏洞卻順手弄壞另一個功能。
最後是成本與時間。倉庫沒有公開費用估算，而部落格說每一輪補洞的成本約為第一輪獵捕的一半，所以多輪執行的帳單會比一次執行高出不少。
這些限制不代表它沒有價值。它的價值在於把稽核流程標準化，並強迫每個發現都經過另一組代理反駁。要不要用，取決於你願不願意為了這個流程準備沙盒與複查人力。實際動手前，讀者最常卡在幾個具體問題，下面逐題回答。
Cloudflare security-audit skill 常見問題
Cloudflare security-audit skill 可以取代靜態分析工具嗎？
不建議這樣假設。README 沒有談它和靜態分析工具的關係。部落格提到，他們在一個月的執行中把 Semgrep 接進流程，獵手卻一次都沒有呼叫，寧可直接讀程式碼與執行。這只說明代理的偏好，不代表靜態分析工具沒有價值，我的做法會是兩者並用。
一定要用 Claude Code 嗎？
README 沒有指名特定代理，只要求模型支援工具呼叫與平行子代理。實際能不能順利跑完六階段，還是要看你使用的代理能不能分派子任務。
掃一次就夠了嗎？
官方說不夠。他們的測試顯示，單次執行找到的漏洞約為多次執行總量的一半，而且重跑會參考前一輪的記錄，只補沒查過的地方，並重新核對有變動的程式碼。
發現漏洞後該怎麼處理？
自己的程式碼就依一般流程開工單、修補與重測。如果掃的是第三方開源專案，我的建議是依對方的資安回報規定私下通報，而不是直接公開。Cloudflare 在 README 留的電子郵件信箱，用途是交流 AI 資安工具的做法，不是漏洞通報窗口。
先用小專案跑一輪，再決定要不要擴大
最穩妥的用法，是先挑一個小專案跑完一輪，再決定要不要擴大。因為這個 skill 值得關注的地方，不在於數字多大，而在於它把「找漏洞的人不能驗證自己」寫成了固定流程，這一點在你的程式碼上有沒有用，只能親自跑過才知道。
如果你的團隊已經有隔離環境和複查人力，我會建議跑完那一輪後重現幾個 confirmed 項目，確認流程有效，再考慮每週或每月定期掃描。
如果還沒有沙盒，先補這一塊，比急著安裝 skill 重要。
想持續追蹤 AI 資安與開發工具的更新，可以免費訂閱 AI 郵報，也歡迎回到官方倉庫核對最新版本的 README。
