サプライチェーン攻撃とは？【概要・解分類・具体例】

ソフトウェアサプライチェーン攻撃はどのように行われるのか？

サプライチェーン攻撃は、被害者がすでに信頼しているもの——開発ツール、ソフトウェアライブラリ、更新サーバーなど——を侵害し、その信頼を配信経路として利用することで成立します。悪意のあるペイロードは、外部から押し入るのではなく、内部から招き入れられるのです。

つまり、攻撃対象領域は自社のコードだけではありません。コードが依存するすべてのもの、そしてそれを届けるすべての経路が対象になります。

ソフトウェアには、設計・開発・デプロイ・維持管理というライフサイクルがあります。攻撃者はこれらのどの段階も侵害することができます。

それでは、攻撃者が各段階をどのように悪用するのかを見ていきましょう。

設計段階では、攻撃がそもそも最初から組み込まれているケースがあります。

設計段階でプロジェクトにアクセスできる攻撃者は、正規のコードが一行も書かれる前に、バックドアを仕込むことができます。悪意のある機能はアーキテクチャそのものに組み込まれ、後から追加されたものでも、外部から注入されたものでもありません。ソフトウェアは、最初からその状態で出荷されるのです。

開発段階は、サプライチェーン攻撃の大半が発生する場所です。

ここでコードが書かれ、依存関係が取り込まれ、ビルド基盤がソースコードを配布可能な製品へと変換します。攻撃者にはここで複数の手段があります。

オープンソースライブラリに注入された悪意のあるコードは、それをインポートするすべてのアプリケーションに広がります。侵害されたSDKは、それを使って構築されるすべてのプロジェクトを汚染します。さらに、ビルドパイプラインへのアクセス権を得た攻撃者は、ソースコードに一切触れることなく、コンパイル後の出力に直接悪意のあるコードを挿入することもできます。

配布されるバイナリには攻撃コードが仕込まれていても、ソースコード自体は綺麗に見えるのです。

ソフトウェアがビルドされた後は、デリバリ基盤が標的になります。

更新サーバーの侵害は特に効果的です。次の通常の更新を受け入れたユーザーは、何の異変も感じることなく、悪意のあるペイロードをインストールしてしまいます。

盗まれたコード署名証明書は、これをさらに検出しにくくします。悪意のあるソフトウェアが、有効なデジタル署名を伴って届くためです。

配布チャネルは第三の攻撃経路です。ウェブサイト、認証機関、ソフトウェアリポジトリはいずれも侵害され、エンドユーザーに届く前にソフトウェアを横取りされる可能性があります。

メンテナンスフェーズにも、それ自体の脆弱性があります。

サポートが終了したソフトウェアは、セキュリティパッチの提供を受けられなくなります。既知の脆弱性は修正されないまま蓄積し、攻撃者はその隙を突いてきます。

オープンソースプロジェクトにも、これに関連したリスクがあります。多くの重要なプロジェクトは、限られたリソースを持つ小規模なチーム、時には開発者一人だけによって維持管理されています。メンテナーが侵害されたり、プロジェクトが放棄されたりすれば、その代償は深刻なものになりかねません。

実際に確認された事例では、攻撃者が悪意のあるコードを注入する前に、オープンソースコミュニティ内で数年かけて信頼を築いていたケースがあります。その「辛抱強さ」こそが、手遅れになるまで攻撃を発見不可能にする最大の要因です。

ソフトウェアサプライチェーン攻撃には、以下のような種類があります。

• 依存関係の混同（Dependency Confusion）
• タイポスクワッティング
• ビルドパイプラインの侵害およびCI/CDへの侵入
• 悪意のあるオープンソースパッケージ
• 侵害されたソフトウェアアップデート
• 盗まれたコード署名証明書
• SDKおよびサードパーティツールの侵害
• 攻撃経路としての「人間」

