npm セキュリティベストプラクティス

Mar 28, 2026 · 3 min read

npm エコシステムは世界最大のパッケージレジストリであり、その規模ゆえに攻撃者にとって高価値なターゲットとなっています。Shai-Hulud、event-stream、eslint-scope などの攻撃は、すべて同じ不都合な真実を示しています。パッケージをインストールすると、そのソースコードを一行も読む前に、マシン上で任意のコードが実行される可能性があるということです。これらの npm セキュリティベストプラクティスは、インストール、開発、公開のすべての段階でリスクを軽減するのに役立ちます。

重要なポイント

インストール後スクリプトをグローバルに無効化し、本当に必要なパッケージのみを許可リストに登録する。
リリース経過期間のクールダウンを設定し、公開直後の(潜在的に悪意のある)バージョンがビルドに自動的に到達しないようにする。
常にロックファイルをコミットし、CI パイプラインでは npm ci を使用して再現可能で改ざん耐性のあるインストールを実現する。
メンテナーアカウントを WebAuthn ベースの 2FA で保護し、OIDC トラステッドパブリッシングを介して公開することで、長期間有効なトークンを排除する。

なぜ今 npm サプライチェーンセキュリティが重要なのか

サプライチェーン攻撃は、あなたのコードを悪用するのではなく、他者のコードに対するあなたの信頼を悪用します。侵害されたパッケージが node_modules に入り込むと、認証情報を盗んだり、環境変数を外部に送信したり、さらに自己増殖したりする可能性があります。Shai-Hulud ワームだけでも、単一のインシデントでレジストリから 500 以上のパッケージが削除されました。脆弱性スキャンだけでは、このクラスの攻撃を捕捉できません。多層防御が必要です。

安全な依存関係管理:インストールを強化する

インストール後スクリプトを無効化する

インストール後スクリプトは、npm サプライチェーン攻撃における最も一般的な攻撃ベクトルです。グローバルに無効化しましょう:

npm config set ignore-scripts true
npm config set allow-git none   # npm CLI 11.10.0+

allow-git=none の設定が重要な理由は、git ベースの依存関係が独自の .npmrc を含んでおり、ignore-scripts を完全にバイパスしてライフサイクルスクリプトを静かに再有効化できるためです。

pnpm を使用している場合、バージョン 10 以降ではインストール後スクリプトがデフォルトで無効になっています。正当に必要なパッケージを明示的に許可リストに登録するには、pnpm-workspace.yaml を使用します:

allowBuilds:
  esbuild: true
  core-js: false

strictDepBuilds: true を有効にすると、レビューされていないビルドスクリプトは、静かな警告ではなく CI をブロックする失敗として扱われます。Bun もデフォルトでインストール後スクリプトをブロックし、package.json の trustedDependencies を介してオプトインできます。

ライフサイクルスクリプトが必要な場合は、@lavamoat/allow-scripts を使用して、スクリプトをグローバルに有効化するのではなく、監査可能な許可リストを作成します。

リリース経過期間のクールダウンを追加する

悪意のあるパッケージは、多くの場合、数時間または数日以内に発見され、公開が取り消されます。公開直後のバージョンをスキップすることで、問題があなたに到達する前にコミュニティが問題を発見する時間を与えます:

npm config set min-release-age 3

これにより、npm は 3 日未満に公開されたパッケージバージョンを無視するようになります。依存関係の自動更新については、Renovate や Dependabot などのツールが同等の minimumReleaseAge 設定をサポートしています。

ロックファイルをコミットし、`npm ci` を使用する

常に package-lock.json をコミットしてください。CI 環境では、npm install を次のように置き換えます:

npm ci

npm ci はロックファイルからのみインストールし、不一致がある場合は失敗し、異なるバージョンを静かに解決することはありません。これは、自動化されたパイプラインにおける再現可能で安全なビルドの基盤です。

盲目的にアップグレードしない

