サプライチェーン系の攻撃と対策

攻撃視点の分類 → セキュリティ脅威マップ ／ 横断「供給網・内部（レイヤーをまたぐ）」

サプライチェーンとは、モノやソフトを作るときに使う 「部品」や「取引先」のつながり のこと。料理でいえば、自分のキッチンがどれだけ清潔でも、仕入れた食材が汚染されていれば食中毒は起きる。これと同じで、自分のシステムは無事でも、取り込んだ外部の部品（OSS＝無料で公開されている共有部品ソフト）や取引先が汚染されると、まきこまれて被害を受ける。しかも 1か所の汚染が、その部品を使う全員へ一気に広がるのがこのジャンルの怖さ。気をつけていた人まで、まとめてやられる。

このページの読み方 — 🟢 は全員が知っておく基礎、🔧 はエンジニア・運用担当者向けの実装/設定。このジャンルは ソフトを作る人・部品やサービスを調達する人が主役だが、汚染された製品やアプリは結局みんなが使うので、全員に関わる。まず🟢を全員で、🔧は技術・調達担当が押さえる。

1. このジャンルの攻撃とは

攻撃者は、ねらった相手を正面から破るのではなく、その相手が信頼して取り込んでいる「上流」を汚染する。上流とは、

  • OSS（オープンソースの部品ソフト） — 世界中の開発者が無料で公開し、ほぼすべてのアプリが内部で使っている共有部品。
  • 配布物・アップデート — 正規メーカーが配るインストーラやソフト更新。
  • ビルド/CI・CD — ソースコードを実際の製品へ「組み立てる」開発工程（自動化された製造ライン）。
  • ベンダー・委託先 — 取引先や外注先など、自社のシステムに正規にアクセスできる相手。

ここに 1回入り込めば、正規の流通ルートに乗って、信頼している全員へ悪いものが配られる。利用者から見れば「いつもの会社の、いつもの正規アップデート」なので、疑いようがない。だから被害が静かに、広く拡散する。

2. 主な手口

手口 しくみ（何が汚染されるか）
OSSパッケージ汚染（npm / PyPI / RubyGems 等） 世界共通の部品置き場に、悪性コード入りの部品を紛れ込ませる
タイポスクワッティング 人気部品と 1文字違い・紛らわしい名前 の偽部品を置き、打ち間違い／コピペミスでの誤インストールを狙う
メンテナのアカウント乗っ取り 正規の部品作者のアカウントを奪い、悪性のアップデートを正規ルートで配信する
推移的依存（“部品の中の部品”） 自分が選んだ部品が、内部でさらに別の部品を呼ぶ。その奥の部品が汚染され、知らぬ間に巻き込まれる
ビルド / CI・CD 侵害 開発の「組み立て工程」に侵入し、正規ソースから悪性物を吐き出させる（SolarWinds型）
改ざんされた配布物 / コンテナイメージ 配布サイトやイメージ置き場のファイルをすり替え、本物そっくりの偽インストーラを掴ませる
署名のないアーティファクト 「誰が作ったか」を保証する電子署名がない成果物。すり替えられても気づけない
ベンダー / 委託先経由の侵入 取引先が持つ正規アクセス権を踏み台にして、本命の組織へ入り込む

🟢 ポイント — 「自分のせい」じゃなくても被害は来る

このジャンルの本質は、信頼の連鎖（信頼している相手が信頼している相手…）のどこか1か所が汚れると、その下流が全部汚れること。「うちはちゃんとしている」だけでは防げない。だからこそ、出どころの怪しいソフトを増やさない（🟢）と、取り込んだ部品をちゃんと管理・検証する（🔧）の両輪が必要になる。

3. 実例・典型シナリオ

  • 人気ライブラリの乗っ取り: 広く使われている OSS の作者アカウントが乗っ取られ、悪性版が「正規アップデート」として配信される。その部品を取り込んでいた世界中のアプリが、更新した瞬間に一斉に汚染される。
  • 1文字違いの偽パッケージ: requests のつもりが reqeusts、lodash のつもりが似た名前 ——タイプミスやコピペで 偽パッケージを誤インストールし、裏で認証情報やトークンを抜かれる。
  • ビルドサーバ汚染（SolarWinds型）: 攻撃者が開発の組み立て工程に侵入。ソースコード自体はきれいなのに、製品化の途中で悪性コードが混ぜ込まれ、正規の署名がついたまま顧客へ配布される。利用者には見破る手段がほぼない。

