アスクル・無印良品・ロフトのECサイトが同時停止 ― ランサムウェア攻撃によるサプライチェーン障害の実態

はじめに

2025年10月19日、アスクル株式会社(以下「アスクル」)のECシステムがランサムウェア攻撃を受け、同社が運営する法人向けサービス「ASKUL」および個人向け「LOHACO」を含む複数のオンラインサービスが停止しました。この障害は同社の物流システムを通じて株式会社良品計画(以下「無印良品」)や株式会社ロフト(以下「ロフト」)など取引先企業にも波及し、各社のECサイトやアプリにおいても受注停止や機能制限が発生しています。

本件は単一企業の被害にとどまらず、物流委託を介して複数のブランドに影響が拡大した点で、典型的な「サプライチェーン攻撃」の構造を示しています。特定のシステムやサーバーだけでなく、委託・連携によって結ばれた業務フロー全体が攻撃対象となり得ることを、あらためて浮き彫りにしました。

この記事では、今回の障害の概要と各社の対応、攻撃の背景、そしてサプライチェーンリスクの観点から見た課題と教訓について整理します。企業システムの安全性が社会インフラの一部となった現代において、こうした事案の分析は単なる被害報道にとどまらず、今後の再発防止とリスク管理に向けた重要な示唆を与えるものです。

発生の概要

2025年10月19日、アスクルは自社のECサイトにおいてシステム障害が発生し、注文や出荷業務を全面的に停止したことを公表しました。原因は、外部からのサイバー攻撃によるランサムウェア感染であり、同社が運営する法人向けサイト「ASKUL」および個人向け通販サイト「LOHACO」で広範なサービス停止が生じました。障害発生後、アスクルは速やかに一部のシステムを遮断し、被害の拡大防止と原因究明のための調査を進めていると説明しています。

この影響はアスクル単体にとどまらず、同社が物流業務を請け負う取引先にも波及しました。特に、無印良品を展開する良品計画およびロフトのECサイトで、受注処理や配送に関わる機能が停止し、利用者に対してサービス一時停止や遅延の案内が出されました。両社の発表によれば、システムそのものが直接攻撃を受けたわけではなく、アスクル傘下の物流子会社である「ASKUL LOGIST」経由の障害が原因とされています。

本件により、複数の企業が同一サプライチェーン上で連携している構造的リスクが明確になりました。単一の攻撃が委託先・取引先を介して連鎖的に影響を及ぼす可能性があり、EC事業や物流を支えるインフラ全体の脆弱性が浮き彫りになったといえます。現在、アスクルおよび関係各社は外部専門機関と連携し、被害範囲の特定とシステム復旧に向けた対応を進めている状況です。

アスクルにおけるシステム障害の詳細

アスクルは、2025年10月19日に発生したシステム障害について「身代金要求型ウイルス(ランサムウェア)」によるサイバー攻撃が原因であると公表しました。今回の攻撃により、同社の受注・出荷関連システムが暗号化され、通常の業務処理が不能な状態に陥りました。これに伴い、法人向けの「ASKUL」および個人向けの「LOHACO」など、主要なオンラインサービスが停止しています。

同社の発表によれば、攻撃を検知した時点で対象サーバー群を即時にネットワークから切り離し、被害の拡大防止措置を講じました。現在は、外部のセキュリティ専門機関と連携し、感染経路や暗号化範囲の特定、バックアップデータの検証を進めている段階です。復旧作業には慎重な手順が必要であり、現時点でサービス再開の明確な見通しは示されていません。

アスクルは、顧客情報および取引データの流出の有無についても調査を継続しており、「現時点では流出の確認には至っていない」としています。ただし、調査結果が確定していない段階であるため、潜在的なリスクについては引き続き注視が必要です。

本障害では、Webサイト上での注文や見積、マイページ機能の利用がすべて停止し、FAXや電話による注文も受付不可となりました。また、既に受注済みであった一部の出荷もキャンセル対象とされ、取引先や利用企業に対して順次連絡が行われています。これにより、法人・個人を問わず多数の顧客が影響を受け、企業間取引(B2B)における物流の停滞も発生しています。

アスクルは、再発防止策としてシステムの再設計およびセキュリティ体制の強化を進める方針を示しています。今回の事案は、単なる障害対応にとどまらず、EC事業と物流システムのサイバー・レジリエンス(復元力)を再評価する契機となる可能性があります。

他社への波及 ― 無印良品とロフトの対応

今回のアスクルにおけるシステム障害は、同社の物流ネットワークを通じて複数の取引先企業に波及しました。特に影響を受けたのが、無印良品を展開する良品計画と、生活雑貨チェーンのロフトです。両社はいずれもアスクルグループの物流子会社である「ASKUL LOGIST」を主要な出荷委託先としており、そのシステム障害により自社ECサイトの運用に支障が生じました。以下では、各社の対応を整理します。

無印良品の対応

