AI-LECTURER 速報課｜2026-09-18｜約 30 分鐘

AI也會『自己講的故事自己信』：Cloudflare怎麼設計出不唬爛的資安稽核員

取材：Cloudflare/Security-Audit-Skill（Hacker News（AI 高人氣））
📍 真實場景
阿凱，一人包辦後端與維運的中小型電商工程師

老闆說下週要上線全新的會員系統，順口交代『資安你也順便看一下』

😖 卡住的地方：他不是資安背景，網路上找到的檢查清單落落長，卻不知道從哪裡開始查；自己一個人看程式碼常常漏東漏西，也擔心自己疑神疑鬼，把正常功能誤判成漏洞
💡 這篇文章要教他抄一份Cloudflare公開的『讓AI當稽核員』SOP：不是丟給AI亂猜，而是照著『偵查→地毯式搜捕→交叉驗證→定案→產報告』六步驟走，連『AI自己會不會唬爛』都內建了防呆機制

🧭 這到底是什麼（白話版）

Cloudflare把一份公開在GitHub上的技能包，叫做『讓AI當資安稽核員』。這裡的coding agent能自己讀程式、寫程式、下指令做事的AI程式，不只是聊天機器人，不是只回答你問題，而是可以真的去翻程式碼、記筆記、寫報告。這份技能包要它做的事，叫做資安稽核有系統地把一套軟體從頭到尾檢查一遍，找出可能被駭客利用的弱點——重點不是叫AI亂猜哪裡有洞，而是照著一套六個步驟的固定SOP走。

這套SOP第一件事，是先畫地圖，不是急著抓漏洞。AI要先弄清楚系統的架構、資料怎麼流進來流出去，特別是找出信任邊界系統裡「應該被信任的資料」跟「不應該被信任的資料」交界的地方，比如使用者輸入的欄位在哪裡，還有整個攻擊面駭客有機會下手、可以跟系統互動的所有入口，例如網址列、上傳按鈕、API有多大，把這些整理成一份清單，後面所有搜捕行動都照著這張清單走。

接下來最關鍵的設計，是『找』跟『驗』分開做。負責搜捕的AI找到可疑的地方後，不會自己說了算，而是交給另一個完全沒參與搜捕過程的AI去驗證，驗證員的任務是想辦法證明這其實是誤報（false positive）AI喊說『這裡有洞』，但其實根本沒有問題，白忙一場的警報，證明不了才算數。這樣設計是為了避免同一個AI自己講的故事自己信。

整套流程走完之後，還會回頭用覆蓋率已經確實檢查過的範圍佔全部應該檢查範圍的比例來確認有沒有漏查的角落，最後才產出一份人看得懂、語氣不偏袒任何一方的報告。這整套流程後來被Cloudflare拿去擴大成公司內部正式的漏洞獵殺系統，不只是一份寫好玩的Demo教學。

🎯 為什麼值得你花時間

資安人力永遠補不齊，漏洞卻越來越多全世界工程師增加的速度，遠追不上要檢查的程式碼行數，中小企業更常常是像阿凱一樣一人身兼資安。這套流程示範了怎麼用AI補上這個人力缺口，而不是繼續用『祈禱不要被駭』的方式上線。
AI抓漏洞最大的坑：自己講的故事自己信如果讓同一個AI找到問題又自己判定問題是真的，它很容易把模糊的線索腦補成真的漏洞。這套SOP刻意拆成『找』跟『驗』兩種角色，就是要堵住這個最容易翻車的地方。
從玩具Demo到正式產品的關鍵：這套流程真的被拿去正式用了這不是一份紙上談兵的教學文，Cloudflare後來把它擴大成公司內部跨整個服務艦隊的漏洞獵殺系統，證明讓AI做苦工式的系統性稽核是可以撐住正式產品規模的，不是只能拿來寫Demo。

⚙️ 它是怎麼運作的

