「ソフトウェア産業は『未曾有の危機』に突入」 GMO Flatt Security米内氏に聞く“axios侵害”の教訓：「使っていないから一安心」は誤解 ソフトウェア開発者は「価値の高い標的」に

2026年3月31日、毎週約1億ダウンロードされていた主要HTTPクライアントライブラリ「axios」の主要開発者アカウントが乗っ取られ、同ライブラリの依存関係にマルウェアが仕込まれた悪意のあるバージョンが公開された。影響範囲は大きく、侵害の全体像と対応の指針を示したGMO Flatt Securityのブログ記事が注目を集めた。本稿は同社で記事を執筆した米内貴志氏にインタビュー。記事では書かれなかった執筆者としての思い、相次ぐ「ソフトウェアサプライチェーン攻撃」の教訓を聞いた。

[石川俊明，＠IT]

　2026年3月31日（日本時間）、OSS（オープンソースソフトウェア）エコシステムを震撼（しんかん）させるソフトウェアサプライチェーン攻撃が発生した。毎週約1億ダウンロードされていた主要なHTTPクライアントライブラリ「axios」において主要開発者（リードメンテナー）のアカウントが乗っ取られ、依存関係にマルウェアが仕込まれた悪意のあるバージョンが公開されたのだ。

　axiosは、WebブラウザやNode.jsでHTTP通信をするためのクライアントライブラリ。枯れたシステムから最新のCLI（コマンドラインインタフェース）ツールまで至る所に組み込まれている。開発者や開発現場にとっていわば「当たり前」の存在だ。

　axiosの侵害は、主要開発者が高度な標的型ソーシャルエンジニアリングの標的となり、PCを乗っ取られたことに端を発する。攻撃者は実在する企業の創業者を装い、偽のSlackワークスペースに開発者を招待し、Microsoft Teamsでのオンラインミーティングを設定。ミーティングの際、「何かが古いようだ」とアップデートを促した。開発者は正規のアップデートだと思い込み、RAT（Remote Access Trojan）をインストールしてしまった。

　攻撃者は開発者のPCを乗っ取った後、依存関係にマルウェアを仕込んだ悪意のあるバージョン（1.14.1および0.30.4）を、npmで直接公開した。

　GMO Flatt Securityの分析によると、インストール後に自身のスクリプトなどの痕跡を自己消去するため、フォルダを検査してもクリーンに見えるという巧妙な仕掛けが施されていたという。悪意のあるバージョンがnpmで露出していた時間はそれぞれ約2時間53分、約2時間15分という出来事であり、コミュニティーの尽力により公開から間もなく無効化（テイクダウン）された。

　もしここまで読んで「自分自身のプロジェクトでは影響がなさそうだから関係ないか」と安心したIT担当者がいるとすれば、それは非常に危険な状態かもしれない。

　本稿は、侵害発生後にいち早く「axios ソフトウェアサプライチェーン攻撃の概要と対応指針」を公開したGMO Flatt Securityで、同記事を執筆した米内貴志氏にインタビュー。記事では書かれなかった執筆者としての思い、相次ぐ「ソフトウェアサプライチェーン攻撃」の教訓を聞いた。

――本日はよろしくお願いします。axiosの侵害について詳細な対応指針をいち早く公開された背景には、どのような動機があったのでしょうか。

GMO Flatt Security 取締役副社長Co-CTO 米内貴志氏

米内氏　私は現在、GMO Flatt Securityで取締役副社長Co-CTO（最高技術責任者）として経営に携わりつつ、2026年1月からソフトウェアサプライチェーンセキュリティ事業の責任者を兼務しています。ソフトウェアサプライチェーンを巡る最新の脅威動向についてリサーチしたり、お客さまにレポーティングしたり、最新の脅威動向をどう弊社のプロダクトに落とし込んでいくかを検討したりしています。新規事業を立ち上げる際はいつも自分自身で手を動かすようにしており、axiosの侵害や直近で起きたコンテナ脆弱（ぜいじゃく）性スキャナー「Trivy」の侵害（関連記事）についても、私自身がいち早く動いて情報をお伝えした次第です。

――2026年1月にソフトウェアサプライチェーン事業を立ち上げられた矢先のことだったのですね。2025年に感染が拡大した自己増殖型ワーム「Shai Hulud」（関連記事）も大きな注目を集めましたが、このタイミングでの事業化と関係しているのでしょうか。

