By HireHackking in HACKER
· 3 views
1.前言在敏捷開發的模式下，應用程序會通過DevSecOps 的敏捷軟件開發生命週期（SDLC）範式進行開發，並使用持續集成/持續交付（CI/CD）管道的流程。
然而，在軟件開發、供應和交付運營中涉及的數字應用、基礎設施服務和供應鏈數據等各種活動中（這些活動共同構成了數字供應鏈），攻擊者可以通過鏈條中的一個薄弱點，隱蔽地引入攻擊載體，對數字供應鏈進行攻擊，繼而引發廣泛的後果。
日前，美國國家標準與技術研究院（NIST）發布了特別出版物《DevSecOps CI/CD 管道中软件供应链安全的集成策略》 (NIST SP 800-204D)。本文基於此文，引發深入討論，闡述如何將數字供應鏈安全保證措施集成到CI/CD 管道中以保護底層活動完整性，從而確保將源代碼帶入構建、測試、打包和部署階段的CI/CD 管道活動不會受到損害。
2.數字供應鏈(DSC)的定義從高層次上講，軟件供應鍊是創建、轉換和評估軟件製品質量和政策一致性的一系列步驟的集合。這些步驟通常由使用和消費製品以生成新製品的不同參與者執行。例如，構建步驟使用一系列人工製品作為工具（如編譯器和鏈接器），並消耗人工製品（如源代碼）來生成新的人工製品（如編譯後的二進製文件）。
我們以往所熟知的軟件供應鍊主要是基於傳統軟件供應關係，通過資源和開發供應過程將軟件產品從供方傳遞給需方的網鏈系統。而這樣的定義如今已無法適應數字經濟時代由於技術創新帶來的產品服務、基礎設施和供應鏈數據等供應對象及供應關係的新變化。
因此，數字供應鏈的概念在軟件供應鏈的基礎上應運而生。數字供應鍊主要由數字應用、基礎設施服務、供應鏈數據三大主要供應對象組成。其中，數字應用包括軟件、Web、固件等，基礎設施服務是指雲服務、IT託管服務等，而供應鏈數據則包括基礎數據和敏感信息。
相較於軟件供應鏈，數字供應鏈更加明確的指出了基礎設施服務和供應鏈數據代表產品服務在供應活動中發揮的建設作用及重要性。
圖1：在數字供應鏈步驟中不同要素之間的互動
數字供應鏈中的大多數活動都會對最終的應用產品產生重大影響。因此，每項活動的安全性對於最終結果的安全性至關重要。在供應鏈引入、生產鏈、供應鏈交付運營的過程中，構建、打包和交付數字應用，重新打包和容器化以及基礎設施服務安全上線運營等都是數字供應鏈的核心範疇。
3.數字供應鏈安全：重點內容和風險因素3.1數字供應鏈安全的重點內容在研國標《信息安全技术 软件供应链安全要求》 明確了軟件供應鏈安全保護目標，分別包括提升軟件產品或服務中斷供應等風險管理能力、提升供應活動引入的技術安全風險管理能力、提升軟件供應鏈數據安全風險管理能力。
數字供應鏈安全作為軟件供應鏈安全概念的關鍵演進，其發展建立在軟件供應鏈安全的基礎之上。相比之下，數字供應鏈安全涉及的保護範圍更廣，保護對象的內涵更加豐富。數字供應鏈安全的重點內容包括：
•數字應用安全：圍繞數字應用的開發全流程與上線運營整體階段，包含應用安全開發（DevSecOps/SDL)、開源治理（合規/風險）和數字免疫（防禦左移，代碼疫苗）。
•基礎設施服務安全：包含雲原生安全（CNAPP）和供應鏈環境安全。
•供應鏈數據安全：包含API安全和應用數據安全。
3.2數字供應鏈中的風險因素數字供應鏈的風險因素通常包括：
•開發環境中的漏洞：開發環境對數字供應鏈的安全性構成了根本性的風險，不應將其作為構建流程的一部分加以信任。成熟的SDLC 流程只有在代碼審查和掃描程序到位後，才會將代碼和資產納入其軟件配置管理(SCM) 主線和版本分支。
•威脅參與方：一般是尋求以特權方式訪問數字供應鏈的外部攻擊者，或心懷不滿、製造內部威脅的員工或供應商；非惡意的威脅參與方也可能影響供應鏈的安全，如軟件工程師由於缺乏工具或為了方便使用而故意隱瞞，導致機密管理不善。
•攻擊向量：包括惡意軟件、代碼重用（代碼級別的引入）、依賴庫和依賴組件的引入、社會工程學、網絡攻擊、物理攻擊等。
•攻擊目標（即資產）：包括源代碼、憑證、敏感信息，如個人身份信息(PII)、受保護健康信息(PHI)、知識產權(IP)、加密材料（如軟件成品簽名密鑰）和專有信息等。
•利用類型：入侵行為通常包括在數字供應鏈中註入易受攻擊或惡意的依賴項、可訪問其他系統的被盜憑證、將惡意代碼或漏洞代碼注入資源庫、通過提交合併請求竊取機密等。
4.CI/CD 管道的安全目標和可信實體在CI/CD 流水線中，實現數字供應鏈安全的一個共同方法是生成盡可能多的出處數據。出處數據與系統或系統組件的起源、開發、所有權、位置和更改的時間順序相關聯，包括促成這些更改或修改的人員和流程。在生成這些數據的同時，還應有相應的機制對其進行驗證、認證，並在決策中加以利用。
總的來說，CI/CD 管道需要添加的安全保證措施：
•在開發和部署第一方軟件時採用的數字供應鏈內部安全做法；
•在採購、集成和部署第三方軟件（即開源和商業軟件模塊）時採用的安全做法。
4.1 CI/CD 管道的安全目標在CI/CD 管道中應用數字供應鏈安全措施或實踐有兩個安全目標：
1.積極維護CI/CD 管道和構建流程。
2.確保上游源頭和製品（如資源庫）的完整性。
最常見的方法是在CI/CD 平台中引入安全措施，使開發人員能夠自動構建、測試和部署管道。
4.2 CI/CD 管道中需要信任的實體零信任架構側重於保護硬件系統（如服務器）、服務和應用程序本身等資源。訪問這些資產的實體（如用戶、服務和其他服務器）本身並不值得信任，零信任架構的主要目標就是建立這種信任。
在CI/CD 管道中，信任的範圍要大得多，至少需要以下步驟：
•參與執行各種數字供應鏈活動（如供應鏈引入、生產鏈、供應鏈交付運營）的實體應通過驗證憑證進行身份驗證。在認證的基礎上，根據企業業務政策，通過一個稱為授權的過程，為這些實體分配適當的權限或訪問權。
•應通過驗證與之相關的數字簽名來確保人工製品及其存儲庫的完整性。這種完整性保證產生信任。
•在整個CI/CD 系統中，上述信任的建立應該是一個循環往復的過程，因為製品要經過不同的存儲庫才能最終成為最終產品。
•每個構建步驟的輸入和輸出都應經過驗證，以確保預期組件或實體執行了正確的步驟。
表1舉例說明了典型的CI/CD 管道中需要信任的實體。
表1：信任實體
5.將數字供應鏈安全集成到CI/CD 管道中為了概述將數字供應鏈安全集成到CI/CD 管道中的策略，有必要了解這兩種管道各自的流水線及其總體安全目標。
激活CI/CD 管道的前提條件如下：
•加固CI/CD 執行環境（如虛擬機或Pod），減少攻擊面。
•為操作各種CI/CD 管道的人員（如應用程序更新人員、軟件包管理員、部署專家）定義角色。
•確定執行各種任務的細粒度授權，如生成代碼並提交到SCM、生成構建和軟件包，以及檢查各種製品（如構建和軟件包）進出版本庫。
•通過部署適當的工具，實現整個CI/CD 管道的自動化。 CI 和CD 流水線的驅動工具處於更高的級別，會調用一系列特定功能的工具，如用於從版本庫中檢出代碼、編輯和編譯、代碼提交和測試的工具，這包括軟件成分分析SCA工具、靜態應用安全測試SAST和動態應用安全測試DAST等。一般來說，驅動工具或構建控制平面的執行信任度要高於構建等單個功能步驟。
•為應用程序代碼的開發和部署定義CI/CD 管道活動和相關安全要求；基礎設施即代碼，包含部署平台的詳細信息；策略即代碼和配置代碼，指定運行時設置（如另一種標記語言(YAML) 文件）。
5.1 確保CI 管道中工作流的安全CI 管道中的流水線主要包括構建操作、版本庫（公共和私有）的PULL/PUSH操作、軟件更新和代碼提交。
用於安全運行CI 管道的框架的總體安全目標包括：
•同時支持雲原生應用和其他類型應用的能力。
•符合標準的證據結構，如元數據和數字簽名。
•支持多種硬件和軟件平台。
•支持生成證據的基礎設施（例如SBOM 生成器、數字簽名生成器）。
5.1.1 安全構建要在構建過程中獲得數字供應鏈安全保證，需要完成以下任務：
1）指定有關構建的政策，包括使用安全隔離平台執行構建並加固構建服務器，用於執行構建的工具，以及執行構建流程的開發人員所需的身份驗證/授權。
2）使用代理和策略執行引擎等技術執行這些構建策略。
3）確保同時生成構建認證的證據，以證明在軟件交付期間符合安全構建流程。
促進第二項任務的常用技術是將CI 工具的命令與收集證據的功能結合起來，並最終創建整個SDLC 的證據跟踪。
第一類證據來自構建系統本身，它應能確認所使用的工具或流程處於隔離環境中。這可提供內部操作保證。第二類應收集的證據包括最終構建製品、文件、庫和製品中使用的其他材料以及所有事件的哈希值。然後，由構建框架中不受開發人員控制的可信組件使用數字證書對其進行簽名，以創建證書，從而為消費者提供軟件質量的可驗證證明，使他們能夠獨立於軟件生產者驗證該製品的質量，從而為消費者提供保證。在這種情況下，製品是由一系列CI 流程步驟生成的構建。
就'同時生成證據'而言，生成的證據應由信任度或隔離度高於構建本身的流程啟用，以防止篡改。此類證據的生成需要在構建過程中進行驗證。
構建階段的認證由以下部分組成：
1.環境認證：涉及CI 流程發生時的系統清單，一般指運行構建流程的平台。平台的組件（如編譯器、解釋器）必須經過加固、隔離和安全處理。
2.過程認證：涉及將原始源代碼或材料轉化為人工製品的計算機程序（如編譯器、打包工具）和/或對該軟件進行測試的程序（如代碼測試工具）。對於只觀察CI 流程的工具來說，有時很難區分哪些數據應填入流程證明，哪些數據應填入材料認證。執行源轉換的工具讀取的文件可能會影響轉換工具的選擇，也可能包含在轉換本身的輸出中。因此，流程證明的填充應被視為'盡力而為'。
3.材料認證：涉及任何原始數據，可包括配置、源代碼和其他數據（如依賴關係）。
4.製品認證：製品是CI 流程的結果或成果。例如，如果CI 流程步驟涉及在C 語言編寫的源代碼上運行編譯器（如GNU 編譯器集(GCC)），那么生成物就是該源代碼的可執行二進製文件。如果該步驟涉及在同一源代碼上運行SAST 工具，則生成物將是'掃描結果'。生成該製品的步驟可以是最終步驟，也可以是中間步驟。與新生成產品有關的證明屬於人工製品證明類別。
與簽名證據（即認證）及其存儲相關的要求必須包括以下內容：
•認證必須使用安全密鑰進行加密簽名。
•存儲位置必須防篡改，並使用強大的訪問控制加以保護。
這些認證可用於評估政策合規性。政策是一份簽名文件，其中包含了對要驗證的製品的要求。該策略可能包括檢查參與CI 流程的每個職能部門是否使用了正確的密鑰來生成證明，是否找到了所需的證明，以及是否指定了根據相關元數據評估證明的方法。該策略使核查人員能夠在製品生命週期的任何時刻跟踪其合規狀態。
上述能力共同提供了以下保證：
•軟件由授權系統按照正確的步驟順序使用授權工具（如每個步驟的基礎設施）構建。
•沒有證據表明存在潛在的篡改或惡意活動。
5.1.2 對存儲庫進行安全的PULL-PUSH操作數字供應鏈的第一項安全任務是確保源代碼開發實踐的安全。在CI/CD 管道中，代碼駐留在資源庫中，由授權開發人員使用PULL 操作提取、修改，然後使用PUSH 操作放回資源庫。要授權這些PULL-PUSH 操作，需要兩種形式的檢查：
1.授權執行PULL-PUSH操作的開發人員所需的驗證類型。開發人員提出的請求必須與其角色（如應用程序更新者、軟件包管理器）相符。擁有'合併審批'權限的開發人員不能審批自己的合併。
2.代碼庫中代碼的完整性值得信賴，可用於進一步更新。
確保代碼庫中代碼可信度的各種機制包括：
•PULL-PUSH請求1：項目維護者應對推送的變更中涉及的所有製品進行自動檢查，如單元測試、襯墊、完整性測試、安全檢查等。
•PULL-PUSH請求2：只有在對工具源代碼來源的可信度有信心的情況下，才能使用這些工具運行CI 流水線。
•PULL-PUSH請求3：版本庫或源代碼管理系統（如GitHub、GitLab）應a) 在沙箱環境中運行CI 工作流，不允許訪問網絡、任何特權訪問或讀取機密；或b) 具有內置保護功能，可延遲CI 工作流的運行，直至獲得具有寫入權限的維護者批准。當外部貢獻者向公共版本庫提交拉取請求時，這種內置保護就會生效。這種保護的設置應該是最嚴格的，例如'要求所有外部合作者批准'。
•PULL-PUSH請求4：如果源代碼管理系統中沒有內置保護功能，則需要具有以下功能的外部安全工具：
評估和加強SCM系統安全態勢的功能，無論有無策略（如開放策略代理（OPA）），都能評估SCM賬戶的安全設置，並生成一份包含可行建議的狀態報告。
通過檢測和修復錯誤配置、安全漏洞和合規問題，提高源代碼管理系統安全性的功能。
5.1.3 軟件更新期間證據生成的完整性軟件更新過程通常由一類特殊的軟件開發工具執行，該工具被稱為軟件更新系統。對軟件更新系統的威脅主要針對證據生成過程，目的是清除更新的痕跡，阻止確定更新是否合法的能力。
軟件更新系統有多種類型：
•軟件包管理器負責管理系統中安裝的所有軟件
•只負責個別已安裝應用程序的應用程序更新程序
•軟件庫管理器，用於安裝可增加功能的軟件，如插件或編程語言庫。
軟件更新系統的主要任務是識別給定更新票據所需的文件，並下載可信文件。乍一看，建立下載文件信任所需的唯一檢查似乎就是通過驗證與單個文件或軟件包相關的元數據上的簽名來執行的各種完整性和真實性檢查。然而，簽名生成過程本身可能會受到已知攻擊的影響，因此軟件更新系統需要許多與簽名生成和驗證相關的其他安全措施。
為軟件更新系統提供安全保障的不斷發展的框架已將其中許多必要的安全措施納入其規範，並為未來的規範規定了其他一些措施。框架是一套庫、文件格式和實用程序，可用於確保新的和現有軟件更新系統的安全。框架應通過要求在執行簽名操作前滿足第5.1.1節中定義的策略來保護簽名操作。以下是該框架的部分共識目標：
•該框架應能防範對軟件更新系統所執行任務的所有已知攻擊，如元數據（哈希值）生成、簽名過程、簽名密鑰管理、執行簽名的機構的完整性、密鑰驗證和簽名驗證。
•該框架應提供一種方法，通過支持具有多個密鑰和閾值或法定人數信任的角色（旨在使用單個密鑰的最低信任角色除外），將密鑰洩露的影響降至最低。對使用高危密鑰的角色來說，密鑰洩露的影響應該是最小的。因此，在線密鑰（即以自動方式使用的密鑰）不應用於客戶最終信任其可能安裝的文件的任何角色。當密鑰在線使用時，應格外小心保管，例如將其存儲在硬件安全模塊(HSM) 中，並且只有在被簽名的製品通過第5.1.1節中定義的策略時才允許使用。
•該框架必須足夠靈活，以滿足各種軟件更新系統的需求。
•該框架必須易於與軟件更新系統集成。
5.1.4 安全代碼提交代碼提交前應進行適當形式的測試，且必須滿足以下要求：
•SAST 和DAST 工具（涵蓋開發中使用的所有語言）應在CI/CD 管道中運行，並向開發人員和安全人員提供代碼覆蓋率報告.
•如果使用開源模塊和庫，則必須列舉、了解和評估依賴關係（通過使用SCA 工具，如源鑑SCA開源威脅管控平台）。此外，還必須測試它們應滿足的安全條件。依賴關係文件檢測器應檢測所有依賴關係，包括傳遞依賴關係，最好不限制要分析的嵌套依賴關係或傳遞依賴關係的深度。
代碼提交過程中所需的一種安全措施是防止秘密進入提交的代碼。這可以通過對秘密的掃描操作來實現，並產生一種稱為推送保護的功能。該功能應滿足以下要求：
•提交請求1：（例如，個人訪問令牌） 評估已提交代碼是否符合組織政策，包括是否存在密鑰和應用程序編程接口(API) 令牌等機密。檢測到的秘密應通過安全儀錶盤等媒體顯著顯示，並在檢測到違反政策時生成適當的警報，同時記錄補救違反政策的方法。
•提交請求2：分配給管理員的所有版本庫都應啟用推送保護功能。此類保護應包括開發人員身份/授權驗證、強制執行開發人員對代碼提交的簽名以及文件名驗證。
5.2 確保CD管道中流水線的安全以下是CD 過程中應使用的一些盡職調查措施。這些措施可以通過定義允許或不允許部署製品的驗證策略來實施。
•部署請求1：對於已在版本庫中並準備部署的代碼，應調用安全掃描子功能來檢測代碼中是否存在密鑰和訪問令牌等機密。在許多情況下，即使在代碼填充之前，也應掃描版本庫中是否存在秘密，因為根據版本庫的可見性，秘密出現在版本庫中可能意味著憑證已經洩露。
•部署請求2：在合併拉取請求之前，應該可以通過依賴性審查的形式查看任何易受攻擊版本的詳細信息。
•部署請求3：如果已經建立了安全的構建環境和相關流程，那麼就應該可以指定部署的製品（即容器鏡像）必須是由該構建流程生成的，這樣才能允許部署。
•部署請求4：應該有證據表明容器鏡像已進行過漏洞掃描並證明了漏洞發現。漏洞掃描的一個重要因素是運行時間。由於用於掃描製品的工具會不斷更新以檢測新出現的漏洞，因此與過去的掃描結果相比，最近的掃描結果更有可能是準確的，並能提供更好的保證。這種技術可確保只有經過驗證的容器鏡像才能進入環境，並在運行期間保持可信，從而使DevOps 團隊能夠實施主動的容器安全態勢。具體來說，應該可以根據組織定義的策略允許或阻止鏡像部署。
•部署請求5：應定期檢查發行版構建腳本是否存在惡意代碼。需要執行的具體任務包括：
容器鏡像一經構建，甚至在推送到註冊表之前，就應進行漏洞掃描。早期掃描功能也可以內置到本地流水線中。
用於與包含容器鏡像和語言包的資源庫進行交互的工具應能與CD工具集成，從而使所有活動成為自動CD管道的組成部分。
5.2.1 安全CD 管道-GitOps在CI/CD 管道中，構建期間和之後的所有操作都涉及與中央存儲庫（如Bitbucket、GitHub 和GitLab）的交互。這些操作統稱為GitOps，是一種由Argo CD 和Flux 等開源工具推動的自動化部署流程。 GitOps 既適用於基礎架構代碼，也適用於應用代碼，包括提交、分叉、拉取和推送請求。
GitOps 的使用範圍如下：
•將基礎設施作為代碼進行管理
•管理和應用群集配置
•將容器化應用程序及其配置自動部署到分佈式系統。
在部署前創建配置數據、捕獲與特定版本相關的所有數據、運行期間修改軟件以及執行監控操作時，應執行以下數字供應鏈安全任務：
•GitOps請求1：流程應依靠自動化而非手工操作。例如，應避免手動配置數百個YAML 文件來回滾Git 倉庫集群上的部署。
•GitOps請求2：為GitOps 提供便利的軟件包管理器應保存已發佈軟件包的所有數據，包括所有模塊的版本號、所有相關配置文件以及其他適合軟件運行環境的元數據。
•GitOps請求3：不應在運行時手動應用變更（如kubectl）。相反，應該對相關代碼進行更改，並觸發包含這些更改的新版本。這樣才能確保Git 提交始終是集群中運行內容的唯一真實來源。
•GitOps請求4：由於Git 倉庫包含應用程序定義和配置代碼，因此應自動提取並與這些配置的指定狀態進行比較（即監控和補救漂移）。對於任何偏離指定狀態的配置，可執行以下操作：
管理員可以選擇自動將配置重新同步到定義的狀態。
應就差異發出通知，並進行人工補救。
5.3 數字供應鏈CI/CD 管道安全-實施策略如果不對基本業務流程和運營成本造成巨大影響，所有企業都不可能一次性實施數字供應鏈安全所需的大量步驟。相反，提供數字供應鏈安全性的解決方案可大致分為以下幾類：
1.通過與DevSecOps 管道中每項任務相關的功能確保數字供應鏈安全的解決方案：
a.通過確保不被篡改的構建管道來驗證軟件的正確構建，例如提供對構建過程中使用的依賴關係和步驟的可驗證可見性，因為被破壞的依賴關係或構建工具是中毒流水線的最大來源。
b.為交付流水線的每個步驟指定核對清單，以便為實施提供指導，並檢查和執行對核對清單遵守情況的控制。
2.通過數字簽名和證書確保完整性和出處的解決方案。
3.確保運行代碼為最新代碼的策略，如製定'構建期限'（即超過一定期限的代碼不應啟動），以盡可能使生產過程與軟件源中已提交的代碼保持一致。
4.保護CI/CD 客戶端，防止惡意代碼竊取機密信息（如專有源代碼、簽名密鑰、雲憑證）、讀取可能包含機密的環境變量，或將數據外洩到敵方控制的遠程端點。
6.結語敏捷開發模式下數字應用以最快速度將代碼從IDE或Git存儲庫帶到生產環境中，加快了部署速度，提升了業務系統上線的效率，但數字供應鏈的安全性對於敏捷開發範式來說同樣至關重要，任何一個漏洞都可能造成巨大的損失。
作為數字供應鏈安全開拓者和DevSecOps敏捷安全領導者，懸鏡將持續帶來專業的國際化視角，與行業同仁及用戶共同探討交流，踐行網絡安全社會責任，守護中國數字供應鏈安全。
Recommended Comments