外包驗收、老系統交接、上線前檢查：台灣中小企業怎麼用 security-audit-skill 留下資安把關紀錄，而不是等出事才處理

「等出事再說」的代價：外包驗收、老系統交接、上線前檢查，台灣中小企業卡在哪裡

台灣多數中小企業的資安心力都放在事件之後：客戶打來問、新聞報出來才找人來看。真正卡住的往往不是預算，而是平常沒人把「檢查了什麼」留下來。以下三個場景，你大概至少遇過一個。

最常見的是外包驗收。驗收單上寫「功能正常」就付款結案，可是功能正常跟「測試金鑰沒有被帶進版控」是兩件事。系統能跑，卻沒有人問過它對外開了哪些入口，等到出事才發現，連當初檢查了哪些範圍都拿不出紀錄。

再來是老系統交接。資深工程師離職，兩小時的交接會議講的多半是「這支程式不能動」，新團隊接手一個能跑、卻沒有人畫得出架構圖的系統，每次改動都像摸黑前進，因為系統的邊界從來沒有被寫下來過。

還有一種最容易被跳過，就是上線前的檢查。這件事平常靠某一個人記得：記得確認金鑰沒進版控、記得測試資料沒留在正式資料庫。只要他請假或離職，關卡就自動消失，把關品質取決於一個人的記憶力，而不是流程。

三個場景的共同點，是把關靠人記，不靠紀錄。Cloudflare 開源的 security-audit-skill（給 coding agent 的稽核作業手冊）正是針對這個缺口：稽核前先產出架構文件與覆蓋清單，把查過哪裡、漏了哪裡變成一份能打開來看的檔案；每個候選漏洞都交給沒參與搜尋的代理設法推翻，推不翻才留下，結論分成 confirmed、needs_validation、rejected 三類，不確定就標不確定。

對台灣企業而言，這類做法的價值不在工具本身，而在把「誰在什麼時候檢查了什麼」變成一份留下來的文件。要判斷它適不適合你，得先弄清楚它到底在做什麼，以及它刻意不做什麼。

security-audit-skill 不是掃描器：它是一份會自我推翻的稽核作業手冊

security-audit-skill 是 Cloudflare 開源的專案，2026 年 10 月底查詢時有五萬四千多顆星。內容是一份給 AI 代理（coding agent）照著跑的作業手冊，加上兩支零依賴的 Node.js 腳本，腳本只檢查輸出格式對不對；也就是說，它管的是「怎麼查」，不是「幫你查」。裝好後在專案裡對代理說一句「security audit this codebase」就會觸發，照手冊跑完六個階段。

六個階段：從畫地圖到寫報告

階段	做什麼	留下什麼檔案
1 偵察	畫出系統架構、信任邊界與輸入介面	architecture.md、coverage-ledger.json
2 覆蓋式搜尋	把清單切成單位，派搜尋代理逐一去查，再由覆蓋評論者補漏	各單位的檢查紀錄
3 候選驗證	每個疑似漏洞交給全新的驗證代理，任務是想辦法推翻它	驗證結論
4 結構化輸出	分成 confirmed、needs_validation、rejected 三類，並檢查欄位	findings.json
5 獨立紀錄驗證	另一個沒參與過的代理重驗每一筆結論	重驗後的紀錄
6 目標中性報告	從通過驗證的紀錄，產生人看得懂的報告	REPORT.md 等三份文件

第三與第五階段是整套設計的靈魂。搜尋代理的任務是「找出可疑的地方」，容易相信自己找到的東西；所以手冊規定驗證要交給沒參與搜尋的另一個代理，交辦的說法是「請推翻它」，不是「請確認它」。推不翻的候選才留得下來，推得翻的就進 rejected，這道安排把 AI 最常見的毛病，也就是把似是而非的猜測講成漏洞，變成必須跨過的門檻。

