多くのセキュリティチームは、EDRを導入し、プロキシを導入して、それで終わりにしています。しかし、サプライチェーンマルウェアに対しては、これらはどちらも有効な防御策とはなりません。なぜなら、これらは本来、別の問題に対処するために開発されたものだからです。
従来のマルウェアはこっそりとマシンに侵入する傾向がありますが、サプライチェーン型マルウェアは招き入れられる形で侵入します。開発者は npm install、そして悪意のあるコードは実行権限を完全に付与された状態で実行される。この逆転現象により、両方のツールは設計レベルで機能しなくなる。
EDRがマルウェアを見逃す理由
EDRは、プロセスの不審な動作（異常なシステムコール、予期しない親子関係、既知の悪意あるシグネチャなど）を監視します。そして、「このプロセスはマルウェアのような振る舞いをしているか？」と問いかけます。
問題は、サプライチェーン型マルウェアが信頼されたランタイム環境内で動作し、そのランタイムが日常的に行っているのと同じ動作を行う点にある。インストール後に`.env`ファイルを読み取り、その内容を攻撃者へPOSTするスクリプトは、コードをデプロイするために認証情報を取得するビルドツールと区別がつかない。どちらも node または python ファイルの読み取りやHTTPリクエストの発行。システムコールとネットワーク呼び出しは同じです。EDRには、一方が正当で他方が不正であるという区別はありません。
2026年3月、攻撃者は、週間ダウンロード数が約1億回に上るパッケージ「axios」の主任メンテナーのnpmアカウントを乗っ取りました。攻撃者はソースコードには手を加えませんでした。代わりに、クロスプラットフォーム対応のRAT（リモートアクセスツール）をダウンロードし、その後自身を削除するというポストインストールスクリプトを実行するだけの、新たな依存関係を1つ追加したのです。 プロセス監視ツールから見れば、これはnpm installが通常通り動作しているのと見分けがつきませんでした。依存関係を解決し、フックを実行し、HTTPリクエストを送信する、という一連の動作と全く同じように見えたのです。
2か月後、 MicrosoftのAzureエコシステムに含まれるPythonパッケージ「durabletask」の3つのバージョンにバックドアが仕込まれていた。その文章は10行ほどありました __init__.py. このコードはファイルを取得し、サブプロセスで実行しながら例外を捕捉します。第2段階では、AWS、Azure、GCP、Kubernetes、およびVaultから認証情報を収集し、SSMを介して他のインスタンスへ、また kubectl exec、被害者自身の認証情報を使用し、被害者自身のクラウドAPIにアクセスする。ロケール設定がイスラエルまたはイランになっているホストでは、6回に1回の確率で「rm -rf /*」が実行された。外部のバイナリも、不審な保存先も存在しない。パッケージ自体が脅威となるケースに対し、EDRには対応モデルが存在しない。
このレイヤーにおけるサプライチェーン攻撃がこれほど危険なのは、悪意のあるペイロードが通常の動作として認識されるためです。検出すべき異常は存在しません。なぜなら、その目的はノイズに溶け込むこと、あるいはこのケースでは、それ自体がノイズとなることにあるからです。
なぜプロキシはそれを見逃すのか
トラフィック経路上のプロキシは、パケットのダウンロードを傍受し、既知の悪意のあるパッケージと照合することができます。理論上は、これは有効です。問題は、「トラフィック経路上」という点にあります。
リモートプロキシや企業プロキシは、開発者が所有するマシン上でオプトイン方式で制御されます。開発者は自宅やカフェ、ホテルのWi-Fi環境などで作業します。彼らはシステムのプロキシ設定をバイパスするツールをインストールします。VS Codeは拡張機能のダウンロードを独自に管理します。npm、pip、cargoには独自のHTTPクライアントが備わっています。多くのCLIツールや言語ランタイムは、 HTTP_PROXY 明示的に設定されていない限り、完全に無効になります。そして、プロキシが原因でツールが動作しなくなった場合、開発者はプロキシを無効にしてツールを修正し、再有効化することを忘れてしまうのです。
このような事例は日常茶飯事です。開発者が夜11時に個人のマシンから、悪意のあるVS Code拡張機能をインストールしてしまう。CIランナーが、企業ネットワークの境界の外から、悪意のある依存関係を取得してしまう。どちらのインストールもプロキシを経由しません。スキャンは実行されず、本来ならこれを検知すべきチェック機能は、そもそも存在していなかったのです。
実際に効果があるもの
EDRもプロキシも、それぞれが対象とする脅威に対しては実効性があり、依然として有用です。ただ、開発者特有のサプライチェーンの攻撃対象領域をカバーできていないだけです。
その環境には、マシン自体に常駐し、インストール時にパッケージが何を実行しているかを把握し、ネットワーク構成にかかわらず常に稼働しているものが必要です。私たちは、まさにその目的のためにAikido Protection」を開発しました。本ブログでは、多くの組織が「Device Protection」を活用して開発者のマシンを保護している事例をご紹介します。
開発者のマシンにおいて、従来のエンドポイント管理ツールが見落としている点をより包括的に把握したい場合は、本記事でMDMにおけるこの問題について解説しています。