サプライチェーン攻撃には、決まった一つの手口があるわけではありません。攻撃者は、最も弱い環（アタックの起点）がどこにあるかによって、異なる侵入経路を悪用します。そしてその弱点は、設定を誤ったパッケージマネージャーから、信頼されたオープンソースのメンテナーまで、あらゆる場所に存在し得ます。

以下の表では、代表的な攻撃手法についてさらに詳しく解説します。中にはコードを直接狙うものもあれば、コードをビルド・配信するインフラを狙うものもあります。そして、その裏にいる「人間」そのものを狙う手法もあります。

この8つすべてに共通する要素は、攻撃者が防御そのものを突破する必要がないという点です。攻撃者に必要なのは、その防御がすでに信頼している何かを見つけ、それを通り道として利用することだけです。それはあるときはパッケージ名であり、またあるときはビルドツール、ソフトウェアアップデート、あるいは人間そのものです。侵入経路はさまざまですが、その仕組みは変わりません。

実際に発生したサプライチェーン攻撃の事例

これから紹介する7つの攻撃は、侵入経路も、標的も、結果もそれぞれ異なります。しかし、共通しているのは一つ——いずれのケースも、被害者は疑う理由のなかったものを信頼していた、という点です。

TeamPCP （2026年）

侵入経路： ビルド基盤

侵害内容： TeamPCPは、Aqua SecurityのTrivy GitHub Actionにおける76個のバージョンタグのうち75個に対して、悪意のあるコミットを強制的にプッシュ（force-push）しました。これらのタグを参照するCI/CDワークフローはすべて、認証情報窃取プログラムを実行し、ランナーのメモリからシークレットを、そしてInstance Metadata Service経由でAWSのクラウド認証情報を収集していました。

拡散の経緯： Trivyの侵害によって盗まれた認証情報は、約4日後にCheckmarxのASTGitHub Actionを汚染する際に使用されました。汚染された各アクションは、ベンダー固有のタイポスクワッティングドメイン（正規のベンダー名に似せたドメイン）を使用していたため、情報の外部送信通信が正規のベンダーから発信されているように見えていました。

確認された兆候： 暗号化されたペイロードを外部ドメインへ送信するアウトバウンドのcurl POSTリクエストが、同一プロセス系列からのInstance Metadata Serviceへのアクセスとともに確認されました。ドメインレピュテーションツールはこの攻撃を完全に見逃しました。タイポスクワッティングドメインは新規登録されたばかりで、スコア上は「クリーン」と判定されていたためです。

結果： 2つの波を通じて、数千のリポジトリが影響を受けました。この連鎖的な侵害は、汚染された単一のCI/CDアクションが、感染が特定される前に開発エコシステム全体へ静かに拡散し得ることを示しました。

Shai-Hulud （2025年）

侵入経路： npmおよびPyPIパッケージレジストリ

侵害内容： Shai-Huludは、オープンソースパッケージレジストリを標的とした、初めて記録された自己増殖型ワームです。npmおよびPyPIに公開された悪意のあるパッケージには、認証情報窃取ペイロードが仕込まれており、攻撃者がさらに関与することなく、被害者の環境内にある他のパッケージへ能動的に感染を広げました。

拡散の経緯： このマルウェアは、依存関係インストールのプリインストール段階で実行されるため、ユーザーの操作を一切必要としませんでした。CI/CD認証情報とクラウドトークンを収集し、攻撃者が管理する基盤へ情報を送信した上で、さらに他のパッケージを改変することで拡散を続けました。第二波である「Shai-Hulud 2.0」では、その範囲が数万に及ぶGitHubリポジトリへと拡大しました。

確認された兆候： 通常とは異なるプリインストールスクリプトの実行と、許可されていないエンドポイントへのアウトバウンド通信が確認されました。単一の感染が検出された時点で、関連する環境全体への拡散はすでに進行していました。

結果： このキャンペーンは数万のリポジトリに影響を及ぼしました。盗まれた認証情報は、「Sha1-Hulud: The Second Coming」というタグが付けられた公開GitHubリポジトリへ送信されていました。

XZ Utils （2024年）

