隨著軟體供應鏈攻擊浪潮愈演愈烈，Google 發布了一系列指南來確保軟體包的完整性，旨在防止影響軟體供應鏈的未經授權的代碼修改，新的 Google SLSA 框架（Supply-chain Levels for Software Artifacts 軟體構件的供應鏈級別）通過識別 CI/CD 流水線中的問題并減小影響，為企業實作更安全的軟體開發和部署流程提供建議，
?
?
Google 的 SLSA 框架
SLSA 是一個端到端框架，旨在確保軟體開發和部署程序的安全性，專注于緩解由于篡改源代碼、構建平臺或構件倉庫而產生的威脅，這些要求源于 Google 的 BAB （Binary Authorization for Borg），該授權已經使用了8年多，并且對于 Google 的所有生產作業負載都是強制性的，
?
SLSA 側重于以下兩個主要原則，即所有軟體工件都應當：
-
非單邊： 未經至少一個其他“受信任的人”的明確審查和批準，任何人都無法修改軟體供應鏈中任何地方的軟體工件，目的是預防或盡早發現風險，
-
可審計： 軟體構件足夠安全透明，來源與依賴項可溯源，主要目的是自動分析來源和依賴關系以及一些特定調查，
?
雖然無法做到萬無一失，但這兩個原則可以幫助企業有效避免和緩解各種篡改和其他供應鏈攻擊帶來的風險和影響，
?
?
CI/CD 流水線流程
軟體供應鏈是創建和發布軟體構件的一系列步驟，上圖展示了源代碼、構建、依賴項和包的流程關系，而每個源代碼、構建和軟體包都可以托管在一個平臺上，例如源代碼管理 （Source Code Management） 或持續集成/持續部署 （CI/CD），
?
?
SLSA 框架下的4個安全級別
安全級別越高，實施的安全控制越強，攻擊者越難破壞代碼：
- SLSA 1： 要求構建程序完全腳本化/自動化并生成出處
- SLSA 2： 要求使用版本控制和托管生成服務來生成身份驗證的出處
- SLSA 3： 要求源和構建平臺符合特定標準，以保證源的可審計性和來源的完整性
- SLSA 4： 要求對所有更改進行兩人審查，并采用封閉的、可重現的構建程序
?
?
將供應鏈保護提升到新的水平
Google 的 SLSA 框架是朝著提高認識和建立標準的正確方向邁出的一步，這些標準將幫助企業控制供應鏈風險，根據 CI/CD 流程（上圖）和 SLSA 建議，我們可以將風險定義為以下三個階段：
?
代碼階段風險：
-
提交惡意代碼 – 將易受攻擊的代碼上傳到公司的源代碼管理系統，其中可能包含漏洞或受損的代碼包，
-
攻陷源代碼管理系統 – 源代碼管理系統中的錯誤配置或漏洞，可能導致代碼、機密和用戶資訊泄露和被盜，
-
使用惡意依賴項 - 可能允許未經授權訪問管道或導致暴露/泄漏代碼，
?
構建階段風險：
-
使用惡意代碼 – 注入錯誤代碼，并在設定流水線流程之外，未經適當的審查和批準而出發的構建程序，
-
攻陷構建平臺 – 利用漏洞或錯誤的配置來獲得對構建服務器的訪問權，并操縱構建程序及其輸出，
-
已泄露的依賴項 – 利用已泄露或易受攻擊的依賴項來獲取訪問權限或操作構建服務器，
?
分發階段風險：
-
繞過 CI/CD – 將惡意構件上傳到 Artifactory，繞過 CI/CD 流程，使客戶暴露于惡意軟體包內，
-
使用惡意包 – 改變系統流程，獲得對構件的訪問權，以便上傳、替換或竊取構件，
?
?
保護軟體供應鏈
保護軟體開發等復雜和動態的程序免受供應鏈攻擊，需要全面的安全解決策略，該策略需要考慮到在工具，源代碼和流程，構建和分發階段中面臨的各種風險，正如 SLSA 指南所強調，實施強大的安全防護策略可強化流水線安全狀況，使攻擊者難以破壞基礎架構、流程或代碼，
?
在過去，我們看到了各類 DevOps 環境中的源代碼泄漏，資產受損和漏洞，這是 CI/CD 流水線上薄弱的安全措施導致的直接結果，微軟、Rapid7、Monday.com、Codecov、SolarWinds 等知名企業成為針對軟體供應鏈攻擊的受害者，在業內和社會引起高度關注，
?
隨著惡意攻擊者發現開發環境可以作為一種簡單且高度可利用的攻擊媒介，企業必須對其開發環境給予更嚴格的安全防護措施，來阻止惡意的軟體供應鏈攻擊，在 SLSA 框架下采用全面的安全策略，提供對 CI/CD 流水線的端到端可見性和控制，并將此作為流水線的一部分進行集成，來實作全方位安全保護，
?
參考鏈接：
Supply-chain Levels for Software Artifacts
https://github.com/slsa-framework/slsa
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/498799.html
標籤：訊息安全
上一篇：攻防世界pwn題：warmup