良品計画は、アスクルのシステム障害発生直後に公式サイトおよびアプリを通じて影響状況を公表しました。自社のシステムが直接攻撃を受けたわけではなく、物流委託先の停止により商品出荷が困難になったことが原因と説明しています。そのため、無印良品のネットストアでは新規注文の受付を停止し、アプリの「マイページ」機能や定額サービスの申し込みなど一部機能を制限しました。

さらに、同社が予定していた会員優待キャンペーン「無印良品週間」についても、オンラインでの実施を見送り、店舗限定で開催すると発表しました。これにより、デジタルチャネルの販促施策にも影響が及んでいます。良品計画は現在、物流経路の再構築および一部代替ルートの確保を進めつつ、システム復旧の進捗に応じて段階的なサービス再開を検討しているとしています。

ロフトの対応

ロフトも同様に、自社の物流処理の一部をアスクル関連会社に委託しており、その停止に伴って「ロフトネットストア」のサービスを全面的に休止しました。公式サイトでは、商品の注文・配送が行えない状態であることを告知し、再開時期は未定としています。ロフトも自社サーバーや基幹システムに直接的な不正アクセスは確認されていないとしていますが、物流の一元化により依存度が高まっていたことが、今回の波及を拡大させた要因と考えられます。


両社のケースは、EC事業の運営における「委託先リスク」が顕在化した代表例といえます。顧客接点としてのECサイトが稼働していても、背後にある物流・受注システムの一部が停止すれば、結果的に販売全体が停止する構造的課題が浮き彫りになりました。今回の障害は、企業間のシステム連携が進む中で、委託先のセキュリティ対策を含めた全体的なリスク管理の重要性を再認識させる事例といえます。

攻撃の背景と特定状況

アスクルに対する今回のシステム障害は、身代金要求型ウイルス(ランサムウェア)を原因とするものであると報じられています。具体的には、オンライン注文や出荷管理のためのサーバー群が暗号化されたことにより、同社のECおよび物流関連の業務プロセスが停止しました。 

攻撃の「背景」には以下のような要素があります:

  • 日本国内におけるランサムウェア攻撃の急増傾向。2025年上半期では前年同期と比べておよそ1.4倍の発生件数が報告されています。 
  • 物流・出荷などのサプライチェーンを担う企業への攻撃が、エンドユーザー向けのブランドサイトやサービス停止を引き起こす“波及型リスク”として認識されている環境下。例えば、アスクルが被害を受けたことで、委託先・取引先である他社のECサービスが停止しています。 
  • 攻撃を受けたとされるアスクルが、自社発表で「受注・出荷業務を全面停止」「現在、影響範囲および個人情報流出の有無を調査中」としており、侵害からの復旧手順を外部セキュリティ企業と連携して進めている状況です。 

「特定状況」に関しては、以下が確認できています:

  • 攻撃者集団またはランサムウェアの種類について、アスクル側から公式に明確な名称の公表はされていません。現時点では、どの集団が本件を主導したかを確定できる公開情報は存在しません。
  • アスクルおよび関連する報道では、システム切断・影響範囲調査・顧客データ流出可能性の確認といった初期対応が行われていることが明らかになっていますが、復旧完了時期や影響を受けた具体的なシステム・データ項目までは公表されていない状況です。例えば「新規注文停止」「既存出荷キャンセル」などがアナウンスされています。 
  • 本件が国内サプライチェーンを通じて複数ブランドに影響を及ぼしている点が特徴であり、物流に深く関わる企業が間接的に影響を受ける典型的な構造を持っています。

以上のとおり、攻撃の背景としては日本国内のランサムウェア脅威の高まりおよびサプライチェーンを狙った攻撃の潮流があり、特定状況としては攻撃者の明確な特定には至っておらず、影響範囲の調査・復旧作業が進行中という段階にあります。

サプライチェーンリスクとしての位置づけ

今回のアスクルを発端とするECサイト停止は、単一企業のサイバー攻撃を超え、サプライチェーン全体の脆弱性が表面化した典型的な事例として位置づけられます。アスクルは物流・出荷インフラを複数企業へ提供しており、そのシステム障害が無印良品やロフトといった異業種の小売ブランドにまで波及しました。この構造的連鎖こそが、現代のデジタルビジネスにおけるサプライチェーンリスクの本質です。

まず注目すべきは、企業間のシステム依存度の高さです。ECや物流の分野では、在庫管理・受注処理・配送指示といった基幹プロセスが委託先のシステム上で完結しているケースが多く、委託先の停止が即時に業務停止へ直結します。今回のケースでは、委託先のインフラが暗号化されたことで、取引先企業は自社サービスを維持できなくなりました。

また、リスク分散の欠如も問題として浮き彫りになりました。多くの企業が効率性を優先し、単一の物流ベンダーやクラウド基盤に依存する傾向がありますが、サイバー攻撃の時代においては、効率と安全性が必ずしも両立しません。万一の停止時に備えた代替経路やバックアップシステムを確保することが、事業継続計画(BCP)の観点から不可欠です。

さらに、セキュリティガバナンスの境界問題も無視できません。サプライチェーンにおける情報共有やアクセス権限は複雑化しており、自社の対策だけでは防げない攻撃経路が存在します。委託先を含めたリスク評価や監査体制、ゼロトラスト(Zero Trust)アプローチの導入など、包括的なセキュリティ戦略が求められます。

