npmサプライチェーン攻撃対策｜今すぐ打つ設定と感染チェック・主要事例の全体像

2025年の相次ぐパッケージ乗っ取りから、2026年8月の keyv 一連のパッケージ汚染（Shai-Hulud の再来）まで、npm のパッケージそのものに悪意あるコードを仕込むサプライチェーン攻撃が続いています。週あたり数億回ダウンロードされるライブラリが標的になり、`npm install` を実行しただけで認証情報を抜かれる事例も確認されました。

ニュースで「危ない」ことは分かっていても、知りたいのは「では、自社の npm プロジェクトを守るために今すぐ何をすればいいのか」ではないでしょうか。設定ファイルに何を書き、どのコマンドを使い、すでに汚染されていないかをどう確認するか——この具体的な手順が最初に必要になります。

本記事では、npm プロジェクトを守るために今日打てる設定とコマンドを冒頭にまとめ、続いて感染の確認手順、各対策の効果と限界、実際に起きた攻撃の手口、感染時の事後対応、そして npm 標準機能で塞ぎきれない部分に使えるサービスまでを順に解説します。

今すぐ打つ最小の防御

まず、自社の npm プロジェクトに今日から入れられる設定を整理します。いずれも npm と GitHub の標準機能だけで完結し、追加のツールは要りません。下の表は「どの設定を・どこに書き・何が防げて・何は防げないか」をまとめたものです。

※ 設定名・既定値は npm CLI v11 / GitHub Docs の2026年11月時点の公式ドキュメントによります。

ライフサイクルスクリプトの自動実行を止める

npm の攻撃の多くは、`npm install` の際に自動で走る install 時スクリプト（preinstall / install / postinstall）を実行経路に使います。まず止めたいのがこのスクリプト実行です。`.npmrc` に次の1行を書くと、ライフサイクルスクリプトが実行されなくなります。

この `.npmrc` はプロジェクト直下に置いてリポジトリにコミットすると、チーム全員と CI/CD に同じ設定が効きます。個人環境だけに効かせたい場合はユーザーのホームディレクトリの `~/.npmrc` に書きます。

# .npmrc
ignore-scripts=true

公式ドキュメントでは、この設定の既定値は false（標準ではスクリプトが走る）と定められています。有効にしても npm start や npm test 本体は動きますが、それらに紐づく pre / post スクリプトは走りません。

この設定は依存パッケージだけでなく、自社プロジェクトの prebuild や pretest などの pre / post スクリプトも止めます。CI で必要なものがあれば、該当スクリプトを明示的に実行する形に切り替えておきます。

If true, npm does not run scripts specified in package.json files. Note that commands explicitly intended to run a particular script, such as npm start, npm stop, npm restart, npm test, and npm run will still run their intended script if ignore-scripts is set, but they will not run any pre- or post-scripts.

出典：config（ignore-scripts）｜npm Docs（docs.npmjs.com）

sharp や bcrypt のようにネイティブビルドを伴うパッケージは、スクリプトを止めると動かなくなることがあります。その場合は npm rebuild sharp のように個別にビルドし直します。また、npm v12（2026年7月リリース）以降は、この停止が既定の挙動です（後述のnpm v12 の変更を参照）。使用中の npm のバージョンによっては、すでに既定でオフになっています。

公開直後のバージョンを避ける（min-release-age）

悪意あるバージョンは、公開から短時間で発見・削除されることが少なくありません。そこで、公開から一定日数が経ったバージョンだけをインストールする設定が有効です。npm には min-release-age が用意されており、次のように日数を指定します。

# .npmrc
min-release-age=7

公式ドキュメントでは、指定した日数より前から公開されていたバージョンだけで依存ツリーを構築する設定と説明されています。利用には npm v11.10.0 以降が必要です（2026年2月11日のリリースで追加されました）。

出典・参考資料（2件）

• 出典：config（min-release-age）｜npm Docs（docs.npmjs.com）
• 出典：CHANGELOG 11.10.0（2026-02-11, add min-release-age）｜npm/cli（github.com/npm/cli）

