AI 找漏洞不難，難的是證明它真的存在

讓 AI 掃一份程式碼，列出幾十個「可能有問題」的地方，已經不稀奇。

真正困難的是下一步：哪一個真的能被利用？哪一個只是少了一層防禦，但攻擊其實仍被前一層擋住？哪一個需要補證據，而不是先貼上高風險標籤？

Cloudflare 公開的 security-audit-skill，把這個問題拆成六個階段。它最值得注意的規則不是模型多強，而是：找到問題的 agent，不能自己替同一個問題背書。

先找，再由另一個角色反駁

流程先做架構偵察，盤點信任邊界、輸入面與既有證據；接著依攻擊類別分派獨立 hunters，尋找候選問題。

候選出現後，不會直接進入報告。新的 verifier 會嘗試反證：攻擊路徑真的存在嗎？受影響程式碼找對了嗎？既有防護是否已經阻止攻擊？證據能不能指回明確的 source？

這個分工很重要。因為提出假設的人，最容易繼續尋找支持自己假設的證據。讓另一個角色負責推翻它，才能降低「看起來合理」被誤當成「已經證實」的機率。

不是只有通過或失敗

工具把結果分成三種：

• confirmed：有完整 source trace，也有界定清楚的觀察結果。
• needs_validation：線索有根據，但仍缺一個必須被解開的事實，不能先給嚴重度。
• rejected：候選已被反證。

這比把所有警告塞進同一份報告更實用。安全團隊真正需要的不是更多紅色驚嘆號，而是知道哪些能立刻處理、哪些還欠證據、哪些應該停止浪費時間。

執行程式，比閱讀程式危險得多

AI 安全審計常需要跑測試、啟動服務、操作瀏覽器或建立 fixture。但 target code 本身就是不可信輸入。

官方要求用作業系統層級的沙箱隔離這些動作：關閉外部網路、清理環境變數、限制資源，並只允許寫入指定 scratch path。缺少這些控制時，線索應保留在 needs_validation，不能為了得到漂亮結論就直接執行。

這條界線也說明了為什麼「把 repository 丟給 AI 跑一遍」不是完整安全流程。審計工具本身同樣需要權限邊界。

一次掃描，不代表已經看完

Cloudflare 公開表示，在其測試中，單次執行大約只能找到多次執行累積漏洞的一半。不同 run 會看到不同路徑，因此既有 coverage ledger 與 findings 需要被保留，讓後續執行補缺口，而不是每次從頭開始。

在更大型的內部 harness 中，Cloudflare 曾記錄 20,799 個原始候選，經過驗證、去重與風險判斷後，留下 7,245 個可交付工程團隊的 findings。這些數字只描述 Cloudflare 自己的系統與時點，不能當成任何專案都會得到相同比例。

但它揭露了一件事：AI 產生候選很便宜，可信的過濾漏斗才是主要工程。

一個明示的虛構例子

假設掃描 agent 認為某個登入 API 可以繞過權限。

獨立 verifier 不應只改寫同一段推論，而要重新確認信任邊界、找到精確程式路徑，並嘗試建立可重現證據。如果環境缺少安全沙箱，無法執行 target code，就應把未解事實寫清楚，維持 needs_validation。

這是虛構教學情境，不代表任何實際系統存在漏洞。

自動修補，仍不能自己上線

候選通過後，自動 Fixer 可以建立 patch 並跑聚焦測試。理想狀態是修補前測試失敗、修補後通過；如果 post-patch test 失敗，就阻擋 commit。

即使如此，官方流程仍要求人員審查 branch，不讓 Fixer 自行合併。因為修掉一個漏洞，同時破壞其他功能，並不是成功的修補。

小團隊真正該抄的三件事

小團隊不需要一開始就複製數百個 agents 或跨 repository tracing。可以先建立三條簡單規則：

1. 發現者與驗證者分開，驗證者的工作是反證。
2. confirmed、needs_validation、rejected 分開記，不把未知包裝成確定。
3. 執行 target code 必須進沙箱；修補必須有測試與人工審查。

AI 可以把安全線索產生得非常快。但在安全工作裡，速度不是最終價值。真正值得信任的系統，必須知道何時可以下結論，也知道何時應該停在「還缺證據」。