総じて、今回の事案は「直接攻撃を受けていない企業も被害者となり得る」という現実を示しました。今後は、取引契約や委託管理の段階で、サイバーリスクを含む全体的な耐障害性を評価することが、企業の社会的責任の一部として位置づけられるでしょう。

各社の今後の対応と再発防止策

アスクル株式会社および影響を受けた取引先企業は、今回のサイバー攻撃を受けて、システムの復旧と再発防止に向けた包括的な対策を進めています。現時点では完全な復旧には至っていませんが、各社の発表内容や取材報道をもとに、今後の対応方針は次の三点に整理できます。

第一に、システム復旧と安全性確認の徹底です。アスクルは感染したシステムをネットワークから隔離し、バックアップデータの復旧可能性を検証しています。外部のサイバーセキュリティ専門企業と協力しながら、暗号化されたデータの復元と感染経路の分析を進めており、安全性が確認された範囲から段階的にサービスを再開する計画です。また、同社は調査完了後に、顧客情報や取引データの流出有無を正式に公表するとしています。

第二に、委託先を含めたサプライチェーン全体でのセキュリティ体制強化です。今回の障害では、アスクルだけでなく物流委託先や取引先の業務も停止したことから、単独企業の対策では限界があることが明らかになりました。良品計画およびロフトは、委託契約の見直しやバックアップルートの確保を検討しており、物流・情報システムの冗長化を進める方針を示しています。これらの動きは、委託元・委託先を問わず、共同でリスクを管理する「セキュリティ・パートナーシップ」の強化につながると考えられます。

第三に、社内ガバナンスとインシデント対応力の向上です。アスクルは、今回の事案を踏まえて全社的なセキュリティ教育の再構築を行い、職員へのフィッシング対策訓練やアクセス制御ポリシーの厳格化を実施する見通しです。さらに、政府機関や業界団体への情報共有を通じ、サプライチェーン攻撃への対応事例や知見を共有していく意向を示しています。これにより、同業他社を含む広範な防御網の構築が期待されます。

今回の一連の障害は、ECと物流が密接に統合された現代の商流におけるリスクを浮き彫りにしました。単なるシステム障害ではなく、事業継続性を左右する経営課題としてのサイバーセキュリティ対策が求められています。今後、各社がどのように復旧と改善を進め、信頼回復を図るかが注目されるところです。

おわりに

今回のアスクルに端を発したECサイト障害は、単なる一企業の被害ではなく、デジタル化された商流全体のリスク構造を浮き彫りにしました。アスクル、無印良品、ロフトという異なる業態の企業が同時に影響を受けたことは、物流・情報システム・販売チャネルが高度に統合されている現代のサプライチェーンの脆弱性を象徴しています。

企業がクラウドや外部委託先に業務を依存する中で、もはや「自社のセキュリティ対策」だけでは事業継続を保証できません。委託先や関連企業を含めた統合的なリスク管理体制、定期的な監査、そして異常発生時に迅速に業務を切り替えられる設計が不可欠です。また、情報公開の迅速さや、顧客・取引先への誠実な説明責任も企業の信頼回復に直結します。

本件は、EC業界や物流業界のみならず、すべての企業に対して「サプライチェーン全体でのセキュリティ・レジリエンス(回復力)」を再考する契機を与えるものです。今後、各社がどのように再発防止策を具体化し、業界全体での共有知へと昇華させていくかが、日本のデジタル経済の信頼性を左右する重要な課題になるでしょう。

参考文献

npm史上最大規模となる自己増殖型ワーム「Shai-Hulud」によるサプライチェーン攻撃

はじめに

2025年9月15日、JavaScript の主要パッケージエコシステムである npm において、これまでにない深刻なサプライチェーン攻撃が発覚しました。攻撃に使われたマルウェアは「Shai-Hulud」と名付けられており、その特徴は単なるパッケージ改ざんにとどまらず、自己伝播(ワーム)機能を備えている点にあります。これにより、感染したパッケージを利用した開発環境や CI/CD 環境から認証情報を奪い取り、さらに別のパッケージを自動的に改ざんして公開するという、従来の攻撃よりもはるかに広範な拡散が可能となりました。

被害は短期間で拡大し、確認されただけでも 200件近い npm パッケージが改ざんされており、その中には広く利用される有名ライブラリや大手企業関連のパッケージも含まれていました。OSS エコシステムは世界中の開発者や企業が依存する基盤であり、サプライチェーン攻撃は一部のパッケージ利用者だけでなく、そこからさらに派生する数多くのソフトウェアやサービスへ影響を与える可能性があります。

今回の Shai-Hulud 攻撃は、サイバー攻撃者がいかに OSS エコシステムを効率的な攻撃対象と見なしているかを改めて示すものであり、npm を利用するすべての開発者・組織にとって重大な警鐘となっています。本記事では、攻撃の概要や技術的な特徴を整理するとともに、想定されるリスクと具体的な対応方法について解説します。