待機日数を何日にするかは、後述の効果と限界で触れるとおり、7日は「大半の攻撃を防げる目安」であって保証値ではありません。急ぐ場合でも数日は確保する運用が現実的です。

Dependabot の更新 PR を遅らせる（cooldown）

GitHub の Dependabot でバージョン更新を自動化している場合は、cooldown を設定すると、公開から一定日数が経つまで更新 PR の作成を遅らせられます。min-release-age と同じ「公開直後を避ける」考え方を、Dependabot 側でも効かせる設定です。

# .github/dependabot.yml（抜粋）
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7

semver のレベル別に待機日数を変えたい場合は semver-major-days / semver-minor-days / semver-patch-days を指定できます。ここで押さえておきたい限界が1つあります。cooldown はバージョン更新にだけ効き、セキュリティアップデートには適用されません。公式ドキュメントにも明記されています。

Defines a cooldown period for dependency updates, allowing updates to be delayed for a configurable number of days. The cooldown option is only available for version updates, not security updates.

出典：Dependabot options reference（cooldown）｜GitHub Docs（docs.github.com）

lockfile を固定し、CI では npm ci –ignore-scripts で入れる

依存バージョンを固定するには、package-lock.json をリポジトリにコミットします。公式ドキュメントでは、このファイルは「生成された正確なツリーを記述し、後続のインストールで同一のツリーを再現できるようにするもので、ソースリポジトリにコミットすることを意図している」と説明されています。

CI/CD では npm install ではなく npm ci を使います。npm ci は lockfile どおりにクリーンインストールし、package.json や lockfile を書き換えません（公式の表現で「installs are essentially frozen」）。

ここに --ignore-scripts を併せると、ビルド環境でもライフサイクルスクリプトを止められます。

# CI/CD での依存インストール
npm ci --ignore-scripts

出典・参考資料（2件）

• 出典：npm-ci｜npm Docs（docs.npmjs.com）
• 出典：package-lock.json｜npm Docs（docs.npmjs.com）

自社がすでに汚染バージョンを踏んでいないかの確認手順

設定を入れて今後を守るのと並行して、「すでに汚染されたバージョンを入れていないか」を確認しておきます。多くの攻撃は特定のパッケージの特定バージョンに紐づくため、自社の依存ツリーと突き合わせれば調べられます。

npm ls と lockfile の照合で該当バージョンを探す

特定のパッケージが依存ツリーのどこに・どのバージョンで入っているかは、npm ls で確認できます。間接依存として引き込まれている場合も表示されます。

# 例: keyv がどのバージョンで入っているか確認
npm ls keyv

# lockfile から該当バージョンを直接探す
grep -n "\"keyv\"" package-lock.json

侵害されたバージョンが見つかった場合は、後述の事後対応にすぐ進みます。見つからなくても、間接依存は更新で入れ替わるため、下記の侵害バージョン一覧と定期的に突き合わせておくと安全です。

依存が数百あるプロジェクトでパッケージを1つずつ調べるのは現実的ではありません。まとめて確認するには npm audit が使えますが、これは既知の脆弱性データベースとの照合なので、公開直後でまだ登録されていない悪性版は検出できないことがあります。網羅的・継続的に調べるには、後述の依存ライブラリ検査（SCA）の仕組みを併用します。

主要インシデントの侵害バージョン・ハッシュ（IoC）と突き合わせる

2026年8月の keyv 一連の汚染では、GMO Flatt Security が解析した検体のファイルハッシュ（SHA-256）などの IoC（Indicators of Compromise＝侵害の痕跡）が公開されています。ビルド成果物やキャッシュに同じファイルが混ざっていないかを照合する際の手がかりになります。

package.json   : c272bde97cecd5a4e90cfebba7a70f704e1ab583267595dea944b706a7a6fab9
setup.mjs      : 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668
Math_Symbol.js : 9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc

侵害されたパッケージとバージョンは事件ごとに多数にのぼります。keyv の事例では keyv 6.0.0、flat-cache 6.1.24、file-entry-cache 11.1.6、cacheable 2.5.1 などが報告されました。

