AI

security-audit-skill：Cloudflare 開源的 AI 程式碼安全稽核 Skill，用「互相質疑」的 Agent 壓低誤報

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

請 AI 幫忙找程式碼裡的安全漏洞，最常見的結果是兩種極端：要嘛一份落落長的清單，裡面八成是誤報；要嘛幾句籠統的「建議加強輸入驗證」。security-audit-skill（cloudflare/security-audit-skill）走的是另一條路：讓多個彼此隔離的 Agent 分工、互相質疑，只有經得起反證的發現才會被標記為「確認」。這個 repo 只有 14 個 commit，卻在短時間內累積約 50.3k stars，10 月 26 日的 AI 開源趨勢報告中單日新增 2,878 顆星。它也是昨天介紹 OpenShell 時，趨勢報告中與之並列的「Agent 安全」代表專案。

1. 專案背景與定位

這個 Skill 由 Cloudflare 以 MIT 授權開源，官方描述是「一個用於多階段安全稽核、產出經獨立驗證且機器可讀發現的 Coding Agent Skill」。README 說明，它正是 Cloudflare 內部漏洞挖掘系統的「種子」——後來的系統就是從這個單一 repo 演化而來，並附上一篇〈Build your own vulnerability harness〉的部落格文章。

它的設計目標是防禦性的程式碼稽核：協助開發與資安團隊在自己的程式碼中找到問題，而不是對外部目標進行攻擊。只要模型支援工具呼叫與平行 sub-agent，任何 Coding Agent 都能使用。

2. 技術架構與核心設計

六階段工作流程：

  1. 偵察（Reconnaissance）：描繪架構、信任邊界、輸入面與既有證據，記錄在 architecture.md 與 coverage-ledger.json。
  2. 依覆蓋清單獵捕（Coverage-led hunting）：把清單中的單元分派給彼此隔離的 hunter Agent，記錄每個人檢查了什麼，再由 coverage critic 找出遺漏。
  3. 候選驗證（Candidate validation）：每個候選問題都交給一個全新的 verifier Agent 嘗試推翻它。
  4. 結構化輸出：結果寫入 findings.json，分為 confirmed、needs_validation、rejected 三類，並以 report-schema.json 檢查格式。
  5. 獨立紀錄驗證：再由新的 Agent 驗證最終的原始碼證據；若有重大修改，還要再經另一個獨立驗證者。
  6. 報告：產出 REPORT.md、FINDINGS-DETAIL.md 與 NEEDS-VALIDATION.md。

幾個值得注意的設計原則：

  • 找到的人不能自己驗證：發現問題的 Agent 永遠不是驗證它的 Agent。
  • 嚴格的確認標準：只有完整的原始碼追蹤與明確的觀察結果才算 confirmed；有根據但無法驗證的線索保持 needs_validation，而且不給嚴重度。
  • 嚴重度 = 可能性 × 影響：不是「違反了某條清單」就算嚴重。
  • 縱深防禦的缺口不等於漏洞：如果另一層防護已經擋住攻擊，缺少的那一層只記為強化建議。
  • 增量執行：多次執行會累加，重用之前的覆蓋清單與發現，並重新檢查變動過的原始碼。
  • 攻擊類別知識庫：涵蓋記憶體安全、AI 與 LLM、Web 協定與認證、前端、供應鏈與發佈、雲端部署、RPC 與訊息、資源耗盡、資料隔離、桌面與行動 IPC 等主題。

3. 社群熱度與生態採用

約 50.3k stars、3.2k forks，但只有 14 個 commit——價值集中在方法論與 prompt 設計，而非程式碼量。安裝方式為 npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit，驗證器需要 Node.js。官方分享了一個實測觀察：單次執行大約只能找到多次執行總數的一半漏洞，因此建議重複執行。

4. 局限性與潛在風險

  • 必須有真正的沙盒才能執行目標程式碼：若要建置、測試或執行受稽核的程式碼，Skill 要求作業系統層級的沙盒——封鎖對外網路、使用乾淨的環境變數、限制資源、只允許寫入指定的暫存路徑。沒有沙盒時，線索只會停在 needs_validation，不會執行目標程式碼。這點和昨天的 OpenShell 正好互補。
  • 輸出位置：完整稽核模式預設輸出到 ~/security-audit-skill/<repo>/run-<N>，只有在使用者明確指定被版本控制忽略的目錄時才會寫入目標 repo——避免稽核結果不小心被 commit 出去。稽核報告本身是敏感資料，應妥善保管。
  • 單次執行涵蓋不完整：官方數據顯示一次只找到約一半，不能把一次乾淨的報告當成「沒有漏洞」的證明。
  • 成本：多個 Agent 平行獵捕與反覆驗證，token 消耗相當可觀。
  • 只用在你有權稽核的程式碼：這是給開發者與資安團隊稽核自己系統的工具；對他人系統進行測試必須取得明確授權。
  • 不取代專業審查：AI 稽核可以大幅提升覆蓋率，但高風險系統仍需要人工安全審查與滲透測試。

5. 應用價值與適用場景

最適合在發佈前或重大改版時對自己的程式碼做一輪系統性的安全檢查：新創團隊沒有專職資安人員時，可以用它作為第一道防線；資安團隊則可以用它擴大覆蓋範圍，把人力集中在 needs_validation 與高嚴重度的項目上。結構化的 findings.json 也方便接進 issue 追蹤或 CI 流程。

Monday 的觀點與架構建議

  • 這個 Skill 最值得借鏡的是「對抗式驗證」：找問題的和驗證問題的永遠是不同的 Agent，而且驗證者的任務是「推翻」而不是「確認」。這個模式可以套用在任何需要高可信度輸出的 Agent 工作——程式碼審查、事實查核、法規比對都適用。
  • 「覆蓋清單」的設計把稽核從「找到幾個問題」變成「哪些地方檢查過了」，這才是安全稽核真正需要回答的問題。
  • 建議的使用方式：搭配 OpenShell 這類沙盒執行目標程式碼、每次重大變更後增量重跑、把 confirmed 項目轉成 issue 並追蹤修補，needs_validation 則交給人工判斷。
  • 回顧這個月，從 OpenCodeReview、iFixAi 到今天的 security-audit-skill，可以看到一個共同方向：讓 AI 的輸出可驗證、可稽核。在 AI 產出的程式碼越來越多的時代，AI 協助的安全審查也會成為開發流程的標準環節。

參考來源