背景

近年、ソフトウェアサプライチェーン攻撃は頻度と巧妙性を増しています。オープンソースパッケージは多くのプロジェクトで基盤的に利用されており,単一の改ざんが間接的に多数のシステムへ波及するリスクを常に伴います。特に JavaScript/npm エコシステムでは依存関係の深さと枝分かれが大きく,一つの小さなユーティリティが数千の最終アプリケーションに取り込まれることが珍しくありません。結果として,攻撃者は影響範囲を指数的に拡大できる利点を得ます。

npm は公開・配布のプロセスを自動化するためにトークンや CI ワークフローに依存していますが,これらは適切に管理されないと大きな攻撃面となります。長期有効の publish トークン,権限が過大な CI ランナー,組織共有の認証情報は侵害時に「自動で書き換える」「自動で公開する」といった自己伝播的な悪用を可能にします。加えて,postinstall 等の実行時フックはビルドや開発環境で任意コードを実行するため,ここに悪意あるコードが紛れ込むと検出が遅れやすい設計上の脆弱性があります。

運用面でも課題があります。開発者は多数の依存を素早く取り込みたいため,package-lock による固定や署名付き配布を怠りがちです。企業では利便性のためにトークンを共有したり,CI 用イメージやランナーを長期間使い回したりする運用が残存します。これらの実務的な慣行は,攻撃者にとって短時間で大規模な被害を生む温床となります。

過去のサプライチェーン攻撃の教訓から,検出と封じ込めには「開発環境・CI・レジストリ」の三点同時対応が必要であることが分かっています。Shai-Hulud のように自己伝播性を持つ攻撃は,これら三領域のいずれか一つでも緩みがあると急速に広がります。したがって,本件は単なるパッケージ単位の問題ではなく,組織の開発・配布プロセス全体を見直す契機として位置づけるべき事象です。

攻撃の技術的特徴

初期侵入

攻撃者は npm の publish トークンや GitHub の Personal Access Token(PAT)などの認証情報を取得して改ざんに利用しました。トークン取得経路としてはフィッシングや公開設定ミス、漏洩した CI 設定などが想定されます。これらのトークンはパッケージ公開権限を直接与えるため,侵害されると改ざんが短時間で実行され得ます。

改ざん手法

改ざん版には postinstall フックやバンドル化された実行スクリプト(例:bundle.js)が組み込まれます。npm install 時に自動実行されるため,開発者や CI が気づきにくく,ビルド段階でコードが動作する設計上の盲点を突きます。

情報収集と流出

実行スクリプトはローカル環境(環境変数、.npmrc 等)とクラウド環境(IMDS 等のメタデータエンドポイント)を探索して認証情報を収集します。収集したデータは攻撃者管理下の GitHub リポジトリやハードコードされた webhook にコミット/POST される仕組みが確認されています。

自己伝播(ワーム化)

感染した環境に残る有効トークンを悪用し,攻撃者は他パッケージを自動で改ざん・公開します。依存関係を介して連鎖的に拡散する点が本件の特徴です。短命で終わらない仕組みになっているため封じ込めが難しくなります。

持続化と権限操作

攻撃スクリプトは GitHub Actions ワークフローを追加したり,リポジトリを private→public に変更するなどして持続化と露出拡大を図ります。これにより単発検出後も再侵害や情報漏えいが継続するリスクが残ります。

検出困難性と難読化

実行コードはバンドル・難読化され,ファイル名やワークフロー名を変えることで痕跡を隠します。postinstall の存在自体が通常の開発フローの一部であるため,単純な目視だけでは発見されにくい設計です。

想定される影響と懸念

1. 認証情報・機密情報の流出と二次被害

改ざんされたパッケージの postinstall や実行スクリプトが開発端末・CI・クラウドのメタデータからトークンやキーを収集し外部に送信します。流出した認証情報は即時に不正利用され、以下の二次被害を引き起こす可能性があります。

  • リポジトリの不正操作(コミット、ワークフロー変更、公開設定切替)によるさらなる改ざん。
  • クラウド資源の不正利用(インスタンス起動、ストレージ操作、データベースアクセス)。
  • サードパーティサービスの乗っ取り(npm、CIサービス、サードパーティAPI)。

2. 依存関係を介した連鎖的な感染拡大

npm の依存グラフは深く広いため、ワーム的に拡散すると多数のプロジェクトに連鎖的影響が及びます。特に共有ライブラリやユーティリティが汚染されると、最終的な配布物や商用サービスにもマルウェアが混入するリスクが高まります。結果として被害の「範囲」と「追跡可能性」が急速に拡大し、封じ込めコストが指数的に増加します。

3. ビルド・デプロイチェーンの汚染と運用停止リスク

CI/CD パイプラインやビルドアーティファクトにマルウェアが混入すると、デプロイ先環境まで影響が及びます。企業は安全確認のためにビルド/デプロイを一時停止せざるを得なくなり、サービス停止やリリース遅延、ビジネス機会の損失につながります。

4. 検出困難性と長期的残存リスク

