サプライチェーン
OWASP Top 10:2025 の A03 と SLSA v1.1 の Levels を取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
なぜ独立したカテゴリになったか
2013年の「既知の脆弱性を持つコンポーネントの使用」が起点だが、範囲が大きく広がった。
旧: 公表済みの脆弱性を持つ古いライブラリを使っていること。 現: 既知の脆弱性に限らない、サプライチェーンの失敗すべて。
新たに含まれるようになったもの。
ベンダー自体の侵害
ビルドパイプラインの悪意ある改変
メンテナンスされなくなったコンポーネント
対象範囲も、依存ライブラリだけではない。
サードパーティの依存とコンポーネント
ビルドとCI/CDの基盤
開発ツールとIDE
コードリポジトリ
成果物の保管場所
配布経路
「何を使っているか」だけでなく「どう作って、どう届けているか」全体が対象になった。
脆弱な状態のサイン
使っているコンポーネントのバージョンが把握できていない(直接依存も推移的依存も)
サポートの切れたソフトウェアを使っている
脆弱性スキャンをしていない
サプライチェーンの変更を追跡していない
重要なシステムへのアクセス制御が甘い
デプロイの職務分離がない
信頼できない供給元からコンポーネントを取得している
パッチ適用が不定期
更新時の互換性テストをしていない
CI/CD のセキュリティが弱い
依存関係の「信頼性の検証」と ビルドの「外部依存関係のセキュリティ」が、ここに接続する。
対策
SBOM(ソフトウェア部品表)を維持する
CVE / NVD / OSV のデータベースを監視する
信頼できる供給元から取得し、暗号学的に検証する
依存のバージョンを意図的に管理する
CI/CD・リポジトリ・IDE・成果物リポジトリの変更を追跡する
MFA を有効にし、最小権限を強制する
一斉更新ではなく段階的に展開する
アプリケーションの生存期間を通じて継続的に監視する
段階的な展開はデプロイ戦略のカナリアと同じ考え方。 依存の更新も、影響範囲を絞って出す対象になる。
MFA と最小権限は認証と認可そのもの。 CI/CD を本番インフラとして扱うという秘密情報の管理とも重なる。
実際に起きたこと
規模感を掴むために、原典が挙げている例。
| 事例 | 内容 |
|---|---|
| SolarWinds (2019) | ビルドパイプラインの侵害。約18,000組織に影響 |
| Bybit (2025) | ウォレットソフトウェアへの攻撃。15億ドルの窃取 |
| Shai-Hulud (npm) | post-install スクリプトを悪用したワーム |
| Log4Shell (CVE-2021-44228) | 広く使われるライブラリの致命的な脆弱性 |
| Struts 2 RCE (CVE-2017-5638) | 同上 |
post-install スクリプトが攻撃面になるのは、依存を入れる行為自体が コード実行になっているため。「入れただけ」で安全ということはない。
SLSA — ビルドの完全性を段階で測る
成果物が改ざんされておらず、出所まで安全に辿れることを保証する枠組み。
プロヴェナンス
誰が、どのプロセスで、どの入力から、その成果物を作ったかを記述したメタデータ。
これがあると、利用側が期待どおりに作られたことを検証し、逸脱を検知できる。
ビルドレベル
| レベル | 要求 | 防げること |
|---|---|---|
| L0 | なし | なし。単一マシンでの開発・テスト用ビルド |
| L1 | 一貫したビルドプロセス。プロヴェナンスを生成して利用側に配布する | リリース手順のミス。 上流リポジトリに存在しないコミットからビルドしてしまう、など。ただし署名がないので、意図的な攻撃者には無力 |
| L2 | L1 に加えて、ホストされた(監査可能で隔離された)ビルド基盤を使い、プロヴェナンスに署名する。利用側が真正性を検証する | ビルド後の改ざん。 署名によって防ぐ。法的・金銭的リスクを負う攻撃者を抑止する。基盤を集約することで攻撃面も減る |
| L3 | L2 に加えて、基盤を堅牢化する。同じプロジェクト内でも実行同士が互いに影響し合わない制御と、ユーザー定義のビルド手順からの秘密情報の分離 | ビルド中の改ざん。 内部関係者、侵害された資格情報、他テナントによるもの。プロヴェナンスの偽造には、大半の攻撃者の能力を超える脆弱性の悪用が必要になる |
L3 がほとんどのソフトウェアリリースの推奨水準。
なぜ段階になっているか
組織によって進む速度が違うため。トラックが分かれているのも同じ理由で、 ある側面の進歩を、無関係な側面の未達で止めないようにしている。
L1 文書化とミス防止。インフラの変更なしで得られる
L2 基盤の移行が要る。ただし完全な堅牢化までは不要
L3 相応の投資が要る。代わりにほぼ最大の保護が得られる
L2 の設計意図が実務的で、 チームを対応済みのビルド基盤へ大規模に移行させることを先に済ませ、 堅牢化はその後で進められるようにしている。
ビルドトラックと他のトラック
ここで扱ったのはビルドトラックで、対象は成果物のプロヴェナンスの信頼性。 他のトラックは別に定義されていて、独立に進められる。
既存の記述との接続
このリポジトリには、SLSA が求めるものの一部が既にある。
| 既にある記述 | SLSA での位置づけ |
|---|---|
| ビルドの外部依存関係の決定性 | 再現可能なビルド。L1 の前提 |
| リリースとデプロイの密閉ビルド | 同上 |
| 依存関係の信頼性の検証 | 供給元の信頼 |
| バージョン管理の単一バージョン原則 | 依存バージョンの意図的な管理 |
| 秘密情報の管理 | L3 の秘密情報の分離 |
足りていないのは、プロヴェナンスの生成と署名、そして SBOM。
取ってきたものを使う前に検証する側は完全性の検証にある。