SLSAはサプライチェーン・セキュリティをレベル化することで採用可能にした

SolarWindsやCodecovなどビルドチェーンへの攻撃を経て、ソフトウェアの利用者は、成果物が期待された供給元とビルドプロセスから生まれたものかを知る必要があった。バイナリ単体ではその問いに答えられなかった。

SLSAの打ち手は、ただちに完全性を求めることではなかった。Googleの2021年の提案は、来歴情報を生成する自動ビルドから始まり、より強固なビルド分離、レビュー、再現性へと段階的に上がっていく、漸進的に採用可能な4つのレベルを描いた。

v1.0仕様ではこれがトラックとレベルへと洗練され、生産者、利用者、インフラ提供者に向けた共通の語彙、チェックリスト、証拠モデルとなった。この形式が支持を得たのは、セキュリティをオール・オア・ナッシングとして扱うのではなく、部分的な前進を可視化できるようにしたからである。

完全性をスイッチではなくはしごにした

レベルによって、組織はすべての依存関係が完全であるかのように装うことなく、特定の完全性の態勢を表明できるようになった。

来歴情報により、ビルドプロセスをポリシーエンジンや利用者が検証できるようになった。

このフレームワークは、抽象的なサプライチェーン・リスクを、ソース、ビルド、配布に関する具体的な統制へと対応づけた。

下位のレベルは、いきなり最高基準へ飛び移れないプロジェクトにアップグレードの道筋を用意した。

理想的な標準がほとんどの利用者にとって高価すぎる場合、採用はリスクをなお低減する部分的な保証を明示することから始められる。

SLSAはソフトウェア成果物の完全性を語る共通言語となった。そのレベルは現在、SBOM、Sigstore、in-totoの証明と並んで、パッケージが期待されたシステムによって期待されたソースからビルドされたかどうかを判断するために用いられている。