サプライチェーン攻撃の仕組み — アプリに届くまでの経路を守る
アプリが届くまでに、どこを守る？
- 身近な例から役割をつかむ
- 確認できる結果と成立条件を区別する
- 次の学習や導入判断につなげる
ひよこ 
ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 ひよこ ペンギン先生 自分のアプリに届くまでをたどる
小さな商品アプリでも、外部のライブラリ、ビルドツール、CI、配布先などを使うことがあります。サプライチェーン攻撃は、こうしたソフトウェアの供給経路を悪用する攻撃です。
例えば、依存ライブラリの保守アカウントが乗っ取られ、不正な版が公開される場合があります。別の入口として、ビルド環境を改変し、読んだソースとは違う成果物を配ることも考えられます。どの環境で何が実行されるかによって影響は変わります。
弱点の悪用と、供給経路への不正混入を分ける
正規のライブラリにある脆弱性が攻撃されることと、攻撃者が配布物へ意図的に不正コードを入れることは同じではありません。ライブラリを使った事件を全てサプライチェーン攻撃と呼ぶと、確認すべき場所を見誤ります。
2024年のXZ Utilsでは、公式の説明によると5.6.0と5.6.1のリリースtarballにバックドアが含まれていました。それらは署名されてもいました。「署名されている」「有名なプロジェクト」という理由だけで内容の安全まで保証できない例です。全てのXZの版や、使った全端末が同じ被害を受けたという意味ではありません。
対策の役割を分けて考える
| 材料・対策 | 役立つこと | それだけでは分からないこと |
|---|---|---|
| lockファイル・版の固定 | 選ぶ依存をそろえる | その版に不正や弱点がないか |
| ハッシュ | 承認した値と内容が一致するか | 承認前の内容が安全か |
| 署名・IDの照合 | 期待した提供者の署名か | 署名者や工程が侵害されていないか |
| SBOM | 含まれる部品を追う | 全部品の安全性 |
| 来歴（provenance） | 元のソースやビルド工程を追う | 全ての不正や設計上の弱点 |
比較するハッシュや署名者の情報自体も、信頼できる経路で入手する必要があります。攻撃者の配布ページにあるハッシュへ合わせただけでは確認になりません。署名や来歴も、期待するIDや方針へ照合して使います。
初心者が最初に確認する5つ
- 入手先：公式の案内からパッケージ名・提供元・リポジトリを確認する。似た名前にも注意する。
- 変更内容：依存の追加・更新で、lockファイルがどう変わったかを見る。
- 必要な権限：テスト用CIへ公開鍵・クラウドの書き込み権限などを不用意に渡さない。
- 記録：使った版、構成、確認した情報を残し、問題発生時に影響を調べられるようにする。
- 更新手順：新しい版の確認、テスト、復旧の手順を用意する。古い版を永久に固定しない。
npm ciはlockファイルと設定の整合を使い、食い違えば失敗しますが、悪意を判定する機能ではありません。Pythonのpip freezeは版の一覧を作る操作で、配布物のハッシュ検証を自動的に有効化するものではありません。pipでは--require-hashesなどを使う別の設定が必要です。
CIの部品にも更新と権限の方針を
GitHub Actionsのactionは、提供元を確認した完全なコミットSHAへ固定することで、タグが指す内容の変更を避けられます。それでも固定したコードの安全性は別の問題です。権限を絞り、信頼できないpull requestのコードがSecretsや公開権限を使わないよう、実行条件を確認します。
SLSAは、ソースやビルドの完全性に関わる脅威・対策を整理しています。全てのソフトウェアの弱点をなくす規格ではありません。まずはGitHub Actions入門の権限を絞ったテストから、使う部品と経路を見えるようにしてみましょう。
参考資料
-
SLSAの脅威モデル — ソース・ビルド等の供給経路と対象範囲
-
XZ Utilsの公式説明 — 対象tarballと署名の事実
-
pipの安全なインストール — ハッシュ検証の条件
-
npm ci — lockファイルの整合
-
Actionsの安全な利用 — 完全SHAへの固定と権限
-
Sigstoreの検証 — 期待したIDとissuerへの照合