Shai-Hulud の第一波では @ctrl/tinycolor 4.1.1・4.1.2 を避けるよう周知されています。本記事で扱った主要インシデントの代表的な危険バージョンを下表にまとめます。自社の npm ls や lockfile と突き合わせてください。

※ 代表例です。各事件とも影響範囲はさらに広く、全量は下記の一次情報の一覧で確認してください。

出典・参考資料（3件）

• 出典：IoCs（SHA-256 ハッシュ）｜GMO Flatt Security「keyv 等 複数著名パッケージへのソフトウェアサプライチェーン攻撃の概要と対応指針」（blog.flatt.tech）
• 出典：Keyv and friends compromised（侵害パッケージ一覧）｜Aikido Security（aikido.dev）
• 出典：ctrl/tinycolor and 40+ npm packages compromised（Affected Packages）｜StepSecurity（stepsecurity.io）

各対策はどこまで守れて、どこは守れないか

ここまでの設定は有効ですが、どれも万能ではありません。守れる範囲と守れない範囲を正しく押さえておくと、どこに穴が残るか、追加で何が要るかが見えてきます。

ignore-scripts は「依存の悪性コードそのもの」は止めない

ignore-scripts が止めるのは install 時に自動で走るスクリプトです。これは多くの攻撃の実行経路を塞ぎますが、悪意あるコードが依存パッケージ本体に仕込まれ、アプリの実行時に読み込まれて動くタイプには効きません。

postinstall を止めても、汚染されたライブラリを import して使えば被害は起こりえます。スクリプト停止は入口を1つ塞ぐ対策であり、依存そのものの信頼性を保証するものではないと捉えておくのが正確です。

provenance（来歴の署名）は「悪性コードがないこと」を保証しない

npm の provenance は、パッケージがどのソースコードからどのビルド手順で作られたかを検証可能な形で結びつける仕組みです。ただし、公式ドキュメントは「provenance があっても、そのパッケージに悪性コードがないことは保証しない」と明記しています。

When a package in the npm registry has established provenance, it does not guarantee the package has no malicious code. Instead, npm provenance provides a verifiable link to the package’s source code and build instructions, which developers can then audit and determine whether to trust it or not.

出典：Generating provenance statements｜npm Docs（docs.npmjs.com）

これは実際の事件でも裏づけられています。2026年8月の keyv の汚染では、悪性版が正規の CI/CD パイプライン経由で公開されたため、GitHub Actions による有効な provenance が付いていました。

メンテナのアカウントやパイプラインが乗っ取られると、正しい署名のまま悪性版が流通しうるということです。来歴の署名は改ざん検知には役立ちますが、これだけで悪性版を見分けることはできません。

出典・参考資料（2件）

• 出典：keyv and friends compromised（valid provenance signed by GitHub Actions）｜Aikido Security（aikido.dev）
• 出典：keyv 等への攻撃の概要と対応指針（有効な npm OIDC provenance）｜GMO Flatt Security（blog.flatt.tech）

min-release-age の7日は「保証」ではなく「目安」

待機日数の「7日」は、セキュリティ研究者 William Woodruff が過去の攻撃を調べた結果に基づく目安です。本人も標本が小さいことを前提に、7日で大多数は防げるが万能ではないと述べています。

In the very small sample set above, 8/10 attacks had windows of opportunity of less than a week. Setting a cooldown of 7 days would have prevented the vast majority of these attacks from reaching end users. Increasing the cooldown to 14 days would have prevented all but 1 of these attacks. Cooldowns are, obviously, not a panacea.

出典：We should all be using dependency cooldowns｜William Woodruff（blog.yossarian.net）

待機日数を延ばせば防げる確率は上がりますが、依存の更新が遅れるトレードオフもあります。7日前後を起点に、自社の更新頻度とリスク許容度で調整するのが実務的です。

対策を層で整理する

個々の対策は、守る対象の層がそれぞれ違います。開発者の手元・CI/CD・レジストリ・実行環境・組織の運用という層ごとに、どの手段が効くかを並べると、自社でどこが手薄かを確かめやすくなります。