侵入経路： オープンソースのメンテナー

侵害内容： ほぼ2年間にわたり、偽の身元を使って活動していた攻撃者が、多くのLinuxディストリビューションに搭載されている広く使われるオープンソースの圧縮ライブラリ「XZ Utils」に対して、正規の貢献を行っていました。その貢献自体は本物であり、信頼は意図的に築き上げられたものでした。

拡散の経緯： 信頼を得た後、攻撃者はこのライブラリにバックドアを組み込みました。これは、影響を受けたシステム上でSSH経由のリモートコード実行を可能にするものでした。悪意のあるコードは複数のファイルとビルドスクリプトにわたって難読化されており、標準的なコードレビューを通過していました。

確認された兆候： これを発見したきっかけは、セキュリティツールではありませんでした。あるデベロッパーが、該当バージョンを実行しているシステムでのSSH認証に、通常よりも時間がかかっていることに気づいたのです。この遅延の異常が、調査のきっかけとなりました。

結果： この攻撃は、大規模な展開に至る前に発見されました。もし安定版のLinuxディストリビューションに大規模に到達していた場合、その潜在的な影響は計り知れないものだったでしょう。

XZ Utilsの攻撃者は、メンテナーがバーンアウト（燃え尽き）状態にあったことを理由に、意図的にその人物を標的にしたと考えられています。攻撃者は、ストレスを抱えている時期に支援的なメッセージや協力の申し出を送り、徐々にプロジェクトへの支配力を強めていきました。このソーシャルエンジニアリングは、持続的かつ計画的なものでした。

3CX （2023年）

侵入経路： 過去のサプライチェーン侵害

侵害内容： 3CXへの攻撃自体が、それ以前に発生した別のサプライチェーン攻撃の結果でした。ある従業員が、サードパーティ製アプリケーションの侵害されたソフトウェアをインストールしていたのです。これにより、攻撃者は3CXの開発環境内に足がかりを得ることになりました。

拡散の経緯： 攻撃者は、3CXの公式デスクトップアプリケーションのインストーラーにトロイの木馬を仕込みました。この悪意のあるバージョンは正規の証明書で署名され、公式の更新メカニズムを通じて配布されました。侵害されたインストーラーは、攻撃者が管理する基盤と通信する情報窃取プログラムを展開しました。

確認された兆候： セキュリティツールは異常な挙動を検知していましたが、そのソフトウェアが署名済みであり、信頼されたベンダーから提供されたものであったため、当初の報告は問題なしとして退けられました。

結果： 3CXは60万社以上の企業にサービスを提供しています。下流への潜在的な影響は非常に大きなものでした。

3CXは、サプライチェーン攻撃が別のサプライチェーン攻撃を実行するために利用された、初めて公に記録された事例です。これは「連鎖的（カスケード）サプライチェーン侵害」と呼ばれることもあります。サードパーティ製アプリケーションへの最初の侵害が、3CX自身のビルド環境への侵入経路となりました。

Kaseya（2021年）

侵入経路： マネージドサービスプロバイダー（MSP）向けソフトウェアの脆弱性

侵害内容： 攻撃者は、MSPが顧客環境を管理するために使用するリモート監視・管理プラットフォームの認証バイパスの脆弱性を悪用しました。このプラットフォームを侵害することで、攻撃者は管理下にあるすべてのエンドポイントにコマンドを送り込む権限を手に入れました。

拡散の経緯： ランサムウェアは、顧客のネットワーク全体に同時展開されました。コマンドは信頼された管理プラットフォームを経由して送られたため、エンドポイントのセキュリティツールはそれらをブロックしませんでした。

確認された兆候： ほとんどありませんでした。コマンドは信頼されたプラットフォームから発信されており、通常の管理業務と一致するように見えていました。

結果： この攻撃は1,500以上の下流組織に影響を及ぼしました。攻撃者は、すべての被害者に対応する復号鍵と引き換えに、7,000万ドルを要求しました。

SolarWinds（2020年）

