Cloudflare security-audit skill 是什麼？讓 Claude Code 變資安稽核員的六階段流程、安裝與沙盒前提

Cloudflare security-audit skill 是 Cloudflare 開源的一份「AI 資安稽核說明書」。裝進 Claude Code 這類 AI 寫程式工具之後，你只要對它說一句「幫這個專案做資安稽核」，它就會派出好幾個 AI 助手分工：有人畫地圖、有人專門找漏洞、有人專門挑錯，最後交出一份每一條都被第二個 AI 驗證過的漏洞報告。它用 MIT 授權免費開放，程式碼放在 GitHub。

這則消息最近在 Threads 上被轉了很多次，我們團隊也是半夜在群組裡收到這張截圖，第一個問題是：「所以以後找漏洞可以全部交給 AI 了嗎？」我們把 Cloudflare 的原文部落格、GitHub 上的說明文件和 Skill 本體逐段讀完，發現社群貼文講的「多個 AI 分工、交叉驗證」是對的，但漏掉了兩件會直接影響你能不能用的事：它要求一個隔離的沙盒環境，而且官方自己說，跑一次大約只抓得到一半的漏洞。

這篇從零講起：Skill 是什麼、六個階段各在做什麼、為什麼要讓 AI 互相挑錯、怎麼安裝、它做不到什麼，最後談中小企業該怎麼看這個工具。如果你連 Claude Code 的 Skill 都還沒用過，可以先翻一下我們寫過的 Claude Code Skill 教學，再回來看會更順。

Cloudflare security-audit skill 是什麼？一張表看懂

一句話：它把資深資安人員做程式碼稽核的流程，寫成 AI 看得懂、照著做的步驟，再加上「找到的人不能自己驗收」這條規矩。下表是我們整理的重點，數字都對過 Cloudflare 原文與 GitHub 頁面（2026 年 10 月 21 日）：

看完這張表，先抓住兩件事。第一，它是一份「做法」，裡面沒有任何掃描引擎，真正動腦的是你接上的 AI 模型，所以模型越強、它越強，費用也跟著模型走。第二，它的價值在流程設計：多數人用 AI 找漏洞，問一句就照單全收，這份 Skill 把「懷疑」寫進了每一個步驟。

還有一個時間點要釐清。社群這兩天才在傳，但這個 repo 其實 6 月就開源了，9 月中又把流程改寫過一輪，所以網路上有些文章寫「七個階段」，有些寫「六個階段」，兩邊都沒錯：七階段是 Cloudflare 部落格描述的內部初版，六階段是現在 GitHub 上的公開版。

先搞懂三個名詞：Skill、子助手、資安稽核

先講結論：Skill 是工作說明書，子助手是被分派任務的同事，資安稽核是「站在駭客角度把程式翻一遍」。三個名詞搞懂，後面的流程就很好讀。

這裡最容易誤會的是「子助手」。很多人以為多開幾個 AI 只是為了跑得比較快，其實 Cloudflare 看重的是「隔離」：每個子助手的記憶是乾淨的，負責驗證的那一位沒看過找漏洞那位的推理過程，所以比較不會被帶著走。就像公司請會計師查帳，會找外面的事務所，原因一樣。

如果你想多了解讓多個 AI 互相辯論為什麼會比較準，可以參考我們整理的 Multi-Agent Debate 架構；想知道 Skill 生態圈還有哪些好用的技能包，可以看 Claude Skills 完整指南。

六個階段怎麼分工：找漏洞的和驗漏洞的永遠是不同助手

一句話分工：先畫地圖，再分頭找，找到的交給別人推翻，推不翻的才寫進報告，寫完還要再請一個新助手對一次原始碼。下面這張圖是公開版的流程：

把每個階段拆開來看，重點如下：

三種判定的差別要特別記住。confirmed 代表有完整的程式路徑和實際觀察到的結果；needs_validation 代表看起來有問題，但缺一個關鍵事實沒辦法確認（例如要看正式環境的設定），這類不給嚴重程度；rejected 代表已經被推翻。官方在 SKILL.md 裡把「替 needs_validation 標嚴重程度」列為禁止做法之一，用意是逼 AI 誠實承認不知道的事。

另一個常被忽略的設計是「重跑會累加」。第二次對同一個專案跑稽核時，它會讀上一次的覆蓋清單和結果，專門去補沒看過的區域、重新驗證有改過的程式碼。這也是它要你把輸出放在固定資料夾的原因，預設位置是家目錄底下的 `security-audit-skill/<專案名>/run-<次數>`。

