# ソフトウェアサプライチェーンセキュリティ ## 定義 ソフトウェアサプライチェーンセキュリティは、コードを書き・ビルドし・テストし・デプロイするまでの一連の工程(software supply chain)に対して、内部者(悪意の有無を問わない)や内部者アカウントを侵害した外部攻撃者が不正な変更を紛れ込ませたり検証プロセスを迂回したりできないようにする取り組みである。中核となる発想の転換は、デプロイ時に「誰がそれを行ったか」を認可するだけでは不十分であり、「何がデプロイされようとしているか」を成果物そのものの性質から検証すべきだという点にある。ソース・ビルド・テストの各段階にどれだけ統制を敷いても、それらを迂回して本番へ直接デプロイできるなら統制は無意味になるため、サプライチェーンの各段階は自らが正しく実行されたことの証拠——バイナリ来歴(binary provenance)——を提供できなければならない。この来歴を評価基準(deployment policy)と突き合わせ、すべてのデプロイ要求が必ず通過するチョークポイントで判定を行い、デプロイ後にも継続的に検証することで、サプライチェーン全体の完全性を担保する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] §Concepts and Terminology, §Best Practices > Verify Artifacts, Not Just People) この転換を支える要素は5つに整理できる。(1) **バイナリ来歴**——ビルドの入力・変換・実行主体を記述し、署名で真正性を保護する記録。(2) **来歴に基づくデプロイポリシー**——各デプロイ環境が要求する性質(ソースの出自・テスト合格・脆弱性スキャン等)を明示的な規則として記述し、署名ベースの検証より暗黙の前提を減らす仕組み。(3) **検証可能ビルド**——信頼できない入力(利用者定義のビルドコマンド)と認証されていない入力(依存関係の取得)の双方に対処し、権限分離とヘルメティックビルドによって来歴の信頼性を担保するビルドアーキテクチャ。(4) **デプロイのチョークポイント**——Kubernetes のコントロールプレーンのように、すべてのデプロイ要求が必ず通過する地点でポリシー判定を行う設計。(5) **デプロイ後検証**——ポリシー変更・フェイルオープン・ブレークグラス・フォレンジックといった理由から、デプロイ時の強制だけに頼らず事後にも検証できるログを残す仕組み。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] §Advanced Mitigation Strategies) ## 横断的知見 - (現時点で本 concept のソースは [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] のみのため蓄積なし。今後、サプライチェーン改ざん対策・SLSA・SBOM 等の他ソースが取り込まれ次第、ここに突き合わせ観察を追記する。) ## 未解決の問い - 来歴に基づくデプロイポリシーは「単一のポリシーだけが適用される」ことを前提に設計を単純化する(ch.14 §Practical Advice > Create Unambiguous Policies)。マイクロサービス間で依存関係が複雑に絡み合う環境で、この単一ポリシー前提はどこまで維持できるか。 - 検証可能ビルドの3アーキテクチャ(信頼済みビルドサービス・自己再ビルド・再ビルダーの合意)のうち、Google は内部ビルドで「信頼済みビルドサービス」モデルを採用するとされる([[ヘルメティックビルド]] concept が集約する Rapid・Blaze の設計とどう対応するか、両者を突き合わせた記述はまだない)。 - バイナリ来歴を「データベース参照」ではなく「アーティファクトへのインライン伝播」にすべきだという教訓(ch.14 §Practical Advice > Ensure Unambiguous Provenance)は、来歴の伝播経路が複数の CI/CD システムをまたぐサプライチェーン(サードパーティ依存を含む)にどこまで一般化できるか。 - [[in-toto]] のような標準フレームワークを採用した場合と、独自にポリシーエンジンを実装した場合とで、実行可能なエラーメッセージの提供しやすさ(ch.14 §Practical Advice > Provide Actionable Error Messages)にどのような差が出るか。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] - 概念: [[ヘルメティックビルド]](検証可能ビルドの基礎となるビルドの再現性を扱う) / [[ソフトウェア変更管理]](設定のコード化・変更のライフサイクル管理) / [[継続的デプロイ]] / [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] / [[セキュアコーディングフレームワーク]] / [[ファジング]] - 実体: [[Binary Authorization]] / [[in-toto]] / [[Kubernetes]] / [[Borg]] ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 14 (Written by Jeremiah Spradlin and Mark Lodato).