🎯 什麼情境該想到我

當你「CI 伺服器上放著能寫入版控的憑證,而那台機器從架起來之後沒人動過也沒人看過」的時候。

⚙️ 怎麼用(步驟 / 公式)

意圖:支撐持續整合與持續部署的基礎設施本身就是一片新的、易受攻擊的表面積,必須像對待面向客戶的生產基礎設施一樣去加固它。

威脅模型(書中講得很具體)

  • 若有人攻破了跑部署管線、且持有版控系統憑證的伺服器,就可能竊取原始碼
  • 更糟的是,若部署管線具有寫入權限,攻擊者可以把惡意變更注入版控儲存庫,因而把惡意變更注入我們的應用程式與服務
  • 最陰險的藏匿處是單元測試。 Jonathan Claudius(TrustWave SpiderLabs 前資深資安測試員):「持續建置與測試伺服器很棒,我自己也在用。但我開始思考怎麼把 CI/CD 拿來當作注入惡意程式碼的方式。這帶出一個問題:哪裡會是藏惡意程式碼的好地方?答案很明顯:在單元測試裡。沒有人真的會去看單元測試,而它們在每次有人 commit 程式碼進 repo 時都會被執行。

五項緩解措施(全列)

  1. 加固持續建置與整合伺服器,並確保我們能以自動化方式重製它們——就像對待支撐面向客戶生產服務的基礎設施一樣,以防止建置/整合伺服器被攻破。
  2. 審查所有進入版控的變更——透過 commit 時的結對程式設計,或在 commit 到合併進 trunk 之間做 code review——以防止持續整合伺服器執行不受控的程式碼(例如單元測試可能含有允許或促成未授權存取的惡意程式碼)。
  3. 檢測(instrument)我們的儲存庫,偵測含有可疑 API 呼叫的測試碼被 check in(例如單元測試存取檔案系統或網路),必要時隔離(quarantine)它並觸發立即的程式碼審查
  4. 確保每一個 CI 程序都跑在它自己隔離的 container 或 VM 上。
  5. 確保 CI 系統所使用的版控憑證是唯讀(read-only)的。

與其他控制的關係:開發者引入允許未授權存取的程式碼,這個風險已由程式碼測試、code review、滲透測試緩解;未授權使用者取得程式碼或環境的存取權,這個風險已由「確保組態符合已知良好狀態」與「有效的修補」緩解。上面五項是專門用來保護持續建置、整合與部署管線本身的補充。

原文(最陰險的藏匿處):「Which led to the question of where would be a good place to hide malicious code? The answer was obvious: in the unit tests. No one actually looks at the unit tests, and they’re run every time someone commits code to the repo.」(L12162–12165)

原文(唯讀憑證):「Ensuring the version control credentials used by the CI system are read-only」(L12196)

原文(可疑 API 呼叫的偵測):「Instrumenting our repository to detect when test code contains suspicious API calls (e.g., unit tests accessing the filesystem or network) is checked in to the repository, perhaps quarantining it and triggering an immediate code review」(L12189–12192)

🧪 我實際套用的紀錄

  • (待填)

⚠️ 注意 / 什麼時候不適用

  • 「CI 憑證唯讀」有時會跟自動 tag/自動 bump 版號之類的流程衝突;書中沒有給例外,若真的需要寫入,至少要把寫入範圍與那條唯讀讀取路徑分開。
  • 第 2 項是有代價的控制:要求所有進版控的變更都被審查,等於把 結對程式設計程式碼審查準則 變成強制。若組織還沒有這個習慣,這條會被繞過。
  • 第 3 項不要做成硬阻擋而做成隔離+觸發審查——書中的措辭是 quarantining 與 triggering an immediate code review,保留人的判斷。
  • 這條的價值高度取決於第 1 項:如果你的 CI 伺服器不能自動重建,其餘四項都只是在保護一個你無法復原的黑盒子。

🔗 相關工具