『ランサムウェア対策としてのpnpm導入のススメ』というタイトルでクラメソさっぽろIT勉強会 (仮) で登壇しました #cm_sapporo_study

クラウド事業本部 コンサルティング部の石川です。2026年2月10日に開催された「クラメソさっぽろIT勉強会 (仮) #12」にて、「ランサムウェア対策としてのpnpm導入のススメ」というタイトルで登壇しました。本記事では、発表内容をブログ形式でお届けします。

https://classmethod.connpass.com/event/379617/

登壇資料

はじめに

「なぜパッケージマネージャーがセキュリティに関係あるの？」と思われた方もいるかもしれません。

しかし今、私たちが無意識に利用している npm install というコマンドが、実は組織全体を危機に陥れる「サプライチェーン攻撃」の入り口の１つになっています。生成AIモデルのAPI利用やMCPの呼び出し、AWS CDKのデプロイなど、npmコマンドは開発現場で避けて通ることができない重要なコマンドです。だからこそ、そのリスクについて正しく理解する必要があります。

2025年に登場した「Shai-Hulud」や「PhantomRaven」といった脅威を例に、なぜ今「pnpm」への移行が最強の防衛策になるのか、その理由を解説しました。

ランサムウェアとサプライチェーン攻撃

ランサムウェアとは

ランサムウェアは、コンピュータやデータを「人質」にとって身代金（ランサム）を要求する悪意のあるソフトウェアです。

巧妙に偽装されたメールの添付ファイルを開いたり、改ざんされたウェブサイトを閲覧したりすることで感染し、ユーザーが気づかないうちに写真、書類、動画などの重要なファイルを暗号化して開けなくします。画面には「ファイルを元に戻したければ、指定の期限までにビットコインなどで金を払え」という警告文が表示されます。

最近では「二重脅迫」が主流になっています。単にデータをロックするだけでなく、「金を払わなければ盗み出した機密データをネット上に公開する」とさらに脅す手法です。

サプライチェーン攻撃

ランサムウェアによるサプライチェーン攻撃とは、ターゲットとなる企業を直接狙うのではなく、その取引先や委託先（サプライチェーンの弱い環）を「踏み台」にして、最終的な標的やその関連組織全体にランサムウェアを感染させる攻撃手法です。

セキュリティが強固な大手企業を正面から突破するのは難しいため、比較的ガードが甘い関連会社やシステム管理会社を狙うのが近年のトレンドになっています。

ランサムウェアに狙われるnpm

npmとは

npm（Node Package Manager）とは、JavaScriptの実行環境であるNode.jsの標準パッケージマネージャです。**レジストリ（Registry）**という公開データベースに保存されたライブラリやフレームワークを、npmコマンドを介してインストール、更新、削除するための仕組みです。

単なるパッケージの取得にとどまらず、各パッケージが依存する他のライブラリとの整合性を自動的に解決する機能や、プロジェクトごとの依存関係を package.json というメタデータファイルに記録して異なる開発環境間での再現性を担保する役割も担っています。

2025年に登場したShai-HuludとPhantomRaven

2025年、npmエコシステムを主な標的としたサプライチェーン攻撃が顕在化しました。

Shai-Hulud（シャイ・フルード） は、npmトークンの窃取とワーム（自己増殖型）の自動拡散を手法とする脅威です。postinstall スクリプトを悪用し、盗んだnpmトークンで被害者が管理する正規パッケージに悪意あるコードを自動注入・公開し、攻撃者の介入なしに指数関数的に拡散するという特徴があります。

PhantomRaven（ファントム・レイヴン） は、セキュリティスキャンの回避（Remote Dynamic Dependencies）を手法とする脅威です。無害に見えるコード（hello worldスクリプト等）をnpmに公開し、依存関係をHTTP URL経由で攻撃者のサーバーから動的に取得します。npmレジストリやセキュリティスキャナーはこのURLを追跡しないため「依存関係0」と表示され、検出を回避します。

npmの構造的な脆弱性

npmには、古くからある「便利だが危険な」仕組みである「ライフサイクルスクリプトの自動実行」が存在します。

npmパッケージには、インストール直後に実行されるスクリプト（postinstall など）を設定できます。本来はネイティブモジュールのコンパイルなど環境構築の自動化が目的ですが、攻撃者はこれを悪用します。開発者が npm install を実行した瞬間、本人の知らないところでモジュールをダウンロードしたり、悪意あるコードをバックグラウンドで実行できてしまいます。

なぜnpmトークンが狙われるのか？

攻撃者の狙いは、開発者の npmトークン です。

トークンは、パスワードや二要素認証（2FA）をスキップして、パッケージを公開・更新できる「マスターキー」です。これが盗まれると、信頼されている既存のパッケージにウイルスを混入させ、世界中の何十万というユーザーにランサムウェアを配布する踏み台にされてしまいます。

