在 SolarWinds、Codecov 及其他建置鏈攻擊之後,軟體消費者需要知道產物是否來自預期的來源與建置流程。單憑一個二進位檔無法回答這個問題。

SLSA 的做法並非要求立即達到完美。Google 於 2021 年提出的方案描述了四個可逐步採用的等級,從產生來源證明的自動化建置開始,逐步提升至更強的建置隔離、審查與可重現性。

v1.0 規格將其細化為軌道與等級:一套供生產者、消費者與基礎設施提供者共用的詞彙、檢查清單與證據模型。此格式之所以勝出,在於它讓部分進展變得可辨識,而非將安全視為全有或全無。

讓完整性成為階梯,而非開關

分級讓組織能夠宣稱特定的完整性態勢,而不必假裝每個相依項目都完美無缺。

來源證明讓建置流程可被政策引擎與消費者檢查。

此框架將抽象的供應鏈風險對應到具體的來源、建置與散布控制措施。

較低的等級為無法直接跳至最高門檻的專案創造了升級路徑。

當理想標準對大多數使用者而言過於昂貴時,採用可以從指明仍能降低風險的部分保證開始。

SLSA 成為軟體產物完整性的共通語言。其等級如今與 SBOM、Sigstore 及 in-toto 證明並用,以判定某個套件是否由預期系統從預期來源建置而成。

追溯依據

參考來源

  1. Introducing SLSA, an End-to-End Framework for Supply Chain Integrity Google Online Security Blog · security.googleblog.com ·
  2. About SLSA SLSA Specification 1.0 · slsa.dev