セキュリティ レベル

要件なし —L0 は SLSA がないことを表します。

単体テストなど、同じマシン上で構築および実行されるソフトウェアの開発またはテスト ビルド。

該当なし

該当なし

パッケージには、それがどのように構築されたかを示す来歴があります。間違いを防ぐために使用できますが、回避したり偽造したりするのは簡単です。

ビルド ワークフローを変更せずに、改ざん防止以外の SLSA の利点を簡単かつ迅速に得たいと考えているプロジェクトや組織。

• ソフトウェア プロデューサーは、他の人が「正しい」ビルドがどのようなものであるかについての期待を形成できるように、一貫したビルド プロセスに従います。

• ビルド プラットフォームは、アーティファクトがどのようにビルドされたかを説明する 来歴 を自動的に生成します。これには、どのエンティティがパッケージをビルドしたか、使用したビルド プロセス、ビルドへのトップレベルの入力が何であったかが含まれます。

• ソフトウェア制作者は、できればパッケージ エコシステムによって決定された規則を使用して、消費者に来歴を配布します。

• 正確なソース バージョンとビルド プロセスを知ることで、プロデューサーとコンシューマーの両方がソフトウェアのデバッグ、パッチ、再構築、分析を容易にします。

• 検証 を使用すると、上流リポジトリに存在しないコミットからビルドするなど、リリース プロセス中のミスを防ぐことができます。

• 組織がソフトウェアのインベントリを作成し、さまざまなチームで使用されるプラットフォームを構築するのを支援します。

• 来歴が不完全であるか、L1 で署名されていない可能性があります。より高いレベルでは、より完全で信頼できる来歴が必要になります。

来歴を偽造したり、検証を回避したりするには、明示的な「攻撃」が必要ですが、これは簡単に実行できる場合もあります。洗練されていない敵や、法的リスクや経済的リスクに直面している敵を阻止します。

実際には、これは、来歴を生成して署名¹するホストされたプラットフォーム上でビルドが実行されることを意味します。

Build L3 で必要なビルド プラットフォーム自体の変更を待ちながら、ホスト型ビルド プラットフォームに切り替えることで SLSA による適度なセキュリティ上のメリットを得たいと考えているプロジェクトおよび組織。

Build L1 のすべてに加えて:

• ビルドは、来歴自体を生成して署名¹するホストされたビルド プラットフォーム上で実行されます。これは、オリジナルのビルド、事後の再現可能なビルド、または来歴の信頼性を保証する同等のプラットフォームである可能性があります。

• 来歴の下流検証には、来歴の信頼性の検証が含まれます。

Build L1 のすべてに加えて:

• デジタル署名¹ によってビルド後の改ざんを防止します。

• 解雇のリスクに直面する従業員など、セキュリティ管理を回避することで法的または財務的リスクに直面する敵対者を阻止します。

• 監査および強化が可能な特定のビルド プラットフォームにビルドを制限することで、攻撃対象領域を削減します。

• さらなる強化作業 (Build L3) を並行して実行しながら、サポートされているビルド プラットフォームへのチームの大規模な移行を早期に行うことができます。

来歴を偽造したり検証を回避するには、ほとんどの攻撃者の能力を超えた脆弱性を悪用する必要があります。

実際には、これは、強力な改ざん保護を提供する強化されたビルド プラットフォーム上でビルドが実行されることを意味します。

ほとんどのソフトウェア リリース。Build L3 では通常、既存のビルド プラットフォームに大幅な変更が必要です。

Build L2 のすべてに加えて:

• ビルド プラットフォームは、以下のための強力な制御を実装します。

  • 同じプロジェクト内であっても、実行が相互に影響を与えないようにします。
  • 来歴の署名に使用される秘密マテリアルがユーザー定義のビルド ステップからアクセスできないようにします。

Build L2 のすべてに加えて:

• 内部関係者の脅威、資格情報の漏洩、または他のテナントによるビルド中の改ざんを防止します。

• 攻撃者にビルド プロセスの困難なエクスプロイトを実行させることで、侵害されたパッケージ アップロードの認証情報の影響を大幅に軽減します。

• パッケージが公式のソースとビルド プロセスからビルドされたという強い信頼性を提供します。