pnpmの導入

pnpmとは

pnpm（Performant npm）は、Node.js用の高速・効率的なパッケージマネージャーです。npmとの主な違いは以下のとおりです。

• ディスク効率: グローバルストアを共有するため、重複インストールがない
• インストール速度: 既にストアにあるパッケージはリンクするだけなので高速
• 厳密なnode_modules構造: フラットではなくシンボリックリンクベースの構造を使うため、package.json に宣言していないパッケージへの暗黙的なアクセス（phantom dependencies）を防げる
• モノレポ対応: ワークスペース機能が充実しており、モノレポ管理に強い

pnpmがランサムウェア対策になる理由

pnpmは単に「高速なnpm」ではありません。設計思想そのものがセキュリティファーストです。

npmはすべてのスクリプトを自動実行しますが、pnpmは違います。ホワイトリスト方式で、信頼できるパッケージ以外、インストールスクリプトの実行をブロックします。たとえ不正なパッケージが紛れ込んでも、その「実行」を阻止するため、PhantomRavenやShai-Huludの被害を未然に防げます。

また、pnpmの minimumReleaseAge という設定により、リリースされてから一定時間が経過していないパッケージをインストールさせないようにすることもできます。

pnpmのインストール方法

npmを使わずにインストールする方法を紹介します。

macOS: Homebrew を使う（推奨）

brew install pnpm

macOS / Linux: インストールスクリプトを使う

curl -fsSL https://get.pnpm.io/install.sh | sh -

Windows (PowerShell): インストールスクリプトを使う（推奨）

iwr https://get.pnpm.io/install.ps1 -useb | iex

npmコマンドの無効化と時限解除（macOS）

移行期間中は、.zshrc 等で npm と npx を実行できないようにし、必要なときだけ「時限解除」する仕組みを導入することも可能です。

macOSの.zshrc の設定例

alias npx='echo "WARNING: npx は実行しないでください" && false'
alias npm='echo "WARNING: npm は実行しないでください" && false'

# 1時間だけ npm/npx の封印を解く関数
function unlock-npm() {
  unalias npm npx
  # macOS用の日付計算。Linuxの場合は $(date -d "+1 hour" ...) に書き換えてください
  local limit=$(date -v+1H "+%Y/%m/%d %H:%M")
  echo "${limit} まで、npm/npx の制限を解除しました。"
  # 1時間後に自動で source を実行
  sched +01:00 "source ~/.zshrc && echo '\a\n1時間経過したため、npm/npx を再度封印しました。'"
}

macOSの.zshrc の実行例

上記のスクリプトを設定した状態では、npmコマンドやnpxコマンドを実行できませんが、unlock-npmコマンドを実行すると、1時間のみnpmコマンドやnpxコマンドを実行できるようになります。このコマンドは、そのセッションにのみ適用されるため、他の実行には影響を与えません。

% npm --version
WARNING: npm は実行しないでください

% unlock-npm
2026/02/11 17:35 まで、npm/npx の制限を解除しました。

% npm --version
10.8.1

%
1時間経過したため、npm/npx を再度封印しました。

% npm --version
WARNING: npm は実行しないでください

npm を pnpm へ移行する

npmコマンドをpnpmコマンドに置き換えて実行してください。package.json に許可リストを明示し、本当に必要なもの（esbuild、sharp など）だけを実行許可します。リストにないパッケージが動こうとするとpnpmは停止し、ユーザーに警告を出します。実行されないウイルスは悪さができません。

package.jsonの設定例:

{
  "pnpm": {
    "onlyBuiltDependencies": [
      "esbuild",
      "sharp"
    ]
  }
}

npx から pnpm dlx への移行

一時的なツール実行も npx ではなく pnpm dlx を使いましょう。

npxは非常に便利ですが、ライフサイクルスクリプトを確認なしで自動実行するリスクがあり、PhantomRavenはこの仕組みを悪用しています。pnpm dlx では、実行対象のパッケージ自身の postinstall スクリプトはデフォルトで許可されますが、その依存関係のライフサイクルスクリプトはブロックされます。つまり、依存ツリーの奥に潜む悪意あるスクリプトの実行を防ぐことができます。

まとめ

今回の登壇では、おすすめの3つの対策をお伝えしました。

1. npmトークンは最も大事、平文で .npmrc に放置せず、実行権限も絞る。
2. pnpmを導入し、スクリプト実行を許可制にする。
3. 「インストールしただけで被害に遭う」リスクがあることを認識する。

セキュリティは便利さとのトレードオフになりがちですが、pnpmは「速くて安全」という利便性も同時に提供してくれます。自分やお客様を守るために、pnpmへの移行をぜひご検討ください。