🎓 レベル：発展 | 重要度：B（推奨） 📎 前提：コンテナとイメージのセキュリティ ⚠️ 脅威・対策ともに動きが速い領域（要最新確認）。本稿は枠組みと原則に絞る。
要点（BLUF）
- 現代のソフトウェアは大半が他人のコード（依存ライブラリ・ベースイメージ・ツール）。攻撃者はそこを狙えば多数を一度に侵せる。
- これが OWASP 2025 の新カテゴリ「ソフトウェア供給網の失敗」（OWASP Top 10 の概観）。守りは「自分のコードの外側」に広がる。
- 防御の柱は 来歴の可視化（SBOM）・署名検証・依存の固定と検証・ビルドの完全性。完全性（情報セキュリティとは（CIAとAAA））を供給網全体に広げる。
概念：自分のコードは氷山の一角
アプリのコードのうち、自分で書く部分はごく一部で、残りはライブラリ・フレームワーク・ベースイメージ・ビルドツールなど外部由来です。攻撃者から見れば、人気の依存を1つ汚染すれば、それを使う全アプリに影響を及ぼせます。だから供給網（サプライチェーン）は効率のよい標的になり、近年事故が増えています。
供給網が狙われる典型的な経路（概念）：
- 依存の汚染：ライブラリそのものや、その更新に悪性コードが混入する。
- ビルド/配布経路の汚染：CI/CD やレジストリを経由して改ざんされる。
- 取り違え：似た名前や内部名の取り違えで、意図しないパッケージを取り込む。
ここでは「どう攻撃するか」ではなく、「どの経路に完全性の保証が要るか」を理解します。
仕組み：供給網を守る4つの柱
| 柱 | 何をするか | 関連 |
|---|---|---|
| 来歴の可視化（SBOM） | 何を使っているか部品表を作る | 脆弱性が出たとき影響範囲を即特定 |
| 署名と検証 | 配布物・イメージの真正性を確認 | デジタル署名（デジタル署名と証明書（PKI）） |
| 依存の固定と検証 | バージョン・ハッシュを固定 | ハッシュ照合（対称鍵暗号とハッシュ） |
| ビルドの完全性 | 再現可能・隔離されたビルド | 改ざんされていないことの担保 |
- SBOM（Software Bill of Materials）：使っている部品の一覧。脆弱性が公表されたとき「自分は影響を受けるか」を即答できる。
- 署名検証：取り込む依存・実行するイメージが「正規の発行元のもので改ざんされていない」ことを署名で確認（デジタル署名と証明書（PKI））。
- 依存の固定（ピン留め）とハッシュ検証：バージョンとハッシュを固定し、取得物が一致するか照合。勝手な差し替えを検知。
- ビルドの完全性：隔離された再現可能なビルドで、出力が入力から決まることを担保する。
flowchart LR
DEP["外部依存・ベースイメージ"] -->|"署名検証・ハッシュ照合"| GATE{"信頼できるか"}
GATE -->|"はい"| BUILD["隔離・再現可能なビルド"]
GATE -->|"いいえ"| STOP["取り込まない"]
BUILD --> SBOM["SBOM を生成（部品表）"]
SBOM --> ART["署名つき成果物"]
ART -.->|"脆弱性公表時に影響範囲を即特定"| SBOM
防御側の使い方／設定
- SBOM を生成・保管：ビルドで部品表を出し、脆弱性公表時に照合できるようにする。
- 依存をピン留め＋ハッシュ検証：バージョン固定とロックファイル＋ハッシュで、取得物の同一性を確認。
- 署名検証を必須化：取り込む依存・実行イメージの署名を検証（コンテナとイメージのセキュリティ）。
- 依存スキャンを継続：SCA で既知脆弱性を検出し更新（セキュアコーディングとレビュー）。
- ビルド環境を隔離・最小権限：CI の権限を絞り、シークレットを保護（シークレット管理）。供給網の中の足場を与えない。
- 最新動向を追う：手口・標準（SBOM 形式や来歴フレームワーク）は更新が速い（要最新確認）。
なぜ安全か：完全性を「自分の外」まで広げる
供給網の防御が効くのは、これまで「自分のコード」に閉じていた完全性の保証を、取り込む部品とビルド工程まで拡張するからです。署名検証で「正規の発行元のものか」、ハッシュ照合で「途中で変わっていないか」、SBOM で「何を抱えているか」を常に把握する。これにより、外部由来の改ざんを取り込み口で弾き、万一の脆弱性公表にも影響範囲を即特定して素早く対応できます。
仕組みの直観
サプライチェーンセキュリティは食品のトレーサビリティです。完成品（アプリ）だけ検査しても、原材料（依存）や加工工場（ビルド）が汚染されていれば防げません。だから原材料の産地証明（署名）、ロット番号での同一性確認（ハッシュ）、全成分表示（SBOM）、衛生管理された工場（隔離ビルド）を揃える。事故（脆弱性公表）が起きたら、成分表からどの製品が該当するかを即座に追跡して回収します。
⚠️ よくある誤解・設定ミス
- 「自分のコードだけ守れば十分」：大半は外部由来。供給網まで完全性を広げる。
- 依存をピン留めせず最新を自動取得：勝手な差し替えや汚染版を取り込みうる。固定＋ハッシュ検証。
- 署名・来歴を確認しない：出所不明の依存・イメージを信頼してしまう。
- SBOM を作らない：脆弱性公表時に「自分は影響を受けるか」を即答できず対応が遅れる。
- CI の権限が広い・シークレットがむき出し：ビルド経路が侵入口になる。最小権限＋シークレット管理。
対応 lab
供給網の各ツールは環境依存のため lab は置きません。署名検証・ハッシュ照合という土台は security-study/labs/digital_signature_demo.py と hash_oneway_demo.py で原理を確認できます。
関連
- 真正性・完全性の土台 → デジタル署名と証明書（PKI）・対称鍵暗号とハッシュ
- イメージの守り → コンテナとイメージのセキュリティ
- 依存スキャンの組み込み → セキュアコーディングとレビュー