AI 稽核不能直接對著正式站跑：security-audit-skill 把目標程式關進無網路沙箱、原始碼只准唯讀，缺沙箱就寫進 needs-validation
目錄
共 10 個章節
先分清它在做什麼：六個階段、三種結論，還有一條「不准直接跑正式站」的規矩
很多人以為「AI 幫忙做資安稽核」是自動掃描、自動列出漏洞的工具。Cloudflare 開源的 security-audit-skill 不是掃描器，而是一份寫給 AI 代理（agent，能自己開子任務、自己跑指令的助手）的作業手冊，外加 2 支檢查輸出格式的 Node.js 腳本。掃描器只找可疑處，這份手冊連「怎麼證明它真的是漏洞」都規定好了，因為團隊的困擾往往不是漏看，而是被誤報淹沒。
整份流程拆成 6 個階段：
- 偵察：畫出系統架構、信任邊界（外部輸入進來的地方）與輸入介面，留下架構文件與覆蓋清單。
- 覆蓋式搜尋：把清單切成獨立單位，派不同代理分頭查，再回頭補漏。
- 候選驗證：每筆可疑問題交給全新的驗證代理，任務是想辦法推翻它。
- 結構化輸出：分成 3 類寫成檔案，再用腳本檢查格式。
- 獨立紀錄驗證：由沒參與過的新代理重驗每一筆結論。
- 目標中性報告：從通過驗證的紀錄產生人看得懂的報告。
三種結論，決定這筆該不該信
confirmed 代表有完整來源追溯、也實際觀察到結果，才算確認的漏洞；needs_validation 代表有一個明確但還沒解開的事實，流程刻意不給嚴重度；rejected 是被推翻的候選。紀律是「誰找到的，就不能由誰來認定」。若某一層防禦已擋住攻擊，另一層沒做到只算加固建議，不能當漏洞上報。
還有一條規矩，是台灣企業最該留意的：手冊明文禁止把被稽核的程式放在正式環境裡跑。原始碼檢視要唯讀；真要執行建置或測試，只能在作業系統層強制的沙箱裡，且對外斷網、空環境啟動、目標唯讀、資源上限這 4 件事必須同時成立。做不到就不能跑，只能把「缺沙箱」寫成一筆待驗證的阻礙。
| 結論 | 代表什麼 | 能不能當漏洞上報 |
|---|---|---|
| confirmed | 有完整來源追溯，也實際觀察到結果 | 可以，這是確認過的漏洞 |
| needs_validation | 有明確但還沒解開的事實 | 不行，流程刻意不給嚴重度 |
| rejected | 被驗證代理推翻的候選 | 不行，只能留紀錄 |
核心限制：原始碼只准唯讀，目標程式只能進作業系統層沙箱
「唯讀」是指稽核 agent 可以翻程式碼、畫架構圖、抄筆記，但一個字都不能改，否則證據無法回溯，也分不清某個問題是原本就有、還是它自己改出來的。檢視階段純讀取；建置、測試、開瀏覽器、跑模擬器或模糊測試都算執行動作，必須進沙箱。
沙箱不能靠一句「請小心」。手冊要求作業系統層強制隔離，讓作業系統把網路與路徑擋死，因為提示詞會被誤解，隔離牆不會。依 Cloudflare 開源的技能包（skill）手冊，以下四項必須同時成立，缺一項就不能執行目標程式碼：
- 對外網路完全關閉，真有本機連線需求時，只能走隔離的 loopback。
- 空環境啟動，環境變數只從明確允許清單填入，HOME、暫存與快取都指向
scratch/。 - 目標程式與工具鏈維持唯讀，被測程序只能寫自己那一個
scratch/。 - 限制 CPU、記憶體、程序數、檔案大小、磁碟與執行時間，避免一個迴圈拖垮整台機器。
寫入隔離同樣徹底：每個搜尋或驗證代理拿到獨立目錄，只能寫自己那份 scratch/；要保留的成品放 artifacts/，由父代理逐檔驗證後才搬進去，過程檢查路徑、拒絕符號連結、確認型別與大小並避免競態。某一層破了洞，污染也只留在一個用完就丟的目錄裡。
手冊也明文禁止對正式站點或共用服務探測、對共用或正式程序做可用性測試、發佈產出物、改動發佈流程、花付費 API 額度；稽核不得製造任何副作用。
環境不夠怎麼辦？不是硬幹，而是把缺沙箱能力寫成一筆 needs-validation 的阻礙，附上安全驗證計畫交回人類決定。這套流程在台灣中小企業落地時，第一步往往不是買工具，而是先挪出一台能斷網、能重來的機器。
實戰操作：缺沙箱就寫進 needs-validation，不是硬著頭皮跑
實作最常卡住的不是技術，是心態。手冊講得明確：環境做不到隔離，就不要執行目標程式碼，並把「做不到」變成一筆正式紀錄，留給人判斷。
把「做不到」寫成一筆可追蹤的阻礙
寫法是在結論裡留下一筆 needs-validation，內容必須是明確未解的事實，例如「尚未在隔離環境重現這個輸入造成的資源耗盡」，不能只寫「無法驗證」。同時附上安全驗證計畫：需要什麼等級的機器、斷掉哪些對外連線、限制多少 CPU 與記憶體、由誰在何時執行。這筆紀錄會進到 NEEDS-VALIDATION.md，人類接手時看到的是一份待辦清單，而不是免責聲明。
動態測試同理。原始碼檢視是唯讀的，但只要牽涉建置、跑測試、開瀏覽器或處理測試資料，就得在作業系統層強制的沙箱裡進行：空環境啟動，被測程序只能寫自己那個 scratch/。做不到就不執行，改成把阻礙寫清楚。
寫入隔離也是同一個邏輯。每個搜尋代理與驗證代理拿到獨立目錄，只能寫底下的 scratch/；要留下的證據放進 artifacts/，由父代理逐檔檢查路徑、拒絕符號連結、確認型別與大小後才搬進去。若所有代理共用一個工作目錄，一份被污染的輸出就可能冒充另一個代理的結論，整條驗證鏈等於白做。
會產生真實副作用的動作則被明文禁止：對正式站點或共用服務探測、對共用或正式程序做可用性測試、發佈產出物或改動發佈流程，以及花掉付費 API 額度。這些限制正是流程能被放進企業內部的理由，也把爭議往前移：與其出事後才吵「當初怎麼沒測」，不如在交付前留下一份寫清楚阻礙與驗證計畫的文件，讓補測與否變成有依據的決定。
替代方案有限公司觀點：台灣中小企業先從一個專案、一次交付前檢查開始
我們的觀察是，台灣多數中小企業一聽到「AI 資安稽核」，直覺就是全公司要動起來，於是卡在預算與人力，什麼都沒開始。務實的起點其實很小：挑一個快要交付的專案先跑一輪，再由人來看那份 confirmed 清單。
三個可以立刻做的場景
第一個場景是外包驗收。過去驗收會議常淪為「對方說測過了」，現在可以把清單當附件，逐條問「這一項怎麼處理」，於是討論有了共同語言，也比較不容易被含糊帶過。
第二個場景是老系統交接，因為不少公司的主力系統根本沒有規格書，工程師一離職就成了黑箱。先讓它產出架構說明與覆蓋清單，交接時至少知道邊界在哪，而不是靠口耳相傳。
第三個場景是上線前檢查。把「測試資料或金鑰有沒有被帶進版控」這種大家都以為別人會記得的事，交給清單逐項確認，因為清單不會疲勞。
不過有三種期待一定落空。它不能取代滲透測試，不能假設零人力，更不能在正式環境直接跑。Cloudflare 在開源專案裡寫明，單次執行大約只找到重複執行總量的一半（2026），所以跑完一次就宣稱安全，是最危險的誤解。
我們認為，這套做法的價值是把「把關」從記憶變成紀錄，而不是取代任何人。台灣企業的資安預算多半落在有事件才處理，平時要留下一份可追溯的清單，成本其實接近零，前提是公司裡真的有人願意看報告。因此我們的落地建議很簡單：先挑一個專案試跑，把 confirmed 逐條轉成待辦與負責人，並在驗收文件註明「本清單僅供參考，不構成保證」。另一方面，缺點也得誠實說，needs_validation 往往比 confirmed 還多，代表後續仍要補人力去查；如果連一個讀得懂報告的人都沒有，先別急著導入。
深入探討：代理呼叫預算、三種執行檔次，以及「單次只抓到約一半」的官方提醒
上一章提到，跑完一次就宣稱安全是最危險的誤解。這套技能的解法是預算設計：不用掃描時間或程式碼行數計價，而是用「代理呼叫次數」計算。所謂代理呼叫，指的是 agent 每開一個子代理去查一段程式碼、驗一個疑點，就算一次；呼叫越多，耗掉的上下文與時間越多，也越容易在不同單元之間失去一致性。
換算方式官方寫得清楚：一個覆蓋單位大約等於一次搜尋代理呼叫，一個候選漏洞則約需一到兩次驗證代理呼叫。關鍵在於順序：先保留評論者與驗證的額度，再派搜尋代理出去找；額度不夠就不派，並把該次執行標記為 incomplete（未完成）。報告裡也不准出現「已完整覆蓋」這種字眼。
三種執行檔次怎麼挑
技能內建三種檔次：quick 適合小型目標、重跑或交付前先看一眼；standard 是預設值，多數專案從這一檔開始；deep 留給高風險系統或大型專案，願意多付呼叫次數換覆蓋率。檔次不等於認真程度，只是預算規模：小型專案硬跑 deep，多半只是把同一批地方重複看很多遍。
至於「跑一次夠不夠」，官方 repo 的〈Design principles〉寫得很直白：「在我們的測試裡，單次執行大約只找到重複執行總量的一半漏洞。」這是 Cloudflare 自己 2026 年的測試，不是全行業統計，也不該解讀成效能提升的百分比。它真正的意思是，第一次跑完你手上大概只有一半的東西，所以報告得交代這是第幾輪、有沒有前次清單可比對。實務上該把它當第一輪篩選，再安排第二輪或人工補查，而不是簽核一次就結案。
| 檔次 | 適用情境 | 呼叫次數 |
|---|---|---|
| quick | 小型目標、重跑、交付前先看一眼 | 最少 |
| standard | 預設值，多數專案從這一檔開始 | 中等 |
| deep | 高風險系統或大型專案 | 最多 |
常見問題 FAQ
Q：這跟我平常聽到的漏洞掃描器有什麼不一樣？
它不是掃描器，而是一份給 AI 代理照著跑的作業手冊，加上兩支零依賴、只檢查輸出格式的 Node.js 腳本。裝好之後，你在自己的專案裡叫 agent 做資安稽核，它會照六個階段走：先畫出系統架構與覆蓋清單，派獨立的搜尋代理去查，每個候選漏洞再交給「沒參與搜尋的驗證代理」想辦法推翻，推不翻才留下。結論只分 confirmed、needs_validation、rejected 三類。跟一般工具最大的差別是「找到的人不能自己確認」，而且官方自己說，單次執行大約只找到重複執行總量的一半，要多跑幾次才接近完整。
Q：可以叫它直接對著正式站跑嗎？
不行，技能本身就明文禁止。它規定不得對正式站點或共用服務探測，也不能對共用或正式程序做可用性測試。原始碼檢視是唯讀的；要跑目標端的建置、測試、程序或模糊測試，只能在「作業系統層強制」的沙箱裡，而且要同時做到沒有對外網路、空環境啟動、目標與工具鏈唯讀、限制 CPU 與記憶體等資源。做不到這些控制就不能執行，必須把「缺沙箱能力」寫成 needs_validation 的阻礙，另外給一份安全驗證計畫。
Q：跑起來會不會改到我的程式碼，或把東西傳出去？
技能對寫入的隔離訂得很硬：每個搜尋代理或驗證代理都拿到獨立目錄，只能寫自己那一個 scratch/，要留下的 artifacts/ 由父代理逐檔驗證後才搬進去，驗證時會檢查路徑、拒絕符號連結、檢查檔案型別與大小、避免競態。沙箱同時要求沒有對外網路，需要本機連線時只能用隔離的 loopback。它另外明文禁止發佈產出物、改動發佈流程，也不准花付費 API 額度。換句話說，被稽核的程式碼是唯讀的，產出物要留下來得先過一關。
📩 有任何問題或需要協助，歡迎聯絡我們：[email protected]
Related
