Cloudflare 開源 security-audit-skill 是什麼？讓 coding agent 自己跑六階段資安稽核，每個候選漏洞都要被獨立代理推翻過才留下來
目錄
共 13 個章節
Cloudflare security-audit-skill 是什麼：不是掃描器，而是給 coding agent 的資安稽核作業手冊
如果你想找一套按下去就自動掃出漏洞的工具，這套東西會讓你失望。Cloudflare 開源的 security-audit-skill，本質是一份用 Markdown 寫成的資安稽核作業手冊，外加兩支零依賴的 Node.js 檢查腳本：validate-findings.cjs 負責驗證發現清單的格式，validate-coverage-ledger.cjs 負責檢查覆蓋紀錄有沒有漏。裝進你平常用的 coding agent（會開子代理、能執行指令的 AI 編碼助理）之後，你要求它對某個專案做資安稽核，它就會照著手冊跑完整流程，而不是憑當下印象隨機翻幾個檔案。
換句話說，這份技能管的是流程，不是掃描引擎。之所以需要它，是因為大型語言模型單獨讀程式碼時，很容易看到類似漏洞的寫法就回報，誤報多到沒人想看完；手冊把偵察、搜尋、驗證、產出報告拆成固定階段，讓每個結論都留下痕跡。
來歷與熱度：從內部小工具到四萬多顆星
這個專案不是憑空冒出來的。依 Cloudflare 官方部落格的說明，起點是公司內部約 450 行的 security-audit 技能，一開始只用在單一專案上，提示詞一路調到真的能抓到問題，後來才長成整個掃描系統的底座。專案在 2026 年 6 月開源，採 MIT 授權，任何人都能自由使用與修改。到 2026 年 10 月 26 日查詢時，GitHub 已累積 46,783 顆星，對一個只放技能文件與檢查腳本的專案來說，這個數字反映的是大家對「讓 AI 自己把關程式碼」的高度期待。
不過期待高，誤解也多。它並不是漏洞掃描器，不會替你枚舉已知漏洞特徵；也不是防毒軟體，不會阻擋執行中的惡意行為。更關鍵的是，它不保證零漏洞：Cloudflare 在說明文件裡寫得很直白，在他們自己的測試中，單次執行大約只找到重複執行總量的一半漏洞。因此正確的心態，是把它當成一位會寫工作紀錄的初階稽核員，而不是驗收章。理解了這個定位，後面的階段流程與沙箱要求才讀得下去。
六個階段怎麼跑：從偵察、覆蓋式搜尋，到「想辦法推翻它」的對抗式驗證
這個技能拆成六個階段，每個階段都有明確的輸入、輸出與負責的代理，跑完會在資料夾裡留下對應檔案。
| 階段 | 做什麼 | 產出檔案 |
|---|---|---|
| 1 偵察 | 畫架構與信任邊界，列出覆蓋清單 | architecture.md、coverage-ledger.json |
| 2 覆蓋式搜尋 | 切出獨立單位派搜尋代理，評論者找漏 | 各單位搜尋紀錄 |
| 3 候選驗證 | 新代理想辦法推翻候選 | 驗證結論 |
| 4 結構化輸出 | 分成 confirmed、needs_validation、rejected | findings.json |
| 5 獨立紀錄驗證 | 再找新代理重驗每筆結論 | 通過驗證的紀錄 |
| 6 目標中性報告 | 從紀錄與清單產生人可讀報告 | REPORT.md 等 |
第一階段常被低估：它畫出系統架構與信任邊界（誰的資料會流到誰手上、哪些輸入從外面進來），再把非查不可的地方寫成覆蓋清單，產出 architecture.md 與 coverage-ledger.json。第二階段據此把範圍切成獨立單位，派搜尋代理分頭查，再由一位沒下去查的評論者回頭找漏。它在乎的是有沒有哪一塊根本沒人看過，而不是找到幾個。
第三階段是分水嶺：每個候選漏洞都交給全新的驗證代理，任務不是確認，是想辦法推翻。
為什麼檢查的人不能是找到的人
同一個代理既搜尋又驗證，會傾向替自己的判斷找理由，這在人類團隊叫球員兼裁判，在 AI 身上更明顯，因為它連自己剛寫下的推理都會當成事實沿用。換成沒參與的代理，只拿到架構文件與候選描述，沒有立場要維護，比較敢說這條不成立。用「推翻」而非「確認」，是因為確認式提示詞會讓代理往成立方向補理由。
跑完後結果硬性分成三類：confirmed 有完整來源追溯且實際觀察到結果，needs_validation 有一個明確未解的事實但不給嚴重度，rejected 是被推翻的候選。看報告的人因此知道哪幾條能直接處理、哪幾條要補資料。
實戰操作：一行指令安裝、一句話觸發，跑完之後你手上會有什麼檔案
安裝只要一行指令。在終端機貼上下面這行，安裝器就會從 GitHub 把技能抓下來，放進 agent 讀得到的位置；因為它裝的是「技能」而不是整套軟體，所以不會多出常駐服務，也不會佔用背景資源。若你電腦裡有多個專案都要用，指令後面補上 --global，改成裝在使用者層級，之後不管切到哪個資料夾都叫得到。
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
裝好之後，進到你要稽核的專案資料夾，用平常講話的方式對 agent 下指令，例如「security audit this codebase」，它就會照著技能手冊跑完六個階段。不過這不是掃描器那種幾秒回傳的東西，因為它要開子代理、逐檔讀原始碼、還要跑對抗式驗證，一次跑上數十分鐘到數小時都有可能，建議放在下班前或獨立機器上執行。結果也不會散落在終端機畫面裡，而是統一落在使用者家目錄下的 ~/security-audit-skill/，裡面再依 repo 名稱與第幾次執行分資料夾，第一次是 run-1，重跑就變 run-2，方便你比對兩次的差異。
跑完之後，資料夾裡會有這些檔案
| 檔案 | 內容 | 誰來看 |
|---|---|---|
architecture.md |
系統架構、信任邊界、對外輸入點 | 接手專案的人、要複查範圍的人 |
coverage-ledger.json |
這次打算查哪些區塊、查了沒 | 想確認「有沒有漏」的人 |
findings.json |
confirmed、needs_validation、rejected 三類結論 | 要接進追蹤流程或其它工具的人 |
REPORT.md |
人看得懂的總結報告 | 主管、客戶、外包驗收 |
FINDINGS-DETAIL.md、NEEDS-VALIDATION.md |
逐條細節與尚未釐清的事實 | 實際要動手修的人 |
這些檔案不是寫完就算，因為格式一旦亂掉，後面的判讀就會跟著歪。所以技能規定，偵察階段建完覆蓋清單、之後每次更新清單，都要跑一次 validate-coverage-ledger.cjs；第四與第五階段每替換一筆紀錄，也要跑 validate-findings.cjs。這兩支是零依賴的 Node.js 小程式，只檢查欄位與格式對不對，不判斷你判得對不對，換句話說，它們擋的是資料結構壞掉，至於漏洞成不成立，責任還是在看報告的人身上。
為什麼不能直接對著正式環境跑：沙箱要求與代理呼叫預算
上一章講輸出格式，這裡面對更實際的問題：讓 AI 跑指令、開瀏覽器、灌測試資料，會不會弄壞正式站？原始碼可唯讀檢視，但建置、測試、模糊測試必須關進作業系統層強制的沙箱，做不到就不能跑。
沙箱不是選項，是能不能執行的前提
沙箱是跑壞也炸不到外面的隔離空間，必須由作業系統核心強制，不能靠人自律。技能拆成四個條件：
- 執行時完全沒有對外網路；需本機連線時只能用隔離的 loopback。
- 環境從空白啟動，環境變數只從明確允許清單填入安全值。
- 目標程式與工具鏈唯讀，被測程序只能寫自己的
scratch目錄。 - CPU、記憶體、行程數、檔案大小與執行時間都要設明確上限。
寫入隔離同樣嚴格：每個搜尋與驗證代理拿到獨立目錄，只能寫自己的 scratch；要留下的產出物由父代理逐檔驗證後搬進 artifacts，檢查路徑與檔案型別，避免競態偷渡。對正式站點探測、對正式程序做可用性測試、發佈產出物、花付費 API 額度，文件明文禁止。環境湊不齊控制時，不是硬跑，而是把缺沙箱能力寫成 needs-validation 阻礙，附安全驗證計畫交人判斷。這種把能力關進邊界的設計，我們在個人助理 Agent 的安全與治理：OpenClaw 的漏洞編號與供應鏈事件、Hermes 沙箱設計怎麼看也整理過一次，結論一樣：功能再強，邊界要先畫。
用代理呼叫次數當預算
安全之外，第二個現實問題是錢與時間。技能不談 token，用代理呼叫次數當預算：一個覆蓋單位約等於一次搜尋代理呼叫，一個候選漏洞依檔次花一到兩次驗證呼叫。官方要求先保留評論者與驗證額度，再派搜尋代理；額度不夠就不派，把該次執行標記 incomplete，不許宣稱完整覆蓋。檔次分 quick、standard、deep，對應先看一眼、預設、高風險大型目標。這條規則的用意不是省錢，而是逼團隊在報告上承認「這次沒跑完」，而不是把沒查到的區塊當成查過了。
替代方案有限公司觀點：台灣中小企業該把它放在哪一個環節
上一段談的是預算，接著要問：這筆錢該放在哪個環節？答案不是「全公司導入」，對多數台灣中小企業來說太大也太抽象。先挑一個具體專案，當成交付前的自我檢查，會務實得多。
場景一是外包驗收，在交付的程式碼上跑一輪，把 confirmed 清單當成驗收附件，讓有沒有問題變成一條可追溯的紀錄。場景二是老系統交接，很多公司的核心系統沒有規格書，先讓它產出 architecture.md 與覆蓋清單，接手的人至少知道邊界。場景三是上線前檢查，「有沒有把金鑰帶進版控」這種事靠人記得一定會漏，交給覆蓋清單反而穩定。
三種情況先不要急著用
它也有明確邊界。期待它取代滲透測試，它本質上是給 AI 代理的稽核流程，不是滲透測試服務。期待零人力，專案說明寫得很清楚：單次執行不等於完整，報告還是得有人讀。想在正式環境直接跑，技能要求唯讀檢視與沙箱隔離，做不到就只能把缺口寫成待驗證項目。
我們的觀察：把關要留下證據，不是取代人
台灣多數中小企業的資安預算落在「有事件才處理」，平時沒有紀錄，事發時只能靠猜；這套做法的價值，在於把平時的把關成本壓到接近零，並且留下證據。當 AI 生成的程式碼變多，誰來把關就從工具問題變成流程問題：工具能幫你跑完六個階段，卻不能替你決定風險要不要接受。落地建議是先用在一個專案、指定一位負責看報告的人，跑兩三輪再決定要不要擴大；反過來說，如果沒有人會看報告，再完整的覆蓋清單也只是存檔。同樣的判斷順序，我們在台灣團隊什麼時候該用 REA：舊系統介面重建、交接文件補齊、內部資安稽核的成本試算與限制也用過：先把範圍、人力與成本算清楚，再決定要不要導入。
常見問題 FAQ
Q：這跟一般的漏洞掃描器差在哪？我該裝嗎？
它不是掃描器，而是一份把資安稽核拆成六個階段的作業手冊，加上兩支只檢查輸出格式的腳本；裝在你平常用的 coding agent 上，在專案裡叫它做稽核，它就會照著跑完。最大差別在驗證方式：每個候選漏洞都交給一個沒參與搜尋的全新代理，任務是想辦法推翻它，推不翻才留下，分成 confirmed、needs_validation、rejected 三類。所以它只確認真的跨過信任邊界、有具體影響的事，縱深防禦的缺口只算加固建議。適合拿一個具體專案、在交付前做自我檢查，不適合期待它取代滲透測試。
Q：跑一次就代表沒漏洞了嗎？
不是。Cloudflare 在自己的測試裡發現，單次執行大約只找到重複執行總量的一半漏洞，這是他們自家的測試結果，不是全行業統計。所以官方明講單次執行不等於完整，沒有前次清單就要在報告裡說明，不能暗示「跑過一次就沒事」。它也用代理呼叫次數當預算，額度不夠就不派搜尋代理，並把該次執行標記為 incomplete，不准宣稱完整覆蓋。實務上要把它當成平時留下紀錄的工具，而不是上線前跑一輪就交差。
Q：它會不會直接對著正式環境跑、亂碰我們的服務？
技能本身規定原始碼檢視是唯讀的。若要在目標端跑建置、測試、模糊測試，只能在作業系統層強制的沙箱裡執行，而且得同時滿足：沒有對外網路、空環境啟動、目標與工具鏈唯讀、被測程序只能寫自己那個 scratch 目錄，並限制 CPU、記憶體、程序數與執行時間。做不到這些控制就不能執行程式碼，要把「缺沙箱能力」寫成待驗證的阻礙並提出安全驗證計畫。
📩 有任何問題或需要協助，歡迎聯絡我們：[email protected]
Related
