很多 谷歌開發者介紹 “SLSA” （軟件工件的供應鏈級別）其目的是照顧 發展基礎設施保護 在產品的編碼、測試、構建和分發階段進行的攻擊。
開發者 提到開發過程越來越複雜並且依賴第三方工具，這為促進攻擊創造了有利條件，這些攻擊與最終產品中的漏洞的識別和利用無關，而是與開發過程本身的妥協有關。
關於 SLSA
值得一提的是，SLSA 注重以下兩個基本原則：
不是單方面的：未經至少一位其他“受信任的人”的明確審查和批准，任何人都不得修改軟件供應鏈中任何地方的軟件工件。 [^1] 目的是預防、威懾或及早發現風險/不良變化。
可審計：軟件工件可以安全、透明地追溯到原始的、人類可讀的來源和依賴項。 主要目的是自動分析來源和依賴性以及臨時調查。
要阻止標記的威脅， SLSA 提供了一套指南和工具來自動創建用於審計的元數據。 SLSA 概述了常見的攻擊方法並引入了保護層的概念。
每一層都有特定的基礎設施要求，以確保開發中使用的工件的完整性，即 支持的 SLSA 級別越高，部署的防禦就越多 並且基礎設施將得到更好的保護，免受典型攻擊。
SLSA 1 級
在這個層面上 要求構建過程完全自動化並生成元數據 （“來源”）有關如何收集工件的信息，包括源、依賴項和構建過程信息（提供了一個示例元數據生成器用於審核 GitHub 操作）。 SLSA 1 不包含針對惡意更改的保護元素，但僅以最簡單的方式識別代碼，並為漏洞管理和風險分析提供元數據。
SLSA 2 級
這裡，第一層通過要求使用源控制系統和構建生成經過身份驗證的元數據的服務來擴展。 指某東西的用途 SLSA 2 允許追踪代碼源並防止未經授權的更改 在代碼中，在使用可信彙編服務的情況下。
SLSA 3 級
從這一點上o 確認源代碼和構建平台符合標準要求 確保可以審核代碼並確保所提供元數據的完整性。 審核員應該能夠證明平台是否符合標準的要求。
SLSA 4 級
這是最高級別，它通過添加更嚴格的要求來補充之前的級別，其中必須由兩個不同的開發人員強制審查所有更改，所有構建步驟、代碼和依賴項必須完全聲明，所有依賴項必須單獨簽出和檢查，並且構建過程必須離線完成。
使用可重複的構建過程還可以重複構建過程並確保可執行文件是從提供的源編譯的。
除了它 該框架考慮了 8 種類型的攻擊 與在產品代碼的開發、編譯、測試和分發階段引入惡意更改的威脅有關。
考慮的攻擊類型 分別是：
1.- 在源代碼中包含包含後門或導致漏洞的潛在錯誤的更改。
2.- 源代碼控制平台的承諾。
3.- 在代碼傳輸階段進行更改到編譯或持續集成系統（收集與存儲庫代碼不對應的代碼）。
4.- 搭建平台的承諾
5.- 通過低質量依賴項傳播惡意代碼。
6.- 加載 CI/CD 系統中未生成的工件。
7.- 軟件包存儲庫的承諾。
8.- 用戶混淆安裝錯誤的軟件包。
終於 如果您想了解更多，您可以查看詳細信息 在下面的鏈接中。