npmサプライチェーン攻撃が継続中｜`npm install`＝任意コード実行という前提で守るCI/CD

npm install を実行した瞬間、見知らぬ誰かのコードが自社のビルド環境で動く——その前提で開発していますか。 2026年5月から6月にかけて、npm（およびPyPI）を標的とする自己増殖型のサプライチェーン攻撃が継続している。Palo Alto Networksの脅威research部門Unit42は、2026年6月2日に追跡状況を更新し、「Mini Shai-Hulud」と呼ばれる攻撃が脅威アクター「TeamPCP」によって続いていると報告した。

この攻撃は、開発の根幹である**OSS依存とCI/CD（継続的インテグレーション／デリバリ）**を侵入口にする。受託・自社開発を行う組織にとって、これは他人事ではない。本記事では、進行中の攻撃の事実を正確に押さえたうえで、依存とCI/CDをどう守るかを整理する。

この記事の要点

• 2026年5〜6月、npm/PyPIを標的とする自己増殖型のサプライチェーン攻撃（Mini Shai-Hulud／TeamPCP）が継続中（Unit42が6月2日に追跡更新）。

• 手口：CI/CD（GitHub Actions等）を乗っ取り、OIDCトークンやnpm／クラウドの認証情報を窃取。盗んだ資格情報で感染パッケージを再公開し、ワームのように広がる。

• 規模は報告により幅がある。初期バーストは@tanstack系42パッケージ・84バージョン。数日でnpm・PyPI合わせて170以上のパッケージに拡大したとの報告（数値は報告・波により差がある）。

• 注意：この攻撃の一部は、正規のSLSA来歴証明（provenance）が付いた悪性パッケージを公開した。来歴の確認だけでは防ぎきれない。

• 本質は、npm install等の依存導入が任意コード実行になりうるという構造。IPA「情報セキュリティ10大脅威2026」でもサプライチェーン攻撃は組織編の上位（第2位・8年連続）。

何が起きているのか

Unit42の報告（2026年6月2日更新）によれば、攻撃の流れはおおむね次のとおりだ。

• CI/CDの侵害：信頼されたパッケージ（@tanstack系など）のリポジトリで、CI設定の弱点（信頼できないフォークからのワークフロー実行など）を突き、GitHub Actionsを乗っ取る。

• 認証情報の窃取：実行環境のメモリからOIDCトークンを抜き取り、npmトークン、クラウド（AWS／Azure／GCP）の鍵、Vaultトークン、Kubernetesシークレットなど、多数のプラットフォームの資格情報を収集する。

• 自己増殖（ワーム化）：盗んだ資格情報で、メンテナーが管理する他のパッケージを列挙し、感染版を次々と再公開する。これによりワームのように拡散する。

この系譜は、2025年9月の「Shai-Hulud」ワームに始まり、11月のShai-Hulud 2.0、2026年の「Mini Shai-Hulud」へと連なる（個別の攻撃キャンペーンは区別すべきで、同一視はしない）。

なぜ npm install が危ないのか

サプライチェーン攻撃が深刻なのは、依存パッケージの導入そのものが任意コード実行になりうる構造にある。

• npmのライフサイクルスクリプト（preinstall／install／postinstall）は、npm install 時に自動で・開発者やCIの権限で実行される。つまり、悪性パッケージを入れた瞬間、任意のコードが自社環境で動く。これは2025年のShai-Hulud（postinstallスクリプトを悪用）の典型的な侵入口だった。

• 2026年のTanStack系の波では、postinstallよりも**CI/CDパイプラインの乗っ取り（OIDCトークン窃取）**が主な機構だった。攻撃の重心が「開発者のPC」から「CI/CD基盤」へ移っていることに注意したい。

さらに厄介なのは、この攻撃の一部が正規のSLSA来歴証明（provenance）を持つ悪性パッケージを公開したことだ。「来歴があるから安全」とは言い切れない。来歴の確認は有効な一手だが、それ単独では防ぎきれない。

開発組織にとって、これは抽象的なリスクではない。受託開発のCI/CDが侵害されれば、顧客の本番環境やデータにまで影響が及ぶ。サプライチェーン攻撃の文脈はnpm依存のサプライチェーンとインシデント対応（axios事例）・VSCode拡張を狙うサプライチェーン攻撃（GlassWorm）でも扱っている。IPAの脅威全体像は情報セキュリティ10大脅威2026とAIリスクを参照されたい。

守りの実践：依存とCI/CDをセキュアにする

Unit42が示す対策をふまえ、開発組織が取るべき要点を整理する。

• ロックファイル＋npm ci：npm install ではなく npm ci を使い、ロックファイルに固定された依存だけを導入する。

• ライフサイクルスクリプトの抑止：.npmrc で ignore-scripts=true を設定し、不要な自動実行を止める（必要なものは個別に検証）。

• SBOM（部品表）の整備：何に依存しているかを可視化し、侵害公表時に「自社が影響を受けるか」を即座に判定できるようにする。

• 来歴検証＋多層防御：slsa-verifier等で来歴を確認しつつ、来歴だけに依存しない（前述のとおり正規来歴付きの悪性版が存在した）。

• CI/CDトークンの最小権限化：OIDCのスコープを絞り、CIからの外部通信（egress）を制限する。信頼できないフォークからのワークフロー実行（pull_request_targetの濫用）を避ける。

こうしたセキュアな開発プロセス（セキュアSDLC）を、自社の開発・CI/CDに合わせて設計・実装することが重要だ。考え方や実装はシステム開発・AI開発として組み立てられる。

