供給チェーン攻撃の対策で増えた「プロキシで止める」。だがこの言葉はレジストリプロキシとL4型というまったく別物を2つ指している。守れる範囲の違いを整理し、AikidoのSafe Chain / Registry Proxy / Endpoint Protectionの住み分けと、AIエージェント時代にL4型が必要になる理由を解説する。
AIエージェントにタスクを投げると、裏でVMが立ち、必要と判断したライブラリが取得され、実行され、結果だけが返ってくる。依頼した本人は npm install が走ったことすら知らない。
供給チェーン攻撃では、悪性コードが本番に届く前に、installの時点で既に被害が出る。開発機やCIで依存を取得した瞬間にpostinstallスクリプトが走り、認証情報やウォレット、開発環境の情報が抜かれる。だから問題は「誰も読んでいないコードが本番に届くこと」だけではない。誰も見ていない取得処理が、実行の入口そのものになっていることだ。
その流れと並行して、供給チェーン攻撃の対策として「プロキシで止める」という言い方が一気に増えた。ところが、この「プロキシ」という言葉はまったく別物を2つ指していて、しばしば曖昧なまま語られている。守れる範囲がまるで違うので、混同すると「導入したのに肝心のところが守れていない」が起きる。
ここでは①レジストリプロキシ ②L4プロキシ の違いを整理し、Aikidoがこの2系統をどう実装しているか、それぞれ何をどこまで守るかを示す。
パッケージを公開レジストリから直接引く代わりに、取得経路を中継サーバ経由に差し替える方式。中継点で「これは悪性」「これは公開が新しすぎる」と判断すれば、パッケージが環境に届く前に止められる。
捕捉できるのは「パッケージマネージャがレジストリ設定を通して取りに行く通信」に限られる。
| 経路 | 捕捉できるか |
|---|---|
| npm install / pip install（レジストリ経由） | ◯ |
| curl で直接ダウンロード | × |
| git clone で直接取得 | × |
| そのレジストリ設定を通らない別経路 | × |
AikidoはDevice Protection（Aikidoのサイトメニュー上の表記はDevice Protection。本稿では製品名のDevice Protectionで統一する）について、各デバイスに軽量なLayer 4プロキシを置き、通信を捕捉する仕組みだと説明している。
ここで重要なのは、厳密なOSI参照モデル上の「L4」論争ではない。意味しているのは、npmやpipのレジストリ設定に依存せず、デバイス側の通信経路でパッケージ取得を捕捉する方式だという点である。
レジストリプロキシが「設定されたレジストリを通って取得する通信」を見るのに対し、L4型は、どのツールが取得を起こしたかに依存せず、対象となるレジストリやマーケットプレイスへの通信をデバイス側で捕捉する。
ただし、この方式にはデバイス側に通信を捕捉する常駐エージェントが必要になる。そのため、「インストール不要」とは構造的に両立しない。
なお、ここで言うL4型は「あらゆる通信を覗く汎用Webフィルタ」ではない。Aikidoの説明では、パッケージレジストリやマーケットプレイスのドメインだけを対象にし、一般のブラウジングなどそれ以外の通信は素通りさせる。
Aikidoは①と②の両方をカバーしており、用途別に3つの形で提供している。
| 製品 | 系統 | 挿す場所 | 主な対応 | 導入の前提 |
|---|---|---|---|---|
| Safe Chain（無料） | レジストリプロキシ | 開発者のシェル | npm / PyPI ほか | 個人の開発機にインストール |
| Registry Proxy | レジストリプロキシ | 既存のArtifactory / Nexusの上流 | npm / PyPI（Maven含む） | 社内レジストリを運用していること |
| Device Protection | L4プロキシ | デバイス常駐エージェント | 多エコシステム（後述） | MDMでの配布 |
Safe Chainは、シェルに npm npx yarn pnpm pip uv poetry などのエイリアスを仕込み、これらのコマンドをローカルのプロキシ経由でラップする。パッケージのダウンロードはこのプロキシを通り、Aikido Intel（脅威情報フィード）とリアルタイムに照合される。悪性が見つかればインストール前にブロックする。トークン不要・無料で、まず単体の開発機で試すのに向く。
設定はワンライナーのインストーラを実行し、ターミナルを再起動するだけ。再起動しないとエイリアスが読み込まれない点だけ注意。
Registry Proxyは、企業が既に運用しているプライベートレジストリ（JFrog Artifactory や Sonatype Nexus）の「上流」にAikidoのプロキシを挿す方式。
開発者 → 社内レジストリ（Artifactory等） → Aikido Registry Proxy
├─ 安全 → 公開レジストリ
└─ 悪性 / 新しすぎ → ブロック
開発者の手元は一切変えず、社内レジストリ側の設定だけで成立する。Aikidoが環境に届く前に各パッケージを検査し、既知の悪性をブロックし、新しすぎて信頼できないバージョンを拒否し、可能な場合はパッチ済みバージョンを提供する。対応は現在 npm / PyPI / Maven で、追加エコシステムは順次拡大中。
ArtifactoryやNexusを既に運用している組織なら、開発者の環境を触らずに既存基盤へ差し込めるのが利点になる。
Device Protectionは各デバイスに軽量なL4プロキシを置き、通信を端末側で捕捉する。HTTPSを検査するためにデバイスローカルのCA（顧客ごとに固有、秘密鍵は端末の保護領域に格納）を使う、とAikidoは説明している。許可・ブロックの判定はすべて端末上でローカルに行われ、Aikidoは通信内容やダウンロードしたファイルを受け取らない。送られるのはインストールの結果と導入済みパッケージ一覧（日次でSBOM化）程度。
傍受するのは登録済みのレジストリ／マーケットプレイスのドメインに限られ、それ以外の通信は素通りする。対応はnpm / PyPIに加え、Maven、NuGet、crates（Rust）、RubyGems、Go、VS Code／Open VSX拡張、Chrome拡張など、開発者の「非バイナリな攻撃面」全般に広い。配布はJamf / Fleet / Iru などのMDM経由で、チーム別ポリシー・許可リスト・承認ワークフローを中央管理できる。
なぜ今、この「レイヤーの違い」が実務で効いてくるのか。コーディングエージェントが、人の目が届かない場所で依存を取得するようになったからだ。
従来、開発者が依存を1つ追加するときは、ダウンロード数・最終コミット・メンテナを一瞥し、プルリクで他の人のレビューも入った。エージェントにはこの判断がまるごと無い。さらにAIは実在しないパッケージ名をハルシネーションする。攻撃者がその「AIが言い出しそうな名前」を先回りして悪性パッケージを置く**スロップスクワッティング（slopsquatting）**も現実の脅威になっている。
そして公開レジストリは現に攻撃を受け続けている。Aikidoが報告した事例では、AIエージェント系エコシステムの@mastraで141パッケージが45分のバーストで汚染された（出典は記事末尾）。攻撃者は各パッケージにeasy-day-jsという単一の悪性依存（人気の日付ライブラリdayjsの悪性クローン）を注入し、そのpostinstallスクリプトがインストール時に自動実行され、第2のペイロードを目に見えないバックグラウンドプロセスとして起動、痕跡を消すために自身を削除し、MetaMaskやCoinbaseなど160を超えるブラウザの暗号資産ウォレット拡張を探索したと報告されている。汚染対象には週918Kダウンロードの@mastra/coreも含まれていた。エージェントを使うほど、エージェント系のパッケージが標的になるという構図だ。
ここで①と②の差が効く。
エージェントやIDEがあなたのエイリアスしたシェルを経由せずにパッケージを引いたら、Safe Chainの視界には入らない。ローカルにキャッシュ済みのパッケージも、レジストリへの通信が起きないため素通りする。守れるのは「設定したレジストリ経由の取得」だけ、という性質はレジストリプロキシ共通の制約だ。
L4プロキシはネットワーク層で捕まえるので、取得を起こしたのがどのツール・IDE・エージェントであっても、対象レジストリのドメインに当たれば捕捉できる。
注意したいのは、L4でも「対象ドメインリストにない通信」（たとえばレジストリ外の野良ダウンロード）は守備範囲外だという点。L4の本質は「あらゆる通信を覗くこと」ではなく、「取得を起こすツールが何であれ、レジストリ通信なら捕まえられること」にある。エージェントが何をどう取ってくるか不透明な以上、この「経路を限定しない捕捉」の価値が上がっている。
Device Protectionが担うのが、このデバイス側の捕捉層だ。要点は、EDRやウイルススキャナとは守る場所が違うことにある。
EDRや従来型の端末防御は、主に実行後の挙動検知、プロセス監視、端末上の異常検知を担う。これに対してDevice Protectionが見るのは、npmパッケージ・IDE拡張・ブラウザプラグイン・AIツールといった、現代的で非バイナリな攻撃面だ。
AikidoはこれをEDRとの関係でこう説明している——EDRが「実行されてから」脅威を捕まえるのに対し、Device Protectionはそもそも危険なパッケージや拡張機能を取得・インストールさせない段階を押さえる。置き換えではなく、補完する関係にある。
加えて、新しすぎるバージョンの取得を一定時間保留する最小パッケージエイジ（デフォルト48時間）を併用できる。攻撃者が公開直後の検知ラグを突いてくる以上、「まだ誰も悪性と気づいていない、新しすぎるパッケージ」を、検知DBへの登録を待たずに時間で遮断できる意味は大きい。これはSafe ChainでもDevice Protectionでも効かせられる設定だが、L4と組むことで「経路を問わず × 検知ラグも塞ぐ」が成立する。
重要なのは「どのプロキシが優れているか」ではない。どの取得経路を自分たちがリスクと見ているかである。
開発者が明示的にnpm installする世界なら、レジストリプロキシでかなり守れる。だが、IDE、拡張機能、AIエージェント、CI内の自動処理まで含めるなら、取得を起こす主体を信用しない設計が必要になる。
「プロキシで止める」と言うとき、それがレジストリ経由の取得だけを見る①なのか、経路を問わずデバイス側で捕まえる②なのかで、守れる範囲はまったく違う。
自分たちが守りたいのは「npm/pip のレジストリ経由の取得」までなのか、「ツールを問わないデバイス全体」なのか——その線引きを先に決めることが、プロキシ選びの出発点になる。
出典: @mastra供給チェーン攻撃の詳細 — Aikido Security, "Over 140 popular Mastra npm Packages Hit by Supply Chain Attack" (2026年6月17日) https://www.aikido.dev/blog/over-140-popular-mastra-npm-packages-hit-by-supply-chain-attack
Aikido Community Japan
公開日: 2026/6/28
最終更新: 2026/6/27
セキュリティの最新情報をお届けします。