postinstall 実行や難読化されたスクリプトは発見が遅れやすく、感染が既に広がった後で検出されるケースが多くなります。さらに、改ざんコードが複数ファイルやワークフローに分散して保存されると、完全除去が難しく「再発」や「潜伏」が残るリスクがあります。

5. 信頼性・ブランド・法務的影響

顧客やパートナーに供給するソフトウェアにマルウェアが混入した場合、信頼失墜や契約違反、損害賠償請求につながる可能性があります。規制業界(金融・医療など)では報告義務や罰則が発生する場合があり、法務・コンプライアンス対応の負荷が増します。

6. インシデント対応コストと人的負荷

影響範囲の特定、シークレットのローテーション、CI の再構築、監査ログ解析、顧客対応など、対応工数とコストは大きくなります。特に短時間で多数のチーム・プロジェクトにまたがる場合、人的リソースの逼迫と対応優先順位の決定が課題となります。

7. 長期的なサプライチェーン健全性の劣化

繰り返しの改ざん事件は OSS 利用に対する過度な懸念を生み、外部ライブラリの採用抑制や自家製化(in-house)への回帰を促す可能性があります。これにより開発効率が低下しエコシステム全体の健全性に悪影響が及ぶ恐れがあります。

8. 観測・検出のギャップによる見落とし

短時間に大量の npm publish やワークフロー変更が行われた場合でも、既存の監視ルールでは閾値を超えるまで気付かない運用が珍しくありません。ログ保持期間やログの粒度が不十分だと、フォレンジック調査の精度が低下します。

マルウェアのチェック方法


セキュリティ専門企業のAikido Securityから対策パッケージが提供されています。

特徴

  • npmやyarnなどのパッケージマネージャのコマンドをラップし、パッケージインストール前にマルウェアチェックを実施します。
  • チェックはAikido Intelというオープンソースの脅威インテリジェンスに照らし合わせて検証します。
  • デフォルトではマルウェアが検出されるとインストールをブロックしてコマンドを終了します。これはユーザーに許可を求めるモードにも設定変更可能です。
  • 対応シェルは、Bash、Zsh、Fish、PowerShell、PowerShell Core
  • Node.js 18以上に対応してます。

といった特徴を持っています。

使い方

npmコマンドを使ってAikido Security Chainパッケージをインストールします。

$ npm install -g @aikidosec/safe-chain

added 110 packages in 6s

29 packages are looking for funding
  run `npm fund` for details

次に以下のコマンドを実行してシェル統合を設定します。

$ safe-chain setup
Setting up shell aliases. This will wrap safe-chain around npm, npx, and yarn commands.

Detected 3 supported shell(s): Zsh, Bash, Fish.
- Zsh: Setup successful
- Bash: Setup successful
- Fish: Setup successful

Please restart your terminal to apply the changes.

使用できるようにするにはターミナルを再起動してください。exec $SHELL -lでも動作しました。

インストールができたかどうかは以下のコマンドで確認します。インストールしようとしているパッケージはマルウェアとしてフラグされている無害なパッケージでシェル統合が成功しコマンドが正常にラップされている場合はブロックが成功します。

$ npm install safe-chain-test
✖ Malicious changes detected:
 - safe-chain-test@0.0.1-security

Exiting without installing malicious packages.

成功すればマルウェアのチェックが有効になっています。このチェックはパッケージのインストール時に行われるため、すでにプロジェクトがある場合は、一旦node_modulesを削除してからnpm installしてください。

$ rm -rf node_modules
$ npm install
✔ No malicious packages detected.
npm warn deprecated source-map@0.8.0-beta.0: The work that was done in this beta branch won't be included in future versions

added 312 packages, and audited 313 packages in 2s

73 packages are looking for funding
  run `npm fund` for details

1 low severity vulnerability

To address all issues, run:
  npm audit fix

Run `npm audit` for details.

これは私が開発中のライブラリで試した結果です。基本的に外部ライブラリに依存していないので、マルウェアは検出されませんでした。

一部開発用パッケージやMCP関連パッケージも標的になっていたので、グローバルインストールされているパッケージについても確認してください。グローバルパッケージの場合は対象パッケージを再度インストールすることでチェックができます。

アンインストール

アンインストールする場合は、

safe-chain teardown

でエイリアスを除去し、

npm uninstall -g @aikidosec/safe-chain

でパッケージをアンイストールし、ターミナルを再起動してください。

CI/CDへの組み込み方法

CI/CDへの組み込み方法についてもガイドされています。

マルウェアを検知するためにディスクをスキャンするため、多くのパッケージに依存している場合はCIにかかる時間の増大やコスト増大を招く場合があります。影響を考慮して導入の可否を判断してください。

GitHub Actionsでの組み込み方法について見ていきます。

私が実際に使っている.github/workflows/ci.yamlは以下のようになっています。

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
      - uses: actions/checkout@v4

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"

      - run: npm install -g @aikidosec/safe-chain
 
      - run: npm install
      - run: npm run lint
      - run: npm run build --if-present
      - run: npm test