為什麼要讓 AI 互相挑錯？Cloudflare 自己踩過的三個坑

因為 AI 找漏洞最大的問題是會「自己騙自己」。Cloudflare 在原文裡講得很直白，他們讓 AI 獵漏洞時遇過這幾種狀況：

• 改程式讓自己的攻擊成功：AI 為了證明漏洞存在，偷偷修改原始碼，再得意地回報一個它自己製造出來的洞。
• 寫出廢話測試：例如「exec() 會執行東西，所以這是嚴重漏洞」，邏輯上永遠成立，卻什麼也沒證明。
• 攻擊情境不合理：寫出能跑的攻擊程式，但前提是「攻擊者已經有資料庫寫入權限」，那本來就能寫資料庫。

他們的解法有三招，公開版 Skill 都保留了精神。第一招，獵人在回報前必須先講清楚「攻擊者是誰、跨過了哪條邊界」，講不出來就不能提交。第二招，驗證者不能自己提交漏洞，唯一工作就是推翻獵人的說法；Cloudflare 的說法是，讓獵人自己批改作業，它一定全部打滿分。第三招，用一般程式（不是另一個 AI）機械檢查引用的檔案和行號真的存在。

這套做法有沒有用，看 Cloudflare 內部大規模版本的數字最清楚。下表是原文公布的漏斗，注意這是他們內部的完整系統跑在 128 個程式庫上的累計結果，公開的 Skill 只是它的起點：

兩萬多條候選，最後只有三分之一左右真的值得工程師花時間。換個角度想，如果沒有驗證這道關卡，工程團隊每收到三條警報就有兩條是白忙，很快就沒人想看了。原文也提到，改善偵察階段給的背景資訊之後，第一輪驗證的否決率從 40% 降到 11%，代表獵人一開始就少寫很多垃圾。

還有一個很實在的數字：官方 README 寫到，在他們的測試中，跑一次大約只抓到多次重跑總數的一半，而且單次抓到的多半偏簡單。這是誠實的提醒，也是我們認為最該被轉傳的一句話：跑完一次沒找到東西，絕對不代表程式碼安全。

我們公司自己的開發流程也有一條很像的規矩：寫程式的 AI 不驗自己的產出。每個 PR 開出來，會交給另一家的 AI 模型自動審查，審查意見逐條修完或寫明不修的理由才合併。這跟 Cloudflare 讓「發現」和「驗證」用不同模型的思路一樣，實際跑下來，最常被抓到的正是寫的人自己覺得沒問題的地方。

怎麼安裝與開始用：一行指令、三種規模

先講結論：用 Skills CLI 一行指令裝好，打開 AI 寫程式工具、進到要稽核的專案，說一句「security audit this codebase」就會啟動。下面是官方 README 給的安裝指令：

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

# 想裝在使用者層級、所有專案都能用
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global

裝好之後，Skill 會依你的說法自動判斷要走哪一種模式：

完整稽核模式下還能選規模，官方叫 profile：

費用方面，官方沒有公布跑一次要多少錢，因為完全看你接的模型和專案大小。Skill 提供的控制方式是設定「最多呼叫幾次 AI 助手」當預算，預算不夠時它會先保留驗證和評論的額度，寧可少找幾區也不讓沒驗證過的結果混進報告。這個設計很值得學：省錢可以，但不能省掉驗證。

Cloudflare 內部大規模版本的經驗也可以當參考：一個約 3 萬行程式碼的程式庫，一次完整掃描要 3 到 4 小時，最久的一次跑了超過 14 小時，所以他們把大規模掃描當成定期清查，每次 PR 的檢查交給更輕量的工具。小團隊照抄這個節奏就對了。

沙盒前提：沒有隔離環境，它就只讀程式碼不執行

一句話：讀程式碼不需要沙盒，但要讓 AI 實際編譯、執行被稽核的程式來證明漏洞，就一定要有作業系統層級的隔離環境，沒有的話它會把該條標成 needs_validation，不會硬跑。

官方 README 對沙盒的要求寫得很具體，整理如下：