米内氏　2025年のShai Huludは、攻撃者にとって「どこまでやれるか」を試す攻撃だったと感じます。われわれとしては「こんな攻撃ができるということは、攻撃者はこれから攻撃を本格化させてくるだろう」という見立てがありました。そこで、2025年末に社内に向けて「2026年度はソフトウェアサプライチェーン事業に取り組んでいく」旨を伝え、弊社の期初である2026年1月に取り組みを始めた矢先、axiosの侵害が起きてしまったという状況です。

「防ぎ切れなかった」　既知の手口でも、わずか3時間で開発者を震撼させた

――axiosの侵害に対する対応指針をまとめて執筆された当時の率直な印象と、その後、被害に遭ったaxiosの主要開発者がGitHubで明かした「ポストモーテム（事後報告）」の内容をご覧になって、専門家としてこの一連の侵害をどう評価されていますか。

米内氏　最初に見掛けたときに抱いた感情は「これは影響がでかすぎる」というものでした。axiosを直接使っていなくても、依存関係のどこかに必ず存在しているのです。弊社の脅威ハンティングプラットフォームでも、世界的な大手テクノロジー企業が提供するものを含め、多様なパッケージの解析ログから「見知らぬ通信が飛んでいる」という膨大なアラートが流れていました。通信元をたどるといずれもaxiosの依存関係に仕込まれたマルウェアからであり、事態の深刻さを痛感したのです。

　攻撃の手口自体は、古くから見られる「ライフサイクルスクリプト（postinstallフック〈※〉）」を経由した攻撃であり、決して目新しいものではありません。これはパッケージをインストールした直後にスクリプトが自動実行される仕組みを悪用したものです。使い古された手口でこれほど影響範囲が大きかったことは、われわれセキュリティ業界やJavaScriptのエコシステムが長年防ぎ切れていなかったという事実をあらためて突き付けられたと、率直に感じました。

　調べていく中で判明した攻撃者のスピード感と練度の向上にも、強い危機感を覚えました。数時間で攻撃し、侵害が明るみに出たと悟ればすぐにC2（Command and Control）サーバの通信を絶って証拠の隠滅を図っていたのです。

　今回はいずれも3時間以内に悪意のあるバージョンを無効化しており、防御側の成長を感じた瞬間でもありました。ただ、結果としては確実に「負け戦」でした。われわれ開発者が普段使っているOSSがいつでも侵害されかねないという前提で、自衛する必要がある時代に突入してしまったと感じています。

※編注： axios侵害においてもaxiosのソースコード自体は書き換えられておらず、依存先として追加された悪性パッケージ「plain-crypto-js」がpostinstallフックで呼び出され、自動実行される仕掛けになっていた。開発者が直接axiosをインストールしていなくても、別のライブラリやコンポーネントがaxiosに依存（間接依存）していれば、気付かぬ内にマルウェアが自動実行されるリスクがあった。

「開発者のPC」が狙われるワケ

――ポストモーテムによると、開発者はnpmの二要素認証（2FA）を有効にしていました。実在企業を偽装した偽のSlackワークスペースやMicrosoft Teamsを用いた巧妙なソーシャルエンジニアリングで開発者のPC自体を乗っ取り、2FAを実質的に無力化（迂回）したことも明らかになっています。開発者のPCを狙う目的や狙いとは何でしょうか。

米内氏　攻撃者の最終目的は「お金（マネタイズ）」でしょう。かつてAnonymousのようなハッカー集団が誇示していたような名声や名誉目的ではなく、ランサムウェア（身代金脅迫型マルウェア）でもご存じのように、盗んだ情報を売れば確実にお金になる時代です。事実、クレデンシャル（認証情報）を盗んで売るだけの脅威アクターと、それを買って攻撃を仕掛ける脅威アクターが分業化されており、立派なサイバー犯罪のマーケットが成立しています。

　国家を背景とするような脅威アクターも体系立って作戦を練り上げ、外貨を獲得することが目的になっており、「どこかを攻撃できました」という名声よりは、金銭目的で攻撃を仕掛けるのが目的だと考えます（※編注：axiosの主要開発者を標的にした脅威アクターは「北朝鮮と関係を持つ勢力・組織」という分析もある）。

　その上で、なぜ開発者のPCが狙われるのか。それは攻撃者にとって非常に「合理的」だからです。簡潔に言えば、開発者は企業にとって大切なクレデンシャルを持っているということです。弊社はペネトレーションテスト（侵入テスト）事業もしていますが、開発者の環境は堅牢（けんろう）ではないと、日々感じています。

