解決方案
在 SolarWinds、Codecov 及其他建置鏈攻擊之後,軟體消費者需要知道產物是否來自預期的來源與建置流程。單憑一個二進位檔無法回答這個問題。
SLSA 的做法並非要求立即達到完美。Google 於 2021 年提出的方案描述了四個可逐步採用的等級,從產生來源證明的自動化建置開始,逐步提升至更強的建置隔離、審查與可重現性。
v1.0 規格將其細化為軌道與等級:一套供生產者、消費者與基礎設施提供者共用的詞彙、檢查清單與證據模型。此格式之所以勝出,在於它讓部分進展變得可辨識,而非將安全視為全有或全無。
達成了什麼
讓完整性成為階梯,而非開關
為何有效
分級讓組織能夠宣稱特定的完整性態勢,而不必假裝每個相依項目都完美無缺。
來源證明讓建置流程可被政策引擎與消費者檢查。
此框架將抽象的供應鏈風險對應到具體的來源、建置與散布控制措施。
較低的等級為無法直接跳至最高門檻的專案創造了升級路徑。
可應用之處
當理想標準對大多數使用者而言過於昂貴時,採用可以從指明仍能降低風險的部分保證開始。
後續發展
SLSA 成為軟體產物完整性的共通語言。其等級如今與 SBOM、Sigstore 及 in-toto 證明並用,以判定某個套件是否由預期系統從預期來源建置而成。
追溯依據
參考來源
- Introducing SLSA, an End-to-End Framework for Supply Chain Integrity Google Online Security Blog · security.googleblog.com ·
- About SLSA SLSA Specification 1.0 · slsa.dev