npm installを行う前にパッケージをインストールします。

      - run: npm install -g @aikidosec/safe-chain

      - run: npm install

次にnpm installのコマンドをaikido-npmに差し替えます。

      - run: aikido-npm install

これらの修正を行なった.github/workflows/ci.yamlは以下のようになります。

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
      - uses: actions/checkout@v4

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"

      - run: npm install -g @aikidosec/safe-chain

      - run: aikido-npm install
      - run: npm run lint
      - run: npm run build --if-present
      - run: npm test

以下はGitHub Actionsの実行結果の抜粋です。マルウェアのチェックが成功していることが確認できます。

Run aikido-npm install
Scanning 312 package(s)...
No malicious packages detected.
npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: '@isaacs/balanced-match@4.0.1',
npm warn EBADENGINE   required: { node: '20 || >=22' },
npm warn EBADENGINE   current: { node: 'v18.20.8', npm: '10.8.2' }
npm warn EBADENGINE }

CI/CDへの組み込みも比較的簡単に実施可能です。

まとめ

今回の Shai-Hulud 攻撃は、npm エコシステムにおけるサプライチェーンの脆弱性を突いた、これまでにない規模と性質を持つ事例でした。単なるパッケージ改ざんにとどまらず、インストール時に自動実行されるスクリプトを利用して認証情報を盗み取り、その情報を活用して別のパッケージを改ざんするという「自己伝播」の性質を持つ点が特に深刻です。これにより、短期間で数百件規模のパッケージが感染する事態となり、ソフトウェアサプライチェーン全体の信頼性に大きな影響を与えました。

本記事では、攻撃の仕組みと影響だけでなく、実際に開発者や企業が取るべき対応についても整理しました。具体的には、感染パッケージの特定と除去、シークレットの全面ローテーション、CI/CD 環境のクリーン再構築、リポジトリやログの監査といった即時対応が必須です。さらに、長期的には権限の最小化や ephemeral runner の利用、SBOM の生成とソフトウェアコンポーネント解析、そして Aikido Safe Chain のようなマルウェア検証ツールの活用など、セキュリティを日常の開発プロセスに組み込む工夫が欠かせません。

特に、CI/CD への統合は鍵となります。開発者が手動で確認するだけでは限界があるため、依存関係の取得やビルドのたびに自動でパッケージを検証し、IOC や脅威インテリジェンスに基づいてブロックする仕組みを導入することで、攻撃の拡大を未然に防げます。OSS に依存する開発体制を維持する以上、こうした仕組みは「特別な対策」ではなく「標準的な衛生管理」として定着させる必要があります。

Shai-Hulud は終息したインシデントではなく、今後の攻撃者の戦術を示す前兆と捉えるべきです。攻撃はますます自動化・巧妙化し、検出をすり抜けて広範囲に広がることが想定されます。したがって、本件を単なる一過性の脅威と見るのではなく、ソフトウェアサプライチェーン防御の基盤整備を加速させるきっかけとすることが重要です。OSS エコシステムと開発者コミュニティの健全性を守るためには、開発者一人ひとりがセキュリティ意識を高め、組織全体として持続的な監視と改善の仕組みを整備していくことが求められます。

参考文献

OAuthトークン窃取によるサプライチェーン攻撃 ― Drift統合経由で複数企業に影響

2025年8月、Salesloft社が提供するチャットプラットフォーム「Drift」を経由した大規模なサプライチェーン攻撃が発覚しました。攻撃者は、Driftと外部サービス(Salesforceなど)を統合する際に利用されていたOAuthトークンを窃取し、複数の大企業のシステムへ不正アクセスを行いました。影響はCloudflareやZscalerといった世界的な企業にまで及び、サポートケースや顧客関連データが流出した可能性が指摘されています。

今回の攻撃の重要な点は、標的が「AIチャットボット」そのものではなく、サプライチェーンを構成する外部サービス統合の脆弱性だったことです。OAuthトークンはサービス間認証の基盤として広く利用されていますが、一度流出すれば本人になりすまして無制限にアクセスできる強力な「鍵」として機能します。そのため、管理の不備や第三者への委託によって安全性が損なわれると、そこを突破口にして被害が一気に広がるリスクを孕んでいます。

この事件は「サプライチェーン攻撃」と呼ばれますが、実態としてはDriftという外部ベンダーを通じて複数企業が侵害された事例です。つまり、1社のセキュリティ不備が取引先全体に波及する構造的なリスクが浮き彫りになったといえます。

本記事では、事件の概要と技術的なポイントを整理し、OAuthトークンのセキュリティに関して押さえるべき基本的な対策について解説します。AIという観点ではなく、「認証情報の管理不備がサプライチェーン全体のリスクになる」という本質的な問題に焦点を当てます。

攻撃の概要

今回確認された攻撃は、Salesloft社のチャットプラットフォーム「Drift」と外部サービス(特にSalesforce)との統合部分を起点としています。Driftは、顧客とのチャット内容やリード情報をSalesforceなどのCRMに自動反映させる機能を持っており、その際にOAuthトークンを用いて認証・認可を行います。

