Day 17：資安合規與 AI 的協作——這個階段怎麼分工，以及要談些什麼

一套固定的工作流

進到資安合規這塊，我跟 AI 的協作慢慢固定成一套流程。它跟前面十六天不太一樣——前面多半是我把現場脈絡餵給 AI、再一起追一個 bug；資安這塊比較像是：東西丟進來，AI 判讀，我做決定，Claude Code 動手。 具體來說，輸入端大概是這四種：

餵一份弱掃或滲透測試報告。 這是最常見的起點。稽核跑完，一份列滿中高風險的報告丟過來，我把它整份貼給 AI，請它判讀——哪些是真的要修、哪些是掃描工具的規則誤用、哪些是報告本身寫錯了。判讀完之後，關鍵的一步是請 AI 把該修的項目整理成一份修改計畫，再把這份計畫交給 Claude Code 去實際改程式。舉個實際的例子：一份 CSP 標頭設定不完整的弱掃報告，我讓 AI 先讀完報告、確認每一條的真偽與修法，產出一份逐項的修改計畫，Claude Code 再照著這份計畫動手。判讀跟動手是分開的兩件事，中間夾著我這一關的確認。

餵一份 log。 access log、錯誤 log、容器 log，貼給 AI 請它分析行為軌跡、定位異常。稽核情境下最常問的是「誰、什麼時候、做了什麼」，log 是回答這句話的原始材料。

餵 curl -I 打出來的回應標頭。 弱點到底修好了沒，不能只看程式碼改了沒，要看正式站實際吐出來的標頭長什麼樣。我拿 curl 手動打，把回應標頭貼給 AI，讓它對照弱點清單一條條判定——這條指令在不在、值對不對、有沒有被別的設定蓋掉。

設定一份規範，交給 Claude Code。 有些資安要求不是改一次就結束，而是要變成之後每次開發都自動遵守的規則。這種就寫進規範文件（例如 CLAUDE.md），讓 Claude Code 在後續每一次動手時都受它約束。

這四種輸入的共同點是：AI 負責把專業知識與判讀能力補上，我負責決定要不要採用、適不適合我的環境，Claude Code 負責執行。 為什麼要特別把這套分工講清楚？因為資安這塊，AI 懂得其實比我多——我是公部門的系統開發者，不是資安專家。當專業知識反過來由 AI 提供時，人剩下的、也是最不能外包的，就是判斷：這條建議適不適合我的系統、能不能通過台灣公部門的稽核、AI 這次是不是又講得太理想化了。這條線貫穿整個資安篇：知識可以外包，判斷不行。

先給一個能立刻拿去用的例子：那堆安全標頭，哪些值得認真做

講一個具體的，順便示範上面那套判讀是怎麼運作的。弱掃報告最常丟過來的，就是一整排看起來都差不多的安全標頭缺失：CSP、COOP、COEP、CORP……全部標成中風險，好像每一條都得動手修。但我跟 AI 把它們一條條拆過之後，發現這些標頭的真實價值差很多，大致分成三組——這一段想寫給正在讀這篇的資安人員看，順便讓你想一想，自己是不是也曾經把它們一視同仁地全部要求下去過。

第一組，真的有價值的。 CSP 是這幾個裡唯一稱得上主力防線的，但前提是要走 nonce 這類真的能擋 XSS 的做法，而不是為了讓報告變綠燈，塞一行 unsafe-inline 交差——那樣防護力等於零，只是把稽核報告餵飽而已。另外像 nosniff、frame-ancestors、HSTS 這三個，投報率最高，一行設定不會弄壞任何東西，不值得花時間辯論，設下去就對了。

第二組，看情況的。 COOP 擋的是透過視窗參照做側通道推測的那類攻擊，系統有登入、有個人化資料才值得設；純公開資訊站設了也沒什麼意義。CORP 成本最低，順手做掉不虧。這組的重點是「先問這個系統需不需要」，而不是照單全收。

第三組，莫名其妙的。 COEP 本質上根本不是一個防護機制——它是啟用某些進階瀏覽器功能（例如 SharedArrayBuffer）的前置條件。一般政府網站沒有這種需求，設了收益趨近於零，代價卻是所有第三方資源都得跟著配合送對應標頭，稍不注意就把頁面打壞。掃描器對一個安安靜靜的靜態機關網站報「缺少 COEP」，說穿了就是規則庫的誤用——它只是機械地比對「這個標頭在不在」，根本不管這個網站到底需不需要它。

