Codex・Claude Code時代の新リスク

AIが勝手にnpm installするなら、通信まで見ないと守れない

npmパッケージ codexui-android に、OpenAI Codexの認証トークンを盗むコードが含まれていたことが報告された。

一見すると、これはよくあるnpmサプライチェーン攻撃に見える。だが今回の本質は、単に「悪意あるパッケージがあった」ことではない。

問題は、AI coding、つまりAIエージェントを使った開発の時代には、依存関係の追加や実行が人間の目を通らずに進んでしまうことだ。

攻撃者は、開発者本人を直接だます必要がなくなりつつある。AIに「便利そう」と判断されるパッケージを用意すればよい。

今回実際に確認されたのは、同じ作者のAndroidアプリが起動時に pnpm add codexui-android@latest を実行し、汚染版を取り込んでいたことだ。これは、CodexやClaude CodeのようなAIエージェントが自律的に依存関係を追加していく時代に、そのまま拡大しうる問題でもある。

GitHubを見ても見つからない

codexui-android は、単なるtyposquatではなかった。OpenAI Codex向けのリモートUIとして実際に動くツールで、GitHubリポジトリも存在していた。

しかし問題は、GitHubのソースコードではなく、npmに公開されたビルド成果物の側にあった。Aikidoによれば、npm公開版にはGitHubには存在しないコードが含まれており、起動時にCodexの認証ファイルを読み取り、外部サーバーへ送信していた。

つまり、ソースコードをSASTで監査しても見つからない。

SASTはリポジトリを見る。しかし攻撃者が悪意コードをnpm公開版だけに入れれば、GitHub上のソース監査では検出できない。

SCAも万能ではない

SCAは依存関係を見て、既知の脆弱性や悪意あるパッケージを検出する。

しかし今回のように、@latest で最新版を動的に取得する場合、検出データベースに載る前の汚染版を引いてしまう可能性がある。Aikidoの記事によれば、Androidアプリは起動時に pnpm add codexui-android@latest を実行していた。バージョン固定がないため、その時点でnpmに公開されている最新版を無条件に取り込んでしまう。

汚染版が公開され、検出されるまでの時間差。ここが攻撃者にとっての窓になる。

CIを通る前に盗まれる

さらに厄介なのは、発火タイミングだ。

今回のコードは、通常のアプリ処理に入る前、モジュールのロード時点で実行される構造だった。認証ファイルを読み取り、外部サーバーへPOSTする。ユーザー操作を待たない。

CI/CDは基本的にリポジトリを見る。しかし攻撃は、開発者マシン、アプリ内の実行環境、AIエージェントの実行環境で起きる。

つまり、CIが見ている場所と、攻撃が起きる場所が違う。

本丸は、人間のレビューゲートが消えること

従来なら、新しいパッケージを追加するとき、人間が一度は判断していた。

• このライブラリを入れてよいか
• メンテナは信用できるか
• ダウンロード数はあるか
• 怪しいpostinstallはないか

しかしAI codingでは、この判断が曖昧になる。

Claude CodeやCodexが、必要なパッケージを探し、インストールし、環境を整える。便利な一方で、開発者は「実際にnpmから何が入ったか」までは見ていないことが多い。

AIが賢くなるほど、人間が見ていない場所でモノが動く。そこに攻撃者が入り込む。

だから通信まで見ないと守れない

これからは、SAST・SCA・CI/CDだけでは足りない。

もちろん従来のスキャンは必要だ。しかしAIが勝手に依存関係を追加し、実行環境でコードを動かすなら、防御もそこまで広げる必要がある。

必要なのは大きく3つだ。

1つ目は、install-timeのゲート。 npm install や pnpm add の瞬間に、新規公開版や怪しいパッケージを止める。特に @latest を無条件に信用しない。

2つ目は、runtime / egressの検知。 実行されてしまった場合でも、未知の外部送信を捕まえる。今回でいえば、認証ファイルを読み取り、外部サーバーへPOSTする通信だ。AIが勝手にインストールし、勝手に実行するなら、勝手に外へ送信する可能性もある。だから通信を見ていないと守れない。

3つ目は、identityの封じ込め。 トークンは盗まれる前提で、影響範囲を小さくする。AIエージェントの実行環境をサンドボックス化し、開発者の auth.json やクラウド認証情報に直接触れさせない。トークンは短命化し、権限は最小化する。

あなたは大丈夫か

今回の件で確認すべきことは具体的だ。

• ~/.codex/auth.json または $CODEX_HOME/auth.json が存在するか
• sentry.anyclaw.store への通信履歴がないか
• codexui-android を導入していないか
• 同じ作者のAndroidアプリをインストールしていないか

導入していた場合は、パッケージを削除するだけでは不十分だ。Codex/OpenAIのトークン再発行まで行う必要がある。

盗まれた認証情報は、こちらが気づくまで静かに使われ続ける可能性がある。

まとめ

AI codingの時代には、攻撃面が変わる。

これまでは、コード、依存関係、CI/CDを中心に見ていれば、かなりの範囲を守れた。しかしCodexやClaude CodeのようなAIエージェントが、依存関係の追加、インストール、実行まで進めるようになると、それだけでは足りない。

防御は、CIの中だけで完結しない。install時、runtime、そして外部通信まで見る必要がある。

AIが勝手に入れるなら、勝手に送信するところまで見ないと守れない。

AIが勝手にコードを書く時代には、AIが勝手に入れたものを実行前に止める仕組みと、実行されてしまった場合に外への通信を検知する仕組みの両方がいる。Aikido Safe Chainのようなinstall-timeの隔離、Endpoint ProtectionやZenのような実行環境・通信の監視は、まさにこの新しいAppSecの領域に対応するための防御だ。