還有一個官方自己講清楚的限制：Cloudflare 在專案說明裡寫，單次執行大約只找到重複執行總量的一半漏洞（README，2026 年）。所以報告會標明這次涵蓋到哪裡、哪些還沒驗完，不會宣稱跑過一次就沒事。把它當成一份會留下紀錄的檢查流程，比當成掃描器更貼近事實。

實際跑一輪：安裝、觸發、看輸出，還有跑之前必須先確認的沙箱條件

安裝只有一行指令，在終端機執行 npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit，技能檔就會進到 agent 讀取的目錄；想讓所有專案共用，末尾加上 --global。環境需要 Node.js，因為安裝器與兩支驗證腳本都是 Node 寫的。裝完不會多出掃描器圖示，它是一份文件，等 agent 讀到才動起來。

進到要稽核的專案資料夾，直接對 agent 說「security audit this codebase」，它就會照六階段流程跑。產出預設落在 ~/security-audit-skill/<repo-name>/run-<N>，第一次 run-1、第二次 run-2，不會蓋掉前一次，你可以把兩個資料夾並排比對，看第二次補到哪些第一次漏掉的地方。

兩支驗證腳本分別在什麼時機跑

覆蓋清單建好、以及之後每次更新清單時，要跑 validate-coverage-ledger.cjs，確認每個覆蓋單位該填的欄位沒有漏；第四階段產出 findings.json、第五階段獨立重驗每次替換紀錄後，則跑 validate-findings.cjs。兩支都是零依賴腳本，只驗格式與欄位，不判斷內容對不對，通過只代表資料結構完整，不代表漏洞找得準。

真正要小心的是動態執行。技能規定原始碼檢視是唯讀，若要讓 agent 跑建置、測試或模糊測試，就得放進作業系統層強制的沙箱，並同時滿足幾個條件：沒有對外網路，本機連線只能走隔離的 loopback；空環境啟動，HOME、暫存目錄、快取都指向 scratch；被測程序只能寫自己那個 scratch/ 目錄；CPU、記憶體、程序數與執行時間都要明確設限。

這些條件做不到，就不該執行目標程式碼，正確做法是把「缺沙箱能力」寫進待驗證項目，並附上一份安全驗證計畫。它同時明文禁止對正式站點或共用服務探測、發布產出物、花付費 API 額度。對台灣企業來說，務實的起手式是先做唯讀的原始碼檢視，真要動態驗證，再準備一台隔離容器。

替代方案有限公司觀點：把關的價值在留下證據，不在工具本身

我們在台灣輔導中小企業的經驗裡，最常看到的不是沒有工具，而是沒有紀錄：買了什麼都很難回答某一天到底發生什麼，事後只能靠記憶拼湊。Cloudflare 開源的 security-audit-skill 之所以值得推薦，不是因為它會掃描，而是它把架構圖、查過哪裡、哪些候選被推翻，全都寫成檔案留下來。它讓「平時就有紀錄」的成本降到接近零，前提卻很現實：組織裡要有人真的打開報告。

我們建議的起點：一個專案，一次交付前的自我檢查

所以我們不建議一開始就談全公司導入。對多數十人以下的團隊來說，先有一個具體專案、一次交付前的自我檢查就夠了，原因是這件事的成本幾乎都落在「有沒有人把報告讀完」，而不是工具或授權費用。第一次跑完，團隊通常會親眼看到過去只在口頭流傳的問題被具體列出來，這種落差比買一套掃描服務更能改變習慣。至於全面推廣，等這一步真的有人看完報告再說，否則只是製造更多沒人讀的檔案。

回到我們的立場：AI 幫忙寫的程式碼變多之後，誰來把關已經不是工具問題，而是流程問題。這套做法的價值，在於把證據固定下來，讓下一次交付、下一位接手的人有東西可以查。工具會換，模型會換，那份留下來的紀錄才是企業真正的資產。

三個場景實際怎麼用：外包驗收附件、交接說明書、上線前檢查清單

