前文
先週の月曜日の夜、私は遅くまで仕事をしていたのですが、3日前に私が作成した監視ツールからSlackのアラートが届きました。世界で最も人気のあるnpmパッケージの一つであるAxiosが侵害された。
心臓が激しく鼓動し始めた。一秒たりとも無駄にせず、迅速に対応して被害を最小限に抑えることが重要だと分かっていた。でも正直、あまりにも異常だったので、偽陽性だと思ったんです。明らかに悪意のある行為だと思われたが、念のため何度も確認した。
偽陽性ではなかった。これはnpm史上最大規模のサプライチェーン侵害の一つであり、北朝鮮の国家主体による犯行と推定されている。金曜日の午後に私が急ごしらえで作った概念実証プログラムで、差分を読み取るAIを使ってそれを発見しました。このプログラムは私のノートパソコン上で動作しています。
私はその全てをお伝えしたい。私たちがどのようにしてここに至ったのか、私が何を構築したのか、そしてそれをオープンに共有することがなぜ皆の安全を少しでも高めると思うのか。
サプライチェーンについては以前から心配していました
最近のサプライチェーン関連のトラブルで、本当に夜も眠れないほど心配しています。サプライチェーンの妥協は難しい問題だ。Elasticには非常に多くの開発者がおり、セキュリティ関連のお客様は、私たちにセキュリティ保護を任せてくださっています。現状維持ではうまくいかないことは明らかであり、それを改善するための新たな技術や手順が必要だ。私は、アプリ制御の原則に基づきつつ、コストと摩擦を最小限に抑えた、より信頼性の高い、AIによる検証済みのエコシステムに関するいくつかのアイデアを持っていました。
しかし、私が本当に注目したのは、トリビーの妥協案だった。3月19日、TeamPCPと呼ばれるグループが、aquasecurity/trivy-action GitHub Action（人気のセキュリティスキャナーであるTrivyのアクション、そうです、セキュリティツールです）を侵害しました。彼らは、CI/CDパイプラインから機密情報を盗み出す認証情報窃盗マルウェアを注入した。大量の認証情報が盗まれた。
それはあっという間に連鎖的に広がった。3月24日、 LiteLLMが攻撃を受けた。TeamPCPは、不正に改変されたTrivyパイプラインを通じてLiteLLMのPyPI公開認証情報を盗み出し、それを利用して悪質な認証情報窃盗プログラムである悪意のあるバージョンを拡散させた。SSHキー、クラウド認証情報、APIキー、ウォレットデータ、すべて。
LiteLLMは私が実際に使用したことのあるパッケージです。だから、その時点では私は完全に「夜更かし」状態だったと言えるでしょう。
Trivyの情報漏洩で大量の認証情報が流出した以上、間違いなく他にも流出するだろうと分かっていた。私たちは、この事態に先手を打つために何か対策を講じる必要があった。お客様のため、そしてElasticを守るため。
金曜日、深夜便の後
私はサンフランシスコで開催されたRSAC 2026から帰ってきたばかりだった。木曜夜の深夜便。4日間の会議の後、夜行便に乗ったことがある人なら、私がどんな状態だったか分かるでしょう。しかし、私は新しいプロジェクトにいつものようにワクワクしていたので、腰を据えてv0.0.1を急いで作り上げた。
そのアイデアとは、パッケージリポジトリにプッシュされる変更を監視することである。変更点を確認するには、diffコマンドを実行してください。AI/LLMを使用して、変更が悪意のあるものかどうかを判断します。基本的には以上です。
パイプラインは次のようになります。
- PyPIの変更履歴APIとnpmのCouchDBフィード
_changesで新しいリリースをチェックします - ダウンロード数上位15,000件のパッケージのウォッチリストでフィルタリングします
- レジストリから旧バージョンと新バージョンを直接ダウンロードできます（pipインストール、npmインストール、コード実行は不要です）。
- それらをマークダウンレポートに差分表示します
- 差分をLLMに送信して、「これは悪意のあるものですか？」と尋ねてください。
- はいの場合、Slackに通知します
攻撃者が狙う可能性が最も高いのは上位パッケージであるため、私は主に上位パッケージに焦点を当てたいと考えました。そうすることで、トークンや計算リソースのコストを大幅に削減できるからです。私のノートパソコンでも全く問題なく動作しました。
カーソルを使う理由
エージェントハーネスは数多く出回っている。私はAIマルウェアのリバースエンジニアリングのようなプロジェクトのために、独自のコードを書いたことがあります。しかし、時間が非常に限られていたので、私の主要な開発ツールの1つであるCursorを活用することにしました。Agent CLI を使用すると、ワークスペース、指示、およびモデルを渡すことで、プログラムからエージェントを呼び出すことができます。私はそれをaskモード（読み取り専用）で実行しているので、差分を読み取るだけで、何も変更することはありません。解析ステップ全体は、単一のサブプロセス呼び出しで実行されます。
指示は単純だ。私は、何を探すべきか（難読化されたコード、base64、exec/eval、予期しないネットワーク呼び出し、ステガノグラフィー、永続化メカニズム、ライフサイクルスクリプトの悪用）を伝え、 Verdict: maliciousまたはVerdict: benignで応答するように要求します。判決を分析し、それに基づいて行動する。
モデル選択について
私は通常、ほとんどの用途でOpus 4.6またはGPT 5.4を使用します。Opusは特にサイバーセキュリティ関連のタスクに適しています。しかし、1時間に数十件のリリースを分析する必要があるものなので、コストを抑えたかったのです。
最近、Cursorチームから非常に優れたブログ記事がいくつか公開されています。1つはエージェントツール向けの高速正規表現検索に関するもので、もう1つは実際の運用推論トークンをトレーニング信号として使用し、約5時間ごとに改良されたチェックポイントをデプロイするリアルタイム強化学習アプローチに関するものです。本当に素晴らしい技術だ。
そこで、Composer 2 を試してみたくなった。高速モードを使用しましたが、本当に速かったです。リアルタイムでの使用に最適です。低コスト、迅速、そして効果的（私のテストでは）。
Telnyxでのテスト
実際に効果があるかどうかを知るには、これらのことをテストする必要がある。通常、それはプロンプトを何度も調整することを意味します。
タイミングが良かった（あるいは悪かった）。私がこれを開発していたまさにその金曜日に、 telnyxのPyPIパッケージがTeamPCPによって侵害されました。彼らは 74 行の悪意のあるコードを_client.pyに注入しました。WAVオーディオファイル内に隠されたペイロード（ステガノグラフィー）、base64難読化、 msbuild.exeとして偽装されたWindows永続化インプラント、ハードコードされたC2へのデータ流出です。
正規のパッケージとtelnyxパッケージの差分を使用して、最初のプロンプトを作成しました。このモデルは、このような悪意のある変更を特定するのに非常に優れていた。侵害が検出された際にすぐに知りたいと思ったので、Slackのアラート機能を追加しました。
月曜の夜
週末の間、そのまま稼働させておいた。次々とリリースが行われたが、どれも無害なものだった。
サイバーセキュリティの検出作業に携わったことがある人なら正直言って不思議に思うだろうが、誤検出は一度もなかった。私たちは通常、FP（ファーストポイント）に溺れています。私は意図的にLLMに対し、「高い確信度」のサプライチェーン上の問題のみを警告するように指示しました。というのも、LLMは初期設定のままでは一般的に警告を発しすぎる傾向があるからです。Telnyxのテストケースを引き続き検出していますが、偽陽性は発生していません。サンプルサイズが小さすぎるため、過学習を起こしている可能性もあるが、より堅牢なモデルを構築する時間はない。
そして月曜日の夜遅くまで仕事をしていると、Slackのアラートが届いた。
🚨 Supply Chain Alert: axios 0.30.4
Verdict: MALICIOUS
npm: https://www.npmjs.com/package/axios/v/0.30.4それは本当に、近年稀に見るほどの大規模なサプライチェーン上の問題点を発見したということなのか？
分析結果を確認しました。再確認しました。もう一度確認しました。攻撃者は、メンテナーのnpmアカウントを侵害し、メールアドレスを自分たちが管理するProtonMailアカウントに変更し、2つの悪意のあるバージョン（1.14.1と0.30.4）を公開した。彼らはAxiosに直接コードを挿入したわけではない。その代わりに、 plain-crypto-jsという架空の依存関係を追加し、インストール後のフックを実行してクロスプラットフォームのマルウェアをデプロイしました。それは明らかに悪意のある行為だった。
回答
私はすぐにElastic社の情報セキュリティチームと研究チームに連絡を取り、彼らを稼働させるよう依頼しました。一秒たりとも無駄にはできないと分かっていた。私が連絡を取った時点で、彼らは既に悪意のあるパッケージをインストールしたホストに関するElastic Defendのアラートを受信しており、積極的に対応していたことが判明した。しかし、その時点では誰も問題の深刻さを認識しておらず、機械がどのようにして感染したのかという根本原因を理解していなかった。監視ツールは、欠けていたコンテキストを提供してくれた。
security@npmjs宛にメールを送信してみましたが、エラーで返送されてきました。セキュリティポータルへの送信を試みましたが、エラーが発生しました。私は必死になって、誰かと連絡を取ろうとツイートした。私はすぐにaxiosのリポジトリ自体にセキュリティ上の問題を報告しました。
その後、この侵害を目撃した別の研究者のツイートを見て、自分がこれをサプライチェーンのインシデントというよりも、脆弱性として捉えていたことに気づきました。脆弱性を利用して、静かに連携を図る。現在、人々のコンピューターにマルウェアをインストールするような活発な侵害行為が行われている状況では、全面的に情報公開を行うのが正しい判断だ。そこで私は、自分がまとめたすべての詳細情報をすぐにXに共有しました。
テレメトリデータから、実際に影響を受けている組織を示すアラートも届き始めました。それは活発に動作していた。
幸いなことに、Axiosチームはすぐに対応し、該当のパッケージを迅速に削除した。また、攻撃者のC2サーバーにはあまりにも多くのリクエストが寄せられ、システムがダウンしかけていた。もっとひどいことになっていた可能性もあった。
Elastic Security Labsのチームは、今回の侵害に関する詳細な技術解説記事を公開しました。最初の記事では、エンドツーエンドの攻撃チェーン、クロスプラットフォームのマルウェア、およびC2プロトコルについて説明します。Axiosサプライチェーン侵害の内幕 - すべてを支配する1つのRAT 。2つ目は、Linux、Windows、macOS 全体にわたるハンティングおよび検出ルールについてです。Elasticは、Axios サプライチェーン侵害に対する検出機能をリリースしました。
これから先はどうなるのか
現状は決して良いとは言えず、セキュリティ業界はもちろんのこと、ソフトウェアエコシステム全体として改善していく必要がある。
3月の2週間：
- Trivy（セキュリティスキャナー）が侵害され、CI/CDの機密情報が盗まれた。
- LiteLLMは、盗まれた秘密情報を使って侵害された。
- Telnyxも同じ攻撃で侵害された。
- npmで最も依存されているパッケージの1つであるAxiosが、北朝鮮の疑いのある人物によって侵害された。
- ほか
パッケージレジストリは重要なインフラストラクチャである。PyPIとnpmを運営するチームは素晴らしい仕事をしているが、脅威は現在の信頼モデルでは対処できないレベルにまで達している。パッケージ変更のより優れた自動監視機能が必要です。署名スキャンだけでなく、コードが実際に何をするのかを理解すること。このプロジェクトが示すように、法学修士課程の学生はこうした分野において本当に優れている。そして、情報漏洩後には、認証情報のローテーションをより迅速に行う必要がある。TrivyからLitellm、そしてTelnyxへと連鎖的に問題が発生したのは、盗まれた認証情報が十分に迅速にローテーションされなかったためです。
今すぐできる実用的な対策の一つは、パッケージのアップデートをすぐに適用しないことです。浸け置き時間を追加してください。新しいバージョンは、ビルドに反映されるまで一定期間放置してください。Elasticでは、shai-huludへの対応として、CI/CDシステムでこれを行っています。全てを阻止できるわけではありませんが、コミュニティがCI/CDパイプラインや開発者のマシンに問題が及ぶ前に、問題点を把握する時間を与えてくれます。朗報なのは、多くのパッケージマネージャーがこの機能をネイティブでサポートするようになったことです。例えば、7日間の遅延を適用するには：
npm config set min-release-age 7
pnpm config set minimum-release-age 10080
yarn config set npmMinimumReleaseAge 10080
uv --exclude-newer "7 days ago"私たちはこれをオープンソース化します
サプライチェーンモニターというツールをリリースします。
正直に言っておきたい。これは概念実証です。睡眠不足のまま、午後だけで組み立てました。誰もこれを実運用レベルで使うとは思っていません。LLM分析にはCursorのサブスクリプションが必要で、リリースは順次処理され、ウォッチリストは静的です。
しかし、この方法は効果がある。パッケージのリリースをリアルタイムで差分分析し、AIを使って変更点を分類することで、npmで最も人気のあるパッケージの1つに対するサプライチェーン攻撃を検知することに成功した。
私がこれを共有するのは、私たちの経験からコミュニティが学ぶことが最善だと考えているからです。もし誰かがこのアイデアを基に、もっと良いものを作り上げたら、それは素晴らしいことだ。パッケージレジストリチームがそれをパイプラインに組み込んでくれれば、なお良い。もしそれが、次回誰かが大きなセーブをするチャンスにつながるなら、これは価値のあることだった。
仕組み（興味のある方へ）
監視: 2 つのスレッドが PyPI ( changelog_since_serial() XML-RPC 経由) と npm (CouchDB _changesフィード経由) をポーリングします。上位N件のウォッチリストに一致する新作リリースはキューに追加されます。状態はlast_serial.yamlまで保持されるため、中断したところから再開されます。
差分比較：レジストリAPIから直接ダウンロードした旧バージョンと新バージョン。pip/npmによるインストールも、コードの実行もできません。アーカイブを抽出し、ファイルをハッシュ化し、統合された差分レポートをマークダウン形式で生成しました。
分析：差分レポートは、読み取り専用モードでカーソルエージェントCLIに送信されます。プロンプトは、サプライチェーン指標を探すように指示します。判決のために出力が解析されました。
警告：悪意のある判定が下された場合、パッケージ名、ランク、レジストリリンク、および分析概要を含むSlackメッセージが送信されます。
このプロジェクトを超えて、セキュリティにおけるAI
サプライチェーンのセキュリティは大きな問題だが、我々は無力ではない。AIは、機械の速度で大規模な防御を行うための新たなツールを提供してくれる。このプロジェクトは、セキュリティ問題の解決にAIを活用した一例ですが、Elastic Security全体では、AIを活用した興味深い取り組みを数多く行っています。一つ強調しておきたいのは、私たちのチームが最近、攻撃検出、ワークフロー、およびエージェントビルダーを使用してAPTレベルの攻撃を自動的に検出および確認する方法に関する記事を公開したことです。これは、Elastic Platformの力を示しており、私たちが皆、攻撃の嵐に晒されている時代において、エージェント型セキュリティを提供することで、SOCの効率性と有効性を大幅に向上させます。
サプライチェーンモニタープロジェクトは、 github.com/elastic/ supply-chain-monitor で入手可能です。
迅速なインシデント対応をしてくれたElastic Infosecチーム、迅速なシステム停止を実現してくれたaxiosのメンテナー、そして被害範囲を最小限に抑えるために尽力してくれたセキュリティコミュニティの皆様に感謝します。