標準機能で守れるのは主に上の2層です。レジストリ・依存の層や実行環境の層には、後述するような専用の仕組みが必要になります。

npmサプライチェーン攻撃で実際に何が起きたか

対策を納得して運用するために、実際に起きた攻撃を振り返ります。ここ1年あまりで、手口と規模の異なる攻撃が続けて確認されました。

主要インシデントの時系列

※ 件数は報告元・集計時点により差があります。各事件の一次情報は本節末尾のリンク集を参照してください。

共通する手口（アカウント乗っ取り→スクリプトで窃取→自己増殖）

npmサプライチェーン攻撃とは、ソフトウェア開発の通常の流れの中で、npm のパッケージを通じて悪意あるコードが配られる攻撃を指します。個々の事件は違っても、手口には共通の流れがあります。

起点はたいてい人のアカウントの侵害です。メンテナが偽の二要素認証更新メールなどのフィッシングで npm アカウントを乗っ取られ、そこから悪性版が公開されます。次に、公開されたパッケージを誰かが npm install すると、install 時スクリプトが認証情報を窃取します。狙われるのは npm・GitHub のトークン、クラウドの認証情報、SSH 鍵などです。

Shai-Hulud 以降で目立つのが自己増殖です。盗んだトークンを使って、感染したメンテナが持つ別のパッケージへ自動で悪性版を公開し、被害が連鎖的に広がります。keyv の事例では、各パッケージの package.json に "preinstall": "node setup.mjs" が加えられ、設置プログラム（dropper）が認証情報を集めて外部へ持ち出していました。

主要インシデントの一次情報

各事件の詳細や侵害パッケージの一覧は、調査にあたった各社・各者の報告で確認できます。

出典・参考資料（5件）

• 参考資料：What AWS Security learned from responding to recent npm supply chain threat campaigns（Nx・tea[.]xyz・chalk/debug）｜AWS（aws.amazon.com）
• 参考資料：ctrl/tinycolor and 40+ npm packages compromised（Shai-Hulud）｜StepSecurity（stepsecurity.io）
• 参考資料：The Axios npm Attack｜OPSWAT（japanese.opswat.com）
• 参考資料：Keyv and friends compromised｜Aikido Security（aikido.dev）
• 参考資料：keyv 等への攻撃の概要と対応指針｜GMO Flatt Security（blog.flatt.tech）

感染していた場合の事後対応

確認の結果、汚染バージョンを踏んでいた場合は、被害が起きた前提で動きます。これらの攻撃は認証情報の窃取を狙うため、まず漏れた可能性のある認証情報をすべて入れ替えることが最優先です。

侵害前提で、認証情報を種類別にすべてローテーションする

GMO Flatt Security の対応指針では、影響を受けた可能性がある場合に入れ替えるべき対象が具体的に挙げられています。

影響を受けた可能性がある場合は、AWS, GitHub, npm, Kubernetes, Vault, SSH のクレデンシャルおよび暗号通貨ウォレットの秘密鍵を即座にローテーションしてください。

出典：keyv 等への攻撃の概要と対応指針（TL;DR）｜GMO Flatt Security（blog.flatt.tech）

感染したマシンから到達できた認証情報は、すべて漏れたものとして扱います。npm・GitHub のトークン、各クラウド（AWS・GCP・Azure など）の認証情報、CI/CD のシークレット、SSH 鍵が主な対象です。トークンは再発行し、古いものは失効させます。

クリーン再構築とログ・リポジトリの確認

汚染された node_modules やキャッシュは削除し、既知の正常なバージョンに固定し直してから、クリーンな環境で入れ直します。あわせて、ビルドログや CI/CD の実行履歴、GitHub のリポジトリに不審なワークフローファイルやコミットが追加されていないかを確認します。

Shai-Hulud 系の攻撃では .github/workflows/ に悪性のワークフローが注入される事例が確認されているためです。

npm標準機能で塞げる範囲と、残るリスクへの本格対策