1
① 偵查：先畫地圖，別急著抓漏洞AI會先弄清楚系統長什麼樣子——架構怎麼分層、資料從哪裡流進來、有哪些信任邊界系統裡「應該被信任的資料」跟「不應該被信任的資料」交界的地方，全部寫成一份架構筆記和一張待檢查清單，這張清單就是後面稽核的地圖。
▼
2
② 地毯式搜捕：派獨立小隊分頭查，還要有人檢查有沒有漏查依照清單上的每一個項目，各自派出互不知情的獵人AI去查，另外還有一個教練角色專門回頭檢查有沒有哪個角落大家都沒查到，避免大家都愛查同一種好抓的漏洞。
▼
3
③ 候選驗證：找到的每個嫌疑犯，都要換人來想辦法幫它翻案獵人回報這裡可能有洞後，不會自己說了算，而是交給一個完全沒看過搜查過程、只看證據的驗證員，驗證員的任務是想辦法證明這是假警報，證明不了才算數。
▼
4
④ 結構化輸出：三種結局，白紙黑字寫清楚每個候選人最後只有三種結局：已確認（confirmed）證據鏈完整、有明確可重現的觀察結果，可以定案的漏洞、待釐清（needs_validation）還缺一個關鍵事實沒查清楚，所以先不判斷嚴重度、已排除（rejected）被驗證員反證推翻的候選人，其實不是漏洞，全部寫進固定格式的檔案，還有程式自動檢查格式對不對。
▼
5
⑤ 二次查核：再換一批新面孔，回頭對答案對於最後定案的每一條說法，再找全新的一批AI回去對照原始程式碼重新核對一次，如果核對過程中有任何一條說法被改掉，還要再找一個獨立的人重新確認過。
▼
6
⑥ 產出報告：對事不對廠商，講人話最後把所有經過層層查證的紀錄，整理成一般人看得懂的報告，而且刻意設計成語氣不會因為委託方是誰而改變，該多嚴重就多嚴重，不會因為是自己家產品就放水。
傳統人工資安稽核 vs. 這套AI六階段稽核SOP的差異
比較項目傳統人工稽核AI六階段稽核SOP
覆蓋範圍看人力跟時間，常常挑重點查靠覆蓋清單強制雨露均沾，逐項打勾
誤報處理靠稽核員自己的經驗判斷強制換人二次驗證，才能定案
產出一致性不同稽核員風格落差大固定格式＋自動格式檢查，人人一致
規模化能力人力是天花板，加案子就要加人理論上可以複製到整個服務艦隊

🔍 程式碼漫遊（點有 ● 的行看白話講解）

這是這套技能包裡，記錄一個漏洞候選人最終定案結果的資料格式，你可以把它想像成偵探破案後要交的結案報告表格，每一格都有固定填法，不能隨便寫。

●{
💬 開始一筆候選人的結案紀錄。
● "id": "F-014",
💬 這個候選人的編號，方便跟報告互相對照，就像案件編號。
● "status": "confirmed",
💬 結局三選一：confirmed（已確認）、needs_validation（待釐清）、rejected（已排除），這裡代表被驗證員證實是真的。
● "component": "auth-middleware",
💬 問題出在系統的哪個模組，這裡是登入驗證的中間層。
● "evidence": ["commit:a1b2c3", "line:middleware.py:88"],
💬 證據鏈：具體是哪一次程式修改、哪一個檔案第幾行，讓人可以自己回去對照，不是空口說白話。
● "severity": "high",
💬 只有status是confirmed才會填嚴重度，needs_validation階段還不能判嚴重度，因為事實都還沒查清楚。
● "verified_by": "agent-07"
💬 記錄是哪一個驗證員蓋的章，之後如果有爭議可以回頭追責，也方便再找第三個人複查。
●}
💬 結束這筆紀錄。

🛠️ 動手做：模擬版《六階段資安稽核SOP》：當一次AI稽核小隊的總指揮

  1. 先按下方的『派出獵人小隊搜查下一個模組』，重複按到覆蓋率變成8 / 8（100%）為止，注意有些模組會顯示沒有發現可疑之處——這是正常的，不是每個角落都一定有洞。
  2. 覆蓋率跑完後，往下看候選驗證區塊，針對每一個跳出來的候選人，按下指派新的驗證員複查。
  3. 觀察三種結果：已確認confirmed（綠色）、待釐清needs_validation（黃色）、已排除rejected（灰色），想想同樣看起來可疑的東西，為什麼下場不一樣。
  4. 全部候選人都處理完之後，按下產出稽核報告，看看最後生出來的報告長什麼樣子。
  5. 重新整理頁面可以重玩一次，每次搜捕的順序會洗牌，但每個模組本身的體質（乾淨或有洞）不會變——這就是覆蓋清單的意義：不管查的順序怎麼變，最後都要全部查過一輪。
👇 下面是活的，直接操作

🧠 工程思維透鏡（資深工程師看到的是什麼）