　開発者のPCに侵入できれば、たいていステージング環境を攻撃できますし、ステージング環境に侵入できれば、プロダクション環境を攻撃できるケースもあります。開発系、CI/CD（継続的インテグレーション／継続的デリバリー）ツールまで侵入できればどうにかなるというのは珍しくありません。

　企業のビジネス部門や営業部門を1人狙うよりも、本番環境やデータベースでクエリを実行できる権限を持った開発者を1人狙う方がはるかに確実です。いくらデータを暗号化していても、クエリを実行できる権限があればデータを引き出せてしまう。つまり、企業の中でも最も価値のあるデータに近い開発者を直接狙うのが攻撃者目線で見ると「手っ取り早い」のです。

　ソフトウェアサプライチェーン攻撃の入口としての圧倒的なハードルの低さも開発者が狙われる理由に挙げられるでしょう。企業の中でSaaS（Software as a Service）の利用申請をしたり、会議室を予約したりする際には社内の承認プロセスやルールがあるはずです。しかし、「OSSをインストールすること」に関しては、誰の承認も取らずに全ての開発者が自由に実行できてしまいます。

　axiosのような毎週約1億回もダウンロードされる著名なパッケージの依存関係にマルウェアを仕込むことができれば、誰の承認もいらない無防備な入り口を通じて、グローバルで数万人の開発者の端末に一気に到達できます。その中に金融系や高い権限を持つ開発者が1人でもいれば攻撃者にとっては「大成功」というわけです。攻撃者にとってこれほど「おいしい」標的はありません。

　だからこそ、アカウントのID/パスワードやトークンだけをピンポイントで抜くのではなく、PCの全権限を奪いに来るのです。今回明らかになった乗っ取りの手口や、乗っ取り後のパッケージ汚染までの速度はかなり洗練されている印象を受けます。

　私の見立てでは、攻撃者の中で効果を検証済みの「プレイブック」（攻撃マニュアル）が確立されていて、彼らにとっても最も効率的な手法を標的に応じて使い分けていると考えます。

――悪意のあるバージョンの露出時間はいずれも3時間未満だったとのことですが、攻撃者にとってはこれだけでも十分な時間なのでしょうか。

米内氏　攻撃者は端末が感染した後の行動（クレデンシャルの窃取など）を自動化して準備していたようです。直近2〜3週間に起きたTrivyの侵害を見ても、数時間あれば「次の侵害・攻撃につなげるためのクレデンシャル」は窃取されてしまっています。

　露出時間が2時間だろうが8時間だろうが、1個でも重要なクレデンシャルが漏れていれば結果は同じです。いくら早く無力化しようとも、起こった時点で防衛側としては「負け」だったということを認識すべきでしょう。

「何も対策していませんでした」では済まされない時代へ

――axiosやTrivyの侵害といったソフトウェアサプライチェーン攻撃が開発者に大きな衝撃を与えている今、あらためてどのようなマインドセットを持つべきでしょうか。

米内氏　まず大前提として、「axiosを使っていない環境」はほとんど存在しないと考えるべきです。直接使っていなくても間接的に依存しています。そしてaxiosの侵害は、単なる一つの被害事例ではなく、未知の脅威の「呼び水」だと考えるべきです。

　直近は「SBOM（ソフトウェア部品表）などでソフトウェアが何に依存しているか把握しましょう」という段階でしたが、これからは「依存関係が分かった上で、えたいの知れないパッケージを本当に使っていいのか？」を悩まなければならないフェーズに入りました。

　もし今回、axios侵害の影響を受けてしまったとしても、「しっかり対策をして次から気を付けよう」で許されるかもしれません。ただ、次にまたソフトウェアサプライチェーン攻撃が起きて、「やられました、何も対策はしていませんでした」では、間違いなくエンドユーザーから責任を問われる事態になると考えます。

　法曹の専門家ではないので個別具体的なコメントは差し控えたいと思いますが、過去に「SQLインジェクション」対策をしていなかった開発会社に対して、発注者から明示されなくとも「専門家として当然果たすべき義務だ」として責任を問われたケースがありました。それと同じように、今後はOSSを利用する企業側にもより厳しい目線で責任が問われる時代になっていくとみています。

　開発者はこれまで以上に、OSSを使うことのセキュリティリスクに敏感になり、企業としてもOSSの管理体制やセキュリティ投資をソフトウェア開発のスタンダードとして受け入れていく必要があります。

　とはいえ、現代のソフトウェア開発においてOSS活用は避けて通れません。開発者や企業はリスクを踏まえながら進めなければならない、非常にしんどい時代に突入しています。

