近年來，各大軟件公司都開始依賴DevOps方法，來增強軟件交付的敏捷性和協作能力。CI/CD管道使得軟件開發生命周期(SDLC)中的各個流程更加自動化，進而實現了新功能的無縫集成和交付。

雖然CI/CD管道能夠通過自動化和敏捷性，來增強軟件的開發，但是它們往往需要集成大量的工具和服務，而這極有可能會引入新的安全漏洞?？梢?，識別和修復這些安全漏洞是確保CI/CD安全實踐的關鍵。本文將和您討論如何安全加固CI/CD管道。

CI/CD安全性簡介

雖然CI/CD管道是通過自動化來提高軟件開發和交付的效率，但是管道的核心階段在默認情況下并不包含安全性。實際上，CI/CD的安全性是一組旨在識別和修復漏洞的實踐，而不會顯著地減慢管道中的各項流程。CI/CD的安全實踐主要涉及到：注入滲透測試和主動安全審計，并據此減少因延遲交付，給安全和QA團隊造成的瓶頸。因此，安全的CI/CD管道會讓軟件團隊能夠自動化多個部署環境，提高SDLC(軟件開發生命周期)的安全性，從而增強敏捷性。

CI/CD管道的常見安全威脅

一個組織的CI/CD管道往往具有基于所使用的業務案例、工作負載、以及技術棧的獨立特征。因此，CI/CD的安全性在實現上也會因用例的不同而有所差異。對此，我們應當首先認識那些幾乎在所有管道中都存在的安全風險類型：

未經授權訪問的代碼存儲庫

CI/CD的各種操作主要依賴共享存儲庫，來實現協作、配置管理、更新和版本控制。所有源代碼和配置文件都被保存在Git存儲庫中，并作為單一的來源。公共存儲庫在CI/CD管道中備受歡迎的原因是，它們降低了開發的成本和時間。

但是，由于開發人員將源代碼從其私有主機發布到公共的共享文件夾中，因此給存儲庫帶來了安全威脅。攻擊者可以搜索開源注冊表作為一種偵察技術，并利用獲得的數據，進行有針對性的網絡釣魚、逆向工程、以及遠程代碼執行攻擊。

不安全的代碼

CI/CD管道中快速開發和交付的要求，導致了越來越多的開源使用、以及與第三方的集成。一些團隊可能會在沒有核查源代碼的安全漏洞的情況下，將第三方代碼集成并導入部署環境。顯然，這是由于開發人員未能遵循代碼安全的最佳實踐，而增加了CI/CD管道的攻擊面。常見的代碼漏洞包括格式字符串漏洞、緩沖區溢出、錯誤處理不當、以及規范化問題等。

密鑰管理不當

密鑰管理有助于合理化對CI/CD管道中數據和資源的訪問。其中包括：密碼、令牌、API密鑰、以及其他身份驗證憑據，它們可以在管道中被用于驗證訪問敏感系統的用戶。因此，密鑰的曝露會讓攻擊者獲取CI/CD進程的部分、甚至全部控制權。常見的密鑰管理環節中的錯誤配置包括：對密鑰進行硬編碼、在公共云環境中存儲密鑰、以及手動進行密鑰管理等。

左移安全

在較舊的管道中，由于安全性往往是最后一步，因此導致了部署過程中的瓶頸。如今的最佳實踐理論是：在SDLC的早期集成安全控制，也被稱為“轉移安全”。此類左移會涉及在CI/CD管道的每個層面上實施安全檢查，從而在每個步驟中，實現更加準確的威脅檢測。顯然，其目標就是為了消除DevOps和安全團隊之間的摩擦，提高軟件開發的效率，并確保穩健的安全實踐。

采用CI/CD安全工具的關鍵注意事項

在選擇保護CI/CD管道的工具時，我們應當考慮如下因素：

• 掃描覆蓋率
• 擁有成本和許可條款
• 需要維護和配置的工作量
• 可擴展性
• 與現有開發和安全棧的集成

在CI/CD管道上管理安全性

隨著威脅態勢的不斷變化，管理安全性已經成為了CI/CD管道的最重要環節之一。保護DevOps工作流的第一步便是評估如何將DevSecOps的原則應用于CI/CD管道。在評估的過程中，我們需要確定管理安全性的工具和策略。

保護CI/CD管道的最佳實踐

為了充分體現將安全性直接集成到軟件生命周期中的好處，開發團隊應該：

避免在配置文件和CI/CD構建工具中使用硬編碼的密鑰

SDLC的各個階段都會用到密鑰。而提供這些密鑰的一種簡單方法是，將它們作為環境變量引用到配置文件和清單中。任何可以訪問這些模板和文件的人員，都將能夠從此類文件中提取憑證信息，這便可能導致數據的泄露。因此，軟件團隊應當使用加密存儲或啟用密鑰集中管理的工具，以使得密鑰數據能夠遠離惡意用戶。為了安全地管理和分發密鑰，管理員應該在將密鑰存儲在ETCD服務器之前，就執行靜態加密。

首先，如下代碼段所示，將密鑰編碼為Base64格式：

$ username=$(echo -n "admin" | base64)
$ password=$(echo -n "a62fjbd37942dcs" | base64)

在YAML文件中定義密鑰：

echo "apiVersion: v1
> kind: Secret
> metadata:
>   name: test-secret
> type: Opaque
> data:
>   username: $username
>   password: $password" >> secret.yaml

