SLSA (Supply-chain Levels for Software Artifacts) について

SLSA (Supply-chain Levels for Software Artifacts) についてSBOMとの関係を調べるうちにいくつかわかったこと・翻訳などをまとめておきます。

SLSAとは

　SLSAとはGoogleが提唱しているソフトウェアのサプライチェーンにおける完全性を確保するためのセキュリティフレームワークです。SLSAの主な目的は、ソフトウェアの開発から顧客が使用までの一連の流れであるサプライチェーンを保護し、改ざんやインシデントからソフトウェアを保護することです。SLSAのフレームワークは、成熟度によってレベル1から4に分類されており、各段階ごとにソフトウェア・サプライチェーンの安全性を強化する事項が定められています。

SLSAが必要な理由

　ここら辺はGoogleの「What is SLSA?」の翻訳＋抜書きになりますので先にご承知おきください。

　ソフトウェア開発において、脆弱性の検出やソースコード分析のセキュリティ技術は不可欠ですが、実際にはファジングや脆弱性スキャンが完了した後でも、意図せず・あるいは内外の脅威によりコードが変更される可能性があります。ソースからビルド／パッケージ化／配布まで、一般的なソフトウェアサプライチェーンの各リンクにコード変更のリスクが存在します。サプライチェーンに弱点があると、実行するコードが実際にスキャンしたコードであるかどうかの信頼性が損なわれます。

　SLSAは、ソースからバイナリまでの自動化処理をサポートするように設計されており、ソフトウェアサプライチェーンの複雑さに関係なく、改ざんから保護します。結果、SLSAはソースコードに対して行った分析やレビューが配布プロセス後のバイナリにも適用できる様に信頼性を高めてくれます。

SLSAとSBOM

　SBOMを「原材料を示すリスト」と考えると、SLSAは原材料リスト(SBOM)の信頼性を高める「食品安全取り扱いガイドライン」であると考えることができます。

　包装工場で変質しないように工場の環境を清潔に保つための基準から、食料品店の棚に並ぶ商品の中身が変えられないように蓋にシールを貼る要件まで、食品安全フレームワーク全体は、原材料リストが実際に購入する商品と一致することを消費者に保証します。

　同様にSLSAフレームワークは、ソフトウェアの製造プロセスの各ステップを保護するためのガイドラインと、改ざん防止の証拠を提供します。つまりソフトウェア製品に予期しないものが追加されていないことだけでなく、成分ラベル(SBOM)自体が改ざんされておらず、ソフトウェアの内容を正確に反映していることもわかります。このように、SLSAは次のリスクからの保護を行います。

コードの改ざんのリスク
想定されるCI/CDプラットフォームでビルドされなかった成果物が混入されているリスク
ビルドプラットフォーム自体に対する脅威

SBOMとSLSAがそれぞれどういう状況で役立つのかを簡単に説明します。

SBOMは部品表・成分表の様なものですので、例えば「 log4jの脆弱性の影響を受けるか?」のようなケースで役立ちます。
SLSA は製造プロセスの保護ですので、例えば「このソフトウェアが製造プロセスの各ステップで改竄されていないかどうか信頼できるか?」という様なケースで役立ちます。さらにSLSAは開発者にとって「この開発中のソフトウェアは、セキュアソフトウェア開発フレームワークの要件を満たす準備ができているか?」という様な場合にも使うことができます。

　結局のところ、SBOMとSLSAは補完的なものになります。

　メインのSLSAルールでは、改ざん防止の来歴(Provenance)データ（成果物のリリースプロセスを実行した人物、生産に使用された材料、成果物が改ざんから保護されていたかどうかを証明するメタデータ）を生成する必要がありますので、成果物のSLSA Provenanceがあると、SBOMの品質と整合性（SBOM は正確性、完全性、信頼性が重要なため）が向上します。

画像はGoogle「SBOM + SLSA: Accelerating SBOM success with the help of SLSA」より転載。SBOM 情報の従来のソースは緑色。SLSAを使用することでビルド情報もSBOMに含めることができる(赤い三角形はSLSAが対処するサプライチェーンへの脅威を示している。)

SLSAのトラックとレベル

　SLSAには「トラック」と「レベル」の概念があります。

SLSAトラックは、ビルドトラックなど、サプライチェーン特有の側面に焦点を当てています。SLSA v1.0は単一のトラック (ビルド) のみで構成されていますが、SLSAの将来のバージョンでは、ソースコードの管理方法など、ソフトウェアサプライチェーンの他の部分をカバーするトラックが追加される予定です。
各トラックでは、レベルが上がるにつれてセキュリティ対策が強化されます。レベルが高いほど、サプライチェーンの脅威に対する保証は強化されますが、実装コストが高くなります。SLSAレベルが低いほど導入が簡単になるようになっていますが、セキュリティの保証は低くなっていきます。SLSA 0は、どのSLSAレベルにもまだ達していないソフトウェアを指します。現在、SLSAビルドトラックにはレベル 1 から 3 までが含まれますが、将来の改訂ではさらに高いレベルも可能になる予定です。

Track/Level	要件	焦点を当てているもの
Build L0	無し(none)	無し(n/a)
Build L1	パッケージがどのように構築されたかを示す来歴(Provenance)	間違いや文書
Build L2	ビルドプラットフォームホストによって生成され・署名された来歴(Provenance)	ビルド後の耐タンパ性
Build L3	セキュリティのハードニングがなされたビルドプラットフォーム	ビルド中の耐タンパ性

表はGoogle「Security Level」より引用。SLSA ver 1.0 ではビルドトラックに重点が置かれています。ソーストラックが将来のバージョンで追加される可能性があります。

まとめ

　SLSAとSBOMの関係を整理したく、簡単に「SLSAとは」のところを翻訳しがてらまとめてみました。SBOM周りは大分色々なベンダーが手掛けていますが、その運用やSLSAの様なフレームワークに関しては未だあまり見かけませんので、これを機会に勉強していけたらと思います。

参考文献

Google「What is SLSA?」
Google「SBOM + SLSA: Accelerating SBOM success with the help of SLSA」
Google「Security Level」