立場講完了，回到日常工作上。它在這三個環節真正幫得上忙，而且都需要有人讀得懂它產出的檔案，因為它跑的是一整套流程，不是按一個鈕就結束。

第一種用法是外包驗收。專案交付前，請外包商或自己在程式庫上跑一輪，把結果裡的 confirmed 清單附在驗收文件後面。這份清單的定義是有完整來源追溯、而且實際觀察到結果的問題，因此能直接當成討論依據。反過來說，如果對方只回一句「掃過了沒問題」，你就有理由請他補上這份紀錄。

另一種情況是老系統交接。多數公司沒有規格書，新人只能靠前任口述拼湊輪廓；這套流程的第一階段會先產出架構圖與覆蓋清單，把信任邊界與查過的範圍寫成檔案。換句話說，交接當下就算沒人記得細節，至少邊界畫得出來，後面接手的人也知道哪裡還沒查。

再來是上線前的自我檢查。「測試資料或金鑰有沒有被帶進版控」這類問題，平常靠人記得，趕上線就容易被跳過；改成交給覆蓋清單逐項確認，漏掉的地方會被記錄下來，而不是消失在某個人的記憶裡。相對地，它不會幫你決定能不能上線，那個判斷仍然是人做的。

三種期待會讓你失望

如果你期待它取代滲透測試，會失望，因為它看的是原始碼與紀錄，滲透測試驗的是實際能不能被打穿，兩件事不能互相替代。期待零人力也不現實，報告要有人讀、有人追，沒人看就等於沒做。至於想在正式環境直接跑，更是明確的紅線：技能本身要求動態驗證只能在作業系統層強制隔離的沙箱裡進行，沒有沙箱就只能做唯讀檢視。所以先挑一個具體專案試，會比全公司導入務實得多。

常見問題 FAQ

Q：這套東西是不是裝了就會自動幫我抓漏洞，像防毒軟體那樣？
不是。它不是掃描器，而是一份「資安稽核怎麼做」的作業手冊，加上兩支檢查輸出格式的腳本。裝好之後，你平常用的 coding agent 在被要求做資安稽核時，會照著手冊跑六個階段：先畫出系統架構與信任邊界，再派搜尋代理分頭去查，每個候選漏洞都交給「沒參與搜尋」的驗證代理想辦法推翻，推不翻才留下來，產出報告。也因為這樣，它不會幫你保證零漏洞，報告裡會寫清楚這次涵蓋到哪裡、哪些還待驗證，不讓你誤會成「跑過一次就沒事」。

Q：我們公司只有兩三個人，外包驗收或老系統交接時真的用得上嗎？
可以，但起點是一個具體專案、一次交付前的自我檢查，不是全公司導入。外包驗收前，請外包商或自己在 repo 上跑一輪，把 confirmed 清單當成驗收附件；老系統沒有規格書，就讓它先產出 architecture.md 與覆蓋清單，交接時至少知道邊界在哪；上線前則把「有沒有把測試資料或金鑰帶進版控」這類問題交給覆蓋清單，而不是靠人記得。它的價值在於把把關的證據留下來，前提是有人真的會看報告；若要拿它取代滲透測試、期待零人力，或想直接在正式環境跑，都不適合。

Q：讓 AI 去翻我們家的程式碼，資料會不會被帶出去？
技能本身有明文規定：原始碼檢視是唯讀的。要讓 AI 去跑目標端的建置、測試或模糊測試，必須先放進作業系統層強制的沙箱，把對外網路、可寫路徑、資源上限都設好，做不到就只能停在唯讀檢視，並把「缺沙箱能力」寫成待驗證項目。它同時禁止對正式站點或共用服務探測、對正式程序做可用性測試、發布產出物或改動發布流程。跑完的預設輸出放在本機的 ~/security-audit-skill/專案名稱/run-1 這類資料夾，不會寫回你的程式庫。

📩 有任何問題或需要協助，歡迎聯絡我們：[email protected]