工芸品の制作

ビルド プロセスは、暗号ダイジェストによって出力パッケージを明確に識別し、そのパッケージがどのように作成されたかを説明する来歴を生成しなければなりません (MUST)。形式は パッケージ エコシステム および/または 消費者 に受け入れられなければなりません。

[SLSA Provenance] 形式と [associated suite] は、SLSA に使用する際に相互運用可能、汎用的、および明確になるように設計されているため、使用することが推奨されます。要件と実装ガイドラインについては、その形式のドキュメントを参照してください。

代替形式を使用する場合は、各レベルで SLSA 来歴と同等の情報が含まれていなければならず (MUST)、SLSA 来歴に双方向に変換可能である必要があります (SHOULD)。

• 完全性: ベストエフォート。L1 の来歴には、間違いを発見し、改ざんがない場合に高いレベルでユーザー エクスペリエンスをシミュレートするのに十分な情報が含まれている必要があります (SHOULD)。言い換えれば、来歴の内容はすべてのビルド レベルで同じであるべきです (SHOULD) が、実装に法外な費用がかかる場合、いくつかのフィールドが L1 に存在しなくてもよい (MAY)。
• 真正性: 要件はありません。
• 精度: 要件はありません。

信頼性: 消費者は、次のことを行うために、来歴証明書の信頼性を検証できなければなりません。

• 整合性の確保: 来歴証明書のデジタル署名が有効であり、来歴がビルド後に改ざんされていないことを確認します。
• 信頼の定義: 生成されたアーティファクトを信頼するために信頼する必要があるビルド プラットフォームとその他のエンティティを特定します。

これは、来歴証明書を生成したビルド プラットフォーム コンポーネントのみがアクセスできる秘密鍵からのデジタル署名を介する必要があります (SHOULD)。

署名方法の選択には多くの制約が影響しますが、ビルド プラットフォームでは、透明性ログや、透明性が適切でない場合はタイムスタンプ サービスに依存する方法など、鍵の侵害を検出して修復する能力を向上させる署名方法を使用することが推奨されます。

信頼性により、消費者はビルド プラットフォームの ID などの来歴証明書の内容を信頼できます。

正確性: 以下に記載する場合を除き、来歴はコントロール プレーン (つまり、[来歴で識別される] 信頼境界内) によって生成されなければならず、ビルド プラットフォームのテナント (つまり、信頼境界の外側) によって生成されることはありません。

• 来歴のデータは、ジェネレーターがビルド プラットフォームであるため、または来歴ジェネレーターがビルド プラットフォームからデータを直接読み取るため、ビルド プラットフォームから取得する必要があります。
• ビルド プラットフォームには、テナントによる来歴の改ざんを防ぐために、何らかのセキュリティ制御が必要です。ただし、強度に下限はありません。その目的は、法的または財務的リスクに直面する可能性のある敵対者が規制を回避するのを阻止することです。
• ビルド プラットフォームのテナントによって生成される可能性があるフィールドの例外:
  • 出力アーティファクトの名前と暗号ダイジェスト、つまり [SLSA Provenance] の「件名」。これが許容される理由の説明については、来歴の出力ダイジェストの出力 を参照してください。
  • ビルド L2 に必須としてマークされていないフィールド。たとえば、[SLSA Provenance] の resolvedDependency は、ビルド L2 でテナント生成される場合があります (MAY)。ビルダーは、テナント生成フィールドのそのようなケースを文書化する必要があります。

完全性: 完全であるべきです。

• 来歴で十分に捕捉されていない 外部パラメータ が存在する可能性があります。
• 解決された依存関係の完全性はベストエフォートです。

精度: 来歴はテナントによる偽造に対して強力な耐性を持たなければなりません。

• 来歴の認証に使用される秘密マテリアル (デジタル署名の生成に使用される署名キーなど) は、そのマテリアルに適した安全な管理システムに保管し、ビルド サービス アカウントのみがアクセスできるようにする必要があります。
• このような秘密マテリアルは、ユーザー定義のビルドステップを実行している環境からアクセスできてはなりません。
• 来歴のすべてのフィールドは、信頼できるコントロール プレーンのビルド プラットフォームによって生成または検証されなければなりません。Provenance は Authentic に記載されている場合を除き、ユーザー制御のビルド ステップでは、コンテンツを挿入したり変更したりしてはなりません (MUST NOT)。(ビルド L3 では、L2 のフィールドを超える追加のフィールドは必要ありません。)

完全性: 完全であるべきです。

• 外部パラメータ は完全に列挙する必要があります。
• 解決された依存関係の完全性はベストエフォートです。

注: この要件は、最初の draft version (v0.1) では「反証不可能」と呼ばれていました。

すべてのビルド ステップは、個人のワークステーションではなく、共有インフラストラクチャまたは専用インフラストラクチャ上のホストされたビルド プラットフォームを使用して実行されました。

例: GitHub Actions, Google Cloud Build, Travis CI.

ビルド プラットフォームにより、意図しない外部からの影響を受けずに、隔離された環境でビルド ステップが実行されることが保証されました。言い換えれば、ビルドに対する外部の影響は、ビルド自体によって明確に要求されたものです。これは、同じテナント プロジェクト内のビルド間でも当てはまらなければなりません。

ビルド プラットフォームは次のことを保証する必要があります。

• 来歴の信憑性が損なわれるため、ビルドが来歴署名キーなどのビルド プラットフォームの秘密にアクセスすることは不可能であってはなりません。
• 同じマシン上で実行されている別のビルド プロセスのメモリを変更するなど、時間的に重なる 2 つのビルドが相互に影響を及ぼしてはなりません。
• 1 つのビルドが持続したり、後続のビルドのビルド環境に影響を与えたりすることはできません。言い換えれば、一時的なビルド環境はビルドごとにプロビジョニングする必要があります。
• あるビルドが、別のビルドで使用されるビルド キャッシュに誤ったエントリを挿入すること (「キャッシュ ポイズニング」とも呼ばれる) を起こしてはなりません。言い換えれば、キャッシュが使用されるかどうかに関係なく、ビルドの出力は同一でなければなりません。
• ビルド プラットフォームは、そのようなすべての対話が来歴の externalParameters としてキャプチャされない限り、リモート影響を可能にするサービスを開いてはなりません (MUST NOT)。

ビルド自体にはサブ要件はありません。ビルド L3 は、善意のビルドが安全に実行されることを保証することに限定されています。ビルド プラットフォームがプロデューサーによる危険なビルドや安全でないビルドの実行を妨げる必要はありません。特に、「分離」要件は、ビルドがビルド プラットフォームの信頼境界の外側にあるリモート実行サービスまたは「セルフホスト ランナー」を呼び出すことを禁止するものではありません。

注: この要件は、初期の ドラフト バージョン (v0.1) では「分離環境」と「一時環境」に分割されていました。

注: この要件を「密閉」と混同しないでください。これは、ネットワーク アクセスなしでビルドが実行されたことを大まかに意味します。このような要件には、ビルド プラットフォームと個々のビルドの両方に大幅な変更が必要であり、将来の方向性 で検討されています。