npm 12、インストールスクリプトを既定で止める—ソフトウェアサプライチェーンの「自動実行」を標準から外した意味

今日の深掘りポイント

• ライフサイクルスクリプト（preinstall/postinstall など）と Git 依存のスクリプト実行を npm 12 はデフォルトで無効化。自動実行前提の文化にブレーキをかけたのは、エコシステム全体の「安全側」への大きな舵切りです。
• 2要素認証回避トークン（GAT）廃止により、アカウント乗っ取りからのパッケージ汚染リスクをさらに抑制。発行運用を残したままの「抜け道」を一段と狭めます。
• CI/CD と開発環境では挙動が即変わるため、「意図せぬビルド失敗」「秘密情報露出タスクの未実行」など副作用にも備える必要があります。
• MITRE ATT&CKで言えば、サプライチェーン妥協（Supply Chain Compromise）における依存関係汚染の成功率を下げ、ローカル実行側の初期実行（Command and Scripting Interpreter）やスクリプトの自動トリガ（Event-Triggered Execution）を抑止する設計変更と捉えられます。
• 当面の運用は「必要最小限のパッケージに限定したスクリプト許可」「再現性の高いロックファイル管理」「署名・整合性検証の強化」を並走させるのが現実解です。

はじめに

npm がバージョン 12 で「インストール時にスクリプトを自動実行しない」世界へ踏み出しました。Node.js エコシステムの長い歴史の中で、postinstall によるバイナリ配布やセットアップは事実上の慣習でしたが、その利便性は攻撃者にとっても恰好の足がかりでした。今回の既定動作変更は、利便と安全のバランスを「安全寄り」に再定義する転換点です。
読者の皆さんの組織でも、依存パッケージの postinstall に頼っていたビルドの一部が静かに止まるかもしれません。だからこそ、単なる「機能変更」ではなく、サプライチェーン・リスクに対する実装レベルの防御線がどう変わるのか、実務目線で見直す好機だと感じます。

本稿では、事実（仕様・アナウンス）と、現場運用へ落とし込むためのインサイトを分けて整理し、最後に想定される脅威シナリオを ATT&CK に沿って紐づけます。スコアリング指標が示す「即応性の高さ」を前提に、短期の破壊的変更と中長期の安全性向上を両立させる道筋を描きます。

深掘り詳細

事実関係—何が変わり、どこに効くのか

• インストールスクリプトの既定無効化
  npm 12 は、依存関係のライフサイクルスクリプト（preinstall/postinstall など）や Git 依存関係に含まれるスクリプトの自動実行を既定で止め、ユーザーが明示的に許可しない限り走らないようにしました。これにより、インストール時に任意コードが「ついでに」実行される旧来の経路が塞がれます。一次情報として、GitHub/NPM の公式リリースノートやドキュメント更新で、該当挙動の既定変更と許可の仕組みが案内されています（参考リンク参照）。
• 2FA 回避トークン（GAT）の廃止
  パブリッシングやメンテナンスの自動化で使われてきた 2FA 回避用の granular access token（GAT）に関し、npm 側は廃止に舵を切り、2FA の実効性を高めています。これにより、盗まれたトークンや不適切に保管された自動化用資格情報からのアカウント悪用を抑えます。
• 影響範囲
  CI/CD パイプライン、開発者のローカル開発環境、コンテナビルド、そしてエンタープライズのアーティファクト管理（社内 npm レジストリ）に波及します。とくに postinstall でネイティブバイナリをフェッチ・ビルドしていたパッケージは、既定では機能が成立しなくなります。

参考情報:

• The Hacker News による報道サマリ（一次情報リンクへのハブとして参照）
  https://thehackernews.com/2026/07/npm-12-disables-install-scripts-by.html

（注）本稿は、編集時点で参照可能な一次情報の確認を継続中です。npm 公式の最終ドキュメント・実装差分が公開されたタイミングで、許可フラグの名称や CI 推奨設定を追補する場合があります。最新の仕様は npm 公式リリースノートおよびドキュメントを必ず確認してください。

インサイト—なぜ今か、そしてどこまで効くのか

• 「自動実行」の撤廃は、攻撃者の成功確率を制度設計で削る動きです
  サプライチェーン攻撃は「開発者の操作に寄り添う自動化」を悪用します。install 時の自動実行がなくなるだけで、初期ペイロードに必要なユーザー関与（explicit allow）という壁が一枚増えます。組織のセキュリティ標準として「許可リストでのみ postinstall を通す」運用に切り替える足場が整います。
• 2FA 回避経路の廃止は「鍵束の細分化」から「多要素の実効性」へ
  CI の利便性と 2FA の両立は長年の課題でした。GAT の廃止は短期的にパイプライン改修コストを伴いますが、長期的には「資格情報奪取→公式パッケージ改ざん」の破壊力を下げます。攻撃面の縮減は、被害時の調査コスト（真正性検証、タイムライン復元）の低減にもつながります。