npm 自体の標準機能も強化が進んでいます。まず塞がる範囲が今後どう広がるかを押さえ、そのうえで標準機能だけでは残るリスクを整理します。

npm v12 のデフォルト変更で塞がる範囲

npm v12 は2026年7月8日にリリースされ、依存パッケージの install 時スクリプトが既定で実行されなくなりました（allowScripts の既定がオフ）。これまで .npmrc に ignore-scripts=true を自分で書いていた対策が、v12 以降は標準の挙動です。

あわせて、git 依存をブロックする --allow-git の既定が none に、リモート URL 依存をブロックする --allow-remote の既定が none になりました。この挙動は npm 11.16.0 以降では警告として先行確認でき、v12 で既定になっています。

binding.gyp を持つネイティブビルド系のパッケージや、git・file・link 依存の prepare スクリプトも対象になります。該当する依存があるプロジェクトは、npm approve-scripts で明示的に許可リストを作り（拒否は npm deny-scripts）、その内容を package.json に記録してコミットします。

出典・参考資料（2件）

• 出典：CHANGELOG 12.0.0（2026-07-08, 依存の lifecycle script を既定でブロック・–allow-git / –allow-remote 既定 none）｜npm/cli（github.com/npm/cli）
• 出典：Upcoming breaking changes for npm v12（2026-06-09 予告）｜GitHub Changelog（github.blog）

標準機能で残るリスクと、それを埋める仕組み

ここまでの標準機能は、スクリプトの自動実行を止め、公開直後の版やアカウント乗っ取りの影響を抑えます。一方で、依存パッケージ本体に仕込まれた悪性・脆弱なコードを、インストール前に見分けることは標準機能ではできません。

provenance があっても悪性コードの有無は保証されず、cooldown はセキュリティアップデートには効かず、ignore-scripts は依存のコードそのものは止めないためです。この残りのリスクを埋めるのが、次のような仕組みです。

• 依存ライブラリ検査（SCA）：依存ツリーを解析し、既知の脆弱性や悪性パッケージを検出する
• SBOM（部品表）の作成：使っている依存を一覧化し、どのバージョンがどこに入っているかを可視化する
• 依存ファイアウォール・公開直後パッケージの検査：悪性と判定したパッケージをインストール前にブロックする
• ソースコード診断：自社のコードに潜む脆弱性を洗い出す

このうち依存ライブラリ検査（SCA）や SBOM の作成を継続的に運用するための専用ツールは数が多く、守りたい対象の範囲（サーバー・コンテナ・自社コードの OSS 依存など）や SBOM 対応の有無で選び方が変わります。製品ごとの違いを比べたい場合は、以下の比較記事が参考になります。

これらを開発工程に組み込めるサービスを、次のセクションで紹介します。

残るリスクの対策に使えるサービス

標準機能で塞ぎきれないリスクに、継続的に開発工程へ組み込めるサービスを2つ取り上げます。npmサプライチェーン（依存側）の残リスクに直接効くのは、依存ライブラリ検査（SCA）・悪性パッケージ検出・SBOM を備える1つ目の Aikido Security です。

2つ目の CoWorker 脆弱性診断サービスは、依存の検査ではなく、自社が書くコードやアプリ側の点検を担います。依存対策と並行して自社コードの弱点も継続的に洗い出したい場合の選択肢です。以下はそれぞれの対応範囲を比べた表です。

1. Aikido Security（株式会社AndGo）

ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中の Web アプリを1つの管理画面で検査する SaaS です。npmサプライチェーン対策との関係では、依存ライブラリ検査（SCA）に加えて、悪性パッケージを検出する Malware Detection、依存の一覧を可視化する SBOM 作成までを備えています。

検出したアラートは自動でトリアージされ、誤検知を抑えられます。Slack・Teams・Jira・AWS などと連携でき、IDE やプルリクエストのレビューに組み込んで、開発の流れの中で継続的に検査する使い方ができます。

無料の Developer プランがあり、導入前に試せる点も特徴です。日本では株式会社AndGo が販売・問い合わせの窓口となり、日本円の請求書払いにも対応しています。料金は年間契約・利用者10人までで月額5万円台からが案内されています（AndGo 取扱ページ）。

