npm v12の破壊的変更とサプライチェーン対策を整理する

はじめに

以前、axiosサプライチェーン攻撃を踏まえたnpm設定の見直しと、AIエージェント時代のnpmサプライチェーン対策について記事を書きました。

その流れでnpmのセキュリティ関連の変更を追っていたところ、GitHub Changelogでnpm v12に入る予定の破壊的変更が公開されました。公開日は2026年6月9日で、npm v12自体は2026年7月リリース予定とされています。

今回の変更は、過去記事で手元の .npmrc や AGENTS.md によって補強していた考え方が、npm本体のデフォルト挙動に近づく内容です。

本記事では、2026年6月時点で公開されている予告内容をもとに、npm v12で変わる npm install の方向性を整理します。

参考にした一次情報は以下です。

• https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
• https://docs.npmjs.com/cli/v11/commands/npm-approve-scripts/
• https://docs.npmjs.com/cli/v11/commands/npm-deny-scripts/
• https://docs.npmjs.com/cli/v11/using-npm/config/

背景

これまでのnpmは、依存パッケージが持つ preinstall、install、postinstall などのライフサイクルスクリプトを、基本的に自動実行する前提で動いていました。

この挙動は便利です。esbuild や sharp のように、インストール時にバイナリを取得したりネイティブモジュールをビルドしたりするパッケージでは、利用者が追加作業をしなくても環境が整います。

一方で、サプライチェーン攻撃の観点では大きなリスクになります。依存関係として取り込んだパッケージに悪意ある postinstall が含まれていた場合、利用者が明示的に実行したつもりのないコードが npm install のタイミングで動くためです。

過去記事では、この自動実行を止めるために .npmrc の ignore-scripts=true を使い、必要なスクリプトだけ @lavamoat/allow-scripts で許可する構成を紹介しました。さらに、AIエージェントが勝手にガードを外さないように AGENTS.md へ禁止事項を書く運用もまとめました。

npm v12の変更は、この「自動実行をやめて、必要なものだけ明示的に許可する」という方向性をnpm本体側で推し進めるものです。

npm v12で変わること

GitHub Changelogでは、npm v12で予定されている破壊的変更として、主に3つの挙動が挙げられています。

重要なのは、どれも「今まで自動で行われていたことを、明示的な許可制に寄せる」変更だという点です。

allowScripts がデフォルトでオフになる

npm v12では、依存パッケージの preinstall、install、postinstall が、プロジェクトで明示的に許可されない限り実行されなくなります。

Git、file、link依存の prepare も同じ扱いです。また、明示的な install スクリプトがなくても、binding.gyp を持つパッケージでnpmが暗黙的に実行する node-gyp rebuild もブロック対象になります。

これは、過去記事で紹介した ignore-scripts=true と似ています。ただし、npm v12の allowScripts は単純に全部止めるだけでなく、プロジェクトの package.json に「どの依存パッケージのinstallスクリプトを許可するか」を記録していく設計です。

たとえば、ネイティブモジュールを使うプロジェクトでは以下のような差が出ます。

過去に ignore-scripts=true を入れたときと同じく、ここで重要なのは「スクリプトを持つパッケージは全部危険」と決めつけないことです。必要なものはあります。ただし、必要だから自動で何でも実行するのではなく、レビューしたうえで許可する運用に変わります。

Git依存関係がデフォルトで止まる

--allow-git のデフォルトも none になります。これにより、直接依存・推移的依存を問わず、Git URLを参照する依存関係は明示的に許可しない限り解決されなくなります。

Git依存は、npm registryに公開されたパッケージよりもレビューや再現性の面で注意が必要です。タグやコミットSHAで固定していない場合、同じ package.json でも別の内容を取得してしまう可能性があります。

また、ChangelogではGit依存の .npmrc がGit実行ファイルを上書きできる経路にも触れられています。ignore-scripts だけでは塞げないコード実行パスがあった、ということです。

筆者の開発環境ではGit依存を使うことはそう多くありませんが、チーム内で使用される可能性もあるため、リリース前に package.json と package-lock.json にGit依存がないかを確認しておきたいと思います。

リモートURL依存もデフォルトで止まる

--allow-remote のデフォルトも none になります。これは、https://example.com/package.tgz のようなURL tarball依存を、明示的に許可しない限り解決しない変更です。

リモートURL依存は、社内配布のtarballや一時的な検証で使われることがあります。ただし、npm registryを経由しないため、監査・キャッシュ・署名・メタデータの扱いが通常の依存より見えにくくなります。

今回の変更により、package.json や package-lock.json に残っている「昔の一時対応」が見つかる可能性があります。これを機に、registryへ公開する、社内registryへ移す、GitHub Packagesなどに寄せる、といった整理を検討できます。

既存の対策との関係

過去記事で紹介した対策とnpm v12の変更は、置き換えというより役割分担で見ると分かりやすいです。

特に min-release-age は、npm v12の3つの変更とは別の防御です。installスクリプトが止まっていても、公開直後の悪意あるパッケージや乗っ取られたバージョンを即座に取り込むリスクは残ります。

