サプライチェーン攻撃とは

サプライチェーン攻撃とは、標的の組織を直接攻撃するのではなく、その組織が信頼して利用しているソフトウェア、ライブラリ、サービス、ハードウェアなどの供給網 (サプライチェーン) を経由して侵入する攻撃手法です。正規の更新メカニズムや依存関係を悪用するため、境界防御やマルウェア対策をすり抜けやすいという厄介な性質があります。

2020 年代のソフトウェア開発では、1 つのアプリケーションが数百から数千のオープンソースライブラリに依存しています。攻撃者はこの依存関係の連鎖のどこか 1 か所に悪意のあるコードを注入するだけで、そのライブラリを利用するすべての組織に影響を及ぼすことができます。ゼロデイ攻撃と組み合わされた場合、検知はさらに困難になります。

代表的な攻撃パターン

サプライチェーン攻撃にはいくつかの典型的なパターンがあります。

ビルドシステムの侵害: ソフトウェアのビルド・配布インフラに侵入し、正規のバイナリにマルウェアを埋め込む。2020 年 12 月に公表された SolarWinds 事件では、ビルドパイプラインが侵害され、同社の発表で最大 18,000 社が改ざんされた更新をダウンロードしたとされる
依存関係の汚染: npm、PyPI などのパッケージレジストリに悪意のあるパッケージを公開する。タイポスクワッティング (正規パッケージに似た名前) や依存関係かく乱 (Dependency Confusion) の手法が使われる
正規メンテナーの乗っ取り: メンテナーのアカウントを侵害する、あるいは協力者として信頼を得たうえで、悪意のあるコードを正規のリリースに混入する。2024 年 3 月に公表された xz Utils のバックドア (CVE-2024-3094) では、2021 年から 2 年以上かけて開発への関与を深めた人物が、ソースリポジトリではなく配布用アーカイブの側に仕掛けを埋め込んでいた
CI/CD パイプラインの悪用: GitHub Actions や Jenkins などの CI/CD 環境に侵入し、ビルド成果物を改ざんする

いずれのパターンも、正規の配布チャネルを通じてマルウェアが拡散するため、受け取る側が不正を検知しにくい構造になっています。

防御策と対策フレームワーク

サプライチェーン攻撃への防御は、単一の対策では不十分であり、多層的なアプローチが求められます。

依存関係の管理

SBOM (Software Bill of Materials) の作成: アプリケーションが依存するすべてのコンポーネントを一覧化し、脆弱性管理の基盤とする
依存関係の固定とハッシュ検証: ロックファイルでバージョンを固定し、パッケージのハッシュ値を検証して改ざんを検知する
プライベートレジストリの活用: 外部パッケージを直接参照せず、検証済みのパッケージのみを格納したプライベートレジストリを経由する

ビルド・デプロイの保護

再現可能ビルド: 同じソースコードから常に同一のバイナリが生成されることを保証し、ビルド環境の改ざんを検知可能にする
署名と検証: ビルド成果物にデジタル署名を付与し、配布先で署名を検証する。Sigstore などのツールが活用できる
コンテナセキュリティの徹底: コンテナイメージのスキャン、ベースイメージの管理、イメージ署名の検証を実施する

組織的な対策

ゼロトラストの適用: サプライチェーン内のすべてのコンポーネントを信頼せず、継続的に検証する
インシデントレスポンス計画: サプライチェーン侵害を想定したシナリオを含め、検知から封じ込めまでの手順を整備する
SLSA (Supply-chain Levels for Software Artifacts) の活用: Google 発の枠組みで、OpenSSF のプロジェクトとして仕様が公開されている。ビルドの由来 (provenance) をどこまで保証できているかが段階的な水準として定義されており、自組織の到達段階を確かめながら対策を積み上げる

IaC とインフラ供給網のリスク

サプライチェーン攻撃はアプリケーションコードだけでなく、IaC (Infrastructure as Code) の領域にも及びます。Terraform モジュールや CloudFormation テンプレートなど、インフラ定義に使われるサードパーティのコンポーネントが改ざんされた場合、クラウド環境全体が侵害される可能性があります。

IaC のサプライチェーンリスクを軽減するには、以下の対策が有効です。

Terraform モジュールや Helm チャートのバージョンを固定し、ハッシュで検証する
サードパーティモジュールの利用前にコードレビューを実施する
インフラ変更の差分 (plan/changeset) を必ず人間がレビューしてから適用する
最小権限の原則に基づき、IaC パイプラインの実行権限を必要最小限に制限する

ソフトウェアとインフラの両面でサプライチェーンの信頼性を検証する体制を、平時から整えておく必要があります。

よくある誤解

信頼できるベンダーのソフトウェアなら安全: SolarWinds 事件が示すように、大手ベンダーの正規ソフトウェアであっても、ビルドプロセスが侵害されれば悪意のあるコードが混入する。ベンダーの信頼性とソフトウェアの安全性は別の問題であり、受け取る側でも検証が必要。
オープンソースは多くの目で監視されているから安全: 多くのオープンソースプロジェクトは少数のメンテナーに依存しており、すべてのコミットが十分にレビューされているとは限らない。2024 年 3 月に公表された xz Utils のバックドアでは、攻撃者が 2021 年から 2 年以上かけて開発への関与を深め、信頼を得たうえで仕掛けを埋め込んでいた。

サプライチェーン攻撃とゼロデイ攻撃の比較