攻撃者は、このDriftが保持していたOAuthアクセストークンを窃取することに成功しました。流出経路の詳細は公表されていませんが、考えられるシナリオとしては以下が指摘されています。

  • Drift内部のシステムやログからトークンが平文で漏洩した可能性
  • トークンの保護・ライフサイクル管理に不備があり、有効期限が長すぎた可能性
  • APIアクセス制御や監視の欠如により、不審な利用が長期間検知されなかった可能性

攻撃期間は2025年8月12日から17日にかけてで、短期間で集中的に行われたとされています。攻撃者は窃取したトークンを使い、Salesforceに正規の認証済みユーザーとしてアクセスし、サポートケース情報や営業関連データなどを参照・抽出したと見られています。

被害は単一の企業にとどまりませんでした。Driftは多数の顧客企業で利用されているため、結果的にCloudflare、Zscaler、Palo Alto Networksといった大手を含む700以上の組織が影響を受けたと報告されています。特にCloudflareは公式ブログで、自社のサポートケース情報が一部閲覧された可能性を認め、即座に対応措置を取ったことを公表しました。

この事件の特徴は、攻撃者がDrift自体を最終標的にしたわけではなく、Driftを踏み台として顧客企業のシステムに侵入した点にあります。つまり、直接攻撃が困難な大企業を狙うのではなく、その周辺のサプライチェーン(サービス提供企業)の弱点を突くことで一気に広範な影響を与える典型的な攻撃パターンです。

技術的なポイント

1. OAuthトークンの仕組みとリスク

OAuth 2.0は、サービス間で安全に認証・認可を行うために広く使われているプロトコルです。ユーザーのパスワードを直接渡す代わりに、アクセストークンという「代理の鍵」を発行し、これを利用してAPIにアクセスします。

しかし、この仕組みには大きな前提があります。「トークンが絶対に漏れない」ということです。アクセストークンは発行後、失効するまで本人になりすまして利用可能であり、流出すれば攻撃者にとって非常に強力な侵入手段となります。

特に、トークンの有効期限が長すぎる場合や、リフレッシュトークンが安全に管理されていない場合、被害はさらに深刻になります

2. 外部サービス統合とサプライチェーンの弱点

今回の事件は、Driftのような外部サービスが保持していたOAuthトークンが突破口となりました。

  • Driftはチャット内容やリード情報をSalesforceに送信するため、Salesforce APIにアクセスする権限を持つトークンを管理していました。
  • つまり、利用企業は自社のSalesforceを守っていても、外部サービス側のセキュリティが甘ければ意味がないという状況が生じてしまいます。
  • このように、自社の境界を超えた場所にある認証情報が侵害されることで被害が波及する点が、サプライチェーン攻撃の典型的な脆弱性です。

3. トークン管理における具体的な問題点

今回のケースで想定される問題は次の通りです。

  • 有効期限が長すぎるトークン:窃取後も長期間利用可能であれば、検知までに甚大な被害が広がる。
  • スコープが広すぎるトークン:不要な権限を持っていれば、侵入後に参照・変更できる範囲が拡大する。
  • 保存方法の不備:ログや設定ファイルに平文で残っていた場合、内部からの流出や外部侵入時に容易に盗まれる。
  • 監視不足:不審なアクセスパターン(例:異常な時間帯や海外からのAPIアクセス)が検知されず、侵入が長期化する。

4. 攻撃の構造的な特徴

攻撃者はDriftのサービス自体を破壊したり改ざんしたりしたわけではありません。代わりに、Driftが持っていたOAuthトークンを利用し、あたかも正規のユーザーやアプリケーションであるかのように外部サービス(Salesforceなど)に侵入しました。

これにより、外部からの攻撃としては目立ちにくく、通常のログイン試行や不正アクセスの兆候を出さずにシステム内部に入り込めたのです。

このような「正規の認証情報を盗んで使う」攻撃は、パスワードやAPIキーの流出と同様に検知が難しいことが特徴です。

5. 今回の事例が示す本質

  • OAuthは利便性の高い認証・認可の仕組みだが、トークン管理の安全性が保証されなければ逆に最大の弱点になる
  • 外部サービスと統合すること自体が「自社の防御範囲外にトークンを置く」ことを意味し、サプライチェーン全体を通じたセキュリティリスク管理が不可欠
  • この構造的な問題は、Driftに限らず多くのSaaSサービス連携に当てはまる。

セキュリティ上の教訓と対策

今回のインシデントは、OAuthトークンの管理不備がどのようにサプライチェーン全体のリスクに直結するかを示しました。重要なのは「トークンを提供する側(外部サービスベンダー)」と「トークンを受領する側(利用企業)」の双方で対策を講じることです。どちらか片方が堅牢でも、もう一方が弱ければ全体として防御は成立しません。

1. OAuthトークンを提供する側(外部サービスベンダー)

外部サービスは、多数の顧客のシステムにアクセスするためのトークンを保持する立場にあり、ここが破られると一気に被害が連鎖するリスクを抱えています。今回のDriftのように「一社の不備が多数の企業へ波及」する構造的な弱点があるため、ベンダー側には特に強固な管理が求められます。