そのため、過去記事で入れた以下のような設定は、npm v12後も意味があります。

# .npmrc
min-release-age=7
audit-level=high

# .npmrc
min-release-age=7
audit-level=high

一方で、ignore-scripts=true はnpm v12の allowScripts と重なる部分があります。npm v12へ移行したあと、プロジェクトによっては ignore-scripts=true を外して allowScripts に寄せる選択肢も出てきます。

@lavamoat/allow-scripts を使っている場合も、すぐに同じ設定として扱わないほうが安全です。過去記事の構成ではLavamoat側のポリシーとして管理していたため、npm本体の npm approve-scripts が書き込む allowScripts と見比べ、どちらを正にするかを決める必要があります。

ただし、すぐに外す必要はありません。ignore-scripts=true は「何があってもinstall時に実行させない」という強い設定です。CIで明示的に npm rebuild や許可済みスクリプトの実行を分けているプロジェクトでは、引き続きその運用のほうが分かりやすい場合があります。

現時点で見ておきたいこと

GitHub Changelogでは、npm 11.16.0以降でv12に向けた警告を確認できると案内されています。npm v12そのものはまだリリース前ですが、スムーズに移行できるように、今のうちから見ておきたいポイントを整理します。

依存パッケージのinstallスクリプト

最初に見ておきたいのは、依存パッケージの中でinstall時のスクリプトに依存しているものです。sharp、canvas、esbuild のようなネイティブモジュールやバイナリ配布を伴うパッケージでは、install時の処理が動く前提になっていることがあります。

現時点では、これらをすぐに許可リストへ入れるというより、「なぜinstall時の処理が必要なのか」「バージョン更新時に再レビューすべきか」を把握しておく段階だと考えています。

Git依存とURL依存

次に、package.json やロックファイルにGit依存、URL tarball依存が残っていないかを確認したいところです。

この種の依存は、昔の一時対応や未公開パッケージの検証として入り、そのまま残ることがあります。npm v12では明示的な許可が必要になる見込みなので、リリース前の今のうちに「registry版へ戻せないか」「コミットSHAや配布元が説明できるか」を見直す価値があります。

npm approve-scripts は方針確認から始める

npm v12関連のドキュメントでは、npm approve-scripts や npm deny-scripts が紹介されています。これらは、installスクリプトを持つ依存について、許可・拒否の意思を package.json 側へ記録するためのコマンドなようです。

執筆時点ではnpm v12は未リリースです。そのため、ここでは方針だけ押さえておこうと思います。たとえば、以下のような方針を先に決めておくと、実際の移行作業で慌てずに済むはずです。

• installスクリプトは、必要なものだけ許可する
• 許可理由をPull Request上で説明できるようにする
• --all 相当の一括許可を標準運用にしない
• 既存の @lavamoat/allow-scripts とnpm本体の allowScripts のどちらを正にするか決める

このあたりの判断基準を先に決めておけば、実際にnpm v12へ上げるタイミングで慌てにくくなります。

CI/CDとDockerで影響が出やすい場所

ローカルで npm install が通っても、CI/CDやDockerビルドで止まる可能性があります。過去記事でも触れたとおり、コンテナやCIはホストの ~/.npmrc をそのまま引き継がないことが多いためです。

特に影響が出やすいのは、クリーンな環境で npm ci を実行している場所です。ローカルでは既存の node_modules やキャッシュで気付かない問題が、DockerのクリーンビルドやCIの新規ジョブで表面化することがあります。

現時点では、DockerfileやGitHub Actionsの書き方を先回りして大きく変えるより、Node.jsとnpmのバージョン、npm ci を実行している場所、ネイティブモジュールを含む依存の有無を把握しておくのが現実的です。実際の移行作業は、npm v12の正式リリース後に挙動を確認してからでも遅くないはずです。

リリース前の棚卸し観点

最後に、既存プロジェクトで今のうちに見ておく観点を整理します。

筆者の環境では、まず依存関係の棚卸しを先に進める方針にします。npm v12の正式リリース前に package.json の許可設定を急いで増やすより、どの依存がinstall時の処理を必要としているのかを把握しておくほうが、後の判断がしやすいためです。

また、min-release-age は引き続き残します。npm v12の変更はinstall時のコード実行経路を狭めるものですが、公開直後のバージョンを即座に拾わない防御とは役割が違うためです。

まとめ

npm v12の破壊的変更は、npm install の安全側デフォルトを大きく変える内容です。installスクリプト、Git依存、リモートURL依存が明示許可に寄ることで、過去記事で手動設定していたサプライチェーン対策の一部がnpm本体の標準挙動に近づきます。

ただし、これで対策が不要になるわけではありません。min-release-age、CI/CDやDockerへの設定伝搬、AGENTS.md によるエージェント行動の制御は、npm v12後も別の防御層として残ります。

今回の作業で改めて感じたのは、サプライチェーン対策は「一度設定して終わり」ではなく、ツールのデフォルト変更に合わせて運用を更新し続けるものだということです。まずはnpm v12の正式リリースを待ちつつ、手元のNode.jsプロジェクトでinstall時の処理に依存しているパッケージを棚卸ししていきます。