4. 対策

🟢 基礎（全員がやること）

  1. 出どころのあやしいソフト/拡張機能/アプリを不用意に入れない — 「便利そう」だけで知らない提供元のものを増やさない。ブラウザ拡張やスマホアプリも対象。
  2. 提供元と正確な名前を確認 — 公式サイト・公式ストアから入手し、名前のつづり（1文字違いの偽物）に注意する。
  3. 社内で許可されたソフトを使う — 勝手な「野良ツール」を持ち込まず、許可リストや情シスの案内に従う。
  4. アップデートは正規ルートから — 更新通知を装う偽サイトに注意し、公式アプリ・公式の更新機能から行う。
  5. おかしいと思ったら報告 — 「変なツールを入れたかも」「見慣れない更新が来た」を責めない文化が、拡散を止める。

※ 部品（依存ライブラリ）そのものの管理・検証は、利用者個人ではできない。開発者が🔧で対応する領域。

🔧 応用（エンジニア・運用）

  1. 依存のピン留め（lockfile）と最小化 — package-lock.json / poetry.lock 等でバージョンを固定し、勝手な更新を防ぐ。そもそも使う部品の数を減らす（攻撃面の縮小）。
  2. 脆弱性監査の自動化 — npm audit / Dependabot / SCA ツールで、既知の脆弱性・悪性パッケージを継続検知し、更新を回す。
  3. SBOM（部品一覧表）の作成 — Software Bill of Materials ＝ 使っている部品の“原材料表示”。何が入っているか分からなければ、汚染時にどこが危ないかも分からない。
  4. 署名検証（Sigstore / cosign） — 成果物・コンテナイメージに署名し、「誰が作ったか・改ざんされていないか」を取り込み時に検証する。
  5. ビルドの隔離・再現性（SLSA） — 組み立て工程を外部から触れないよう隔離し、同じ入力から同じ成果物が必ず出る（再現可能ビルド）状態にして、混入を検知できるようにする。
  6. 社内ミラー / 許可リスト — 外部の部品置き場を直接叩かず、検証済みの社内ミラー経由にする。許可した部品だけを通す。
  7. CI/CD の権限最小化とシークレット保護 — 組み立て工程に与える権限を絞り、APIキー・トークンなどの秘密情報を厳重に管理・短命化する。
  8. ベンダー / 委託先のリスク評価 — 取引先・外注先のセキュリティ体制を確認し、与えるアクセス権を必要最小限にする。退出時は権限を確実に止める。

5. 解説動画（実在確認済み）

サプライチェーン専用の特定動画IDは確証が取れないため、個別動画は埋め込まず、IPA（情報処理推進機構）の公式ページへのリンクのみ掲載する。一覧から関連テーマの映像を選べる。

6. チェックリスト

🟢 全員

  • 出どころの不明なソフト・拡張機能・アプリを不用意に入れていない
  • 入手時に提供元と正確な名前（1文字違いの偽物）を確認している
  • 社内で許可されたソフト・正規ルートの更新だけを使っている
  • 見慣れないツールや不審な更新に気づいたら報告する先を知っている

🔧 エンジニア・運用

  • 依存を lockfile でピン留めし、不要な部品を減らしている
  • npm audit / Dependabot / SCA で脆弱性・悪性パッケージを継続監査している
  • SBOM（部品一覧表）を生成・更新している
  • 成果物・イメージの署名を検証（Sigstore / cosign）してから取り込んでいる
  • ビルドを隔離し、再現性（SLSA）を確保している
  • 外部部品は社内ミラー／許可リスト経由に限定している
  • CI/CD の権限を最小化し、シークレットを保護・短命化している
  • ベンダー／委託先のリスクを評価し、アクセス権を最小化・確実に失効している

7. 関連ジャンル・出典

関連ジャンル

出典（一次情報）

  • IPA「情報セキュリティ10大脅威」 — https://www.ipa.go.jp/security/10threats/（「サプライチェーンの弱点を悪用した攻撃」は組織向けの常連）
  • IPA「映像で知る情報セキュリティ」 — https://www.ipa.go.jp/security/videos/index.html
  • JPCERT/CC — サプライチェーン攻撃・OSS脆弱性の注意喚起
  • NIST — SSDF（セキュアソフトウェア開発フレームワーク）／ SLSA（サプライチェーン保証レベル）
  • OpenSSF（Open Source Security Foundation） — OSS供給網セキュリティの実践とツール（Sigstore 等）

合わせて読む