サプライチェーン
SLSAとは？
SLSA（「サルサ」と発音）は、Supply-chain Levels for Software Artifactsの略です。ソフトウェアが、提供者の主張どおりの方法で、主張どおりのソースから、途中で改ざんされることなくビルドされたことを証明するためのセキュリティフレームワークです。そのレベルは、提供者には従うべき道筋を、利用者にはそれを求める手段を与えます。
更新日
SLSAが解決する問題
ソースコードを1行残らずレビューしても、別のものを出荷してしまう可能性があります。ユーザーが実行するのはビルドの出力だからです。 SolarWindsの事例のようにビルドが侵害されれば、クリーンなソースから汚染されたリリースが生まれます。SLSAが焦点を当てるのはまさにそのギャップです。この成果物がこのソースから、このプロセスを経て作られたことを、誰もが検証できるでしょうか。
SLSAのレベル
SLSAは要件をトラックに分けて整理しています。現行バージョンの1.2には、BuildトラックとSourceトラックがあります。 Buildトラックには4つのレベルがあります。
| レベル | 名称 | 要件 | 得られるもの |
|---|---|---|---|
| Build L0 | 保証なし | なし | L0はSLSAがない状態 |
| Build L1 | 来歴が存在する | 一貫したビルドプロセスと、ビルドプラットフォームが生成して利用者に提供する来歴 | ミスの防止に役立つが、回避や偽造は容易 |
| Build L2 | ホスト型ビルドプラットフォーム | 来歴を生成・署名するホスト型プラットフォームでビルドを実行し、利用者がそれを検証する | 来歴の偽造には明確な攻撃が必要になる |
| Build L3 | 強化されたビルド | 実行同士が互いに隔離され、署名用のシークレットにユーザー定義のビルドステップからアクセスできない | 来歴の偽造には脆弱性の悪用が必要で、ほとんどの攻撃者には困難 |
レベルは最大化すべき評点ではありません。各レベルは特定の脅威から守るものなので、自社のリスクに合ったレベルを選んでください。ホスト型CIサービスを使っているオープンソースのメンテナーであれば、多くの場合それほど手間をかけずにL2に到達できます。
来歴とは？
来歴とは、成果物がどのように作られたかの記録です。SLSAでは、どのプラットフォームが、どのソースから、どのプロセスで、どの最上位の入力を使ってビルドしたかを示します。L2以上の来歴には署名が付くため、利用者はそれがビルドプラットフォームから発行され、改ざんされていないことを確認できます。
SBOMを材料表とすれば、来歴はその料理がどこでどのように調理されたかにあたります。両者は異なる問いに答え、互いをうまく補完します。SBOMは中に何が入っているかを列挙し、来歴は成果物がどこから来たかを示します。
SLSAの導入方法
- CIで、毎回同じ方法でビルドする。ノートPCからのリリースをやめましょう。L1に到達するための作業の大半はこれです。
- 来歴を生成する。GitHubでは、artifact attestationsで署名付きの来歴を生成できます。GitHub ActionsでattestationsがSBOMとどう連携するかをご覧ください。
- 意味のある場所で検証する。誰も確認しない署名付きの来歴は、誰も守りません。デプロイステップやアドミッションコントローラーに検証を追加してください。
- ビルドを強化する。実行を隔離し、署名鍵をビルドステップから遠ざけます。ランナーセキュリティの比較をご覧ください。
- 依存先に求める。npmなどのレジストリが現在対応しているように、来歴を公開しているパッケージを優先しましょう。
SLSAが対象としないもの
- 脆弱性。完璧にビルドされた成果物にも欠陥は含まれえます。SLSAはコードが安全かどうかについては何も示しません。
- 悪意のあるソース。攻撃者がリポジトリにコミットした場合、来歴はそのコードのビルドを忠実に記録します。 Sourceトラックはこの問題の一部に対処します。
- ビルドが取り込んだもの。来歴に記載されるのは最上位の入力です。Buildトラックには依存関係の完全な一覧を求める要件はなく、それはSBOMの役割です。
- 信頼された内部関係者。xzのバックドアは信頼されたメンテナーを通じて持ち込まれたもので、SLSAだけでは防げなかったでしょう。
SLSAと他のフレームワーク
SLSAはビルドの完全性を深く掘り下げます。NIST SSDFははるかに範囲が広く、セキュアな開発全体を対象とし、SLSAの来歴が支えるリリースの保護とアーカイブに関するプラクティスも含みます。SLSAはOpenSSFのプロジェクトであり、多くのチームが両者を併用しています。全体像については、ソフトウェアサプライチェーンセキュリティとはをご覧ください。
CRACIの位置付け
CRACIは署名付きの来歴を生成せず、SLSAレベルを主張することもありません。必要な場合は、GitHubのartifact attestationsや同様のサービスをご利用ください。CRACIが加えるのは、SLSAが対象外とするもの、つまり各GitHub Actionsジョブが取り込んだものの完全な記録です。各ジョブは専用の隔離された仮想マシンで実行され、取得されるすべてのパッケージがSBOMに記録され、エグレスポリシーがビルドに不要な接続をブロックします。ビルド時のSBOM生成をご覧ください。
SLSAに関するよくあるご質問
SLSAは何の略ですか？
Supply-chain Levels for Software Artifactsの略で、「サルサ」と発音します。
SLSAのレベルにはどのようなものがありますか？
Buildトラックには4つあります。L0は保証なし、L1は来歴が存在する、L2は来歴に署名するホスト型ビルドプラットフォーム、L3は実行の隔離と署名用シークレットの保護を備えた強化されたビルドです。バージョン1.2ではSourceトラックも追加されています。
SLSAの来歴とは何ですか？
成果物がどのようにビルドされたか、つまりどのプラットフォームで、どのソースから、どのプロセスで、どの最上位の入力を使ったかの記録です。Build L2以上では署名が付くため、利用者が検証できます。
SLSAとSBOMの違いは何ですか？
SBOMはソフトウェアの中に何が入っているかを列挙します。SLSAの来歴は、それがどのように、どこでビルドされたかを記述します。一般的には両方が必要です。
SLSAは義務ですか？
いいえ。OpenSSFコミュニティによる任意のフレームワークです。顧客や組織からレベルを求められることはありますが、法律ではありません。
どのSLSAレベルを目指すべきですか？
まずはCIでビルドして来歴を生成することでBuild L1から始め、次にホスト型プラットフォームでL2に進みます。多くのチームはL2に素早く到達できます。L3は、多くの人が依存するリリースや高いリスクを伴うリリースに適しています。