侵入経路： ビルド基盤

侵害内容： 攻撃者はSolarWindsのソフトウェアビルド環境へのアクセス権を獲得し、広く使われるネットワーク監視プラットフォーム「Orion」のコンパイル過程に悪意のあるコードを注入しました。生成された更新プログラムは正規の証明書でデジタル署名され、公式チャネルを通じて配布されました。

拡散の経緯： 後に「SUNBURST」と名付けられた悪意のあるコードは、インストール後最長2週間ほど休止状態を保ち、その後に活動を開始しました。このコードは、正規のOrionの通信に紛れ込むように設計されており、自動検知ツールが無視するようにチューニングされた範囲内にわずかに収まるパターンで、攻撃者が管理する基盤と通信していました。

確認された兆候： 通常範囲の境界にあたる、異常なDNSパターンとHTTP通信でした。セキュリティツールはこれらを見逃しました。

結果： この攻撃は数ヶ月間発覚しませんでした。およそ18,000の組織が侵害された更新プログラムをインストールし、そのうち100未満の組織が、複数の米国連邦機関を含め、より深いレベルの攻撃対象として選別されました。

Outcome: The attack went undetected for months. Approximately 18,000 organizations installed the compromised update. Fewer than 100 were selected for deeper exploitation, including multiple U.S. federal agencies.

参考情報： SUNBURSTがインストール後に最長14日間の休止期間を設けていたのは、初期の感染と、検知のきっかけとなり得る挙動の変化との間に「距離」を作るためでした。この滞留時間は、副作用ではなく、意図的な設計上の仕組みだったのです。

NotPetya （2017年）

侵入経路： ソフトウェア更新の仕組み

侵害内容： 攻撃者は、広く使われる会計アプリケーションの更新基盤を侵害し、通常のソフトウェア更新を通じて、一見ランサムウェアのように見えるものを配信しました。しかし、それはランサムウェアではありませんでした。復号する手段が存在しない、「ワイパー（データ破壊型マルウェア）」だったのです。

拡散の経緯： NotPetyaは、リークされたエクスプロイトを利用して、ユーザーの操作を介さずにネットワーク内を横方向に移動しながら拡散しました。一度内部に侵入すると、その拡散速度は非常に速いものでした。

確認された兆候： ほとんどありませんでした。更新プログラムは正規の提供元から届いており、初期の挙動は既知のランサムウェアに似ていました。組織が事態を正しく理解した頃には、すでに被害は広がっていました。

結果： 全世界での被害額は推定100億ドルを超えました。大手の海運、製薬、物流企業は、数週間分の業務能力を失いました。

サプライチェーン攻撃はなぜ検知が難しいのか？

サプライチェーン攻撃の検知が難しいのは、攻撃そのものが、すでに信頼されているものと全く同じ見た目で届くからです。

これは、単なる漠然とした感想ではありません。これこそが、技術的に本質的な問題なのです。従来のセキュリティ対策はすべて、「異常なもの」を検知するように設計されています。しかしサプライチェーン攻撃は、まさに「正常なもの」と区別できないように設計されているのです。

ここからは、従来の防御の各層が、なぜそれぞれ機能しないのかを見ていきます。

コード署名とハッシュ検証は、ソフトウェアが署名された時点から改変されていないことを確認するものです。しかし、そのソフトウェアが実行時に何をするかについては、何も示してくれません。悪意のあるバイナリに完全に有効な署名がついていることは、矛盾ではありません。それこそが、この手口の本質なのです。

静的スキャンは、既知のパッケージに存在する既知の脆弱性を検出します。しかし、未知の悪意ある挙動を検知することはできません。過去に前例のないコードにフラグを立てることもできません。そして、パッケージが実行時に何をするかを見ることもできません。見えているのは、あくまで「静止した状態」で何を含んでいるかだけです。

休止状態のペイロードは、この両方を無力化します。攻撃者は、インストール後数日から数週間、悪意のあるコードを意図的に非活動状態に保ち、特定の条件下でのみ起動するように設計することが一般的です。挙動が変化する頃には、当初の侵害との関連性を突き止めることは難しくなっています。

