在本篇文章中，我們將瞭解第三方服務的監管不足，工件完整性驗證及日誌可見性不足這三個關鍵 CI/CD 安全風險，並給出緩解相應風險的建議與措施。
第三方服務監管不足
______________________
CI/CD 攻擊面包括企業資產，例如 SCM 和 CI，以及被授權訪問這些資產的第三方服務。與不受監管地使用第三方服務有關的風險依賴於第三方服務可以極其輕鬆地被授予對 CI/CD 系統中資源的訪問許可權，從而有效地擴大了企業的攻擊面。
風險描述
如今大部分企業都將第三方連結到其 CI/CD 系統和流程，這樣易於實施且易於發揮直接價值，也使第三方成為日常軟體開發中不可或缺的一部分，嵌入或授予第三方訪問許可權的方法正變得越來越多樣化。以常見的 SCM—GitHub SAAS—為例，可以透過以下 5 種方法中的一種或多種連線第三方應用程式：
- GitHub 應用程式
- OAuth 應用程式
- 提供給第三方應用程式的訪問令牌
- 提供給第三方應用程式的 SSH 金鑰
- 傳送給第三方的 webhook 事件配置
每種方法都需要幾秒鐘到幾分鐘的時間來實施，併為第三方提供多種功能，比如讀取單個儲存庫中的程式碼，甚至是全面管理 GitHub 組織。儘管這些第三方被授予對系統的潛在高級別許可，但在許多情況下，企業在實際實施之前不需要特殊許可或批准。
構建系統還允許輕鬆整合第三方。將第三方整合到構建流水線中通常並不會比在流水線配置檔案中新增 1-2 行程式碼或從構建系統的市場安裝外掛（例如 Github Actions 中的操作、CircleCI 中的 Orbs）更復雜。將第三方功能作為構建過程的一部分匯入並執行，並可以完全訪問執行它的流水線階段可用的任何資源。
在大多數 CI/CD 系統中，類似的整合方法以各種形式提供，從而使在整個軟體工程生態系統中管理和維護圍繞第三方使用的最小特權的過程變得極其複雜。各企業也正在努力應對以下挑戰：
- 全面瞭解哪些第三方可以訪問不同的系統
- 第三方擁有哪些訪問方法、被授予的許可權/訪問級別以及實際使用的許可權/訪問級別
影響
缺乏對第三方實施的管理和可見性會影響企業在其 CI/CD 系統中維護 RBAC。RBAC 的實施不足和第三方的最小特權，加上圍繞第三方實施過程的管理和盡職調查不足，顯著增加了企業的攻擊面。鑑於 CI/CD 系統和環境的高度互聯性，單個第三方威脅可被利用，給企業造成巨大損失，例如具有寫入許可權的第三方儲存庫，攻擊者可以利用該程式碼將程式碼推送到儲存庫，這反過來又會觸發構建並在構建系統上執行惡意程式碼。
建議
圍繞第三方服務的管理控制應在第三方使用生命週期的每個階段實施：
批准
——建立審查程式，以確保在軟體工程生態系統中的任何地方獲得資源訪問許可權的第三方在被授予環境訪問許可權之前獲得批准，並且授予他們的許可權級別符合最小特權原則。
整合
——引入控制和程式以保持對整合到 CI/CD 系統的所有第三方的持續可見性，包括：整合方法。確保涵蓋每個系統的所有整合方法（包括市場應用程式、外掛、OAuth 應用程式、程式設計訪問令牌等）。授予第三方的許可權級別。第三方實際使用的許可級別。
持續使用的可見性
——確保每個第三方都被限制在其需要訪問和刪除未使用和/或冗餘許可權的特定資源的範圍內。作為構建過程的一部分整合的第三方應在範圍內執行，對機密和程式碼的訪問受限，並具有嚴格的出入口過濾機制。
取消配置
——定期審查所有整合的第三方並刪除不再使用的部分。
工件完整性驗證不當
_________________
由於確保程式碼和工件驗證的機制不足，工件完整性驗證不當風險會導致訪問 CI/CD 流程中的系統的攻擊者將惡意程式碼或工件推入流水線中。
CI/CD 流程由多個步驟組成，最終負責將程式碼從開發人員的工作站推送到生產環境。在這個過程中內部資源和工件與從遠端位置獲取的第三方包和工件相結合，最終資源依賴於分佈在不同步驟中的多個來源，由多個貢獻者提供，這也意味著多個入口點被建立，透過這些入口點可以篡改最終資源。如果被篡改的資源能夠成功地滲透到交付過程中，很可能會以當作受信任的資源一直流向生產環境。
影響
在軟體交付過程中，惡意攻擊者可能會濫用不當的工件完整性驗證，透過流水線傳送惡意工件，最終導致惡意程式碼在 CI/CD 流程中的系統上，或更糟的情況，在生產環境中執行。
建議
防止不當的工件完整性驗證風險需要一系列措施，跨越軟體交付鏈中的不同系統和階段。建議企業考慮以下實踐：
實施相關流程和技術來驗證從開發到生產的整個過程中資源的完整性。生成資源時，該過程將包括使用外部資源簽名基礎架構對該資源進行簽名。在流水線的後續步驟中使用該資源之前，應根據簽名許可權驗證資源的完整性。在這種情況下需要考慮的一些普遍措施有：
程式碼簽名
——SCM 解決方案提供了使用每個貢獻者的唯一金鑰對提交進行簽名的能力。然後可以利用此措施來防止未簽名的提交流下流水線。
工件驗證軟體
——使用簽名和驗證程式碼和工件的工具提供了一種方法來防止未經驗證的軟體被交付到流水線中（如 Sigstore）。
配置偏差檢測
——檢測配置偏差的措施（例如，未使用簽名 IAC 模板管理的雲環境中的資源），表明資源由不受信任的源或程序部署。
從構建/部署流水線獲取的第三方資源（例如作為構建過程的一部分匯入和執行的指令碼）應遵循類似的邏輯——在使用第三方資源之前，應計算資源的雜湊值，並交叉引用官方釋出的來自資源提供者釋出的雜湊。
日誌記錄和可見性不足
_____________________
日誌記錄和可見性不足將給攻擊者在 CI/CD 環境中執行惡意活動的機會。強大的日誌記錄和可見性功能對於企業準備、檢測和調查安全相關事件的能力至關重要。雖然工作站、伺服器、網路裝置以及關鍵 IT 和業務應用程式通常在企業的日誌記錄和可見性程式中全面覆蓋，但開發環境中的系統和流程通常並非如此。
鑑於利用軟體工程環境和流程的潛在攻擊向量的數量，安全團隊必須培養足夠的能力以在這些攻擊發生時立即執行檢測。由於其中許多向量涉及利用針對不同系統的程式化訪問，因此面臨這一挑戰的關鍵方面是圍繞人工和程式訪問建立強大的可見性。鑑於 CI/CD 攻擊向量的複雜性，系統的審計日誌（例如使用者訪問、使用者建立、許可權修改）和應用日誌（例如將事件推送到儲存庫、執行）具有同等的重要性構建，上傳工件。
影響
惡意攻擊者為了達成攻擊目的，逐漸將注意力轉移到開發環境。企業如果無法確保圍繞這些環境進行適當的日誌記錄和可見性控制，則可能無法檢測到違規行為，而且企業在緩解/補救以及事件調查能力也會大大降低。對於受到攻擊的企業來說，時間和資料至關重要，集中放置所有相關資料來源將在事件響應場景中起到完全不同的作用（成功補救或破壞性打擊）。
建議
實現足夠的日誌記錄和可見性有幾個要素：
對映環境
——如果不熟悉涉及潛在威脅的所有不同系統，就無法實現強大的可見效能力。潛在的違規可能涉及參與 CI/CD 流程的任何系統，包括 SCM、CI、工件儲存庫、包管理軟體、容器登錄檔、CD 和編排引擎（例如 K8s）。識別並建立組織內使用的所有系統的清單，包含這些系統的每個例項（例如 Jenkins）。
識別並啟用合適的日誌源
——一旦識別了所有相關係統，下一步就是確保啟用所有相關日誌。應透過允許的所有各種措施，圍繞人工訪問和程式訪問最佳化可見性。所有相關審計日誌源以及應用日誌源都非常重要，應當給予同等重視。
將日誌傳送到集中位置
（例如 SIEM），來支援不同系統之間日誌的聚合和關聯，方便進行檢測和調查。
為檢測異常和潛在的惡意活動建立警
報，包括每個系統本身的異常和程式碼傳送過程中的異常，這涉及多個系統並且需要更深入地瞭解內部構建和部署過程。
本系列文章至此篇已完結，在五篇文章中我們陸續介紹了十大 CI/CD 安全風險並給出了緩解相應風險的安全建議。Seal 軟體供應鏈防火牆旨在為企業提供程式碼安全、構建安全、依賴項安全及執行環境安全等4大防護，透過全鏈路掃描、問題關聯及風險組織的方式保護企業軟體供應鏈安全，降低企業安全漏洞修復成本。