npmサプライチェーン攻撃でOpenAI Codex認証トークンが盗まれる
サプライチェーンリスクは従来、SolarWindsやXZ Utilsに代表されるような、コンパイル済み製品に脆弱性を持ち込むソフトウェア依存関係に焦点が当てられてきました。しかしCodexトークン窃取は異なるモデルです。この侵害されたパッケージは、開発者のコードに脆弱性を持ち込むのではなく、開発作業中に開発者の環境から認証情報を抜き取ります。
攻撃のライフサイクルは予測可能なパターンに従います。まず、機能するパッケージが公開され、通常のチャネルを通じてダウンロード数を伸ばします。パッケージはメンテナンスされ、更新され、正当性を示すコミット履歴が積み上がります。ある時点で認証情報収集コードが追加されますが、パッケージ自体は正常に動作するため、開発者は細かくチェックしません。情報の持ち出しは、検知されるまで数週間から数か月間、静かに続きます。
Codex事例における偽装の巧妙さは示唆に富みます。盗まれた認証情報は、Sentryエラー報告連携を装ったサーバーエンドポイントに送信されました。Sentryは開発者ツールからのテレメトリを日常的に受信するサービスであり、未知のドメインへの外部接続を検知するネットワーク監視でも、Sentryに見える通信は警告されません。攻撃者は、外部へのデータ持ち出しを検知する最も一般的な仕組みを予測し、それを回避しました。
ソフトウェアベンダーのセキュリティ体制を評価するベンダーリスク管理プログラムは、ベンダーが利用するパッケージエコシステムも評価範囲に含める必要があります。npmパッケージは調達プロセスを伴わないベンダー関係です。
5つの重要なポイント
1. 機能するnpmパッケージがCodex OAuthトークンを1か月間、静かに窃取
「codexui-android」（週あたり約29,000ダウンロード）は、ローカルストレージからOpenAI Codex認証トークンを収集し、完全なOAuth認証情報バンドルをSentryエンドポイントを装った攻撃者管理サーバーへ送信していました。同じ情報持ち出しロジックは、合計60,000回以上ダウンロードされた2つのAndroidアプリにも見られました。パッケージは表向きの機能を果たしつつ、裏で認証情報収集が行われていたため、開発者は異常に気付く手がかりがありません。サプライチェーンの事前公開スキャンでは、このパターンは検出できません。
2. リフレッシュトークンは失効しない—この窃取が特にしつこい理由
盗まれた~/.codex/auth.jsonファイルには、アクセストークンだけでなくリフレッシュトークンも含まれていました。攻撃者がリフレッシュトークンを保持していれば、再認証を要求されることなく、必要に応じて新しいアクセストークンを生成し続け、被害者になりすまし続けることができます。多くの認証情報窃取被害者は、侵害に気付かず、何も失効しないため、継続的なコンテキスト認証がトークン有効期限よりも有効なコントロールとなります。
3. 平文での認証情報保存は、開発者ツールチェーン全体に共通するシステミックリスク
開発者がインストールするどのパッケージも、ホームディレクトリに保存されたすべての認証情報へアクセスできる可能性があります。このパターンは、クラウドプロバイダーCLI、バージョン管理システム、コンテナレジストリ、AIサービスプロバイダーなど、さまざまなツールで見られ、いずれも認証情報を平文のローカルファイルに保存しています。SaaSベンダー向けに構築されたベンダーリスク管理フレームワークには、オープンソースパッケージ依存関係向けの同等の仕組みが必要です。
4. 盗まれたAI開発者認証情報は、ワークステーションを超えてエンタープライズデータシステムに到達
Codexトークンは、開発者が接続しているエンタープライズシステム—ファイル共有環境、MFTパイプライン、コンテンツリポジトリ、社内API—へのアクセス権を持ちます。攻撃者が有効な開発者認証情報を使えば、AIを介したワークフローを通じて、監査ログシステムが異常な人間の行動を監視していても、まったく通常の操作としてシステムとやり取りできます。
5. ゼロトラストアクセス制御は、認証情報が盗まれても被害を限定
機密データに付与されたポリシー条件—単なる認証情報の正当性だけでなく—がアクセス可否を決定します。ゼロトラストデータ保護では、予期しない場所や異常な時間、通常とは異なる範囲のデータ要求など、想定外の状況で提示された盗難トークンは、トークン自体が技術的に有効でもポリシー評価で拒否されます。Kiteworks Secure MCP Serverは、攻撃者が管理するトークンでも突破できないボトルネックを作ります。
自社のセキュリティ、信じていませんか？その確証、本当にありますか？
Read Now
なぜ平文での認証情報保存がシステミックリスクなのか
~/.codex/auth.jsonファイルがOAuth認証情報を平文で保存しているのは、開発者ツールの導入障壁を下げるためです。開発者はツールがスムーズに認証できることを求めます。ローカルファイルシステム上の認証情報ファイルは、開発者が実行するどのプロセスからも読み取れるため、この要件を効率的に満たしますが、同時に単一障害点も生み出します。ファイルシステムの読み取り権限を持つプロセスなら、アカウントなりすましに必要なすべてを収集できてしまいます。
これはCodex固有の問題ではありません。同じパターンは開発者ツールチェーン全体—クラウドプロバイダーCLI、バージョン管理システム、コンテナレジストリ、AIサービスプロバイダー—で広く見られ、いずれも認証情報を平文のローカルファイルに保存しています。ネットワークレベルのアクセス制御や境界防御に注力するセキュリティチームは、このローカル認証情報の脆弱性を見落としがちです。
開発者がインストールするどのパッケージも、ホームディレクトリに保存されたすべての認証情報へアクセスできる可能性があります。SaaSベンダーやクラウドプロバイダー向けに設計されたサードパーティリスク管理フレームワークには、オープンソースパッケージ依存関係向けの同等の仕組みが必要です。保存中の認証情報も、保存中の機密データと同様に扱うべきです。つまり、暗号化し、鍵は暗号化データとは別に保管する必要があります。
盗まれたAI認証情報がエンタープライズデータ侵害に発展する仕組み
Codexトークン窃取は単なるアカウント侵害ではなく、最終的にエンタープライズデータの持ち出しにつながる一連の連鎖の第一歩です。開発者が悪意あるパッケージをインストールし、パッケージがCodex認証情報を収集、攻撃者がその認証情報で開発者アカウントがアクセスできるエンタープライズシステムに侵入、そして開発者の正規操作と見分けがつかないチャネルを通じて機密コンテンツを持ち出します。
特にリスクが高いのは、AIツールが接続する機会が増えているエンタープライズデータシステム—ドキュメントリポジトリ、セキュアなファイル共有プラットフォーム、仮想データルーム、マネージドファイル転送パイプライン—です。これらのシステムには契約書、財務データ、知的財産、規制対象の個人情報が保存されています。攻撃者が開発者のCodex認証情報を使えば、AIを介したワークフローで、監査ログシステムが異常な人間の行動を監視していても、通常の操作としてシステムとやり取りできます。
Kiteworksは、この連鎖をデータアクセス層で遮断します。Secure MCP Serverは、どのAIツールがエンタープライズデータとやり取りできるかを制御し、ツールのIDやポリシーコンテキストが許可セットに合致しなければ、どんな認証情報を提示してもデータに到達できません。ABAC制御はさらに進み、「誰が」だけでなく、リクエストやデータ、運用状況を記述する属性まで評価します。予期しない地理的ロケーションや異常な時間、通常の範囲外のデータ要求など、想定外の状況で提示された盗難トークンは、トークン自体が有効でもポリシー評価で拒否されます。
AIツールチェーンのサプライチェーン侵害への対応
この種の認証情報窃取が発生した場合、対応は「即時の被害封じ込め」と「再発防止策の構築」という2つの軸で進みます。即時対応としては、影響を受けたパッケージをインストールした開発者全員がauth.json認証情報を侵害されたものとして扱い、すべての該当トークンを失効させる必要があります。多くのOAuth実装ではトークン失効は手動で行う必要があり、どの開発者がどのサービスの認証情報を保有しているかのインベントリがない組織では、網羅的な対応が困難です。
AIツールチェーン侵害をカバーするインシデント対応計画には、未承認プロセスによる認証情報ファイルアクセスの自動検知、組織全体を対象としたトークン失効手順、開発者AIツール認証情報が到達可能なエンタープライズシステムの棚卸しが含まれるべきです。AIを介したデータアクセスを記録する監査ログは、攻撃者が被害期間中に実際に何にアクセスしたか—規制対象データが関与したかどうか—を判断するための証拠となります。
AIサプライチェーン攻撃から機密データを守る方法について詳しく知りたい方は、カスタムデモを今すぐご予約ください。
よくあるご質問
攻撃者は、盗んだ認証情報をSentryエラー報告連携を装ったエンドポイント経由で送信しており、ほとんどのネットワーク監視では検知されませんでした。パッケージ自体も正常に動作していたため、開発者に異常を示す兆候がありません。事前公開レジストリスキャンは既知の悪意あるシグネチャをチェックしますが、実行時の認証情報アクセスを明らかにするような挙動シミュレーションは行いません。サプライチェーンリスク管理では、インストール時のシグネチャチェックだけでなく、インストール済みパッケージの実行時挙動分析も必要です。
アクセストークンは数分から数時間で失効しますが、リフレッシュトークンは明示的に失効されるまで新しいアクセストークンを無期限に発行できます。多くの被害者は侵害に気付かず、リフレッシュトークンを失効しません。ゼロトラストの原則では、技術的に有効なトークンであっても異常なコンテキストで使用された場合にフラグを立てる「継続的なコンテキスト認証」で対処します。KiteworksのABAC制御は、トークンの有効性に関係なく、すべてのデータアクセスリクエストにこのコンテキスト評価を適用します。
はい。OAuth認証情報は、macOSのシステムキーチェーン、Windowsの資格情報マネージャー、エンタープライズ導入ならハードウェアセキュリティモジュールなど、プラットフォーム管理のキーストアに保存すべきです。ホームディレクトリの平文JSONファイルに保存してはいけません。プラットフォームキーストアは認証情報を取得する前に明示的なユーザー認証を要求するため、悪意あるパッケージによる静かなバックグラウンドアクセスを大幅に困難にします。また、組織はベンダーリスク管理プログラムの一環として、どの開発者ツールがエンタープライズシステムの認証情報にアクセスできるかを定期的に監査すべきです。
その認証情報がどのエンタープライズシステムにアクセスできるかによります。ドキュメントリポジトリ、セキュアなファイル共有プラットフォーム、MFTパイプラインなどにアクセス権があれば、攻撃者はAIを介したワークフローでそれらのシステムとやり取りできます。HIPAAで保護されるPHI、GDPR対象の個人データ、CMMCのCUIなど、規制対象データが直接危険にさらされます。AIツールの認証情報が侵害された場合は、特権ユーザー認証情報の侵害と同等の緊急性で対応してください。
Kiteworksは、認証だけでなくデータ層でアクセス制御を実施します。Secure MCP Serverは、どのAIツールがエンタープライズデータとやり取りできるかを制御し、認識されないツールIDは、どんな認証情報を提示しても保護されたコンテンツに到達できません。AI Data GatewayとABAC制御は、ID、ツール、データ分類、環境、行動パターンなどリクエスト全体のコンテキストを評価するため、失効前の盗難トークンでも異常な状況で使われればポリシー評価で拒否されます。すべてのやり取りは改ざん防止の監査証跡として記録されます。
追加リソース
- ブログ記事
AIプライバシー保護を実現するゼロトラスト戦略 - ブログ記事
77%の組織がAIデータセキュリティに失敗している理由 - eBook
AIガバナンスギャップ：91%の中小企業が2025年にデータセキュリティでロシアンルーレット状態に - ブログ記事
あなたのデータに「–dangerously-skip-permissions」は存在しない - ブログ記事
規制当局は「AIポリシーがあるか」ではなく「機能している証拠」を求めている