title: "npmサプライチェーン攻撃 2026年版｜provenanceでも汚染される時代の依存管理・防御設計チェックリスト" description: "2026年はaxios・node-ipc・Red Hat（Miasma）・Mastraと、npm依存の汚染が連鎖した。SLSA provenance付きの正規パッケージすら乗っ取られる時代に、CTO・開発リーダー・セキュリティ担当が設計すべき依存ピン留め、postinstall制御、SBOM、CI/CD権限分離を、一次情報をもとにチェックリスト化する。" keyword: "npm サプライチェーン攻撃 2026 依存管理 provenance 防御 チェックリスト" slug: "npm-supply-chain-2026-defense-checklist-evergreen-20260625" date: "2026-06-25" updatedAt: "2026-06-25" category: "セキュリティ" tags: ["サプライチェーン攻撃","npm","DevSecOps","依存管理","セキュア開発"] author: "GXO株式会社" lead_summary: "2026年はnpm依存の汚染が連鎖。provenance付きでも汚染される前提で防御を設計する。"
npmサプライチェーン攻撃 2026年版｜provenanceでも汚染される時代の依存管理・防御設計チェックリスト
結論：自社のコードが安全でも、npm install 一回で侵害される時代になった
2026年に入ってから、npm（Node.jsのパッケージ管理）を経由したサプライチェーン攻撃が立て続けに起きている。axios、node-ipc、Red Hat配下のパッケージ群、AIエージェント開発フレームワークMastra——いずれも「自社が書いたコード」ではなく「自社がビルドに使う部品」が乗っ取られた事案である。
押さえるべき結論は3つだ。
- 被害は自社コードの脆弱性ではなく、依存パッケージそのものの汚染で起きる。 開発者が
npm installを一度実行しただけで、認証情報の窃取やバックドアの埋め込みが始まる事案が複数確認されている。 - 「正規メンテナーが署名している」「SLSA provenance（来歴証明）が付いている」は、もはや安全の証明にならない。 2026年6月のRed Hat事案では、攻撃者が正規のCI/CDパイプラインを乗っ取り、本物のSLSA provenanceを付けた汚染パッケージを公開した（後述）。
- 防御の主戦場はアプリケーションではなく、依存管理とCI/CDパイプラインの統制に移った。 依存のピン留め、インストール時スクリプトの制御、SBOM、CI/CDの権限分離が、もはや「あれば良い」ではなく前提になった。
押さえるべき1点：サプライチェーン攻撃の防御は「汚染を完全に防ぐ」より「汚染される前提で被害範囲を最小化する」設計へ切り替える。
この記事は、CTO・開発リーダー・セキュリティ担当に向けて、2026年に何が起きたのか、provenanceの限界はどこにあるのか、そして自社で今すぐ着手できる防御設計を、一次情報をもとにチェックリスト形式で整理する。すぐに体制づくりへ動きたい場合はDevSecOpsによるセキュア開発体制、サプライチェーン攻撃を含むセキュリティ事故の類型はセキュリティ失敗図鑑で押さえられる。なお、本日付で公開しているMastra事案の速報解説はMastra npmパッケージのバックドア化（Sapphire Sleet）にまとめている。本記事はそれを含む2026年の傾向と、再現性のある防御設計に焦点を当てた総説である。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
2026年のnpm汚染は「単発の事故」ではなく「連鎖」になった
2026年のnpmサプライチェーン攻撃の特徴は、個別事案の派手さではなく、手口が定着し、短期間に繰り返されている点にある。主要な公表事案を時系列で整理する。
| 時期 | 対象パッケージ | 概要 | 一次/主要出典 |
|---|---|---|---|
| 2026年3月31日 | axios（HTTPクライアント、週1億DL超） | 悪性版 1.14.1 / 0.30.4 が公開。plain-crypto-js という偽の依存をpostinstallで読み込ませRAT（遠隔操作型マルウェア）を配信。約3時間で削除。Microsoftは北朝鮮系Sapphire Sleetに帰属 | Microsoft Security Blog（4/1）、CISA Alert（4/20） |
| 2026年5月14日 | node-ipc（IPCライブラリ、週約80万DL規模） | 過去のリリース実績がないメンテナーアカウント（atiertant）から悪性版3本を公開。約90種類の認証情報（クラウド鍵、SSH、Kubernetes、DBパスワード等）を窃取。失効ドメインの再取得が侵入の起点 | Snyk、BleepingComputer、CSO Online |
| 2026年6月1日 | @redhat-cloud-services 配下（32パッケージ・90超バージョン） | 正規CI/CDパイプライン（GitHub Actions OIDC）を乗っ取り、本物のSLSA provenance付きで汚染版を公開。自己増殖する「Miasma」ワーム。preinstallで4.2MBのドロッパーを実行 | Microsoft Security Blog（6/2）、Red Hat RHSB-2026-006 |
| 2026年6月17日 | Mastra（AIエージェント開発FW、140本超） | タイポスクワット easy-day-js を依存注入。乗っ取ったメンテナーアカウントから大量再公開。Microsoftは6/19にSapphire Sleetへ帰属 | Microsoft Security Blog、本サイト速報 |
この4件だけを見ても、攻撃手口の「型」が見えてくる。
- postinstall / preinstall フックの悪用：
npm installの過程で自動実行されるスクリプトに、認証情報窃取やRAT配信を仕込む。利用者は「いつも通りインストールしただけ」で侵害される。 - メンテナーアカウントの乗っ取り：正規の公開権限を奪い、短時間で大量のパッケージを差し替える。axiosは約3時間、Mastra系は短時間のうちに140本超が一斉に差し替えられた。
- 偽の依存・タイポスクワット：本体には悪意あるコードを直接入れず、
plain-crypto-js（axios）やeasy-day-js（Mastra）のような「呼び出されない偽依存」をインストール時だけ走らせる。 - 自己増殖（ワーム化）：Miasmaのように、窃取したトークンで「被害者が公開権限を持つ他のパッケージ」へ感染を広げる。
Palo Alto Networks Unit42のnpm脅威レポートでも、2026年は大量公開型の攻撃が観測されている。同レポートは、5月19日の@antv関連の事案で約1時間に323パッケージ・639バージョンが汚染されたケースを「単一時間あたりの最大規模」として記録している（数値はUnit42公表値）。つまり、「滅多に起きない事故」ではなく「日常的に起きうるリスク」として依存管理を設計し直す必要がある。
なぜ「provenance付き」「正規署名済み」でも汚染されたのか
サプライチェーン対策として、ここ数年は「SLSA provenance」「Sigstoreによる署名」「GitHub Actionsのトラステッド・パブリッシング（OIDC）」が推奨されてきた。これらは「長期間有効な公開トークン（long-lived secret）を排除し、短命トークンで安全に公開する」ための仕組みである。方向性としては正しい。
しかし2026年6月のRed Hat（Miasma）事案は、この前提の限界を突いた。Microsoftの解析とRed HatのRHSB-2026-006によれば、攻撃の流れは次の通りである。
- ある従業員のGitHubアカウントの認証情報が、商用インフォスティーラー（情報窃取マルウェア）のログに2026年4月13日時点で出現していた。窃取から悪用まで約7週間の空白があった。
- 攻撃者はそのアカウントを使い、RedHatInsights配下のリポジトリにブランチ保護やレビューを回避してコミットを注入した。
- 正規のCI/CDパイプライン（GitHub Actions OIDC）が、汚染されたコードに対して正規の公開トークンを発行してしまった。結果として、汚染版パッケージは本物のSLSA provenance attestation付きでnpmに公開された。
- インストール時のpreinstallフックが4.2MBの難読化ドロッパーを実行し、開発者環境ではSSH鍵・CLI認証情報・ブラウザデータなどを、CI/CD環境ではランナーのメモリ上の秘密情報やクラウド認証情報（AWS/Azure/GCP/Vault/Kubernetes）を窃取した。
- さらに、窃取したトークンで被害者が公開権限を持つ他パッケージへ感染を広げ、Sigstore経由で偽造したprovenanceを付けて再公開した（ワーム化）。
ここから導かれる教訓は明快だ。
provenanceや署名は「誰が・どのパイプラインで公開したか」を証明するが、「そのパイプラインに入ったコードが安全か」までは証明しない。上流のアイデンティティ（開発者アカウントやCI/CD）が乗っ取られると、整合性を守る仕組み自体が正規の偽造装置になる。
| 仕組み | 何を保証するか | 2026年に突かれた限界 |
|---|---|---|
| メンテナー署名 | 公開者の身元 | アカウント乗っ取りで正規署名のまま汚染（axios/node-ipc/Mastra） |
| SLSA provenance | どのビルド経路で作られたか | CI/CD・開発者アカウント乗っ取りで正規provenance付き汚染（Red Hat/Miasma） |
| OIDCトラステッド・パブリッシング | 長期トークン排除 | 上流IdP/アカウントが侵害されると短命トークンが攻撃者に発行される |
つまりprovenanceは「導入すべきだが、それだけに依存してはいけない」コントロールである。次章の防御設計は、「正規に見える汚染が入ってくる」前提で組む。
防御設計チェックリスト（2026年版）
以下は、開発組織がnpm（および同種のパッケージエコシステム）汚染に備えて整備すべき防御を、4レイヤーに分けたチェックリストである。すべてを一度に導入する必要はないが、①依存ピン留め＋②インストール時スクリプト制御は最優先で着手すべきである。
レイヤー1：依存の固定とピン留め
| 項目 | やること | 効果 |
|---|---|---|
| ロックファイルの厳格化 | npm ci を使い、npm install での暗黙更新を本番ビルドで禁止する | 後から公開された悪性版への自動更新を防ぐ |
| バージョンの固定 | ^ / ~ のレンジ指定を避け、可能な範囲で正確なバージョンに固定する | SemVer解決による「武器化版への自動更新」を抑止 |
| 導入の遅延（クールダウン） | 新規公開バージョンを即時導入せず、24〜72時間程度の待機期間を設ける | 短時間で差し替え→削除される攻撃の被弾を避ける |
| 依存の棚卸し | 直接依存だけでなく推移的依存（依存の依存）まで可視化する | 偽依存・タイポスクワットの混入を発見しやすくする |
ポイント：axios・Mastra事案は「悪性版が短時間で公開→削除」された。導入を数十時間遅らせるだけで被弾確率は大きく下がる。
レイヤー2：インストール時スクリプトの制御
| 項目 | やること | 効果 |
|---|---|---|
| ライフサイクルスクリプトの無効化 | .npmrc に ignore-scripts=true を設定し、必要なパッケージだけ例外許可する | postinstall/preinstall経由の自動実行を遮断 |
| 実行環境の隔離 | 依存解決・ビルドをコンテナや使い捨て環境で実行する | 認証情報やSSH鍵がインストール時に露出する範囲を限定 |
| インストール時通信の制限 | ビルド時に外部へ通信させない（egress制限） | RAT配信や認証情報の外部送信を遮断 |
Red Hat（Miasma）・axios・node-ipcはいずれもインストール時スクリプトが侵入の起点だった。ignore-scripts の徹底は、最も費用対効果が高い対策の一つである。
レイヤー3：SBOMと継続的な可視化
| 項目 | やること | 効果 |
|---|---|---|
| SBOMの生成 | ビルドごとにSBOM（ソフトウェア部品表）を生成・保管する | 事案発生時に「自社が影響を受けるか」を即時判定できる |
| 脆弱性・侵害情報の照合 | SBOMを脆弱性DB・侵害情報と継続照合する | 既知の悪性版・侵害バージョンの利用を検知 |
| プライベートレジストリ経由化 | npmへの直接アクセスでなく社内プロキシ/プライベートレジストリ経由にする | 許可していないパッケージの混入を制御 |
| インストール元の検査 | provenanceや署名は「補助情報」として検証しつつ、それだけに依存しない | 偽造provenance事案でも単独で素通りさせない |
SBOMの最大の価値は、平時の証明書ではなく有事の即応にある。「自社が今回の侵害バージョンを使っているか」を数分で答えられるかどうかが、被害範囲の確定速度を決める。
レイヤー4：CI/CDの権限分離と認証情報管理
| 項目 | やること | 効果 |
|---|---|---|
| 最小権限のトークン | CI/CDのトークン・OIDC権限を必要最小限に絞る | 乗っ取り時の被害（再公開・横展開）を限定 |
| ビルドと公開の分離 | 「ビルドする権限」と「公開する権限」を別ジョブ・別アカウントに分離する | 1アカウント乗っ取りで公開まで一気に通ることを防ぐ |
| シークレットの隔離 | ビルドランナーのメモリ・環境変数に長期シークレットを置かない | Miasma型のランナーメモリ窃取の被害を縮小 |
| ランナーのegress制限 | CI/CDランナーから外部への送信を許可先のみに制限 | 認証情報の外部exfiltrationを遮断 |
| 認証情報の即時ローテーション手順 | 侵害が疑われた場合のクラウド鍵・トークン一括ローテ手順を事前整備 | 検知から封じ込めまでの時間を短縮 |
| 開発者アカウントの保護 | フィッシング耐性のあるMFA、インフォスティーラー対策、認証情報の早期検知 | 上流アカウント乗っ取り（根本原因）を抑止 |
Red Hat事案の根本原因は「従業員アカウントの認証情報が情報窃取マルウェアで漏れていた」ことだった。最後の防衛線は技術的なprovenanceではなく、開発者端末とアカウントの衛生である。
インシデント発生時の初動（影響確認の手順）
汚染事案が公表されたとき、自社が影響を受けるかは次の順で確認する。
- 対象パッケージ・バージョンの特定：公表された侵害バージョンを一次情報（ベンダーのアドバイザリ、CISA、公式リポジトリのIssue）で確認する。
- 自社利用の確認：ロックファイルやSBOMを横断検索し、該当バージョンを直接・推移的に使っていないか確認する。
- インストール実行有無の確認：CI/CDログや開発端末で、該当期間に
npm install等が走ったかを確認する（インストールしていなければスクリプトは実行されていない）。 - 認証情報のローテーション：影響が疑われる場合、クラウド鍵・SSH鍵・npm/GitHubトークン・CIシークレットをローテーションする。
- 横展開の確認：ワーム型の場合、自社が公開権限を持つパッケージや、不審なリポジトリ・コミットがないかを確認する。
- 安全版へのロールバック：公式が案内する安全なバージョンへ固定し直す。
インシデント時に最も時間を食うのは「自社が影響を受けるかの判定」である。SBOMとロックファイル管理を平時に整えておくことが、初動の速さに直結する。
よくある質問（FAQ）
Q. provenanceや署名は導入しても無駄なのですか？ 無駄ではない。来歴の検証は侵害の検知・追跡に有効で、導入すべきコントロールである。ただし2026年の事案が示すのは「provenanceだけを安全の根拠にしてはいけない」ということだ。依存ピン留め・スクリプト制御・権限分離と多層で組み合わせる前提で使う。
Q. 自社はNode.js/npmを使っていないので関係ない？ 攻撃の構造（インストール時スクリプト悪用、メンテナー乗っ取り、自己増殖）は、PyPI（Python）やコンテナイメージなど他のエコシステムでも共通している。npmは事例が顕在化しやすいだけで、依存管理の考え方は言語を問わず適用すべきである。
Q. ignore-scripts=true にすると動かなくなるパッケージがあるのでは？
ネイティブビルドを伴う一部パッケージは影響を受ける。全面禁止ではなく「原則無効化＋必要なものだけ明示的に許可」という運用が現実的である。導入時にビルド検証を行えば移行できる。
Q. AI開発（RAGやAIエージェント）を外注しているが、依存管理まで見るべき？ 見るべきである。Mastra事案のように、AI開発フレームワーク自体が標的になっている。外注の場合は、RFPや要件定義に「依存管理・SBOM・CI/CD権限分離・インシデント初動手順」を明記し、検収条件に含めることを推奨する。
Q. 中小・中堅企業でも全部やる必要がある？
まず①ロックファイルの厳格化（npm ci）、②インストール時スクリプト制御（ignore-scripts）、③新規バージョンの導入遅延の3点から始めれば、費用対効果の高い防御になる。SBOMやCI/CD権限分離は、扱うシステムの重要度に応じて段階導入すればよい。
この記事を読むべき人
- 自社プロダクト・社内システムでnpm（Node.js）や同種のパッケージ管理を使っている開発組織
- AIチャットボット・RAG・AIエージェントを内製または外注で開発している企業
- 「SLSA provenanceを入れたから大丈夫」と整理していたが、2026年の事案で再評価が必要なセキュリティ担当
- CI/CDパイプラインの権限設計や認証情報管理に不安があるCTO・開発リーダー
- ベンダー・委託先の開発体制について、サプライチェーンの観点で監査基準を作りたい情シス・購買・法務
いつGXOに相談すべきか
- npmなどの依存管理・CI/CDパイプラインに、サプライチェーン攻撃に耐える統制を入れたい
- 自社が今回のような事案で影響を受けるか、即時に判定できる体制（SBOM・ロックファイル管理）がない
- AI開発・システム開発を外注しているが、依存管理やセキュア開発の要件をどう書けばよいか分からない
- 過去に構築したシステムのセキュリティを、サプライチェーンまで含めて棚卸ししたい
GXOでは、セキュア開発（DevSecOps）の設計、依存管理・CI/CD権限分離の整備、脆弱性・侵害情報の継続診断、AI開発を含むセキュアな受託開発を組み合わせ、「汚染される前提」での防御設計を支援する。
- セキュア開発・CI/CDパイプライン統制：DevSecOpsの設計・伴走
- 自社の依存・構成のリスク可視化：脆弱性診断
- AI機能の内製・外注を安全に進める：AI開発サービス
本記事の4レイヤー防御チェックリストは、依存管理・CI/CD防御チェックリストとして無料ダウンロードできる。CTO・開発リーダーの社内合意形成や外注先への要件提示にそのまま使える。
SNSで刺さる論点
- 2026年のnpm汚染で分かったのは「正規署名済み・provenance付きでも汚染される」ということ。安全の根拠を1つに依存しない設計へ。
- サプライチェーン攻撃の最大のコストは「自社が影響を受けるかの判定時間」。SBOMとロックファイル管理は平時の保険。
- 最も費用対効果が高い対策は地味だ——
npm ci、ignore-scripts=true、新規バージョンの導入を数十時間遅らせる、この3つ。 - 攻撃の根本原因は高度な技術ではなく「開発者アカウントの認証情報漏れ」。最後の防衛線は端末とアカウントの衛生。
関連記事
- Mastra npmパッケージのバックドア化（Sapphire Sleet）
- axios npm汚染の影響確認とインシデント対応
- npmサプライチェーン攻撃｜CI/CD・依存セキュリティ
- GlassWorm｜自己増殖型サプライチェーン攻撃の脅威分析
参考資料
- Microsoft Security Blog "Preinstall to persistence: Inside the Red Hat npm Miasma credential-stealing campaign"（2026年6月2日）https://www.microsoft.com/en-us/security/blog/2026/06/02/preinstall-persistence-inside-red-hat-npm-miasma-credential-stealing-campaign/
- Red Hat "RHSB-2026-006 Supply chain compromise of @redhat-cloud-services npm packages" https://access.redhat.com/security/vulnerabilities/RHSB-2026-006
- Microsoft Security Blog "Mitigating the Axios npm supply chain compromise"（2026年4月1日）https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/
- CISA Alert "Supply Chain Compromise Impacts Axios Node Package Manager"（2026年4月20日）https://www.cisa.gov/news-events/alerts/2026/04/20/supply-chain-compromise-impacts-axios-node-package-manager
- Snyk "Malicious node-ipc Versions Published to npm" https://snyk.io/blog/malicious-node-ipc-versions-published-npm/
- Unit42（Palo Alto Networks）"The npm Threat Landscape: Attack Surface and Mitigations" https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
本記事は2026年6月25日時点の公開情報をもとに作成。各事案の最終的な影響範囲・帰属・侵害バージョンは、各ベンダーの公式アドバイザリおよびCISA等の一次情報で確認すること。攻撃手口は更新されうるため、防御設計は定期的に見直すこと。
正規署名・provenance付きでも汚染される——手遅れになる前に依存管理を整えませんか
GXOでは、npm等の依存管理・CI/CD権限分離・SBOM・脆弱性診断を組み合わせ、サプライチェーン攻撃に耐える開発体制づくりを支援します。AI開発・システム開発の外注先選定や要件定義の段階からご相談いただけます。
DevSecOps・セキュア開発を見る サプライチェーン対策を相談する
※ 既存システムの構成資料がなくても相談可 | 情シス・開発・セキュリティ担当の同席歓迎