開発スピードを落とさない「最低限の対策」とは

――axiosの侵害のように影響範囲が大きい侵害が話題になると、OSSの使用を厳しく制限したり、GitHubの使用を禁止したりするといった現場の開発スピードを著しく損ないかねないルールを整備するケースも懸念されます。現場の開発スピードやモチベーションを損なわずに、ソフトウェアサプライチェーン攻撃から組織を守っていくために、「これだけは再度点検してほしい」「開発環境をこう変えてほしい」という点はありますか。

米内氏　まず前提として、「当該パッケージへの依存がないかどうかを確認する」「不審な通信がされていなかったかどうかを確認する」といったaxios侵害に対する直接的な緩和策の実施や対応の指針については、弊社のブログ記事や他のメディアなどでも広く発信されている通りですので、まずはそちらをご確認いただきたいと思います。

　その上で、ブログで解説した内容へのプラスアルファとして、現場の皆さまに最も強く意識していただきたいのは、「普段管理していないエンドポイントを点検すること」です。

　法人のPC端末であれば、EDR（Endpoint Detection and Response）などのセキュリティ製品が入っていたり、SOC（Security Operation Center）が端末ログを監視・ハンティングしてくれていたりするケースが多いでしょう。

　一方で、Amazon Web Services（AWS）上の仮想マシン（VM）やサーバレス製品（「AWS Lambda」など）には、こうしたセキュリティ製品が入っておらず、必要なテレメトリーやログすら取れてないケースが非常に多いのです。だからこそ、対策として意識すべきことがあるとすれば、まずは「今見ていないところ（死角）を見る」ということを皆さまに一番に提言したいです。

――なるほど。「見ていないところを見る」となると、VMやサーバレス環境の全てに対して、PC端末と同じようなセキュリティ製品を導入すべきということになるのでしょうか。ただ、それではコストの大幅な増大を招くため、企業の意思決定としては非常にハードルが高い印象も受けます。

米内氏　おっしゃる通りです。そこは明確にバランスを取る必要があります。

　結論から言えば、金融機関のように特段の厳しいコンプライアンス要件が求められる環境を除けば、ランタイムのレイヤーで攻撃を遮断・ブロックするようなセキュリティ製品を、全てのサーバに無理に持っていく必要はなく、個人的な肌感覚としては「入れない方向」で十分だと考えています。なぜなら、コストの問題だけでなく、プロダクション環境のパフォーマンスに対しても悪影響を与えうるためです。

　そこで、開発のスピードやパフォーマンスを落とさないために、現実的に最低限やってほしい対策として「有事に調査するためのログ（ネットワークの通信ログやコマンド実行ログなど）を確実にとっておくこと」が挙げられます。

――「セキュリティインシデントが起きた際、ログがなければ影響範囲が全く分からない」というのはランサムウェア攻撃の被害事例でも課題としてよく挙げられています。ソフトウェアサプライチェーン攻撃にも通ずるセキュリティ対策の基本というわけですね。

米内氏　一方で、現実にはプロダクション環境でそうしたログが取られていないケースがほとんどです。数万〜数百万ユーザーを抱える大規模なSaaS環境では、通信ログを全量確保するのも「コスト面で現実的ではない」という声もあるでしょう。全量確保が本当に大変なことであるのは、私も気持ちとして痛いほど理解しています。

　しかし、今はソフトウェアサプライチェーン攻撃のリスクがかつてないほど高い状態にあります。ログが全くなければ、「自社に影響があったかどうかも顧客に説明できない」「全部のデータが抜かれたと想定して対応するしかない」という最悪の対応に陥ってしまいます。ログさえ確保していれば影響範囲が明確になり、被害箇所も特定できます。「ここだけ対応しよう」と判断できれば、結果的に有事の際の対応・復旧コストを大幅に下げることができます。

　これからのソフトウェアサプライチェーンの脅威と戦うために必要な投資として割り切るべきタイミングに来ていると考えます。

　その上で、もしセキュリティ予算や、パフォーマンスへの影響をビジネスとして許容・納得できる環境であれば、最大限の対策として「CNAPP（Cloud Native Application Protection Platform）」と呼ばれるような、クラウド環境を守るためのセキュリティ製品を導入し、検知やブロックの能力を高めていくのがポイントになると考えます。

　少し皮肉な話ですが、一部金融系のセキュリティ基準や、省庁系ガイドラインでは、クラウド環境を含む全てのサーバにアンチウイルスやEDRを導入することが実質義務付けられている場合もあります。

