【コラム】「npm install」で会社が乗っ取られる？ ― axios事件から学ぶサプライチェーン攻撃の現実

はじめに

2026年3月31日、JavaScript開発者の間に衝撃が走りました。

世界で最も使われているHTTP通信ライブラリ「axios」（週間ダウンロード数1億超）に、マルウェアが仕込まれたバージョンが公開されたのです。

「有名なライブラリだから安全」——そんな常識が、一夜にして覆りました。

本コラムでは、技術的な詳細を噛み砕きながら、「自社の開発環境をどう守ればいいのか」 を考えます。エンジニアでない方にも読んでいただけるよう、できるだけ平易に書きます。

何が起きたのか

ひとことで

axiosという有名なソフトウェア部品の管理者アカウントが乗っ取られ、正規の配布ルートからマルウェア入りバージョンが公開されました。

もう少し詳しく

ソフトウェア開発では、世界中の開発者が作った「パッケージ」と呼ばれる部品を組み合わせてシステムを作ります。これらのパッケージは「npm」というインターネット上の倉庫で管理・配布されています。

今回の攻撃の流れは、こうです。

1. 攻撃者が、axiosの管理者のアカウント情報を盗んだ
2. そのアカウントを使って、マルウェア入りのaxiosを正規の倉庫（npm）に公開した
3. 開発者がいつも通り npm install（部品の取り寄せコマンド）を実行すると、マルウェア入りバージョンがインストールされる
4. インストールした瞬間、PCがリモートで操作できる状態にされてしまう

宅配便に例えると、いつも使っている通販サイトの倉庫に、正規品そっくりの偽商品が紛れ込んだようなものです。注文も届け先も正規ルート。届いた箱を開けたら、中身が違っていた——しかも開けた瞬間に被害が発生する。

なぜ「有名だから安全」は通用しないのか

axiosはGitHub上でスター数10万超、世界中の企業が使っている超定番ライブラリです。コードレビューも活発で、品質に問題はありませんでした。

しかし、今回壊されたのは「コード」ではなく「アカウント」でした。

どれだけコードの品質管理が厳重でも、管理者のパスワードが1つ漏れれば、正規の配布ルートからマルウェアを送り込めてしまうのです。

これは「サプライチェーン攻撃」と呼ばれる手法で、近年急速に増えています。

年	事例	影響
2021	ua-parser-js 乗っ取り	週間800万DLのパッケージに暗号通貨マイナーが混入
2024	xz-utils バックドア	Linux基盤に3年がかりでバックドアが仕込まれた
2026	axios 乗っ取り	週間1億DLのパッケージにRAT（遠隔操作ツール）が混入

規模も手口も、年々高度化しています。

企業として何を守るべきか

1. まず現状を把握する

自社の開発プロジェクトで、axiosの汚染バージョン（1.14.1 または 0.30.4）が使われていないか確認します。エンジニアに以下のコマンドを実行してもらってください。

npm list axios

2. 「ロックファイル」を正しく使う

パッケージの取り寄せには npm ci というコマンドを使います。これは「前回と同じバージョンを正確に再現する」コマンドです。

一方、npm install は「互換性のある最新バージョン」を取りにいきます。今回のケースでは、これが汚染バージョンを引き込むトリガーになり得ました。

たった2文字の違いですが、セキュリティ上の意味はまったく異なります。

3. バージョンを「固定」する

「1.x系の最新」ではなく「1.14.0」のように、使うバージョンを明示的に指定します。多少の手間はかかりますが、意図しないアップグレードによる被害を防げます。

4. ロックファイルの変更をレビュー対象にする

開発チームがコードをレビューする際、「どのパッケージが追加・更新されたか」も確認する仕組みを作ります。見慣れないパッケージが増えていないか、バージョンが意図せず上がっていないかをチェックする——これが最後の防衛線になります。

「うちはソフトウェア会社じゃないから関係ない」は本当か

「自社でnpmなんて使っていないから大丈夫」と思われるかもしれません。

しかし、以下に心当たりはないでしょうか。

• 外部の開発会社に業務システムを委託している
• SaaSやクラウドサービスを利用している
• 社内にちょっとしたツールを作れるエンジニアがいる

これらのシステムの裏側で、axiosのようなオープンソースパッケージは日常的に使われています。自社が直接使っていなくても、取引先やサービス提供者を通じて間接的に影響を受ける可能性はあります。

サプライチェーン攻撃の怖さは、まさにここです。自分が気をつけていても、「信頼の連鎖」のどこか一箇所が崩れれば、その先すべてに影響が及びます。

経営者・マネージャーが今日できること

技術的な対処はエンジニアに任せるとして、経営判断としてできることがあります。

1. 「依存パッケージの棚卸し」を指示する

自社プロジェクトが依存しているパッケージの一覧を出してもらい、その中に既知の脆弱性がないか確認させましょう。npm audit というコマンド一つで、自動チェックができます。

2. 「ロックファイルの運用ルール」を確認する

npm ci を標準にしているか、ロックファイルの変更はレビューされているか。この2点だけで、今回のような攻撃のリスクは大幅に下がります。

3. シークレット（APIキー等）の管理状況を確認する

万が一マルウェアに感染した場合、最大の被害は「シークレットの流出」です。APIキーやパスワードがどこに保管されているか、定期的にローテーション（更新）されているかを把握しておくことが重要です。

まとめ

今回のaxios事件は、オープンソースのエコシステムが抱える構造的なリスクを改めて突きつけました。

ソフトウェア開発は、世界中の開発者が作った部品を「信頼」して組み合わせることで成り立っています。その信頼がパスワード一つで崩れ得るという現実を、私たちは受け入れなければなりません。

だからといって、オープンソースを使わないという選択肢は現実的ではありません。大切なのは、「信頼するが、検証する」 という姿勢を開発プロセスに組み込むことです。

ロックファイルを使う。バージョンを固定する。変更をレビューする。地味な一手間ですが、この一手間が、いざというとき会社を守ります。

AppTalentHubでは、こうしたセキュリティインシデントの情報をいち早くキャッチし、お客さまの開発環境を守るための支援を行っています。自社の依存パッケージの安全性に不安がある方は、お気軽にご相談ください。

---

参考リンク:

• axios サプライチェーン攻撃の詳細分析（Zenn）

汚染バージョン: axios@1.14.1, axios@0.30.4
安全バージョン: axios@1.14.0, axios@0.30.3