🎯 什麼情境該想到我
當你「資安在上線前兩週丟來一份幾百頁的 PDF 漏洞報告，而專案根本來不及改」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：把資安測試自動化到部署管線裡，理想上在 Dev 或 Ops 的每一次 code commit 就執行，甚至在軟體專案最早期就開始跑，讓資安回饋跟其他自動化測試一樣快。
心法：測 sad paths 與 bad paths，不是只測 happy path。
開發測試通常聚焦在功能正確性與正向邏輯流（happy path）；有效的 QA、Infosec 與防詐實務者則聚焦在事情出錯時的 sad paths，尤其是與資安相關的錯誤條件（這類特別針對資安的條件常被戲稱為 bad paths）。這些測試不該手動做，而該產生成自動化單元／功能測試的一部分，在部署管線中持續執行。
四類測試（全列）
(a) Static analysis 靜態分析
- 在非執行期環境中進行的測試，理想上放在部署管線裡。
- 靜態分析工具檢視程式碼的所有可能執行期行為，找出編碼瑕疵、後門與潛在惡意程式碼——這有時被稱為 “testing from the inside-out”。
- 工具範例：Brakeman、Code Climate，以及搜尋被禁用的程式函式（例如
exec()）。
(b) Dynamic analysis 動態分析
- 與靜態測試相對，動態分析由程式運行中執行的測試組成，監控系統記憶體、功能行為、回應時間與整體效能。
- 這個方法（有時稱為 “testing from the outside-in”）類似惡意第三方與應用程式互動的方式。
- 工具範例：Arachni、OWASP ZAP（Zed Attack Proxy）。
- 某些類型的滲透測試也可以自動化執行並納入動態分析，工具如 Nmap 與 Metasploit。
- 理想上在部署管線的自動化功能測試階段執行動態測試，甚至對生產中的服務執行；OWASP ZAP 可設定成透過瀏覽器 proxy 攻擊我們的服務，並檢視測試框架內的網路流量。
(c) Dependency scanning 相依掃描
- 另一種靜態測試，通常在部署管線內的 build 時執行。
- 做法：盤點所有二進位與可執行檔的相依，確保這些我們往往無法控制的相依沒有漏洞或惡意二進位。
- 工具範例：Ruby 的 Gemnasium 與 bundler audit、Java 的 Maven，以及 OWASP Dependency-Check。
(d) Source code integrity and code signing 原始碼完整性與程式碼簽章
- 每一位開發者都應該有自己的 PGP key（可用 keybase.io 之類的系統建立與管理）。
- 所有 commit 到版控都應該被簽章——用開源工具 gpg 與 git 設定起來很直接。
- 所有由 CI 程序產生的套件都應該被簽章，且其 hash 記錄到集中式的 logging service 供稽核之用。
讓資安測試住進開發者熟悉的框架
Gauntlt 這類工具就是設計來整合進部署管線，對應用程式、應用相依、環境執行自動化資安測試。值得注意的是 Gauntlt 把所有資安測試都寫成 Gherkin syntax 的測試腳本——那是開發者做單元與功能測試時廣泛使用的語法，等於把資安測試放進他們早已熟悉的框架裡。
Twitter 2009 案例
- 2009 年初兩起嚴重外洩（一月 @BarackObama 帳號被駭；四月管理帳號被暴力字典攻擊攻破）導致 FTC 認定 Twitter 誤導使用者相信帳號是安全的，並發出 consent order，要求六十天內建立一套必須執行二十年的流程。
- 第一個大突破發生在一次全公司的 hack week：他們把靜態程式碼分析整合進 Twitter 的 build 流程，使用 Brakeman（掃描 Ruby on Rails 應用漏洞）。目標是把資安掃描整合進開發流程的最早期階段，而不只是程式碼 commit 進 repo 的時候。
- 成果：多年下來，藉由在開發者寫出不安全程式碼時給予快速回饋、並示範如何修復，Brakeman 讓發現的漏洞率降低了 60%。
- 六條原則中特別可搬用的兩條：
- 不要跑一個工具產出一份巨大 PDF 報告然後 email 給 Dev 或 Ops 的某個人——而是把修復所需的確切資訊，給那位造出這個漏洞的開發者。
- 要知道自己何時送出了 false positive，這樣才能修正產生 false positive 的錯誤，避免浪費開發團隊的時間（這是維繫 Development 信任的條件）。
為什麼相依掃描不能省：軟體供應鏈的數字
Verizon 的 2014 PCI Data Breach Investigation Report（DBIR）研究了超過八萬五千起外洩，發現十個漏洞（CVE）就佔了 2014 年所研究的持卡人資料外洩中所用漏洞的近 97%；而這十個之中有八個已經超過十年。
原文（原始碼完整性與簽章）：「All developers should have their own PGP key, perhaps created and managed in a system such as keybase.io. All commits to version control should be signed—that is straightforward to configure using the open source tools gpg and git. Furthermore, all packages created by the CI process should be signed, and their hash recorded in the centralized logging service for audit purposes.」（L11722–11727）
原文（Twitter 的成效）：「Brakeman has reduced the rate of vulnerabilities found by 60%」（L11845–11846）
原文（供應鏈的數字）：「The DBIR found that ten vulnerabilities (i.e., CVEs) accounted for almost 97% of the exploits used in studied cardholder data breaches in 2014. Of these ten vulnerabilities, eight of them were over ten years old.」（L11880–11882）
🧪 我實際套用的紀錄
- （導入順序建議：先 (c) 相依掃描，因為它成本最低而 97%／十年舊漏洞的數字說明它報酬最高；再 (a) 靜態分析；然後 (d) 簽章；最後 (b) 動態分析。）
- （待填）
⚠️ 注意 / 什麼時候不適用
- False positive 會直接毀掉這條。 Twitter 的六條原則裡專門有一條在講「要知道自己何時送出 false positive 並修正它」——因為他們需要贏得並維持 Development 的信任。
- 不要產大 PDF。 報告寄給不對的人、在不對的時間，等於沒做。輸出必須是「給造成該漏洞的那位開發者的、修復所需的確切資訊」。
- 光把工具接上還不夠：Twitter 的問題定義裡有一條是「即使漏洞掃描自動化了，Infosec 仍要做大量手動工作與等待」——等掃描、拿一疊報告、解讀、找到該修的人，程式一改又要重來。要把這段也自動化。
- 動態分析對生產服務執行前，要先確認爆炸半徑；書中把它放在自動化功能測試階段或針對生產服務，但沒有給無條件的許可。
🔗 相關工具
- 預先核可的資安函式庫（預防端；這條是偵測端）
- 保護部署管線（跑這些測試的管線本身也要被保護）
- 資安遙測（把測不到的部分交給生產環境的觀測）
- 工具-部署管線與持續交付（這些測試要跟其他自動化測試跑在同一條管線上）
- 測試金字塔（sad path 與 bad path 應該做成單元／功能測試而不是手動）
- 單一共用原始碼儲存庫（測試標準與工具「含資安」就放在這裡）
- DevOps手冊