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

サプライチェーン攻撃とは、標的の組織を直接攻撃するのではなく、その組織が信頼して利用しているソフトウェア、ライブラリ、サービス、ハードウェアなどの供給網 (サプライチェーン) を経由して侵入する攻撃手法です。正規の更新メカニズムや依存関係を悪用するため、従来のセキュリティ対策をすり抜けやすい点が最大の脅威です。

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

代表的な攻撃パターン

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

ビルドシステムの侵害: ソフトウェアのビルド・配布インフラに侵入し、正規のバイナリにマルウェアを埋め込む。SolarWinds 事件 (2020 年) では、ビルドパイプラインが侵害され、約 18,000 の組織に悪意のある更新が配布された
依存関係の汚染: npm、PyPI などのパッケージレジストリに悪意のあるパッケージを公開する。タイポスクワッティング (正規パッケージに似た名前) や依存関係かく乱 (Dependency Confusion) の手法が使われる
正規メンテナーの乗っ取り: オープンソースプロジェクトのメンテナーのアカウントを侵害し、悪意のあるコードを正規のリリースに混入する。xz Utils 事件 (2024 年) では、長期間にわたる信頼構築の後にバックドアが仕込まれた
CI/CD パイプラインの悪用: GitHub Actions や Jenkins などの CI/CD 環境に侵入し、ビルド成果物を改ざんする

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

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

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

依存関係の管理

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

ビルド・デプロイの保護

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

組織的な対策

ゼロトラストの適用: サプライチェーン内のすべてのコンポーネントを信頼せず、継続的に検証する
インシデントレスポンス計画: サプライチェーン侵害を想定したシナリオを含め、検知から封じ込めまでの手順を整備する
SLSA (Supply-chain Levels for Software Artifacts) フレームワーク: Google が提唱するサプライチェーンセキュリティの成熟度モデルに沿って、段階的に対策レベルを引き上げる

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

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

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

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

ソフトウェアとインフラの両面でサプライチェーンの信頼性を検証する体制が、現代のセキュリティには不可欠です。

よくある誤解

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

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