サプライチェーン攻撃は、取引先やソフトの配布経路など、信頼しているつながりを利用して被害を広げる攻撃です。利用中のサービスを正面から狙う代わりに、そのサービスが頼っている別の場所を入口にします。
「自分は怪しいサイトから何も入れていないのに、なぜ関係するの？」という疑問は、このつながりを見ると分かりやすくなります。まずは、ソフトの部品を通る場合と、取引先を通る場合を分けてみましょう。
サプライチェーン攻撃は信頼している経路を狙う
サプライチェーンは、製品やサービスができて届くまでのつながりです。物を作る工場なら、材料の仕入れ先や部品メーカー、配送会社などが関わります。
ソフトウェアにも似たつながりがあります。アプリを作る人がすべてを一から書くとは限りません。ほかの開発者が作った機能を取り込んだり、外部の道具で組み立てたり、別の会社へ管理を任せたりします。
そうした関係を攻撃に利用するのが、サプライチェーン攻撃です。JPNICの用語解説でも、関係先を足掛かりにする方法と、製品へ悪意のあるソフトを組み込む方法が挙げられています。
部品や更新ファイルへ悪意のある処理が入り、取り込んだ環境へ届く。
関係先へ侵入し、預けていた権限や接続を利用して別の組織へ進む。
代表的な経路の模式図です。関係があるすべての組織へ必ず被害が及ぶわけではありません。
つながりがあるだけで、必ず被害が広がるわけではありません。どの情報やシステムへ届く権限があるか、問題の部品を実際に使ったかによって、影響は変わります。
ソフトウェアの部品が改ざんされると何が起きる？
ソフトの「部品」とは、よく使う処理をまとめたプログラムなどのことです。画面を表示する、日付を扱う、通信する、といった機能を再利用できます。こうした部品はライブラリ、配布用にまとめたものはパッケージなどと呼ばれます。
たとえば、三つのアプリが同じ日付表示の部品を使っているとします。その部品の配布物に悪意のある処理が混ざると、取り込んだアプリや、そのアプリを作る環境へ影響が及ぶ可能性があります。
完成したアプリを使うときだけが、危険が生じる場面ではありません。 部品を入れる際の処理や、アプリを組み立てる道具が入口になる場合もあります。MDNのサプライチェーン攻撃の解説は、部品だけでなく、編集ソフトや開発用の追加機能なども対象に含めています。
npmで起きた事例から分かること
npmは、JavaScriptなどの開発で使うパッケージを配布・管理する仕組みです。Node.js本体とは別の役割があります。
TanStackの公式事後報告によると、2026年5月11日、同プロジェクトの一部パッケージに悪意のある版が公開されました。対象の版をインストールすると、開発環境にある認証情報を盗む処理が動く仕組みでした。
同報告の5月15日更新では、影響を受けた範囲と、該当版の削除などの対応が示されています。これは過去の特定の版の事例で、TanStackのすべての製品や現在の配布物が侵害されているという意味ではありません。
事例のポイントは、「有名な名前だったか」だけでは判断できないことです。どの部品の、どの版を、いつ、どこで使ったかが、影響を確かめる手がかりになります。
委託先への侵入とソフトの部品の改ざんを比べる
どちらもつながりを利用しますが、入り方と確認する場所が違います。
| 比較する点 | ソフトの配布物を通る場合 | 委託先などを通る場合 |
|---|---|---|
| 入口の例 | 部品、更新ファイル、開発用の道具 | 管理を任せた会社のアカウントや接続 |
| 広がる仕組み | 問題の配布物を取り込んで実行する | 任せていた操作権限や接続を悪用する |
| 確認の手がかり | 製品名、版、導入した時期、実行した場所 | 取引関係、接続範囲、預けたデータ、許可した操作 |
外部サービスとの接続にAPIを使うこともありますが、APIを使っているだけで攻撃されたことにはなりません。つながる機能があることと、その経路が実際に悪用されたことを分けます。
脆弱性が見つかったニュースは、全部この攻撃？
違います。脆弱性は、攻撃に利用され得る弱点です。悪意なく作ったプログラムにも見つかります。一方、悪意のある処理を配布物へ混ぜる行為は、意図的な改ざんです。
部品の弱点がサプライチェーンのリスクになることはありますが、「修正版が出た」という事実だけで「誰かに部品を改ざんされた」とは判断できません。Node.jsやPHPの更新情報でも、弱点の修正なのか、配布経路への侵入なのかを確認する必要があります。
また、外部企業で情報漏えいが起きたことだけで、すべてをサプライチェーン攻撃と呼ぶのも早計です。公表された侵入経路や、どこへ被害が及んだかを見ます。
サプライチェーン攻撃に備えて配布元・権限・更新情報を見る
普通の利用者が、アプリに含まれる全部の部品を調べるのは現実的ではありません。自分の立場でできる確認と、提供側に必要な対策を分けておきましょう。
| 立場 | 確認すること |
|---|---|
| アプリを使う人 | 正規の配布元を使う。公式のお知らせで対象製品・版・必要な対応を確かめる |
| アプリを作る人 | 取り込む部品と版、提供元、実行時に渡す権限や秘密情報を把握する |
| 管理や委託を担当する人 | 外部に許す接続や操作を必要な範囲に絞り、問題発生時の連絡と停止方法を決める |
正規の配布元を使うことは大切ですが、それだけでどんな侵害も防げるわけではありません。公式から問題の対象が公表されたら、自分が使った版と照合することまで含めて考えます。
開発では、使っている部品の一覧を管理すると、後から調べやすくなります。「ソフトウェア部品表（SBOM）」という言葉は、その一覧を扱う文脈で登場します。ここでは、アプリにも部品の把握が必要だと分かれば十分です。
更新が怖いから、全部止めた方がよい？
更新をずっと止めると、既知の弱点を修正できなくなります。逆に、侵害が公表された最中に、内容を見ずに何でも入れ直せばよいわけでもありません。
対象の版、公式の対処、更新先を確認して対応します。すでに問題の部品を動かした場合は、入れ直すだけで十分か、認証情報の交換なども必要かを公式案内で確かめます。仕事の環境なら管理担当へ連絡してください。
クラウドや外部の部品を使う便利さは、多くの人の仕事に支えられています。そのつながりを全部避けるのではなく、何を使い、誰に何を任せているかが分かる状態にすることが、問題が起きたときの助けになります。