検査を開発工程の中に組み込むというこの考え方の背景について、日本窓口である株式会社AndGo 代表取締役の原氏は、インタビューで開発現場の変化を次のように語っています。

2. CoWorker 脆弱性診断サービス（CoWorker株式会社）

ツールを自分で回すのではなく、専門家に診断を依頼したい場合の選択肢です。CoWorker株式会社が、自社開発の AI「Red Agent」による自動解析と、社内の専門家による最終確認を組み合わせて提供しています。

診断メニューは、ソースコードと設計書を解析する「ソースコードAI診断」、稼働中の Web アプリ・API を対象とする「動的脆弱性診断」、攻撃を想定した「実践攻撃シミュレーション診断」の3つです。

ソースコードAI診断は本番環境に影響を与えずに実行でき、料金は150,000円から案内されています。AI による一次解析で診断時間を従来比で短縮しつつ、専門家がレポートまで仕上げる構成です。自社が開発・公開するコードやアプリの弱点を、依存対策と並行して継続的に点検したい場合に向きます。

この診断時間の短縮がどのような仕組みによるものか、CoWorker株式会社 Sales Manager の一ノ瀬氏は、インタビューで次のように説明しています。

ここで取り上げた2サービスのほかにも、脆弱性診断サービスは診断方法（手動・ツール自動・ハイブリッド）や対象範囲、費用相場が幅広くあります。自社の状況に合うものを一覧で比較検討したい場合は、以下の記事が参考になります。

まとめ

npmサプライチェーン攻撃への対策は、まず標準機能でできることから始められます。.npmrc に ignore-scripts=true と min-release-age=7 を設定し、lockfile をコミットして CI では npm ci --ignore-scripts を使います。

この最小構成で、install 時スクリプトの実行と公開直後の版を避けられます。あわせて、npm ls と侵害バージョンの照合で、すでに汚染を踏んでいないかを確認しておきます。

一方で、これらは依存そのものの悪性コードを見分けるものではありません。provenance や cooldown にも効く範囲の限界があります。依存の検査（SCA）や SBOM、自社コードの診断といった仕組みで、残るリスクを埋める検討を進めるとよいでしょう。

よくある質問（FAQ）

Q. npmサプライチェーン攻撃とは何ですか？

A. npmサプライチェーン攻撃とは、ソフトウェア開発の通常の流れの中で、npm のパッケージを通じて悪意あるコードが配られる攻撃です。攻撃者はメンテナのアカウントをフィッシングなどで乗っ取り、悪性版のパッケージを公開します。

開発者や CI/CD がそれを npm install すると、install 時スクリプトなどを経由して認証情報が盗まれ、盗んだトークンでさらに別のパッケージへ悪性版が自動公開される（自己増殖する）事例も確認されています。

Q. npmサプライチェーン攻撃を防ぐために今すぐ打つべき設定は何ですか？

A. npm の標準機能だけでできる最小構成は、.npmrc に ignore-scripts=true と min-release-age=7 を設定し、package-lock.json をコミットして、CI では npm ci --ignore-scripts を使うことです。

これで install 時スクリプトの自動実行を止め、公開直後のバージョンを避け、固定したバージョンでクリーンにインストールできます。Dependabot で更新を自動化している場合は dependabot.yml に cooldown を加えると、更新 PR も公開から一定日数遅らせられます。

Q. ignore-scripts=true を設定すると npm パッケージのビルドが動かなくなりませんか？

A. sharp や bcrypt のようにネイティブビルドを伴うパッケージは、ignore-scripts=true で動かなくなることがあります。その場合は npm rebuild sharp のように対象を個別にビルドし直せば利用できます。

npm start や npm test 本体は動き、止まるのはそれらに紐づく pre / post スクリプトだけです。また、npm v12（2026年7月リリース）以降は、この停止が既定の挙動です。

Q. min-release-age は何日に設定すればよいですか？

