Supply Chain Attack

サプライチェーン攻撃（Supply Chain Attack）とは、ソフトウェアやハードウェアの開発・製造・配布の過程（サプライチェーン）に侵入し、正規の製品やサービスに悪意のあるコードやコンポーネントを混入させるサイバー攻撃手法です。最終的なターゲットを直接攻撃するのではなく、信頼されたサプライヤーや開発プロセスを経由して間接的に攻撃を行います。

現代のソフトウェア開発は多数のオープンソースライブラリや外部サービスに依存しており、依存関係攻撃（Dependency Attack）のリスクが増大しています。npmやPyPIなどのパッケージリポジトリに悪意あるパッケージを公開するタイポスクワッティングや、内部パッケージ名と同名のパッケージを公開リポジトリに登録する依存関係混乱攻撃が報告されています。

また、CI/CDパイプラインやビルドシステムへの侵入によるビルドシステム攻撃も深刻な脅威です。正規のビルドプロセスに悪意あるコードを挿入することで、コード署名された正規の配布物にマルウェアを含めることが可能になります。サプライチェーン攻撃は発見が極めて困難であり、一度成功すると広範な被害をもたらすため、近年最も警戒されている攻撃手法の一つです。

サプライチェーン攻撃の種類

• ソフトウェアサプライチェーン攻撃：ソフトウェアの開発・ビルド・配布プロセスに侵入し、正規のソフトウェアアップデートにマルウェアを混入させる。ソースコードリポジトリ、CI/CDパイプライン、アップデートサーバーなどが攻撃対象
• ハードウェアサプライチェーン攻撃：製造過程でハードウェアコンポーネントに悪意あるチップや回路を埋め込む。ファームウェアの改ざんやバックドアの挿入が含まれる。発見が極めて困難
• サービスプロバイダー攻撃：MSP（マネージドサービスプロバイダー）やクラウドサービスプロバイダーを侵害し、そのサービスを利用しているすべての顧客に対して攻撃を展開する。一度の侵害で多数の組織にアクセス可能

SBOM（Software Bill of Materials）

SBOMは、ソフトウェア製品に含まれるすべてのコンポーネント（オープンソースライブラリ、サードパーティモジュール、依存関係）の一覧表です。製品に含まれるすべての構成要素を可視化することで、脆弱性管理とサプライチェーンリスクの把握を支援します。

米国では2021年の大統領令（EO 14028）によりSBOMの提供が連邦政府向けソフトウェアに義務化されました。主要なSBOMフォーマットとして、SPDX（Software Package Data Exchange）とCycloneDXがあります。SBOMを活用することで、新たな脆弱性が発見された際に、影響を受ける製品を迅速に特定できます。

依存関係混乱攻撃

依存関係混乱攻撃（Dependency Confusion Attack）は、2021年にセキュリティ研究者のAlex Birsan氏によって公開された攻撃手法です。多くのパッケージマネージャーが内部パッケージよりも公開リポジトリのパッケージを優先する挙動を悪用します。

攻撃者は、ターゲット企業が内部で使用しているパッケージ名を特定し、同名のパッケージをより高いバージョン番号で公開パッケージリポジトリ（npm、PyPI等）に登録します。ビルドシステムが自動的に公開リポジトリの高バージョンパッケージを取得し、悪意あるコードが実行されます。この手法はApple、Microsoft、PayPalなど大手テック企業でも有効であることが実証されました。

コードサイニング

コードサイニング（Code Signing）は、ソフトウェアの開発者が自身の秘密鍵でコードにデジタル署名を付与し、ソフトウェアの真正性と完全性を保証する技術です。ユーザーは署名を検証することで、ソフトウェアが正規の開発者によって作成され、配布後に改ざんされていないことを確認できます。

ただし、コードサイニングの鍵が盗まれた場合、攻撃者はマルウェアに正規の署名を付与できるため、鍵の保護が極めて重要です。HSM（Hardware Security Module）での鍵管理や、署名プロセスのアクセス制御を厳格に行う必要があります。

SLSAフレームワーク

SLSA（Supply-chain Levels for Software Artifacts、スルサ）は、Googleが提唱するソフトウェアサプライチェーンセキュリティのフレームワークです。ソフトウェアアーティファクトの完全性を保証するための段階的なセキュリティレベルを定義しています。

• Level 1：ビルドプロセスの文書化。ビルドがどのように行われたかの来歴（Provenance）情報を記録
• Level 2：ホストされたビルドサービスの使用。ビルドがバージョン管理されたソースから実行され、来歴情報が署名される
• Level 3：ハード化されたビルド環境。ビルドプラットフォームが改ざん防止機能を持ち、来歴情報が偽造不可能

SLSAは、ソースコードの改ざん、ビルドプロセスの侵害、配布物のすり替えなど、サプライチェーンの各段階での攻撃に対する防御を体系的に提供します。

• 01
  SBOMの作成と管理：すべてのソフトウェア製品についてSBOM（Software Bill of Materials）を作成・維持してください。SPDX またはCycloneDXフォーマットを使用し、CI/CDパイプラインに自動生成を組み込みましょう。新たなCVEが公開された際に、影響を受けるコンポーネントを即座に特定できます。
• 02
  依存関係の検証と固定：パッケージマネージャーのロックファイル（package-lock.json、Pipfile.lock等）を使用して依存関係のバージョンを固定し、ハッシュ検証を有効化してください。依存関係の自動更新にはDependabotやRenovateを使用し、更新内容を必ずレビューしてからマージしましょう。
• 03
  ビルドシステムのセキュリティ強化：CI/CDパイプラインのアクセス制御を厳格化し、ビルドに使用するシークレット（APIキー、署名鍵等）の管理にシークレットマネージャーを使用してください。SLSAフレームワークに沿ったビルドの来歴（Provenance）情報の生成と署名を実装しましょう。
• 04
  コード署名と検証の実装：すべてのリリースアーティファクトにコードサイニングを適用し、署名鍵をHSM（Hardware Security Module）で保護してください。ソフトウェアのインストール・更新時に署名検証を自動的に実行し、署名が無効な場合はインストールを拒否する仕組みを導入しましょう。
• 05
  サードパーティリスクの評価：外部のソフトウェアベンダーやサービスプロバイダーに対して、セキュリティ評価を定期的に実施してください。SOC 2レポート、ペネトレーションテスト結果、セキュリティ認証の確認に加え、インシデント対応計画の有無も評価項目に含めましょう。
• 06
  内部パッケージリポジトリの保護：依存関係混乱攻撃を防止するため、内部パッケージ名を公開リポジトリに予約登録（名前空間の確保）してください。パッケージマネージャーの設定で内部レジストリを優先するよう構成し、スコープ付きパッケージ（@org/package-name等）の使用を徹底しましょう。