接著，一旦創建了密鑰，您就可以將它們應用到Kubernetes的pod中。這可以通過創建一個.yaml文件來完成。文件secret-env.yaml的環境變量中存放了源自密鑰的數據。該文件的規范，如下代碼段所示：

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
    - name: mycontainer
      image: alpine:latest
      command: ["sleep", "9999"]
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: username
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: password
  restartPolicy: Never

如上述代碼段所示，在填充環境變量時，Kubernetes會解碼Base64值。這些環境變量可被用于所有的Kubernetes API對象，且無需對密鑰數據進行硬編碼。

對CI/CD的構建工具實施訪問控制

DevOps團隊應實施身份驗證和授權機制，以管控那些可以訪問CI/CD管道中特定流程和工具的實體。團隊應貫徹最小權限原則，以確保僅將資源的訪問權限，授予絕對需要的角色。同時，CI/CD管道中的數據還應該使用令牌、訪問密鑰和密碼等方式予以保護，以防止惡意負載被添加到管道中。

為源代碼管理建立身份驗證機制

帶版本控制的存儲庫(通常在Git中)是CI/CD管道的必備工具。它們能夠促進協作并實現新功能的持續部署。不過，由于Git存儲庫包含著應用程序的源代碼、基礎設施即代碼(Infrastructure-as-Code)清單、以及知識產權，因此源代碼控制中的漏洞將會允許攻擊者訪問到應用程序的設計和實現邏輯。

鑒于它們往往是黑客逐利的目標，因此我們應該使用多因素身份驗證，來對Git存儲庫的訪問予以安全加固。同時，開發團隊還可以通過Git的最佳實踐，來防止意外的分支、以及提交.gitignore文件。

確保管道中所有環境配置的一致性

DevOps團隊應確保開發、測試、生產等所有環境的配置具有一致性。通過配置奇偶校驗，QA團隊可以在測試期間準確地檢測出安全問題，特別是那些普遍存在于所有環境配置中的問題。同時，團隊也可以使用容器和基礎設施即代碼的聲明等虛擬化和抽象技術，來實現一致性的檢測。

配置回滾功能

安全和QA團隊通常會在應用程序更新或部署后發現安全問題。這往往需要管理員將相應的部署回滾(或稱恢復)到早期的版本。此類部署配置的回滾應當十分謹慎，以消除安全問題，直至開發團隊對其進行妥善的處理。在實踐中，我們最好通過保留舊版本的工件，直至新的部署被批準用于生產環境的回滾。

實施持續的漏洞掃描和監控

監控和測試CI/CD管道中的每個資源也是非常必要的。我們可以使用漏洞掃描工具利用已知漏洞的數據庫，去測試應用代碼、環境配置、以及部署腳本，進而消除潛在的受攻擊媒介。此類掃描和監控工具應當被部署在整個SDLC中，以便在漏洞發生時，及時發現漏洞，進而避免漏洞被利用。

持續清理冗余資源

CI/CD管道通常使用不可變的基礎架構來構建，這些基礎架構在運行了特定的進程之后就會終止。由于攻擊者可以使用臨時資源的開放端口，來作為跳板進入已部署的環境，因此我們有必要合理地管理這些資源，以減少安全漏洞。在實踐中，DevOps團隊應確保在資源被終止后，及時清理包括容器、服務和虛擬機在內的所有臨時資源。

CI/CD的安全層

管理CI/CD安全通常需要一種全面的、多層次的方法，以加強管道上每個節點的防御能力。下圖展示了該安全層的邏輯結構：

安全CI/CD管道中的安全層

漏洞掃描

如前所述，漏洞掃描涉及到使用已知的威脅數據庫，來識別和修復整個CI/CD管道中的安全漏洞。自動化的測試可以掃描指定的應用程序和部署環境，以識別和分類代碼、基礎設施、以及第三方服務中的弱點。

靜態安全測試

此類軟件組合分析技術，旨在識別內部開發團隊編寫出的代碼中的潛在漏洞。安全團隊可以經常使用這些工具，來開發測試用例，進而在部署新的應用程序構建之前，查明不安全的代碼漏洞。

運行時安全

該層面主要依賴運行時應用自我保護(runtime application self-protection，RASP)工具，來實時檢測生產環境中應用所面臨的安全威脅。此類工具會掃描配置模板，并持續測試已部署的環境狀態，進而通過比較，來識別和響應任何運行時威脅。

審計和監控

應用和基礎設施的日志，會持續跟蹤和存儲應用與部署的相關數據。審計主要涉及到通過分析日志，以推斷出可用于改善應用安全態勢的模式。我們可以通過部署診斷工具，來監控和分析指標，以獲悉與目標系統相關的問題。

持續的審計和監控可幫助開發團隊，構建出對應的應用場景，并預測基線用戶的行為。安全團隊可以通過分析那些偏離已有基線的用戶行為，來識別安全威脅。

結論

眾所周知，任何有權訪問源代碼存儲庫或容器注冊表的人，都可以在CI/CD管道中運行代碼，因此DevOps工作流帶有固有的安全隱患。根據最近的一項調查預計，大約55%的組織出于安全考慮，推遲了??其應用程序的推出??。雖然DevOps框架可以增強協作和自動化，但組織必須采用帶有高級策略和工具的持續安全模型，來確保CI/CD管道在所有層面上都有統一的安全態勢。

譯者介紹

陳峻 (Julian Chen)，51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。

原文標題：??Securing Your CI/CD Pipeline??，作者：Sudip Sengupta