🔭 為什麼要花兩次力氣做獨立驗證，而不是讓找到漏洞的那個AI自己順便判定就好？
AI跟人一樣有確認偏誤：找漏洞的agent有強烈動機把模糊的線索腦補成『真的有洞』，這樣才算有產出。刻意讓完全不知道搜查過程、只看證據的新agent來複查，等於是設計上的『檢察官不能兼法官』——用流程分權換取可信度，代價是多花一倍的算力跟時間，但換來的是報告能被信任。
🔭 為什麼要有coverage-ledger.json這種地毯式覆蓋清單，而不是讓AI自由發揮去找洞？
自由發揮的AI會有『社群媒體式』偏好——反覆去檢查最常見、最容易寫成一篇文章的漏洞類型（例如SQL Injection），卻漏掉冷門但要命的角落。覆蓋清單用確定性的checklist強制AI雨露均沾，把『找到幾個漏洞』的KPI換成『覆蓋了多少比例的攻擊面』，這是從隨機抽查升級成系統性稽核的關鍵設計。
🔭 為什麼最後產出報告要target-neutral（對事不對廠商）？
意涵是報告的嚴重度判定不能因為這是自己家產品就放水，也不能因為甲方付錢就誇大。這背後是把AI稽核當作可以對外公信的第三方鑑證角色來設計——如果報告口吻會因委託者不同而變來變去，整套系統的可信度就歸零，這是從玩具Demo走向正式產品必須跨過的信任門檻。
🔭 為什麼一個GitHub技能包最後會演變成公司內部的正式漏洞獵殺系統？
這反映一個工程真理：好的流程設計比模型能力更早決定天花板。不是因為模型變強了才能做這件事，而是先有偵查→搜捕→驗證→複核→報告這個可稽核、可重現的骨架，之後才談得上把它規模化鋪到整個服務艦隊上——先有可信的單元流程，才有資格談規模化。

📝 隨堂考（點選答案，立即回饋）

Q1. 這套技能包的第一階段「偵查」主要在做什麼？
✅ 偵查階段是先建立architecture.md和覆蓋清單，弄懂哪裡是資料進出口、哪裡跨越了信任邊界，這是後面地毯式搜捕的地圖依據，不是一開始就衝去抓漏洞。
Q2. 候選驗證階段為什麼要交給一個全新的驗證員，而不是找到問題的那個AI自己驗證？
✅ 核心設計理由就是防止找到問題的人順便自己蓋章通過，容易把模糊線索腦補成真的漏洞；獨立驗證者的任務是想辦法證明它是假的，證明不了才算數。
Q3. findings.json裡的confirmed、needs_validation、rejected三種狀態，差別在哪？
✅ 依素材說明，三種狀態的定義不是嚴重程度，而是證據完整度：confirmed要有完整來源追溯與有界限的觀察結果，needs_validation是還缺一個確定的事實所以先不判嚴重度，rejected則是候選人已被反證推翻。
Q4. 覆蓋率（coverage ledger）在這套系統裡解決的主要問題是什麼？
✅ 覆蓋清單強制AI依照確定性的checklist逐項打勾，避免大家都愛查同一種好抓的漏洞，卻漏掉冷門但可能更致命的角落。
Q5. 這套技能包後來演變成Cloudflare內部正式的漏洞獵殺系統，這件事說明了什麼工程道理？
✅ 先有偵查、搜捕、驗證、複核、報告這個可稽核、可重現的骨架，之後才談得上把它規模化鋪到整個服務艦隊上，說明流程設計往往比模型能力更早決定天花板。

🃏 翻牌記憶卡（先想答案，再點開對答）

Reconnaissance（偵查階段）在做什麼？點我翻面
畫系統地圖：架構、信任邊界、資料進出口，寫成架構筆記和覆蓋清單。
Coverage-led hunting是什麼？點我翻面
依照覆蓋清單派出互不知情的獵人小隊分頭搜查，還有教練角色檢查有沒有漏查的角落。
為什麼驗證要換人做？點我翻面
避免找到問題的AI自己球員兼裁判，出現自己講的故事自己信的確認偏誤。
confirmed / needs_validation / rejected差在哪？點我翻面
分別是：證據完整可定案／缺一個關鍵事實待查／候選人已被反證推翻。
target-neutral reporting是什麼意思？點我翻面
報告的口吻與嚴重度判定不因委託方或廠商別而改變，維持第三方鑑證的可信度。
這套技能包最終演變成什麼？點我翻面
Cloudflare內部正式、多階段、涵蓋整個服務艦隊的漏洞獵殺系統。

✅ 離開前自測（全勾＝這課真的學會了）

0%