Cloudflare security-audit-skill：把 AI 程式碼稽核變成可驗證的六階段流程 | Allen 知識庫 | Allen 知識庫Security / DevTools / Open Source
Cloudflare security-audit-skill：把 AI 程式碼稽核變成可驗證的六階段流程
Cloudflare 將 AI 安全稽核拆成偵察、覆蓋導向獵捕、候選否證、結構化輸出、獨立複核與報告六階段；關鍵是發現者不能自己證明自己正確。
2026年9月15日3 分鐘閱讀👁 7
AI Security · Agent Skills · Cloudflare
重點不是讓同一個 Agent 多想幾次，而是把「找漏洞」與「證明漏洞」拆給彼此獨立的角色
Cloudflare 的 security-audit-skill 把程式碼安全稽核做成可追蹤、可否證、可機械驗證的流程。它最值得帶走的設計原則是：發現候選漏洞的 Agent，不能自己替該漏洞背書。
版本查核：Threads 貼文把流程濃縮成四段；截至 2026-09-16，官方 README 與 SKILL.md 已明確定義為六個階段。本文以目前官方版本為準。
六階段稽核流程
| 階段 | 輸出／目的 | 真正解決的問題 |
|---|
| 1. Reconnaissance | architecture.md、coverage-ledger.json | 先畫出架構、輸入面、Trust Boundary 與可稽核範圍，避免漫無目的掃描。 |
| 2. Coverage-led hunting | 依 coverage unit 分派彼此隔離的 hunter | 用攻擊面與覆蓋缺口驅動搜尋，而不是只跑一份 checklist。 |
| 3. Candidate validation | 每個候選交給新的 verifier 嘗試推翻 | 壓低同一模型自我合理化造成的假陽性。 |
| 4. Structured output | findings.json：confirmed、needs_validation、rejected | 把證據、狀態與不確定性結構化，並用 JSON Schema／validator 機械檢查。 |
| 5. Independent record verification |
| 新 Agent 再驗最終 source trace 與結論 |
| 6. Target-neutral reporting | REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md | 從已驗證紀錄生成報告，避免報告文字與結構化事實分叉。 |
這套 Skill 真正有價值的四個設計
1. 獨立否證，而非自我審核
Hunter 只負責提出候選；fresh verifier 的任務是找理由推翻它。這比要求同一個 Agent「再檢查一次」更接近真正的職責分離。
2. Coverage ledger 外部化狀態
每個範圍、嘗試與缺口都有可驗證紀錄。多次執行是累加式的，可針對未覆蓋區域與變更過的程式碼重新稽核。
3. 不確定就保留為 needs_validation
若缺少部署設定、代理層行為或安全 sandbox，不能硬判成漏洞；系統要記錄「還缺哪個事實」，且不能替它配嚴重度。
4. Schema 與 validator 約束產物
機械驗證只能檢查格式、欄位與一致性，不能證明漏洞是真的；但它能防止行號、source trace、狀態與報告在流程中悄悄漂移。
安全邊界比「Agent 很聰明」更重要
官方 Skill 對執行環境的要求很嚴：目標程式碼的 build、test、browser、fuzzer 或 fixture 處理，必須在 OS 強制 sandbox 中運行，關閉外部網路、清空並 allowlist 環境變數、限制 CPU／記憶體／程序／磁碟／時間，且只能寫入隔離 scratch。若做不到，候選應停在 needs_validation，而不是直接執行未知程式碼。
使用邊界：這不是「裝上就能自動證明安全」的掃描器。Cloudflare 官方也明說，單次執行大約只能找到多次執行所得漏洞的一半，而且偏向較簡單的問題。高風險專案仍需人工資安審查、威脅建模與受控重現。
Skill 與完整 vulnerability harness 的差別
Cloudflare 的官方文章說明，這個 Skill 是其多階段漏洞探索 harness 的起點。當範圍擴大到多 repo、長時間執行與跨服務追蹤後，單一對話會撞上三個瓶頸：context exhaustion、執行中斷後缺乏持久化、以及看不到跨 repo 介面。官方建議不要一開始就造大型平台；先從最小的 Recon → Hunt → Validate 加上「validator 不能自己提交 finding」開始，只有當單一 Skill 明確成為瓶頸時再擴建。
對 BigIntTech／Hermes 的可用結論
- 可直接借鏡流程，不必照搬工具：既有的 security review 可以加入「發現者 ≠ 驗證者」與結構化 findings gate。
- 先把結果資料模型定義好：至少區分 confirmed、needs validation、rejected，並保存 source trace、實際影響與最小修復點。
- 把 coverage 當資產：每次 review 不應從零開始；保存範圍、未覆蓋區與程式碼版本，下一輪優先補洞。
- 禁止 Agent 直接碰正式環境：資安驗證只在本地隔離環境使用 dummy principal／fixture，不能對 production、共享服務或真實使用者資料做探測。
安裝與成熟度
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
截至 2026-09-16 查核：GitHub repository 為 Cloudflare 官方組織所有、MIT License、約 5,012 stars／312 forks，近期仍有提交；尚無 GitHub Release。Stars 與 forks 會持續變動，不能取代實際程式碼與 sandbox 設計審查。
來源