教訓と対策

  • 短寿命トークンの発行と更新
    • 長期間有効なアクセストークンを発行せず、数分〜数時間で期限切れとなる短命トークンを基本とする。
    • 自動更新の仕組みを導入し、顧客側は透過的に新しいトークンを利用できるようにする。
  • スコープの最小化と分離
    • 「読み取り専用」「書き込み限定」など、用途ごとにスコープを細かく分ける。
    • 顧客ごとに独立したトークンを発行し、1つが流出しても他社には波及しない設計にする。
  • 安全な保管と鍵管理
    • トークンを平文でログや設定に残さない。
    • HSM(Hardware Security Module)やSecrets Managerを用い、復号は安全領域でのみ可能にする。
  • 異常利用の監視と自動失効
    • 不自然なアクセスパターン(短時間で大量アクセス、国外からの利用など)を監視。
    • 検知した場合は自動的にトークンを失効し、顧客に即通知する仕組みを標準化する。
  • 透明性の確保
    • インシデントが発生した場合、影響範囲と対応策を迅速かつ正確に公表する。
    • 顧客に「どのトークンが影響を受けたか」「どのデータにアクセスされた可能性があるか」を開示できるログを保持しておく。

2. OAuthトークンを受領する側(顧客企業)

顧客企業は外部サービスとの統合によって利便性を得る一方、自社の認証情報を第三者に預けることになります。この時点で「自社のセキュリティ境界が広がる」ため、依存リスクを踏まえた設計・運用が不可欠です。

教訓と対策

  • 外部サービスのセキュリティ評価
    • ベンダー選定時に、OAuthトークンの取り扱い方針、暗号化方法、監査体制を確認する。
    • SOC 2やISO 27001などの認証取得状況を参考にする。
  • スコープと権限の制御
    • 不要に広いスコープのトークンを許可しない。
    • 「参照だけで十分な統合」であれば書き込み権限を付与しない。
  • 利用環境の制限
    • トークンの利用元を特定のネットワークやIPに限定する。
    • 自社内のアクセス制御(ゼロトラストモデル)と組み合わせ、外部からの不審アクセスを防ぐ。
  • 監視とアラート
    • 外部サービス経由で行われたAPIアクセスを可視化し、不審な挙動があれば即時検知できる仕組みを持つ。
    • Salesforceなど側でも「どのアプリケーションからアクセスが来ているか」を監査する。
  • 侵害前提のリスクマネジメント
    • トークンが漏洩する可能性をゼロにできない前提で設計する。
    • 被害が起きても影響範囲を限定できるように、重要データと外部サービスとの接続を分離する。
    • 定期的にトークンを再発行・棚卸しし、不要な連携は削除する。

まとめ

OAuthトークンはサービス統合の利便性を支える一方で、流出すれば強力な攻撃手段となります。今回の事件は「提供する側」と「受領する側」の双方で適切な管理を怠れば、サプライチェーンを通じて被害が拡大することを示しました。

  • 提供側には「短寿命化・スコープ最小化・強固な保管・監視・透明性」が求められ、
  • 受領側には「ベンダー評価・権限制御・利用制限・監視・リスクマネジメント」が不可欠です。

つまり、セキュリティは一方的な責任ではなく、提供者と利用者の協働によって初めて成り立つという点が最大の教訓といえます。

まとめ

今回の事件は、OAuthトークンという技術要素がいかに便利であると同時に、大きなリスクを抱えているかを改めて示しました。OAuthはWebサービスやSaaSの統合を容易にし、ユーザー体験を向上させる強力な仕組みです。しかし、その利便性の裏には「一度発行されたトークンが漏洩すれば、正規のユーザーになりすまして広範なアクセスを許してしまう」という構造的な脆弱性があります。

今回の侵害は、AIチャットボット自体が攻撃対象だったわけではなく、外部統合に利用されるOAuthトークンが突破口になったという事実に注目すべきです。つまり、個別のサービスだけを堅牢に守っても、サプライチェーンの一部に弱点があれば全体が危険にさらされるという現実を突きつけています。これはSolarWinds事件や他の大規模サプライチェーン攻撃とも共通する教訓です。

では、我々はどう対応すべきか。答えは「完璧な防御」を追い求めるのではなく、多層的に防御を重ね、攻撃の成功確率を下げ、万一突破されても被害を最小化することにあります。提供する側(サービスベンダー)は短寿命トークンや権限スコープの制御、安全な保管と監視を徹底し、受領する側(顧客企業)はベンダー評価や利用制御、リスク前提の運用を組み込む必要があります。

サプライチェーンを通じた攻撃は今後も増えると予想されます。外部サービスとの統合は避けられない以上、「どのように信頼を設計するか」が問われています。OAuthトークン管理のあり方は、その最前線にある課題の一つです。本件を一過性の事故として片付けるのではなく、セキュリティを提供者と利用者の協働によって成り立たせる仕組みを築くきっかけにすべきでしょう。

参考文献

モバイルバージョンを終了