出所情報は証拠ではない: `npm install -g` する前に確認すべき点（トンネル CLI）

2026年11月時点で、2つの事実が成り立っています。npm 12 はデフォルトで依存関係のインストールスクリプトの実行を拒否するようになり、最も一般的なサプライチェーンの配布経路を閉ざします。そして同年、攻撃者は有効な出所認証を伴う悪意のある npm リリースを配布し、インストールスクリプトには一切触れないペイロードを含むものもありました。

もしあなたがトンネル クライアントで npm install -g を実行するところなら、両方の事実が重要です。トンネル CLI は長寿命のプロセスで、認証トークンを保持し、シェルの環境変数を継承し、パブリックインターネットと localhost の間でトラフィックを中継します。このガイドは、npm 12 が何を変更したか、出所情報が何を証明できるか・できないか、事前インストールチェックリストとしてバージョンの固定、ignore-scripts、チェックサム検証済みのスタンドアロンバイナリ、送出許可リストを扱います。

なぜトンネル CLI は高価値なターゲットなのか

トンネル CLI は数時間または数日間、あなたのユーザー権限で動作します。コード・鍵・.env ファイルが格納されているマシン、そして改ざんされたコピーが中継するデータを読めるネットワーク経路上にあります。Palo Alto Networks の乗っ取り @bitwarden/cli リリースの解説は、対象として SSH キー、 .npmrc トークン、 .env ファイル、 AWS 認証情報、Git 設定、GitHub CLI トークン、npm 認証トークン、AI/MCP 設定を挙げています。トンネル クライアント自身の認証トークンは、それらと自然に並ぶことになるでしょう。すでにアウトバウンド接続を持つプロセスは、それをどこかへ送るのに適しています。

npm 12 が変更した点と、変更されていない点

GitHub は 2026年7月に npm 12 を発表し、allowScripts がデフォルトでオフになっています。The Hacker News の報道によれば、依存関係の preinstall、install、postinstall スクリプト、および暗黙の node-gyp ビルドは、明示的に許可されない限り実行されなくなりました。Git の依存関係とリモート URL の tarball も、--allow-git または --allow-remote にオプトインしない限りオフのままです。破壊的変更の通知は、6月9日付の GitHub の Changelog に遡ります。

トンネル CLI に対する3つの実用的な影響:

• インストール時にバイナリをダウンロードするラッパーパッケージは、それを行わなくなります。 ngrok の Node.js ラッパーは、npm install が postinstall ステップで ngrok のホスティングからプラットフォームバイナリを取得することを文書化しています。npm 12 では、そのダウンロードは承認されるまでブロックされます。これは機能です：ダウンロード経路を信頼するかどうかを自分で決めさせます。
• グローバルインストールにはフラグが必要で、allowlist は不要です。 npm CLI トラッカーの報告によれば、npm install -g の場合、警告は npm install -g --allow-scripts=<pkg>、あるいは npm config set allow-scripts=<pkg> --location=user のように永続化します。コミュニティの解説では、グローバルインストールで npm approve-scripts がエラーになる点も指摘されています。
• 古い npm バージョンでは ignore-scripts が依然必要。 デフォルトを変更した PR の主張は、ignore-scripts=true が古いバージョンのフォールバックとして残るとしています。 fleet の全マシンが npm 12 を実行するまで、設定を維持してください。

ギャップ: コードが実行されるときに動作するペイロード

インストール時のスクリプトをブロックしても、パッケージを使用する際に実行されるコードには対抗できません。AsyncAPI のサプライチェーン妥協に関する Microsoft の 2026 年7月の分析では、モジュールロード時にトリガーするペイロードが見つかり、--ignore-scripts がそのパターンを中和しないと述べられています。事件の報告では、@asyncapi パッケージが4つトロージャン化されており、うち @asyncapi/specs は週あたり約266万回のダウンロードがあるとしています。Bitwarden CLI のケースは、別の角度から同じ盲点を示しています。悪意のある 2026.4.0 リリースは、preinstall フックと bw バイナリエントリポイントをローダースクリプトへと再配線しました。OpenReplay の分析は、bin エントリが、--ignore-scripts が設定されていてもコマンドを実行するたびにペイロードを実行することを意味していたと指摘します。これをグローバル CLI に適用します。あなたは正確にそれを実行するためにインストールします。トンネル クライアントの場合、”インストール済み” と “実行済み” の境界は1コマンド分長いので、スクリプトのブロックだけの効果はフロントエンドの依存ツリーほど大きくありません。それでも保持する価値はあります。十分ではありません。

