🎯 什麼情境該想到我
當資安與稽核總是在最後一刻出現、擋住上線，或丟給你一份沒人有時間處理的漏洞清單時。
⚙️ 怎麼用
- 先認清人數比例：書中給的數字是 Dev : Ops : Infosec ≈ 100 : 10 : 1。資安以這種比例被稀釋時，除了做合規勾選什麼也做不了——唯一的出路是自動化，並把資安放進 Dev 與 Ops 的日常工作裡。
- 把預先核可的東西放進共用儲存庫：把資安已 pre-blessed 的函式庫與服務（2FA、bcrypt 密碼雜湊、秘密管理、正確組態的 OpenSSL、集中式 log）放進共用版控。判準：工程師用了這些，該模組就不必再另外排一次資安設計審查——這是把資安變成阻力最小路徑的關鍵。
- 把資安測試放進部署管線，四類一起跑：
- 靜態分析（非執行期，“testing from the inside-out”）：Brakeman、Code Climate、掃被禁函式如
exec() - 動態分析（執行期，“testing from the outside-in”）：Arachni、OWASP ZAP
- 相依掃描：盤點所有二進位與可執行相依有無已知漏洞
- 原始碼完整性與簽章：每位開發者有自己的 PGP key、所有 commit 簽章、CI 產物簽章且 hash 記錄到集中式 log 供稽核
- 靜態分析（非執行期，“testing from the inside-out”）：Brakeman、Code Climate、掃被禁函式如
- 回饋要給對人：不要產一份巨大 PDF 報告 email 出去，而是把修復所需的確切資訊，給造成那個漏洞的那位開發者。也要知道自己何時送出 false positive 並修正——不然開發者很快就不信任你的工具了。
- 用變更歷史去換取「標準變更」資格：拿出數月到數季的變更歷史 ＋ 同期完整的生產事故清單，證明高變更成功率與低 MTTR，就能主張這些低風險變更可預先核可、不必每次送 CAB。書中明確指出：CAB 有協調與治理的角色，但不該手動評估每一個變更，ITIL 也沒有規定要這樣做。
原文：「the ratio of engineers in Development, Operations, and Infosec in a typical technology organization is 100:10:1.」
🧪 我實際套用的紀錄
- 2026-08-02：（待填）
⚠️ 注意
- 職責分離（separation of duties）不是唯一解，而且有代價。 書中拿 Etsy 的 PCI DSS 隔離環境當警世故事：合規報告拿到了，但那個環境裡沒有人能當 full-stack engineer，部署與維護開始出現恐懼與不情願。書中的建議是盡可能改用結對、持續檢查 check-in、code review 這些控制，並能證明達到等效結果。
🔗 相關工具
- 工具-部署管線與持續交付 —— 承載平台，資安測試就是管線裡多加的幾道自動化測試
- 工具-遙測與監控 —— 偵測面的另一半，資安遙測跟營運遙測該進同一套工具
- 工具-無指責事後檢討 —— 每次資安事件也開一次檢討，是知識轉移給工程團隊的機制
- 四類應用資安自動測試、把變更重歸類為標準變更 —— 型錄條目，含 Twitter 漏洞率降 60% 與 Salesforce 的完整做法