要約：脆弱性スキャナーを超えたnpmサプライチェーンセキュリティ
npmサプライチェーンセキュリティとは、JavaScriptプロジェクトがインストールするすべてのパッケージが正当で、改変されておらず、安全であることを確認する手法です。 既知の脆弱性がないというだけではない。
- ギャップ： 従来のnpm脆弱性スキャナーは、パッケージをCVEデータベースと照合します。悪意のあるパッケージにはCVEがないため、スキャンを通過します。
- の証拠： 2026年3月、乗っ取られた管理者アカウントによって、週間のダウンロード数が1億回を超えるaxiosが、約3時間にわたってマルウェア配信チャネルへと変貌した。
- 入り口： ほとんどのnpm攻撃はインストールスクリプトを介して行われ、それはあなたが入力した瞬間に実行されます。
npm install. - 修正： パッケージが公開された時点で悪意のある動作を検出し、CVEが出現した後ではなく、インストールの実行方法を強化する。
2026年3月31日、何千人もの開発者がJavaScriptでごく一般的なコマンドを実行した。 npm install彼らの中には、世界中のウェブアプリケーションの大部分で使用されているHTTPクライアントであるaxiosの新しいバージョンをプルした者もいた。依存関係スキャナーは正常のままで、ビルドも成功した。しかし、リモートアクセス型トロイの木馬がひっそりと彼らのマシンに侵入したのだ。
その話には脆弱性は一切関係していなかった。だからこそ、多くのnpmセキュリティプログラムがそれを見逃したのだ。
axiosはどうなったのか
攻撃は単純かつ忍耐強いものだった。 axiosのメンテナーによる事後分析2 つの悪意のあるバージョン、1.14.1 と 0.30.4 が、リード メンテナーの侵害されたアカウントを通じて公開されました。攻撃者は axios のコードを 1 行も変更していません。新しい依存関係を 1 つ追加しました。 plain-crypto-js運営されていた postinstall 第2段階のペイロードを取得するスクリプト。
Microsoft Threat Intelligence はインフラストラクチャを 北朝鮮の国家アクターであるサファイア・スリートへ。汚染されたバージョンは約3時間公開された後、npmによって削除されました。CIの場合 pipeline あるいは、その期間中にインストールされたノートパソコンであれば、3時間で十分だった。
これは孤立した事例ではなかった。2025年9月、Shai-Huludワームは、メンテナートークンを盗み出し、自身を再公開することで、数百ものnpmパッケージに拡散した。手法は違えど、教訓は同じだ。npmでは信頼は自動的に継承されるため、攻撃者はそれを知っているのだ。
なぜあなたのnpm脆弱性スキャナーは何も警告しなかったのか
ほとんどのチームは、npmサプライチェーンのセキュリティを脆弱性の問題として捉えています。npm脆弱性スキャナーを実行し、依存関係ツリーを既知の脆弱性データベースと比較し、報告された問題を修正します。この作業は重要ですが、答える質問が異なるだけです。
| 次元 | 脆弱なパッケージ | 悪意のあるパッケージ |
|---|---|---|
| それは何ですか | バグのある正規のコード | あなたに危害を加えるために書かれたコード |
| CVEはありますか？ | 通常、最終的には | ほとんどは決してない |
| 危険な時 | 脆弱性が到達可能で悪用可能な場合 | インストールした瞬間 |
| 何がそれを捕らえるのか | 脆弱性データベース検索 | パッケージ自体の動作分析 |
| 必要な標準的な応答時間 | 数日から数週間 | 数分から数時間 |
脆弱性データベースには、既に誰かが分析してカタログ化した情報しか記載できません。1時間前に公開された悪意のあるパッケージは、どこにも登録されていません。そのため、スキャナーは「クリーン」と表示し、「クリーン」は安全と解釈されます。
これがnpmサプライチェーンセキュリティにおける根本的な変化です。もはや「このパッケージには既知の欠陥があるか？」ではなく、「このパッケージは本来行うべきではないことをしているか？」という問いが重要になります。
攻撃者がnode_modulesに侵入する4つの方法
- アカウント乗っ取り。 メンテナーの認証情報やトークンを盗み出し、既に信頼されているパッケージの改ざん版を公開する。これはaxiosの典型的な手口であり、パッケージ名がまさに本物そっくりなので、見破るのが非常に難しい。
- タイポスコーティング. パブリッシュ
axoisorreqeustsそして、タイプミスや質の悪いチュートリアルからのコピペ、あるいはAIコーディングアシスタントが間違った名前を提案するのを待つ。 - 依存関係の混乱. 社内パッケージと同じ名前の公開パッケージを公開します。レジストリの設定で公開パッケージが優先される場合、攻撃者のコードがインストールされます。
- スクリプトをインストールします。 上記のほとんどすべてに共通する点。npm はパッケージを実行可能にする。
preinstall(NAIST) とpostinstallスクリプトを自動的に実行するため、誰かが何かをインポートする前に悪意のあるコードが実行されます。 CISAによるアクシオス妥協案に関するガイダンス 設定を推奨しますignore-scripts=trueプレのためにcisまさにこの理由です。
npmサプライチェーンセキュリティの実践例
一つの対策だけで全ての攻撃を防ぐことはできません。しかし、いくつかの習慣を身につけることで、より攻撃されにくい標的になることができます。
- Commit ロックファイルとインストール
npm ci. ビルドは、レビューされたものを正確にインストールするべきであり、その日の朝にレジストリが提供していたものをそのままインストールするべきではない。 - インストールスクリプトはデフォルトで無効になっています。 作成セッションプロセスで
ignore-scripts=trueそして、本当に必要とするパッケージのみにスクリプトを許可する。 - 社内パッケージの範囲を明確にしましょう。 スコープのない内部名は、依存関係の混乱を招く原因となる。
- 出所を確認してください。 npm はサポートしています 出所に関する記述 公開されたパッケージをソースコードとビルドにリンクさせるものです。通常はこれらが含まれているプロジェクトから、これらが含まれていない状態で突然リリースされた場合は、自動化する価値のある危険信号です。
- 脆弱性スキャンとマルウェア検出を組み合わせる。 npmの脆弱性スキャナーは既知の脆弱性に対応するために残し、新しいパッケージが実際に何をするのかを分析する検出機能を追加してください。
5つ目の習慣は、ほとんどのチームが見落としているものであり、Axiosの攻撃によって露呈した習慣でもある。
悪意のあるパッケージが名前を付けられる前に捕捉する
ザイジェニの マルウェア早期警戒システム（MEW） 公開レジストリ（npmを含む）上の新しいパッケージが公開されるとすぐにスキャンし、既知の署名を待つことなくコードの動作を分析します。パッケージにフラグが立てられると、影響を受けるユーザーにはメール、メッセージングプラットフォーム、またはWebを通じて通知されます。hooks荷物は隔離されているので 停止できます CI/CD guardrails.
その周囲には ザイジェニの open source security 上記4つの攻撃経路が依存する残りの部分、すなわちタイポスクワッティング、依存関係の混乱、疑わしいインストールスクリプト、スコープ外の内部npmコンポーネントも捕捉します。また、NVD、OSV、GitHubのアドバイザリで既知の脆弱性もカバーし、到達可能性に基づいて優先順位付けされているため、実際に悪用可能なものだけを自動的に修正できます。 pull requests 修正のため。
MEWは無料の開発者プランに含まれています。 無料で始める そして、最初のnpmプロジェクトを数分でスキャンできます。
FAQ
npmのサプライチェーンセキュリティとは何ですか？
npmサプライチェーンセキュリティは、JavaScriptプロジェクトが依存するパッケージを通じて発生するあらゆるリスク（既知の脆弱性、悪意のあるパッケージ、侵害されたメンテナーアカウント、タイポスクワッティング、依存関係の混乱など）を網羅しています。脆弱性スキャンにとどまらず、インストールするパッケージが正当なものであることを検証します。
npmの脆弱性スキャナーはマルウェアを検出できますか？
通常はそうではありません。従来のnpm脆弱性スキャナーは、既知の脆弱性データベースと照合してパッケージをチェックします。新たに公開された悪意のあるパッケージはデータベースに登録されていないため、ツールがパッケージの動作も分析しない限り、チェックを通過します。
Is npm audit 十分な？
npm audit これは、既知の脆弱性に関する有用な無料のベースラインツールです。ただし、新たに公開されたマルウェア、タイポスクワッティング、依存関係の混乱は検出できず、脆弱な関数が実際にコードからアクセス可能かどうかも教えてくれません。
パッケージが悪意のあるものかどうかは、どうすればわかりますか？
警告の兆候としては、リモートコードをダウンロードまたは実行するインストールスクリプト、難読化されたコード、パッケージの目的に関係のないネットワーク呼び出し、ソースリポジトリで参照されていない新しい依存関係、およびプロジェクトが通常公開する出所情報のないリリースなどが挙げられます。