出所情報: 何を証明し、何を証明しないか

npm の出所情報は、公開されたパッケージをそのソースリポジトリと、それを作成したビルド手順へ結びつけます。npm の公式ドキュメントはその限界を明確にしています：出所情報が悪意のコードの不在を保証するものではありません。監査可能な記録を提供しますが、結論を出すものではありません。

2026年には3つの明確なデモンストレーションがありました。

日付	事象	出所が正当だったもの
2026年5月11日	TanStack のワーム：42 個の @tanstack/* パッケージに跨る 84 バージョン	実際の信頼できる公開パイプラインから公開された、OIDC トークンが盗まれた後
2026年9月9日	GHAPPIER: @dforge-core/dforge-mcp@0.2.21	GitHub Actions による OIDC 信頼公開で作成。アテステーションには攻撃者のコミットが記載
2026年10月	「Slugfest」信頼公開の欠陥: 1500+ パッケージ公開	放棄された名前を主張するリポジトリのリリースにも有効な attestations が付随

TanStack の事例について、Palo Alto の Unit 42 は、それを初の公式文献として文書化されたワームとして説明しており、有効な SLSA Build Level 3 provenance を伴うと要約しています。出所情報はどのパイプラインがパッケージを作成したかを示しますが、そのパイプラインがクリーンだったかどうかを保証するものではありません。信頼済みパブリッシャーの結合は、保護ブランチの1つのワークフローではなく、リポジトリ全体をカバーしていたと分析は付け加えます。

GHAPPIER は別の入口から同じ点を指摘します。CloudSEK は、攻撃者が保守者のアクセスを約105分間使い、リリースワークフローを編集して自動的にプッシュするようにし、バージョン 0.2.21 を出荷したと報告しています。リポジトリの CI の身元をレジストリが信頼したため、そのリリースは npm audit signatures をすり抜けてしまった可能性があります。Bloom Security の Slugfest の研究では、保守者が放棄した GitHub リポジトリ名を登録した人は、未だそれを信頼しているパッケージへ公開できるとしています。GitHub は修正を出荷したと発表し、未検証の設定は 48 時間後に失効します。Bloom の消費者への助言は、 attestations がプロジェクトの出所になるリポジトリを指していることを確認することです。

出所情報が欠如していることは依然として信号になる

出所情報が欠如しているからといって、出所情報が無意味になるわけではありません。2026年3月31日の axios 脆弱性に関する報告は、悪意のあるリリースには正当なリリースが持つ GitHub Actions 出所情報が欠けていたと指摘しています。Mondoo のセキュリティ分析は関連する警告を追加します：出所情報を落としたバージョンをインストールするのを妨げるものは何もありません。結論としては、欠落または不一致の attestations は停止の理由であり、有効な attestations は検証を継続する理由です。

インストール前チェックリスト

1. 身元を確認し、厳密なバージョンを固定する

パッケージ名、スコープ、バージョンをベンダーの公式ドキュメントと照合してください。JFrog の分析によれば、乗っ取られた Bitwarden バージョン 2026.4.0 は実在しません。@latest をインストールする代わりに、確認したバージョンを固定してください：

npm install -g some-tunnel-cli@1.2.3

3. リリース年齢ゲートを追加

npm 11.10（2026年2月）は min-release-age を追加しました。日数で測定します。悪意のあるバージョンはしばしば数時間以内に検知され、除外されます。GHAPPIER の悪いリリースは約35分最新で、Bitwarden のウィンドウは約90分でした。7日間のゲートがあれば両方を回避できたかもしれません。

# ~/.npmrc
min-release-age=7
ignore-scripts=true

2つのクセとして、npm config get min-release-age は null と表示されることがあります。npm が内部的に before タイムスタンプへ変換するためです。--before と組み合わせることはできません。深刻なホットフィックスをすぐに適用するには、コマンドごとに --min-release-age=0 で上書きしてください。

4. インストールせずにマニフェストを検査する

パッケージがあなたのシステムに触れる前に宣言する内容を確認してください：

npm view some-tunnel-cli@1.2.3 scripts bin dependencies --json
npm pack some-tunnel-cli@1.2.3   # tarball のみをダウンロード
tar -tzf some-tunnel-cli-1.2.3.tgz

Red flags: パッケージに本来必要のない preinstall / install / postinstall、実際のエントリポイントではなくセットアップやローダー ファイルを指す bin エントリ、最近追加された依存関係など。Bitwarden のマニフェストにも両方のシグナルが現れました。

5. 捨て用ディレクトリで検証し、 attestations を検証する

npm audit signatures はレジストリ署名と provenance attestations を検証しますが、これはプロジェクト内のインストール済み依存関係に対して機能するため、グローバルインストールを直接監査するものではありません。スクリプトを無効化したスクラッチディレクトリにインストールしてから監査します：

mkdir /tmp/vet && cd /tmp/vet && npm init -y
npm install --ignore-scripts some-tunnel-cli@1.2.3
npm audit signatures

npm のドキュメントはこれを行うには npm 9.5.0 以上が必要です。次に attestations 自体を読んでください。レジストリは registry.npmjs.org/-/npm/v1/attestations/<package>@<version> の attestations を公開しています。ソースリポジトリとワークフローがベンダーの公式リポジトリと一致していること、以前のバージョンに attestations が存在していた場合は attestation があることを確認してください。

6. どのスクリプトを許可するか決める

npm 12 では、理解できるものだけを承認します。ポストインストールが実際に必要なグローバルツールの場合:

npm install -g --allow-scripts=some-tunnel-cli some-tunnel-cli@1.2.3

パッケージの唯一のスクリプトがバイナリダウンローダーであれば、それは次のセクションの合図です。

チェックサム検証済みのスタンドアロンバイナリを推奨

多くのトンネルクライアントは単一の静的バイナリとして配布されます。バイナリを直接インストールすることで、npm の依存ツリー、ラッパーの postinstall ダウンロード、インポート時の攻撃対象を一度に排除します。Cloudflare は、cloudflared アセットの SHA-256 のチェックサムを公開しています。固定され、検証済みのインストールは次のようになります:

VERSION=<reviewed-release-tag>
curl -fsSLO "https://github.com/cloudflare/cloudflared/releases/download/${VERSION}/cloudflared-linux-amd64"
echo "<sha256-recorded-at-review-time>  cloudflared-linux-amd64" | sha256sum -c -
install -m 0755 cloudflared-linux-amd64 /usr/local/bin/cloudflared

これが証明する内容について正直になってください。バイナリと同じリリースページからコピーしたチェックサムは、破損と改ざんされたダウンロード経路を防ぎますが、妥当なリリースを保証するものではありません。リリースを人がレビューしたときにハッシュを自分のリポジトリやインフラコードに記録し、プロビジョニングスクリプトがそれと照合するようにしてください。

GitHub アーティファクト attestations を公開するリポジトリには、gh attestation verify ./some-binary --repo owner/repo を追加します。gh CLI は公開リポジトリでも認証されている必要があり、リリースに attestation がない場合は検証がスキップされるインストーラがあるため（Foundry のドキュメントでは、そのインストーラがそうだと記載）、自分のスクリプトをすべてが失敗するようにしてください。これらの attestations は npm provenance の制限を共有します。つまりビルドを特定するもので、著者の意図を特定するものではありません。

送出を制限する

トンネル クライアントは外部へのアクセスを非常に少なくて済みます。多くの悪意のペイロードは、盗んだファイルを送る先が必要ですし、時にはセカンドステージを取得する場所も必要です。Bitwarden のローダーは Bun ランタイムを GitHub からダウンロードし、外部流出エンドポイントはセキュリティベンダーのテレメトリ ドメインに似せたものになっていました。

2つの人気クライアントの公式要件:

• cloudflared はポート 7844 でアウトバウンド接続を行い、HTTP/2 は TCP、QUIC は UDP を使用し、少なくとも2つの Cloudflare データセンターへ4本のアウトバウンド接続を開きます。Cloudflare のファイアウォール ガイドには region1.v2.argotunnel.com および region2.v2.argotunnel.com が掲載され、SNI を強制するファイアウォール向けには cftunnel.com のようなホスト名を追加します。また、ポート 443 の宛先（更新チェック）はオプションとして扱われます。Ingress をすべてブロックすることを推奨します。
• ngrok エージェントはポート 443 のアウトバウンド TLS 接続を connect.ngrok-agent.com に行います。ngrok のドキュメントでは IP アドレスの回転が述べられており、ホスト名での許可リスト化を推奨します。*.ngrok-agent.com ファミリーは latency-based routing のために必要になることがあります。接続 URL をホワイトラベル化することもでき、ngrok diagnose を実行して接続性をテストできます。

宛先がホスト名のため、単純な IP ベースのルールだけでは不十分です。FQDN 対応のファイアウォール、プロキシ、あるいは Cilium 風の toFQDNs ポリシーを使用し、トンネルを実行しているユーザーまたはコンテナに適用してください。ホスト全体ではなく、対象のユーザー/コンテナに適用します。

アロウリストは爆発半径を縮小しますが、消し去るわけではありません。トンネル ベンダーのエンドポイントは必ず許可されたものになります。

実行時に不正が疑われる前提で実行する

クライアントを将来、あなたが見逃した悪いリリースになると想定してください。クラウド認証情報、SSH 鍵、公開トークンの入手できない専用ユーザーやコンテナで実行し、秘密をエクスポートしたシェルを使わずクリーンな環境から起動し、限定的な権限の認証トークンを回転させてください。必要な1つのポートだけを外部に公開します。

上記はすべてクライアントを信頼する話です。許可されていないトンネルを見つけることは別の問題で、以前の不正 Reverse SSH トンネル検出に関する投稿で扱っています。

よくある質問

npm 12 は npm install -g を安全にしますか？ いいえ。依存関係インストール スクリプトをデフォルトでブロックするため、主要な攻撃経路を取り除きます。ただし、モジュールをインポートしたり CLI を起動したときに実行されるコードには影響しません。

npm の出所情報だけでパッケージを信頼できますか？ いいえ。出所情報はパッケージがどこでどうビルドされたかを示します。複数の 2026年の事例は、有効な attestations を伴う正規のパイプラインを通じて悪意のあるリリースが配布されたことを示しています。したがって attestation がリポジトリと一致するかを検証し、バージョン固定とマニフェストの精査と組み合わせてください。

結論

npm 12 は最低ラインを引き上げ、攻撃者はそれがカバーしない場所へ移動しました。出所情報をリリース元を示す1つの手掛かりとみなし、実行するかどうかの唯一の答えとしないでください。長寿命で認証情報を持つネットワーク対応のトンネル CLI の場合、検討済みのバージョンを固定し、リリースの初期日数を待ち、ハッシュ検証済みのバイナリを優先し、プロセスが必要とするホストだけに到達させてください。

出典

• npm 12 がデフォルトでインストールスクリプトを無効化してサプライチェーンリスクを低減, The Hacker News (Jul 2026)
• Upcoming breaking changes for npm v12, GitHub Changelog (Jun 9, 2026)
• npm CLI PR #9424: block unreviewed install scripts by default (v12)
• npm CLI issue #9797: global install allow-scripts warning
• npm approve-scripts vs allow-scripts, DEV Community
• Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery, Microsoft Security Blog
• AsyncAPI npm Attack: Import-Time Malware Defense Guide, Digital Applied
• TeamPCP Campaign Spreads to npm via a Hijacked Bitwarden CLI, JFrog
• Bitwarden CLI Impersonation Attack, Palo Alto Networks
• A Simple Defense Against npm Supply Chain Attacks, OpenReplay
• The npm Threat Landscape: Attack Surface and Mitigations, Unit 42
• Why npm Provenance Didn’t Stop the TanStack Compromise, AppSec Santa
• Attackers Abuse npm Trusted Publishing in GHAPPIER Campaign, Infosecurity Magazine
• npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover, Help Net Security
• Your node_modules Is an Attack Surface: npm Security Checklist for 2026, DEV Community
• npm Supply Chain Security in 2026, Mondoo
• Generating provenance statements, npm Docs
• Viewing package provenance, npm Docs
• npm audit, npm Docs
• Configuring minimum release age across npm, pnpm, and yarn (gist)
• ngrok Node.js wrapper README
• cloudflared releases, GitHub
• Tunnel with firewall, Cloudflare Docs
• Cloudflare Tunnel configuration, Cloudflare Docs
• ngrok network egress, ngrok Docs
• ngrok custom connect URL, ngrok Docs
• Use artifact attestations, GitHub Docs
• Verifying releases, Foundry docs
• Integrity verification, Qlty docs