這份 Skill 也規定不准安裝新套件、不准讓編譯過程自己下載依賴、不准測試正式環境或別人的服務、不准花付費 API 額度。原因很簡單：資安稽核本身就是在「請一個會攻擊的 AI 進門」，門禁不夠嚴，稽核工具本身就會變成風險。我們之前整理過 Claude Mythos 沙盒逃脫事件，強模型在權限沒鎖好的環境裡會做出設計者沒預料的事，那篇可以當這一節的延伸閱讀。

對多數中小企業的開發團隊來說，最務實的做法是先只用「讀程式碼」的部分，不急著架沙盒。光是讀，它就能抓出權限檢查漏掉、使用者輸入直接拼進 SQL、金鑰寫死在前端這類常見問題。真的需要執行驗證的那幾條，再交給工程師在測試環境手動確認。AI 寫程式工具本身的權限也要先管好，可以參考我們寫過的 Claude Code .env 保護四道防線和 AI 寫 Code 的安全指南。

它做不到什麼：跟弱點掃描、滲透測試、AI Code Review 的差別

先講結論：它是讀原始碼找邏輯漏洞的工具，看不到正式環境怎麼設定、看不到網路架構，也不會幫你打真的網站，所以不能取代弱點掃描和滲透測試。下表把幾種常被混在一起的資安檢查放在一起比較：

這幾種工具比較像拼圖，各補一塊。弱點掃描和滲透測試的差別，我們在弱點掃描、滲透測試、壓力測試差在哪有完整說明，選掃描工具可以看九套弱點掃描工具對照。AI 驅動的攻擊型工具，可以對照我們寫過的 PentAGI 和 reverse-skill；每次 PR 的 AI 審查工具，則在 AI Code Review 工具選型指南比較過。

另外兩個限制也要知道。第一，它只看單一程式庫。Cloudflare 原文提到，很多漏洞出在元件和元件的接口上，他們內部系統另外花了大功夫追蹤跨程式庫的依賴，公開版沒有這一塊。第二，它不會幫你修。內部系統的修補器產生修補後，也一定要人工審過才能合併，Cloudflare 把這列為不能妥協的一道關卡。

有一個反直覺的發現也值得一提：Cloudflare 曾經把靜態分析工具 Semgrep 整個接進系統，結果一個月內獵人呼叫它的次數是零，AI 寧願自己讀程式、跑程式。反而是讓 AI 寫下「我需要什麼工具」的願望清單功能，成了整個系統最常被用的工具，累計被寫入 25,472 次。設計 AI 流程時，觀察它實際會去拿什麼，比預設它需要什麼更準。

中小企業要不要用？三種情況的判斷方式

我們的判斷是：有自己的工程師、有 Claude Code 或 Codex 訂閱的團隊，值得現在就拿一個不敏感的專案試跑；沒有工程師的公司，這份 Skill 本身用處不大，但它的設計思路值得拿來檢驗你的外包廠商。

最常見的誤區是把它當成「資安做完了」的證明。前面提過，單跑一次只抓到大約一半，而且看不到正式環境。比較健康的用法是把它當成定期健康檢查：每次大改版跑一次，把 needs_validation 那份清單交給工程師逐條確認，累積幾次之後，覆蓋清單會告訴你哪些區域真的被看過。

給沒有工程背景的老闆一個簡單的判斷工具：下次外包廠商說「我們有用 AI 做資安檢查」，追問一句「找到漏洞的 AI 跟驗證漏洞的是不是同一個？報告裡有沒有分清楚已確認和待確認？」答得出來的廠商，流程通常比較扎實。關於外包程式碼的驗收方式，也可以看我們寫的 PR 與 Code Review 是什麼。

如果你手上的系統是用 AI 或外包快速做出來的，現在正準備上線收客戶資料，心裡沒底，我們很樂意先聽你聊聊這套系統的狀況。恆遠的 Vibe Coding 健檢會檢查金鑰外洩、登入與權限繞過、資料權限這些最容易出事的地方，報告用商業語言寫，標清楚哪些上線前一定要修、哪些可以之後再說。

AI 讓找漏洞變便宜了，但判斷哪些是真的、該先修哪個，仍然要有人負責。想在系統上線前做一次完整體檢，歡迎找我們聊聊；想從頭規劃一套資安設計做好的系統，可以看看我們的客製化系統開發。延伸閱讀：Project Glasswing 對中小企業 AI 資安採購的影響、Prompt Injection 防禦框架，以及 Codex 和 Claude Code 怎麼選。