要約

  • SLSA v1.2では、プロベナンスは検証者の期待と照合される証拠であり、誰かが検査するまで自ら何かを決定しない。
  • 仕様は、成果物に結び付くアテステーション、信頼の根、パッケージ名に結び付く期待、そしてエコシステム・利用者・監視者の受入れ判断を分けている。
  • 期待と対応の記録を残せば、正当なアテステーションをリリース全体への万能な承認と取り違えずに済む。

アテステーションが述べる範囲

SLSAのビルド・プロベナンスは、プロジェクト一般に「安全」という印を付けるためのものではない。特定のビルド・プラットフォームが buildDefinition を実行して成果物を生成した、というアテステーションである。subject をハッシュに結び、ビルダー、ビルド種別、パラメータ、依存関係を記録できる。利用者はそれを使って、実際のビルドが期待したビルドだったかを照合し、必要なら再現や調査を行える。

配布に関する仕様は、この限界をさらに明確にする。アテステーションはリリースではなく成果物に結び付けるべきである。一つのリリースには複数のアーキテクチャや環境向けの成果物が入り、ビルド時刻も同じとは限らない。後から成果物とアテステーションが追加されることもある。したがって、リリース名だけで、あるファイルとその証拠の厳密な関係を代用してはならない。

これは弱さではなく、検証可能性の源である。SLSAは、プロベナンスは誰かが検査するまで何もしないと述べる。証拠を発行すること、検証者が比較すること、権限を持つ側が受入れ・拒否・隔離・監視を決めることは三つの段階である。それらを一つの「承認済み」ラベルに畳み込むと、後で根拠をほどけなくなる。

期待は封筒から自動的には出てこない

SLSAは検証者に、信頼の根を設定するよう求める。認識するビルダーのアイデンティティと、各アイデンティティをどのBuild Levelまで信頼するかである。さらに署名を確認し、subject と成果物のダイジェストを対応させ、buildType と externalParameters が期待値に合うかを確かめる。

署名が正しいアテステーションでも、その期待値を選ぶことはできない。SLSAは異なる検証者が異なる信頼の根を使い得ることを認め、期待はパッケージ名に、プロベナンスは成果物に結び付くと説明する。エコシステムは正規のソースリポジトリを決められる。利用者は独自の規則を持てる。生産者は認証済みの経路で期待を提示できる。初回信頼モデルは最初の状態を比較の基準にできる。いずれも「この状況でこのパッケージに何を許すか」という、アテステーションだけでは答えない問いへの答えである。

externalParameters は境界をよく示す。外部の管理下にあり、記録され、下流で検証されるべき値である。記載されていることは許可を意味しない。SLSAは未知のパラメータを拒否する側に倒すよう勧める。builder.id も同じで、記録されたからといって全ての検証者が信頼の根に入れる義務はない。真正性は発言と発行者を結ぶが、信頼は依然として政策上の選択である。

受入れ地点には持ち主がいる

SLSAは検証の場所として、パッケージ・エコシステムでのアップロード時、利用者のダウンロード時または使用前、監視者による継続的な確認を挙げる。これらは併用できる。レジストリは受け入れるかを決め、利用者はインストールや配備を決め、監視者は差異を発見して公表できる。ただし仕様は、失敗を発見しても、人または自動化された仕組みが対応しなければ利益は限られると明記する。

従って同じ成果物が、ある政策では受入れられ、別の政策では拒否され、監視者には検出されても処理待ちであり得る。これはプロベナンスの矛盾ではない。決定者が異なることの通常の帰結である。配布仕様は、プロベナンスを、リポジトリがあるSLSA水準を要求する可能な公開政策を検証するための証拠として位置付ける。それは政策そのものでも、執行でも、受入れ済みの記録でもない。

期待と対応のレシート

必要なのは新しいSLSA形式ではない。検証を行うエコシステム、利用者、監視者が判断の横に残す、期待と対応のレシートである。成果物のダイジェスト、アテステーション参照、検証者と政策版、実際に使った信頼の根、期待する正規ソース、buildType、許容する外部パラメータ、評価時刻、結果を記すべきである。

失敗時には、拒否、隔離、警告、時限付き例外、保留のどれになったかと、状態を変えられる者を記す。期待が変わるなら、過去の評価を黙って書き換えるのでなく、権限ある変更に結び付ける。このレシートは普遍的安全性、依存関係の完全性、迅速な修復を約束しない。しかし、真正な証拠と受入れ済み成果物、政策変更と署名更新、監視の通知と修復完了を別の事実として残せる。

境界を保てば選択を保てる

ここでのHeng Luの示唆はSLSAについての証拠ではなく方法である。調整の記録は、自分にない権限まで借りて現実を宣言してはならない。SLSAはプロベナンスの生成、配布、検証を定めるが、誰を信頼するか、何を期待するか、差異に誰が応答するかという別々の選択を消してはいない。

「真正なビルド」「承認済みパッケージ」「完成したリリース」「有効な対応」を一文にする近道は、信頼の根が変わり、新しいアーキテクチャが加わり、例外が失効し、監視者が差異を見つけたときに高くつく。レシートは協調を妨げず、証拠・期待・決定を別々に読めるようにする。

出典

  1. SLSA v1.2 — Build: Verifying artifacts
  2. SLSA v1.2 — Build: Provenance
  3. SLSA v1.2 — Build: Distributing provenance