npm audit と npm outdated は有用なシグナルですが、完全なソリューションではなく、一つの入力として扱ってください。依存関係をアップグレードする前に、変更履歴を確認してください。このステップをスキップする一括アップグレードは避けましょう。各バージョンアップは潜在的な攻撃面の変化です。

パッケージメンテナー向けの安全な npm ワークフロー

2FA を有効化し、WebAuthn にアップグレードする

アカウント乗っ取りは、レジストリへのサプライチェーン攻撃の主要なメカニズムです。書き込みモード保護を有効にして、npm アカウントで 2FA を有効化します:

npm profile enable-2fa auth-and-writes

GitHub は、従来の TOTP ベースの 2FA よりもフィッシング耐性が大幅に高い、パスキーと WebAuthn ベースの認証をますます推奨しています。ハードウェアキーやパスキーは TOTP コードよりもフィッシングが困難なため、早めに切り替える価値があります。

トラステッドパブリッシング(OIDC)で公開する

長期間有効な npm トークンは負債です。OIDC を介したトラステッドパブリッシングにより、GitHub Actions や GitLab CI が、保存されたトークンを必要とせずに、短期間有効なワークフロースコープの認証情報を使用して npm と直接認証できます。また、**来歴証明(provenance attestations)**も自動的に生成され、消費者にパッケージがどこでどのようにビルドされたかの暗号的証明を提供します。

これはエコシステムが向かっている方向です。GitHub は、レガシートークンを段階的に廃止し、トラステッドパブリッシングを自動化のデフォルトパスにする計画を示しています。

インストールするものを検証する

公式レジストリが安全だと仮定しないでください。Socket や npq を使用して、インストール前にパッケージの疑わしい動作をスクリーニングします。ダウンロード数、リポジトリのアクティビティ、メンテナーの履歴を確認してください。特に AI コーディングアシスタントが提案するパッケージには注意が必要です。これらは存在しないパッケージ名を幻覚し、攻撃者がそれを登録する(スロップスクワッティングと呼ばれる手法)可能性があります。

まとめ

単一のツールですべての npm サプライチェーン攻撃を防ぐことはできません。最も重要なプラクティスは多層的です:ライフサイクルスクリプトを無効化し、ロックファイルを強制し、新バージョンにクールダウンを追加し、CI で npm ci を使用し、2FA を有効にした OIDC で公開を行います。各層は独立してリスクを軽減します。それらを組み合わせることで、ワークフローの侵害を意味のあるレベルで困難にします。

よくある質問

はい、esbuild や sharp などの一部のパッケージは、プラットフォーム固有のバイナリをダウンロードするためにインストール後スクリプトが必要です。スクリプトをグローバルに再有効化するのではなく、pnpm の allowBuilds 設定や LavaMoat の allow-scripts を使用した許可リストアプローチを使用して、ビルドステップが本当に必要な特定の信頼できるパッケージにのみ許可を与えてください。

いいえ。npm audit は公開されたアドバイザリ内の既知の脆弱性をチェックしますが、タイポスクワッティング、アカウント乗っ取り、または正当なパッケージに注入された悪意のあるコードなどの新規のサプライチェーン攻撃を検出することはできません。audit は、ロックファイルの強制、スクリプト制限、インストール前スクリーニングツールを含む、より広範な多層防御戦略内の有用なシグナルの一つとして扱ってください。

npm install は package.json を読み取り、依存関係の範囲を解決し、ロックファイルを変更できます。npm ci は package-lock.json からのみ読み取り、正確なバージョンをインストールし、ロックファイルが欠落しているか package.json と一致しない場合は即座に失敗します。再現可能で改ざん耐性のあるビルドを保証するために、継続的インテグレーションパイプラインでは常に npm ci を使用してください。

従来の npm トークンは、CI 環境に保存される長期間有効なシークレットであり、盗難の魅力的なターゲットとなります。OIDC トラステッドパブリッシングは、特定のリポジトリとアクション実行に紐付けられた、短期間有効なワークフロースコープの認証情報を生成します。シークレットはどこにも保存されず、各公開操作はそのソースに暗号的にリンクされ、検証可能な来歴証明が自動的に生成されます。

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.