用語
SLSA レベル に入る前に、何を保護しているのかを説明するための用語とモデルの中核セットを確立する必要があります。
ソフトウェア サプライ チェーン
SLSA のフレームワークは、ソフトウェア サプライ チェーンのあらゆるステップ、つまり成果物の作成につながる一連のステップに対応します。サプライ チェーンをソース、ビルド、依存関係、パッケージの [有向非循環グラフ] として表します。1 つのアーティファクトのサプライ チェーンは、その依存関係のサプライ チェーンに独自のソースとビルドを加えたものです。
| 用語 | 説明 | 例 |
|---|---|---|
| アーティファクト | 不変のデータの塊。主にソフトウェアを指しますが、SLSA はあらゆるアーティファクトに使用できます。 | ファイル、git コミット、ファイルのディレクトリ (何らかの方法でシリアル化された)、コンテナー イメージ、ファームウェア イメージ。 |
| 証明書 | ソフトウェア アーティファクトまたはソフトウェア アーティファクトのコレクションに関する認証されたステートメント (メタデータ)。 | 署名された [SLSA Provenance] ファイル。 |
| 出典 | 変更を加えることなく、人によって直接作成またはレビューされた成果物。それはサプライチェーンの始まりです。これ以上出所を遡ることはしません。 | GitHub (プラットフォーム) でホストされている Git コミット (ソース)。 |
| ビルド | 一連の入力成果物を一連の出力成果物に変換するプロセス。入力は、ソース、依存関係、または一時的なビルド出力である場合があります。 | .travis.yml (プロセス) Travis CI (プラットフォーム) によって実行されます。 |
| パッケージ | 他人が使用するために「公開」されたアーティファクト。モデルでは、これは常にビルド プロセスの出力ですが、ビルド プロセスが何も行われない場合もあります。 | DockerHub（プラットフォーム）上で配布されるDockerイメージ（パッケージ）。ソース コードを含む ZIP ファイルは、git コミットなどの他のソースからビルドされるため、ソースではなくパッケージです。 |
| 依存関係 | ビルド プロセスへの入力ではあるが、ソースではないアーティファクト。モデルでは、それは常にパッケージです。 | Alpine Linux (プラットフォーム) 上で配布される Alpine パッケージ (パッケージ)。 |
役割
仕様全体を通じて、ソフトウェア サプライ チェーンに参加する次の役割への言及が見られます。実際には、役割は複数の個人または組織によって満たされる場合があることに注意してください。同様に、個人または組織は、特定のソフトウェア サプライ チェーン内で複数の役割を担う場合があります。
| 役割 | 説明 | 例 |
|---|---|---|
| プロデューサー | ソフトウェアを作成し、他者に提供する者。生産者は消費者でもあることがよくあります。 | オープンソース プロジェクトのメンテナ。ソフトウェアベンダー。 |
| 検証者 | アーティファクトの出所を検査して、アーティファクトの信頼性を判断する当事者。 | 企業のソフトウェア取り込みシステム。プログラミング言語エコシステムのパッケージ レジストリ。 |
| 消費者 | 製作者が提供するソフトウェアを使用する当事者。消費者は、消費するソフトウェアの出所を検証することも、その責任を別の検証者に委任することもできます。 | オープンソース ソフトウェア ディストリビューションを使用する開発者。POSシステムを利用したビジネス。 |
| インフラプロバイダー | 他の役割にソフトウェアまたはサービスを提供する当事者。 | パッケージ レジストリのメンテナ。ビルド プラットフォームのメンテナ。 |
モデルの構築
ビルドは、各実行が独立したマルチテナント ビルド プラットフォーム 上で実行されるものとしてモデル化されます。
- テナントは、直接または何らかのトリガーを介して インターフェイス を介して 外部パラメーター を指定することにより、ビルドを呼び出します。通常、これらの外部パラメータの少なくとも 1 つは 依存関係 への参照です。(外部パラメーターはリテラル値ですが、依存関係は成果物です。)
- ビルド プラットフォームの コントロール プレーン は、これらの外部パラメーターを解釈し、依存関係の初期セットをフェッチし、ビルド環境 を初期化し、その環境内で実行を開始します。
- その後、ビルドは追加の依存関係の取得などの任意の手順を実行し、1 つ以上の 出力 アーティファクトを生成します。ビルド環境内のステップはテナントの制御下にあります。ビルド プラットフォームは、ビルド環境を互いにある程度分離します (これは SLSA ビルド レベルによって測定されます)。
- 最後に、SLSA Build L2+ の場合、コントロール プレーンはこのプロセス全体を説明する 来歴 を出力します。
特に、ビルド モデルには「ソース」という正式な概念はなく、外部パラメーターと依存関係だけが存在します。ほとんどのビルド プラットフォームには、ビルド元となる明示的な「ソース」アーティファクトがあり、これは多くの場合 git リポジトリです。ビルド モデルでは、このアーティファクトへの参照は外部パラメーターですが、アーティファクト自体は依存関係です。
このモデルが実際のビルド プラットフォームにどのように適用されるかの例については、ビルド タイプのインデックス を参照してください。
| 初等用語 | 説明 |
|---|---|
| プラットフォーム | テナントがビルドを実行できるシステム。技術的には、ビルドを忠実に実行するには信頼する必要があるソフトウェアとサービスの推移的クロージャです。これには、ソフトウェア、ハードウェア、人、組織が含まれます。 |
| 管理者 | プラットフォームへの管理アクセス権を持つ特権ユーザー。ビルドやコントロール プレーンの改ざんを許可される可能性があります。 |
| テナント | プラットフォーム上にアーティファクトを構築する信頼できないユーザー。テナントはビルドステップと外部パラメータを定義します。 |
| コントロールプレーン | それぞれの独立したビルド実行を調整し、来歴を生成するビルド プラットフォーム コンポーネント。コントロール プレーンは管理者によって管理され、テナントの制御外にあると信頼されています。 |
| ビルド | 入力ソースと依存関係を出力アーティファクトに変換するプロセス。テナントによって定義され、プラットフォーム上の単一のビルド環境内で実行されます。 |
| ステップ | テナントによって定義された、ビルドを構成する一連のアクション。 |
| 構築環境 | ビルドが実行される独立した実行コンテキスト。コントロール プレーンによって初期化されます。分散ビルドの場合、これはステップを実行するすべてのマシン/コンテナ/VM のコレクションです。 |
| キャッシュを構築する | プラットフォームによって管理される中間アーティファクト ストレージ。中間アーティファクトを明示的な入力にマッピングします。ビルドは、プラットフォーム上で実行されている後続のビルドとビルド キャッシュを共有する場合があります。 |
| 外部パラメータ | ビルドへのトップレベルの独立した入力のセット。テナントによって指定され、ビルドを初期化するためにコントロール プレーンによって使用されます。 |
| 依存関係 | 構成ファイル、ソースアーティファクト、ビルドツールなど、ビルドプロセスの初期化または実行中にフェッチされたアーティファクト。 |
| 出力 | ビルドによって生成されたアーティファクトのコレクション。 |
| 来歴 | プラットフォームと外部パラメータの識別を含む、出力がどのように生成されたかを説明する証明書 (メタデータ)。 |
避けるべきあいまいな用語
- ビルド レシピ: 外部パラメーター を意味する可能性がありますが、ビルドを実行する方法の具体的な手順が含まれる場合があります。実装の詳細を避けるため、この用語は定義しませんが、ビルド プラットフォームへのインターフェイスである「外部パラメータ」を常に使用します。同様の用語として、ビルド構成ソース および ビルド定義 があります。
- Builder: 通常は ビルド プラットフォーム を意味しますが、ビルド環境、ビルドを呼び出したユーザー、または 依存関係 からのビルド ツールに使用される場合もあります。混乱を避けるために、私たちは常に「プラットフォームの構築」を使用します。唯一の例外は provenance です。ここでは、
builderがより簡潔なフィールド名として使用されます。
パッケージモデル
ソフトウェアは、パッケージ エコシステムのルールと規約に従って、パッケージと呼ばれる識別可能な単位で配布されます。正式なエコシステムの例には、Python/PyPA、Debian/Apt、[OCI](https: //github.com/opencontainers/distribution-spec)、非公式エコシステムの例には、Web サイト上のファイルへのリンクや企業内でのファーストパーティ ソフトウェアの配布などが含まれます。
抽象的には、消費者は、パッケージ レジストリに変更可能な パッケージ名を不変のパッケージ アーティファクトに解決するように依頼することにより、エコシステム内のソフトウェアを見つけます。1 ] パッケージ アーティファクトを公開するには、ソフトウェア プロデューサーはレジストリにこのマッピングを更新して新しいアーティファクトに解決するように要求します。レジストリは、特定のパッケージ名に対して消費者が受け入れるアーティファクトを変更する権限を持つエンティティを表します。たとえば、消費者が特定の公開キーで署名されたパッケージのみを受け入れる場合、レジストリとして機能するのはその公開キーへのアクセスです。
パッケージ名は、パッケージ エコシステム内の主要なセキュリティ境界です。異なるパッケージ名は、実質的に異なるソフトウェア部分、つまり異なる所有者、動作、セキュリティ特性などを表します。したがって、パッケージ名は SLSA で保護されるプライマリ ユニットです。これは、消費者が期待する主な識別子です。
| 用語 | 説明 |
|---|---|
| パッケージ | 配布を目的としたソフトウェアの識別可能な単位。「成果物」または「パッケージ名」のいずれかを曖昧に意味します。この用語は、曖昧さが許容されるか望ましい場合にのみ使用してください。 |
| パッケージアーティファクト | 配布を目的としたファイルまたはその他の不変オブジェクト。 |
| パッケージエコシステム | クライアントがパッケージ名を 1 つ以上の特定のアーティファクトに解決する方法など、パッケージの配布方法を管理する一連の規則と規則。 |
| パッケージマネージャークライアント | パッケージ エコシステムと対話するためのクライアント側ツール。 |
| パッケージ名 | 同じソフトウェアの異なるバージョンをすべて表す、変更可能なアーティファクトのコレクションの主な識別子。これは、消費者がソフトウェアを入手するために使用する主な識別子です。 パッケージ名はエコシステム + レジストリに固有であり、メンテナーがあり、特定のハッシュやバージョンよりも一般的で、「正しい」ソースの場所があります。パッケージ エコシステムでは、パッケージ名を Maven のグループ ID などの何らかの階層にグループ化する場合がありますが、SLSA にはこれを表す特別な用語がありません。 |
| パッケージレジストリ | パッケージング エコシステム内のアーティファクトにパッケージ名をマッピングする責任を負うエンティティ。ほとんどのエコシステムは複数のレジストリ (通常は 1 つのグローバル レジストリと複数のプライベート レジストリ) をサポートします。 |
| パッケージ を発行する | アーティファクトをパッケージ レジストリに登録して、アーティファクトを使用できるようにします。技術用語では、これはアーティファクトをパッケージ名に関連付けることを意味します。これは必ずしもアーティファクトを完全に公開することを意味するわけではありません。アーティファクトは、内部テストやクローズド ベータなど、一部のユーザーに対してのみ公開される場合があります。 |
避けるべきあいまいな用語
- パッケージ リポジトリ: エコシステムに応じて、パッケージ レジストリまたはパッケージ名のいずれかを意味します。混乱を避けるために、曖昧さがない限り、常に「ソース リポジトリ」を意味するためにのみ「リポジトリ」を使用します。
- パッケージ マネージャー (「クライアント」なし): パッケージ エコシステム、パッケージ レジストリ、またはクライアント側ツールのいずれかを意味します。
現実世界のエコシステムへのマッピング
現実世界のほとんどのエコシステムは上記のパッケージ モデルに適合しますが、異なる用語を使用します。以下の表は、さまざまなエコシステムが SLSA パッケージ モデルにどのようにマッピングされるかを文書化しようとしています。間違いや省略がある可能性があります。修正や追加も大歓迎です！
| パッケージエコシステム | パッケージレジストリ | パッケージ名 | パッケージアーティファクト | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Cargo (Rust) | Registry | Crate name | Artifact | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CPAN (Perl) | Upload server | Distribution | Release (or Distribution) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Go | Module proxy | Module path | Module | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Maven (Java) | Repository | Group ID + Artifact ID | Artifact | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| npm (JavaScript) | Registry | Package Name | Package | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| NuGet (C#) | Host | Project | Package | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PyPA (Python) | Index | Project Name | Distribution | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Dpkg (e.g. Debian) | ? | Package name | Package | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Flatpak | Repository | Application | Bundle | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Homebrew (e.g. Mac) | Repository (Tap) | Package name (Formula) | Binary package (Bottle) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Pacman (e.g. Arch) | Repository | Package name | Package | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| RPM (e.g. Red Hat) | Repository | Package name | Package | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| nix (e.g. NixOS) | ? | Store Object? | Package or Derivation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ストレージ システム | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| GCS | n/a | Object name | Object | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| OCI/Docker | Registry | Repository | Object | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Meta | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| deps.dev: System | Packaging authority | Package | n/a | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| purl: type | Namespace | Name | n/a | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ノート：
- Go は、他のエコシステムとは大きく異なる配布モデルを使用します。go では、パッケージ名はソース リポジトリ URL です。クライアントはその URL から直接フェッチすることもできますが (この場合、「パッケージ」や「レジストリ」はありません)、通常は モジュール プロキシ から zip ファイルをフェッチします。モジュール プロキシは、ビルダー (ソースからパッケージ アーティファクトを構築することによって) とレジストリ (パッケージ名をパッケージ アーティファクトにマッピングすることによって) の両方として機能します。ビルドは独立して再現可能であり、チェックサム データベース により、すべてのクライアントが特定の URL に対して同じアーティファクトを受け取ることが保証されるため、人々はモジュール プロキシを信頼します。
検証モデル
SLSA での検証は 2 つの方法で実行されます。まず、ビルド プラットフォームは、ビルド プラットフォームが要求するレベルでの要件への準拠を保証するために認定されます。この認定は、ユーザーがレビューし、どのビルダーを信頼するかについて情報に基づいた決定を下せるように、プラットフォーム オペレーターによって公開される結果とともに定期的に行われる必要があります。
次に、アーティファクトが検証され、パッケージのソース コードがどこから取得され、どのビルド プラットフォームでパッケージがビルドされたかについて、プロデューサーが定義した期待を満たしていることが確認されます。
| 用語 | 説明 |
|---|---|
| 期待 | パッケージの出所メタデータに対する一連の制約。パッケージプロデューサーは、明示的または暗黙的に、パッケージに対する期待を設定します。 |
| 出所の検証 | アーティファクトは、パッケージが使用される前にパッケージの期待が満たされていることを確認するために、パッケージ エコシステムによって検証されます。 |
| ビルドプラットフォーム認定 | ビルド プラットフォームは、指定されたレベルで SLSA 要件に準拠していることが認定されています。 |
以下の例は、さまざまな広義のパッケージ エコシステムに対して期待と検証を実装できるいくつかの方法を示しています。
例: 小規模なソフトウェア チーム
| 用語 | 例 |
|---|---|
| 期待 | プロデューサーのセキュリティ担当者によって定義され、データベースに保存されます。 |
| 出所の検証 | 実行前に期待値データベースにクエリを実行することにより、クラスター ノード上で自動的に実行されます。 |
| ビルドプラットフォーム認定 | ビルド プラットフォームの実装者は、安全な設計と開発のベスト プラクティスに従い、毎年侵入テストを実施し、SLSA 要件への適合性を自己認証します。 |
例: オープンソース言語の配布
| 用語 | 例 |
|---|---|
| 期待 | パッケージごとに個別に定義され、パッケージ レジストリに保存されます。 |
| 出所の検証 | 言語配布レジストリは、新しくアップロードされたパッケージが公開前に期待を満たしていることを検証します。さらに、パッケージ マネージャー クライアントは、パッケージをインストールする前に期待値も検証します。 |
| ビルドプラットフォーム認定 | 言語エコシステムのパッケージ化当局によって実行されます。 |
-
この解決には、パッケージ名に加えて、バージョン番号、ラベル、またはその他のセレクターが含まれる場合がありますが、SLSA にとっては重要ではありません。 ↩