サプライチェーン攻撃（Supply Chain Attack）

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

ソフトウェア開発は、もはや一社だけで完結しない。OSS ライブラリ、CI/CD パイプライン、パッケージレジストリ、コードサイニング証明書――プロダクトが利用者の手元に届くまでの経路全体が「サプライチェーン」であり、攻撃者はその中で最も防御が薄い一点を狙う。被害組織が直接侵害されるのではなく、信頼している上流の提供元が踏み台にされる点が従来の攻撃と根本的に異なる。

なぜ深刻なのか

正規の配布チャネルを経由するため、OWASP が示す一般的な Web アプリケーション脆弱性とは検知の難易度が段違いになる。署名付きアップデートに混入されたバックドアはエンドポイント保護をすり抜け、発見まで数か月を要した事例も珍しくない。npm や PyPI のようなパブリックレジストリでは、タイポスクワッティング（正規パッケージに似た名前で悪意あるパッケージを公開する手口）が繰り返し報告されている。一つの汚染されたライブラリが数千のプロジェクトに波及する――この増幅効果こそがサプライチェーン攻撃の最大の脅威である。

防御の考え方

DevSecOps の文脈では、シフトレフトの原則に沿って依存関係の検証を開発初期から組み込むことが基本戦略になる。具体的には以下のようなアプローチが実務で定着しつつある。

• SBOM（Software Bill of Materials）の生成と管理: プロダクトに含まれる全依存関係を一覧化し、脆弱性データベースと継続的に照合する
• 依存関係のピン留めとハッシュ検証: ロックファイルで依存バージョンを固定し、取得時にチェックサムを検証する
• 最小権限の CI/CD 設計: ビルドパイプラインに過剰な権限を与えない。ゼロトラスト・ネットワーク・アクセスの考え方はネットワークだけでなく、ビルド環境にも当てはまる
• 署名検証の自動化: コミット署名や成果物署名を CI で自動検証し、改ざんされたコードがマージされる前に遮断する

筆者の経験では、SBOM の導入は「何が入っているか分からない」状態を解消するだけで、インシデント発生時の影響範囲特定が劇的に速くなる。

AI 開発におけるリスク

LLM を活用したシステムでは、モデルの重みファイルや学習データもサプライチェーンの一部となる。汚染されたデータセットでファインチューニングされたモデルは、プロンプトインジェクションとは異なる経路で意図しない出力を生成しうる。AI サプライチェーンの信頼性検証は、従来のソフトウェアよりもさらに難しく、業界全体が対策を模索している段階だ。