A. 7日前後が出発点の目安で、保証値ではありません。セキュリティ研究者 William Woodruff が過去の攻撃10件を調べた結果では、8件が1週間未満で削除されており、7日の待機で大多数を、14日なら1件を除くすべてを防げたとされています。日数を延ばすほど防げる確率は上がりますが依存の更新が遅れるトレードオフがあるため、自社の更新頻度とリスク許容度に合わせて調整してください。

Q. これらの対策に必要な npm のバージョンはいくつですか？

A. min-release-age の利用には npm v11.10.0 以降（2026年2月11日のリリースで追加）が必要です。ignore-scripts の設定や lockfile のコミット、npm ci --ignore-scripts は従来のバージョンでも使えます。

install 時スクリプトを既定で止める挙動は npm v12（2026年7月8日リリース）以降で標準になり、npm 11.16.0 以降では警告として先行確認できます。

Q. バージョンを固定（lockfile のコミット）すれば npmサプライチェーン攻撃は防げますか？

A. バージョン固定は新しく公開された悪性版を自動で取り込むことは防ぎますが、それだけで攻撃を防ぎきることはできません。固定したバージョン自体がすでに汚染されていれば効果はなく、依存の悪性コードそのものを見分ける仕組みではないためです。lockfile のコミットは重要な土台ですが、スクリプトの停止・公開直後の版の回避・依存の検査と組み合わせて初めて有効に働きます。

Q. provenance（来歴の署名）が付いていれば、その npm パッケージは安全ですか？

A. provenance が付いていても、そのパッケージに悪性コードがないことは保証されません。provenance はパッケージがどのソースコードからどのビルド手順で作られたかを検証可能にする仕組みで、npm 公式ドキュメントも「悪性コードがないことは保証しない」と明記しています。

実際に2026年8月の keyv の汚染では、悪性版が正規の CI/CD パイプライン経由で公開されたため、有効な provenance が付いていました。来歴の署名は改ざん検知に役立ちますが、これだけで悪性版を見分けることはできません。

Q. なぜコードレビューでは悪性な npm パッケージに気づけないのですか？

A. 悪性コードが自社のソースコードではなく、外部の依存パッケージ側に仕込まれるため、通常のコードレビューの範囲外にあるからです。リポジトリ上で見えるのは package.json の依存エントリの変更だけで、実際のマルウェアはインストール時に外部から取り込まれます。だからこそ、インストール前に依存パッケージの中身やライフサイクルスクリプトを検査する仕組みが必要になります。

Q. npmサプライチェーン攻撃に感染したかもしれないとき、まず何をすべきですか？

A. まず、漏れた可能性のある認証情報をすべて入れ替える（ローテーションする）ことが最優先です。これらの攻撃は認証情報の窃取を狙います。感染したマシンから到達できた npm・GitHub のトークン、各クラウド（AWS・GCP・Azure など）の認証情報、CI/CD のシークレット、SSH 鍵、暗号資産ウォレットの秘密鍵などは、漏えい前提で再発行し、古いものを失効させます。

あわせて汚染された node_modules やキャッシュを削除してクリーンな環境で入れ直し、.github/workflows/ に不審なワークフローが追加されていないかも確認します。

Q. npm の標準機能だけで npmサプライチェーン攻撃を防ぎきれますか？

A. 標準機能だけでは、依存パッケージ本体に仕込まれた悪性・脆弱なコードをインストール前に見分けることはできません。スクリプトの自動実行停止や公開直後の版の回避には効きます。一方で、provenance は悪性コードの有無を保証せず、cooldown はセキュリティアップデートには効かず、ignore-scripts は依存のコードそのものは止めないためです。

この残りのリスクを埋めるには、依存ライブラリ検査（SCA）や SBOM の作成、悪性パッケージをインストール前にブロックする依存ファイアウォール、自社コードのソースコード診断といった仕組みを開発工程に組み込む検討が有効です。

脆弱性診断・セキュリティ対策サービスの資料を一括チェック

MCB FinTechカタログでは、依存ライブラリ検査やソースコード診断などに対応する脆弱性診断サービスの最新資料を無料で一括請求できます。対応範囲や料金を並べて比較できます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。