自社のCI/CDと依存、サプライチェーン攻撃に耐えますか

GXOでは、OSS依存・CI/CDのセキュリティ点検から、SBOM整備、CIトークンの最小権限化、セキュアSDLCの設計・実装まで支援しています。「依存が多すぎて把握できていない」段階のご相談を歓迎します。

CI/CD・依存のセキュリティを相談する → GXO お問い合わせ

※ 営業電話はしません ｜ オンライン対応可 ｜ 構想段階の相談だけでもOK

実務判断のポイント

この記事を読むべきなのは、経営者、CIO、情シス、セキュリティ担当、開発責任者です。単に情報を把握するだけでなく、脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応の相談に進めるべきかを判断するための材料として整理する必要があります。

GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。npmサプライチェーン攻撃が継続中｜npm install＝任意コード実行という前提で守るCI/CDに関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。

放置した場合と整備した場合の違い

導入・改善前のチェックリスト

• 対象業務、対象部門、対象データを明文化しているか
• 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
• 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
• 例外処理、承認、差し戻し、監査証跡まで確認しているか
• 社内で判断できる範囲と外部支援が必要な範囲を分けているか
• 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
• 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
• 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
• セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
• 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
• 経営判断に必要な資料を1枚で説明できる状態にしているか
• 次の90日で検証する範囲と、やらない範囲を明確にしているか

GXOの見解

セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。

GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。

GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、診断、監査、保守契約、月次レポート、緊急対応支援へ接続。さらに、チェックリスト型診断を入口に、継続監視・改善支援へ展開。

相談につながる進め方

1. 現在の業務、データ、ツール、担当者を棚卸しする
2. 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
3. 初期対応、90日以内の改善、半年以上の投資を分ける
4. 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
5. 小さく検証し、効果測定後に本番化や横展開を判断する

よくある質問（FAQ）

Q1. 自社は影響を受けていますか？

まず、影響が報告されているパッケージ（@tanstack系など）への依存があるか、SBOMやロックファイルで確認してください。依存の可視化ができていないと、この判定自体ができません。Unit42等のベンダーが公開する影響パッケージ一覧と、自社の依存を突き合わせるのが第一歩です。

Q2. npm install と npm ci は何が違うのですか？

npm ci はロックファイルに固定された依存だけを忠実に導入し、勝手な更新を行いません。CI/CDでは npm ci を使うことで、ビルドのたびに想定外の（侵害された可能性のある）バージョンが入り込むリスクを下げられます。

Q3. 来歴証明（provenance）があれば安全ですか？

いいえ。今回の攻撃の一部は、正規のSLSA来歴証明が付いた悪性パッケージを公開しました。来歴の確認は有効な一手ですが、それ単独では防ぎきれません。ロックファイル運用、スクリプト抑止、SBOM、CIトークンの最小権限化と組み合わせた多層防御が必要です。

Q4. CI/CDの何を見直せばよいですか？

OIDCトークンのスコープを最小化し、CIからの外部通信を制限し、信頼できないフォークからのワークフロー実行（pull_request_targetの濫用）を避けることが要点です。CI環境のメモリからトークンを抜き取る手口が報告されているため、CIに渡す権限と秘密情報を最小限にすることが重要です。

まとめ：依存を「信じる」から「検証する」へ

進行中のnpmサプライチェーン攻撃は、npm install等の依存導入が任意コード実行になりうること、そして攻撃の重心が開発者PCからCI/CD基盤へ移っていることを示している。正規の来歴証明を持つ悪性パッケージまで現れた以上、「信頼された名前だから安全」という前提は通用しない。

守りの要は、依存を可視化し（SBOM）、固定して導入し（ロックファイル＋npm ci）、自動実行を抑止し、CI/CDの権限を最小化する多層防御だ。これらをセキュアな開発プロセスとして自社に実装することが、受託・自社開発の信頼を守る。GXOは、セキュアSDLCの設計・実装をシステム開発・AI開発として支援している。詳細はセキュリティ事業も併せてご覧いただきたい。

依存とCI/CDの「現在地」を点検しませんか

OSS依存の可視化（SBOM）、CIトークンの権限見直し、セキュアSDLCの設計・実装まで、貴社の開発体制に合わせて整理します。受託開発の信頼を守る備えを、一緒に進めましょう。

セキュアな開発体制を相談する → GXO お問い合わせ

参考情報

• Palo Alto Networks Unit42「Monitoring npm Supply Chain Attacks」（2026年6月2日更新。Mini Shai-Hulud／TeamPCPの継続、CI/CD乗っ取り・OIDCトークン窃取・自己増殖、対策＝npm ci／ignore-scripts／SBOM／最小権限CIトークン等）：https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/

• Snyk「TanStack npm packages compromised」（@tanstack系42パッケージ・84バージョンの初期バースト、GitHub Actions経由のOIDCトークン窃取）：https://snyk.io/blog/tanstack-npm-packages-compromised/

• IPA「情報セキュリティ10大脅威 2026」（組織編で「サプライチェーンや委託先を狙った攻撃」が第2位・8年連続。2026年1月29日公表）：https://www.ipa.go.jp/pressrelease/2025/press20260129.html

• ※ 影響を受けたパッケージ数・バージョン数は報告および攻撃の波により差がある。累計ダウンロード数等の数値は概算（スナップショット）である点に留意。

関連記事

• npm依存のサプライチェーンとインシデント対応（axios事例）

• VSCode拡張を狙うサプライチェーン攻撃（GlassWorm）

• 情報セキュリティ10大脅威2026とAIリスク