　普通の企業からすると「そこまでやるの？　過剰じゃない？」と思われがちなポリシーですし、私自身、正直なところナンセンスではと感じる部分がありました。しかし、axiosの侵害においては「影響の有無を後からログで追える」という点で大きなアドバンテージを得る結果となりました。逆に、そういったポリシーがなくクラウドを運用していた（ログを取っていない）企業は「自社に影響があったかどうかも答えられない」という状況に陥ってしまっています。

　現在のプロダクト開発環境は、ある意味で「ゼロトラスト以前」の状態に近いといえます。「開発者はITリテラシーが高いから、強い権限を持たせておいても大丈夫だろう」と、利便性を優先しがちです。

　だからこそ経営・エグゼクティブ層の方々にはぜひ、開発スピードとセキュリティのバランスを取り、「CTOのPCが乗っ取られても、または開発系システム（CI/CDなど）が侵害されても、本番環境やプロダクトには致命的な影響が出ない」といった「侵害される前提で被害を最小化するシステム設計や権限の分離」への投資を進めていただきたいですね。

未曾有の危機からソフトウェア産業をどう守るか

――少し視点は変わりますが、直近のMicrosoftやMandiantなどのレポートでは「今後はAI（人工知能）を使った攻撃が主流になる」「AIが脅威になる」という見通しや予測が出ています。ソフトウェアサプライチェーン攻撃においても、こうした「AIの悪用」は加速していくと実感されていますか。

米内氏　私も100％その方向へ進むと確信しています。これからの脅威を語る上で忘れてはならないのが、まさにAIの悪用です。攻撃者はAIを使ってマルウェア作成や攻撃の自動化を恐ろしいスピードで加速させています。AnthropicなどのAI開発企業はセーフティ（安全対策）の強化を打ち出してはいますが、セーフティの効いていない別のAIモデルを悪用すれば極めて容易に攻撃できてしまうのが現実です。

　またAIにコードを書かせる「バイブコーディング」が普及しており、攻撃者にとって格好の標的を増やす結果につながってしまっています。これらを踏まえ、防御側もAIなどの技術を活用して守りを固めていく必要があります。

　弊社の「Takumi byGMO」（Takumi Guard機能）はnpmのproxyとして動作し、悪意あるパッケージを検知・ブロックする無料のサービスです。裏側では、日々公開される膨大な数のパッケージに対して、ペネトレーションテストの知見を持つ人間と独自に開発したAI「Takumi」のハイブリッド体制で検査を回しています。今回のaxios事案に当てはめると、午前11時台には弊社側でブロック対応が完了していました。悪性パッケージが無効化されるまでの数時間のうち、約1.5時間分は「感染するリスクを削る」ことができていた計算になります。

　防ぎ切れずにダウンロードしてしまった場合でも、後から「あなたが管理する環境で悪性パッケージがダウンロードされていました」と通知する機能があります。これにより、SNSなどで話題になってから慌てて調べるのではなく、先手でログの調査やクレデンシャルのローテーションなどの初動対応に移ることができます。

――最後に、開発者やセキュリティ担当者に向けてメッセージをお願いします。

米内氏　あえて強めの言葉を使わせていただきますが、私はaxiosやTrivyなど直近で起きている一連のソフトウェアサプライチェーン攻撃を、ソフトウェア産業にとっての「未曾有の危機」だと捉えています。

　ソフトウェア産業は、Linuxも含め、開発者同士でOSSを共有し、改善し合うという素晴らしいエコシステムを頑張って作り上げてきました。過去にも「XZ Utils」のように、OSSにバックドアが仕掛けられるケースはありましたが、2026年に入って起きている一連の攻撃によって「ここを狙えば明確に金銭を得られる（マネタイズできる）」という事実が、攻撃者に知れ渡ってしまいました。これはソフトウェア産業にとって危機的状況です。

　今後は、作り手である開発者も、OSSを使う企業も一丸となって、このエコシステムを守っていく必要があります。そうした中で、弊社もその一助となれるよう、引き続き取り組んでいく所存です。

――本日はありがとうございました。

---

　本当に恐ろしいのは今回のaxiosの侵害そのものではなく、「自社には関係なさそうだ」と目を背け、OSSという巨大なエコシステムの恩恵を享受するにとどまる企業の姿勢かもしれない。開発スピード向上のためのOSS活用と、侵害を前提としたセキュリティ対策への投資はセットで取り組むべき要件といえる。米内氏が指摘するように、OSSに関わる全ての企業が当事者として向き合うべき時が来ている。