セキュリティレベル

SLSAは、完全性（integrity）をどこまで強く保証するかに応じて、一連のレベルに分けられています。 これにより、ソフトウェアが改ざんされておらず、ソースまで確実にトレースして戻れるという確信を得ることができます。

このページは、SLSAレベルの理解に役立つ概要であり、各レベルの目的と保証内容を記載しています。 各レベルの規範的な要求事項については、要求事項を参照してください。

SLSAとは何か？

SLSAは段階的に採用可能なセキュリティガイドラインのセットで、業界で一般に合意された意見をもとに確立されました。 SLSAで提示される標準は、ソフトウェア製作者と利用者の両方に対するガイドとなる原則です。 製作者は自身のソフトウェアをよりセキュアにするためのガイドラインに従うことができ、利用者はソフトウェアパッケージのセキュリティに対する姿勢を基に判断を下すことができます。 SLSAの4つのレベルは、低い方から段階的になっていて対応を始めやすいように、またそれぞれ完全性に対する特定の攻撃が防止されるように設計されています。 SLSA 4は理想的な最終状態を表し、それより低いレベルは、対応するintegrityの保証にあわせたマイルストーンを表します。

各レベルの要約

レベル 説明 例
1 ビルドプロセスの文書化 未署名の来歴
2 ビルドサービスの改ざんへの耐性 ホスト提供されたソース/ビルド、署名された来歴
3 特定の脅威に対する追加の耐性 ホストでのセキュリティ制御、偽造不可能な来歴
4 最も高いレベルの確実性と信頼 2人の関係者によるレビュー＋密封されたビルド

理想的なセキュリティ状態を達成するには何年もかかることがあるので、中間的なマイルストーンは重要です。 SLSAは、サービスのセキュリティを少しずつ改善していくためのガイドとなります。 重要なインフラや欠かせない業務に使用されているアーティファクトであればより高いレベルのセキュリティを得たいでしょうし、リスクの低いソフトウェアであれば満足した時点で改善を止めることもあるでしょう。

詳細な解説

レベル 要求事項
0 保証なし。 SLSA 0は、どのSLSAレベルにもなっていないことを表す。
1 ビルドプロセスは完全にスクリプト化/自動化されており、来歴を生成する。 来歴はアーティファクトがどのようにビルドされたかについてのメタデータであり、ビルドプロセス、トップレベルのソース、依存関係を含む。来歴を知ることで、ソフトウェア利用者はセキュリティ上の判断をリスクベースで行えるようになる。SLSA 1での来歴は改ざんに対する防御はしないが、コードの発生元の識別手段を基本的なレベルで提供し、脆弱性管理を支援することができる。
2 バージョン管理と、認証済みの来歴を生成するような、ホスト提供されたビルドサービスを使用することを要求する。 これらの追加の要求事項により、ソフトウェアの利用者は、ソフトウェアの出自についてより深い確信を持つことができる。このレベルでは、来歴はビルドサービスが信頼されている範囲において改ざんを防止する。SLSA 2は、SLSA 3へのアップグレードを容易にするためのパスも提供する。
3 ソースとビルドプラットフォームは、ソースとそれに対応する来歴との整合性が監査可能であることを保証するための、特定の標準に適合する。 我々は、監査者がプラットフォームを要求事項に適合していると証明するための認定プロセスを想像している。そして、利用者はその認証プロセスを信頼することができる。SLSA 3は、ビルド間をまたぐ汚染のような特定の種類の脅威を防止することで、改ざんに対して前のレベルよりも大幅に強化された防御を提供する。
4 全ての変更を2人でレビューすることと、密封された再現可能なビルドプロセスを要求する。 2人によるレビューは、ミスを捕捉し悪質な行動を抑止するための業界のベストプラクティスである。密封されたビルドは、来歴の依存関係リストが完全であることを保証する。再現可能なビルドは、厳格に要求されているわけではないものの、監査可能性と信頼性に多くの利点をもたらす。全体として、SLSA 4は、ソフトウェアが改ざんされていないという高いレベルの信頼を利用者に与える。

SLSAレベルは推移的ではありません（私たちのFAQを参照）。 これにより、各アーティファクトのSLSAの格付けは互いに独立したものとなり、並行して対応を進めることと、リスクに応じた優先付けが可能になります。 レベルは、アーティファクトのビルドプロセスとトップレベルのソースに対する完全性の保護を説明していますが、アーティファクトの依存先については何も説明していません。 依存先は自身のSLSAの格付けを持っているため、SLSA 4のアーティファクトをSLSA 0の依存先からビルドすることもあり得ます。

制約

SLSAはソフトウェア・アーティファクトにおけるサプライチェーンの脅威を減らす助けにはなりますが、制約もあります。

  • 多くのアーティファクトのサプライチェーンには、膨大な数の依存関係があります。依存関係の完全なグラフは、扱いが困難なほど大きなものになり得ます。
  • 現実には、セキュリティに従事するチームはサプライチェーンの重要なコンポーネントを識別しそれに集中する必要があるでしょう。これは手動で行うことができますが、そのための労力は大きなものになるかもしれません。
  • アーティファクトのSLSAレベルは推移的でなく（私たちのFAQを参照）、依存先は独自のSLSA格付けを持ちます。そのため、主となるアーティファクトのセキュリティが強くても、他の場所にリスクが存在することがあります。それらのリスクを集計したものは、ソフトウェアの利用者がSLSA 4アーティファクトをどこでどのように使用するかを理解する助けになるでしょう。
  • これらのタスクの自動化は助けになるでしょうが、全てのソフトウェア利用者が全てのアーティファクトのグラフ全体を完全に調査することは現実的ではありません。このギャップを埋めるために、監査者と認定主体は、どこかがSLSA要求事項に合致していることを証明し主張してもよいでしょう。これは特にクローズドソースのソフトウェアに対して価値があるかもしれません。

私たちは、ロードマップの一部として、重要なコンポーネントをどう識別するか、サプライチェーン全体に渡り集約されたリスクをどう決定するか、認定の役割、について検討する予定です。

このページの内容