GitHub、npm v12でinstallスクリプトをデフォルト無効化、サプライチェーン攻撃対策を強化

「npm installするたびに、知らないスクリプトが動いてるって本当でしゅか？」
「依存パッケージ経由でコードを実行されるって聞いて、何を確認すればいいか分からないんでしゅ……」

チップス

うちのCIも npm install で全部おまかせでしゅ……これって危ないんでしゅか？

ボス

ふふふ、そこにGitHubがメスを入れた。npm v12でインストール時スクリプトが既定で止まる。意味を押さえれば、自社のビルドを安全にできるぞ。

本記事では、GitHubが発表したnpm v12のセキュリティ変更について、何が既定で無効になり、開発現場が何を準備すべきかを整理します。

読み終える頃には、サプライチェーン攻撃に強いnpm運用へ切り替える着眼点が手に入ります。

npm v12で変わるインストールの既定動作

まずは何が、なぜ既定で無効になるのかを整理します。

「最大のコード実行面」を既定で閉じる

npm installは、依存ツリー全体のpreinstall・install・postinstallスクリプトを自動で走らせます。
そのため、どこかひとつのパッケージが汚染されただけで、開発端末やCI環境で任意コードが動いてしまいます。
GitHubはこれを「npmで最大のコード実行面」と表現し、npm v12ではallowScriptsを既定でオフにして自動実行を止めます。
あわせてGit由来の依存（–allow-git）やリモートURL由来の依存（–allow-remote）も既定で遮断し、悪用の入口を狭めます。

主な変更点は以下のとおりです。

チップス

依存のひとつが乗っ取られただけで、CI全体に広がっちゃうんでしゅか……。

ボス

そこが急所だ。eslint-config-prettierやShai-Huludの一件も、この自動実行が悪用された。既定を閉じれば、同じ手は通りにくくなる。

開発現場が今から備えるべきこと

既定が変わると、ビルドが止まる現場も出てきます。

事前に警告を洗い出し、信頼するものだけ承認する

native moduleのビルドなど、正規にスクリプトを必要とする依存は実際に存在します。
そこでGitHubは、まずnpm 11.16.0以降へ更新し、通常のインストールで表示される警告を確認するよう推奨しています。
そのうえで「npm approve-scripts –allow-scripts-pending」でスクリプトを持つパッケージを洗い出し、信頼できるものだけ承認してpackage.jsonをコミットします。
CIが自動実行に依存している場合は、承認済みの構成へ書き換えておけば、v12移行時の停止を避けられます。

移行に向けて進めたい手順は次のとおりです。

チップス

いきなり止まると困るから、今のうちに警告を見ておけばいいんでしゅね。

ボス

そういうことだ。前もって承認の棚卸しを済ませれば、7月の移行も慌てずに済むぞ。

まとめ：既定の安全化に運用を合わせる

npm v12は、install時スクリプトとGit・リモート依存を既定で止め、サプライチェーン攻撃の入口を狭める変更です。
開発現場はnpm 11.16.0以降で警告を確認し、信頼できる依存だけ承認する運用へ前倒しで移しておく必要があります。
既定が安全側に倒れる流れに合わせて、自社のビルドとCIを見直す好機といえます。
こうしたDevSecOps領域の実装に挑みたい方は、ぜひセキュリティフリーランス案件で多様な現場を経験してみてください。

参考: BleepingComputer「GitHub announces npm security changes to tackle supply-chain attacks」