滞留時間の長さは、すべての問題を増幅させます。例えばSolarWindsの侵害は、数ヶ月間発覚しませんでした。悪意のあるコードは、その存在が知られるまでの間、数千の環境内に潜在し、活動を続けていました。攻撃者が発覚せずに活動を続ける期間が長くなるほど、責任の特定は難しくなり、被害はより深刻になっていきます。

XZ Utilsのバックドアは、この問題を具体的に示す事例です。このコードは、コードレビュー、署名、静的解析といった、ビルド時のあらゆる検査をすべて通過していました。それを発見したのは、あるデベロッパーが「SSH認証がわずかに時間がかかっている」ことに気づいたからでした。遅延の異常です。セキュリティツールではありませんでした。

要点：

ビルド時の検知は必要不可欠ですが、それだけでは十分ではありません。ソフトウェアが実行時に何をするか——それこそが、唯一の「真実」なのです。

AIはサプライチェーン攻撃の状況をどのように変えているのか？

AIは、新しい攻撃カテゴリーを生み出したわけではありません。既存の攻撃を、より速く、より安く、そしてより発見しにくいものにしているのです。

最も直接的な影響は「規模」です。

攻撃者は、大規模言語モデル（LLM）を使い、人間によるレビュープロセスでは到底追いつけない量の、説得力のある悪意あるパッケージを生成しています。

かつては手作業を必要としていたタイポスクワッティングのキャンペーンも、今では自動化できるようになりました。2024年には、セキュリティ研究者らが主要なレジストリ全体で数千件の悪意あるパッケージを特定しており、その中にはAIライブラリを標的としたものがかなりの割合を占めていました。

国家が支援する攻撃者もまた、脆弱性調査や、開発者・オープンソースメンテナーを狙った標的型フィッシングキャンペーンに、AIを活用し始めています。

MLモデルのサプライチェーンは、より新しいリスクをもたらしています。

多くの組織は、開発者がオープンソースライブラリを取得するのと同じように、公開リポジトリから事前学習済みモデルを取得する機会が増えています。こうしたモデルには、重み（weights）や学習データの中に悪意のあるコードが埋め込まれている可能性があります。つまり、デプロイ時に起動し、標準的なスキャンツールでは検知できないペイロードです。

オープンソースプロジェクトへのAI支援によるコード貢献も、この問題をさらに複雑にしています。こうしたコードは、監査が難しく、責任の所在を特定することも難しいのです。

しかし、次の点は留意すべきでしょう。

防御側も同様に前進しています。

AI支援による行動検知は、パッケージの挙動、ネットワーク通信、実行時のアクティビティといった領域全体で、異常なパターンを大規模に識別する能力を向上させています。攻撃者がより速く動くために使っているのと同じ技術が、人間の分析担当者ではとても手作業では回せないような検知パイプラインにも応用されているのです。

規制当局も対応を進めています。EUのAI法や、ソフトウェアサプライチェーンの完全性に関する最近の大統領令などは、AIコンポーネントの透明性——モデルの出自（プロベナンス）や、AIシステム向けのソフトウェア部品表（SBOM）を含む——について、公式な基準を確立し始めています。

サプライチェーン攻撃から守るための方法

単一の対策だけで、サプライチェーン攻撃を完全に防ぐことはできません。有効なのは、検知・緩和・防止にまたがる、多層的なアプローチです。

それぞれの層は、攻撃の異なる段階に対応しており、この3つすべてが必要不可欠です。

検知

まずはここから始めましょう。ビルド時の対策だけでは、そこをすり抜けてしまうものを検知できないからです。

実行環境にインストゥルメンテーションを施し、次のような行動シグナルを監視してください。予期しないプロセスの実行、異常なシステムコール、不明なエンドポイントへのネットワーク接続、権限昇格の試み、そして通常の範囲を超えたファイルシステムへのアクセスです。