我把這組特別拉出來講，是因為它點出資安這一行一個很常見、卻很少有人停下來想的問題：我們是不是常常把「掃描器報了」直接當成「這就是弱點」，然後花力氣去修一個根本不該存在於這個系統的東西？ 掃描器抓的是標頭表面上在不在，不是它背後到底有沒有在保護什麼。這兩件事，是不一樣的。

而且很多時候，逼你去修這些東西的人，自己也沒搞清楚狀況。我遇過的實際狀況是，某個縣市的資訊單位直接要求「報告上要零弱點」——不是零高風險、不是零真正該修的項目，是掃描報告上一條都不能剩。這種要求聽起來很負責任，實際上是把「報告好看」跟「系統安全」畫上了等號，逼著開發端去為一個靜態網站硬塞 COEP、去把一個內部服務的自簽憑證想辦法「消掉」，做一堆對真實安全毫無幫助、甚至可能弄壞服務的事。當提要求的人也只看報告上的數字時，那份判斷的責任，就只能落回真正懂這個系統的人身上——這也是為什麼在這個「AI 懂得比我多」的領域裡，我還是不敢把判斷整包交出去。

這個例子也正好示範了這個階段的協作長什麼樣：分級這件事，是 AI 幫我把知識整理出來的；但「這個系統到底需不需要 COEP」「為了過弱掃硬塞 unsafe-inline 值不值得」——這些判斷，是我這個懂自己系統、懂台灣稽核現實的人下的。

這個階段會談到的所有議題

除了上面那組安全標頭，這幾天在真實專案裡碰到的資安議題，整理成一份目錄。這篇當作整個資安合規篇的索引，之後每一篇會挑其中一條深入。

第一組，安全標頭與弱點判定。

• 安全標頭價值分級：CSP／COOP／COEP／CORP 哪些真的在保護東西、哪些是掃描器誤用（就是上面那組）
• 從一份 curl -I 的回應標頭，判定一個弱點到底修好了沒；以及「有設定卻沒生效」的根因（middleware 註冊順序）
• 一個更根本的質疑：這些標頭全部規範瀏覽器行為，但攻擊者用 curl，那它們到底還有沒有價值

第二組，弱點的真偽與判讀。

• 一份滲透報告聲稱破解了 JWT，但看它的操作流程，是真的破解還是自己簽自己驗
• 一份報告裡的多個弱點，逐項判讀哪些成立、哪些要靠升級元件解決
• 掃描原理的侷限：非 service 的元件是不是就掃不到（用一個反例打臉）
• 能不能乾脆讓 AI 自己當滲透測試工具去打自己的站

第三組，合規落地的現實。

• 組態基準（GCB）導入不是打勾清單，防火牆規則套用順序錯了會直接斷線
• 檔案完整性監控（FIM）：上線當晚就被合法排程觸發、假警報滿天飛的坑
• 自簽憑證在資安設計上完全合理，但台灣公部門的弱掃就是不會讓它過
• host 系統層的檔案完整性監控：怎麼盤點「哪些變動其實是合法的」

第四組，把資安焊進日常工程。

• 一張不合格的稽核紀錄表，怎麼重新設計成能上稽核的架構
• 用 Jenkins 把 SonarQube、ZAP、Trivy 焊進部署管線，並分辨哪些掃描值得跑、哪些只是形式
• 資料庫端的稽核 hook 怎麼設計，才不會漏記又不會拖垮效能
• 系統掛掉時要顯示的靜態維護頁，該放在哪一層

這一天的定位

這篇是整個資安篇的索引，也是一次對協作模式的重新定位。在資安這塊，我是提問的那一方，AI 是給答案的那一方——但這不代表協作的價值變低了。恰恰相反，它讓「人到底不可取代在哪裡」這個問題變得更清楚：當 AI 懂得比你多的時候，你的價值不在於知道答案，而在於知道要問什麼、聽得懂它的答案、判斷得出它適不適合你的處境，以及在它講錯或講得不夠的時候有能力反駁。就像那組安全標頭——AI 給了我分級的知識，但決定「這個系統不需要 COEP、別為了過弱掃而自廢武功」的，還是得是我。

明天先把安全標頭這條線走完：從一份 curl -I 打出來的回應標頭，到「有設定卻沒生效」的根因，一次真正動手判定弱點的過程。