• 代替経路の芽は残る—だからこそ「積層防御」
  スクリプトの既定停止は強い一手ですが、攻撃者は transitive dependency の rename、typosquatting、README/metadata を通じたソーシャルエンジニアリング、Node ランタイムの別フック（実行時 import フックや build ステップの別タスク）などに転進します。だから、SBOM 運用、整合性検証（署名、ハッシュピンニング）、スコープ付きトークン、レジストリのポリシー制御を重ねる必要があります。
• メトリクス観点の補足
  即応性・実行可能性が高い一方で、組織のビルド再現性に与える摩擦は小さくありません。短期の混乱は避けにくいですが、ここで明示的許可と監査ログを整えるほど、後工程（インシデントレスポンス、根本原因分析）の品質が上がる—この「後方工程のコスト最適化」こそ、経営目線では最も大きなリターンです。

脅威シナリオと影響

以下は仮説ベースのシナリオと MITRE ATT&CK の観点での整理です。実際の挙動は npm 12 の最終仕様・運用設定に依存します。

• シナリオA：悪性 postinstall による初期実行の遮断

  • これまでの常套手段：悪性パッケージが postinstall で情報窃取・C2 設定を実行。
  • npm 12 の影響：既定でスクリプトが走らず、明示許可なしでは成立しにくい。
  • ATT&CK 該当例（観点）：
    • Supply Chain Compromise（依存関係の汚染）
    • Command and Scripting Interpreter（T1059 系）による JS/Node 実行の困難化
    • Event-Triggered Execution（T1546 系）の install トリガ抑止

• シナリオB：アカウント侵害→正規パッケージ改ざん

  • これまで：2FA 回避トークンの悪用でパッケージ発行権限を奪取し、改ざんを配布。
  • npm 12 の影響：GAT 廃止でトークン奪取からの不正発行が困難に。
  • ATT&CK 該当例（観点）：
    • Valid Accounts（T1078）による正規資格情報の悪用リスク低減
    • Exfiltration/Impact フェーズの拡大抑止（破壊的更新の配信阻止）

• シナリオC：回避戦術のシフト

  • 予想される転進：インストール後の実行パス（開発サーバ起動スクリプト、ビルドツールのプラグイン機構）や、ドキュメント・スクリプト貼り付け誘導などのソーシャル手口強化。
  • 必要な対抗：CI での Node 実行時ポリシー（例：--disable やポリシーファイル）強化、SBOM での transitive 可視化、開発者教育のアップデート。

組織インパクトとしては、短期は「ビルドエラーと手動許可作業の増加」、中期は「許可リストと監査の定着」、長期で「依存管理の文化が安全側に収斂」という三段変化になるはずです。

セキュリティ担当者のアクション

• 設計・ポリシー

  • ライフサイクルスクリプトの許可方針を定義し、パッケージ単位の allowlist をリポジトリ内で宣言管理（コードオーナー承認とセット）します。
  • 署名付きリリース・整合性検証（ハッシュピンニング、Sigstore/Provenance など）の導入を前倒しします。
  • 内部レジストリ（npm Enterprise/社内 Verdaccio 等）におけるスクリプト実行ポリシーと公開レジストリへのプロキシ制御を再評価します。

• CI/CD 実装

  • npm 12 への段階的移行ブランチを作成し、ビルド行程で postinstall 依存がないかを自動検知するジョブを追加します。
  • 必要なパッケージのみスクリプト許可する仕組み（フラグ・設定ファイル）を CI で集中管理。ローカルと CI の動作差をなくします。
  • 2FA 周りは PAT/トークンのスコープ最小化、ローテーション自動化、OIDC フェデレーション（GitHub Actions → npm へのワークロード ID 連携等）を優先検討します。

• 監視・検知

  • パッケージ更新イベントとロックファイル差分を SIEM に取り込み、希少依存の追加や、人気パッケージの突然のメンテナ交代を検知ルール化します。
  • インストール時スクリプトの許可イベントを監査ログ化し、異常頻度・時間帯・ユーザーの相関でアラートを定義します。

• ガバナンス・教育

  • 「postinstall が走らないのが正常」という新常識を開発者の行動規範に落とし込み、README のコピペ実行を避ける実践的ガイドを提供します。
  • 重要リポジトリの「依存更新は PR＋レビュー必須」を徹底し、メンテナ交代・所有権変更のモニタリングを周知します。

参考情報:

• The Hacker News: npm 12 disables install scripts by default（該当変更の報道）
  https://thehackernews.com/2026/07/npm-12-disables-install-scripts-by.html

（お願い）本件は CI と開発者体験に直接効く構造変更です。いったん動かなくなる不便はありますが、そこで炙り出される「暗黙の自動実行」こそが長年の脅威の源でした。許可の明文化、ログの残存、整合性の検証——この3点をセットで前進させることが、サプライチェーン防御を現実の強度に引き上げる最短距離です。皆さんの現場での工夫を、また共有できれば嬉しいです。