これらのシグナルは、既知のシグネチャを必要としません。必要なのは、通常時の基準(ベースライン)と、そこからの逸脱を見極める能力です。

コンテナやKubernetesを運用している場合、定期的なスキャンだけでは不十分です。ワークロードは一時的な存在であるため、すべてのワークロードのライフサイクルにわたる継続的なランタイムモニタリングが必要です。スナップショットでは足りません。

‍

プロのヒント： まずは、最もリスクの高いワークロードから着手し、その挙動のベースラインを確立しましょう。すべてを同時にベースライン化しようとすると、かえってノイズが増え、逸脱の識別が難しくなってしまいます。

緩和

何かが侵入してくることを前提に、その被害範囲を最小限に抑えましょう。

すべてのアプリケーション、サービス、依存関係について、実際に機能するために必要なものだけを見極め、それ以外はすべて取り除きましょう。ビルド環境とランタイム環境の間にネットワークの分離を徹底し、侵害されたコンポーネントが横方向に移動できないようにしてください。そして、ソフトウェア部品表(SBOM)をランタイムデータと組み合わせて活用し、修復の優先順位を決めましょう。

インストールされているものすべてではなく、実際に実行されているコードに存在する脆弱性に焦点を当てることが重要です。

プロのヒント： 依存関係を最小権限の観点で見直す際は、設定されている権限だけを確認するのではなく、実行時に実際に使用されている権限を確認してください。その両者の間にあるギャップこそが、本当のリスクが潜んでいる場所です。

防止

コードが出荷される前に、攻撃者が利用できる領域を減らしておきましょう。

すべてのアプリケーションについて、ソフトウェア部品表(SBOM)を生成・維持してください。コンテナイメージには署名を行い、アドミッションコントロールを徹底することで、検証されていないイメージが本番環境に到達しないようにしましょう。

CI/CDパイプラインを強化してください。シークレットを定期的にローテーションし、ビルドエージェントには最小権限を適用し、ビルドシステムとデプロイシステムを分離しましょう。依存関係のバージョンを固定し、ビルドごとにスキャンを行ってください。

そして、サードパーティのツールやサービスを組み込む前に、ベンダーのセキュリティ体制を評価しましょう。

プロのヒント： ベンダーを導入する前に、次の2つの質問をしてください。「ビルドパイプラインをどのように保護しているか」、そして「統合する対象についてSBOMを提示できるか」。どちらか一方にでも答えられない場合、それは重要なリスクの兆候と考えられます。

規制当局はサプライチェーンリスクにどう対応しているのか？

サプライチェーン攻撃は、もはや単なるセキュリティ上の問題ではありません。政策上の課題でもあるのです。

各国政府や標準化団体は、組織がソフトウェアを構築・配布する方法に影響を与えるフレームワーク、義務、法的責任をもって対応を進めています。

規制対応はまだ発展途上にありますが、その方向性は明確です。ソフトウェアサプライチェーン全体における透明性、追跡可能性、そして責任の所在——これらは、もはや推奨事項ではなく、必須要件になりつつあります。

それでは、主要なフレームワークと規制を比較してみましょう。

これらのフレームワークは、それぞれ異なる機能を持ち、異なる対象者に向けたものです。中には法的拘束力を持つものもあれば、任意のガイドラインにとどまるものもあります。

しかし、共通しているのは一つの前提です。組織は自らのソフトウェアに何が含まれているかを理解し、それがどのように構築されたかを示せるようにすべきだ、という期待です。

このリストにあるすべてのフレームワークにおいて、繰り返し登場する要件があります。それが、ソフトウェア部品表(SBOM)です。

SBOMがあることで、サプライチェーンの透明性は初めて実践可能なものになります。SBOMがなければ、新たな脆弱性が公表された際に、組織は自らの影響範囲を評価することができません。あるコンポーネントが侵害された場合にも、効果的な対応ができません。そして、規制当局がますます求めるようになっている透明性の要件を満たすこともできません。

‍