「Safe Chain 入れてるから大丈夫」ではない理由 — Endpoint Protection が埋める「第1層の死角」

5月2日に書いた「Aikidoのスキャン: IDE、PR、Actions の3層防御」 で、開発フローを 3つの層で守る という整理をしました。

第1層 (IDE/ローカル) には Cursor + Aikido Extension で MCP / Safe Chain / Pre-Commit Hook を入れた。これで「コードを書く瞬間からマージまで」がカバーできる多層防御が完成、と書きました。

ところが、です。 第1層には実は『Safe Chain で守りきれない死角』があった。

TL;DR

Endpoint Protection は、前回説明した三層構造の 第1層 (IDE/ローカル) を強化するもの です。なぜなら、Safe Chain だけでは第1層にまだ守りきれない死角があるから。既存 EDR (ウイルスバスター等) も対象が違うので併存して使う。第1層を完成させるには EDR × Safe Chain × Endpoint の3点併存が必要、という話です。

---

前回の3層を振り返る

第3層: リポジトリ監視     ← 継続スキャン + AutoFix
第2層: PR / GitHub        ← PR Checks (SAST/SCA/Secrets/Code Quality)
第1層: IDE / ローカル     ← MCP / Safe Chain / Pre-Commit Hook

これは SDLC の時系列軸 で、コードが「書かれる→レビューされる→マージ後監視される」のそれぞれを守る構造です。

今回の論点はこの 第1層の中身 にあります。

第1層 (IDE/ローカル) を解剖する

実は第1層は1枚岩ではなく、役割の違う複数のツールが重なる場所 です。

つまり Endpoint は 第1層の死角を埋めて完成させる 役割。前回の3層構造を捨てるのではなく、その 第1層を強化する ためのツールです。

---

開発者として整理しておきたい4つの疑問

新しいセキュリティツールが出るたびに「これも入れるの…?」となるので、素朴な疑問を順番に潰していきます。

Q1. Safe Chain 入れてるから足りるんじゃないの?

足りません。Safe Chain は shell alias で npm / pip をラップするプロキシ なので、守れるのは CLI 経由のパッケージインストール だけです。

開発者の Mac には、CLI を通らない経路で入ってくるソフトがたくさんあります:

• VS Code / Cursor の 拡張機能 (マーケットプレイスから直接インストール)
• Chrome の ブラウザ拡張
• Cursor / Claude Code に追加する MCP サーバー
• Skills.sh などの AI エージェントスキル
• Docker コンテナ内の pip install (ホスト側 alias が効かない)
• 別シェルや別ユーザでの実行

これらはすべて Safe Chain の守備範囲の 外 です。

Q2. でも既存の EDR (ウイルスバスター等) があるから二重では?

これも違います。EDR と Endpoint Protection は 対象がそもそも違う:

EDR は家全体の煙感知器、Endpoint はキッチンの専用安全装置。火災一般を見るのと、コンロ周りを見るのは別の役割です。両方あって初めて家が守られる。

Q3. EDR で守れない具体例ある?

3つ挙げます。

1. 悪意ある IDE 拡張機能

2026年1月にAikido が検知した Fake Clawdbot VS Code 拡張 は、正規拡張に見せかけて起動時に RAT (Remote Access Trojan) をドロップする仕掛けでした。EDR は VS Code が拡張を読み込む動作を「正常な IDE 動作」として通します。実行されて初めて気づく — その時には .env も SSH 鍵も既に外に出ています。

2. ブラウザ拡張経由の侵入 (Vercel事件)

2026年4月の Vercel 内部システム侵害は、従業員が使っていた Chrome 拡張 が侵害ルートでした。EDR は Chrome ストアからの拡張インストールを「ブラウザの正常動作」として見逃します。

3. AI エージェントによる勝手な MCP / ライブラリ追加

「このタスク完了させて」と Cursor / Claude Code に頼むと、エージェントは自分で必要そうなツールを判断して追加していきます。サードパーティ MCP サーバーが裏で .env を読んだり、SSH 鍵にアクセスしたりするケースは既に複数報告されています。EDR から見ると「python プロセスがファイル読んでるだけ」で異常検知のしようがありません。

Q4. Safe Chain × EDR の二重でも突破される?

されます。攻撃者は 両方を迂回するルート を選びます。

シナリオ A: IDE 拡張経由のスタックイン

1. 開発者が「便利そう」と Cursor 拡張をマーケットプレイスから直接インストール
2. → Safe Chain は CLI じゃないので見ない
3. → EDR は「IDE が拡張動かしてるだけ」と判断
4. 拡張がバックグラウンドで .env 盗む、SSH 鍵を抜く
5. その認証情報で GitHub に侵入、悪意あるコミットを push
6. CI/CD 経由で本番に到達

シナリオ B: チームメイトの未対策マシンから侵入

1. npm パッケージが侵害される (例: 2026年4月の Shai-Hulud 第3波)
2. 自分の Mac は Safe Chain 入れてるからブロック
3. でもチームの誰かが Safe Chain 入れてない → そのマシンから侵入される
4. その人の npm publish トークンで他のパッケージにワーム伝播
5. 自分のマシンに、別経路で侵害版が回ってくる

→ Safe Chain は 個人任せ、Endpoint は MDM 経由でチーム全員に強制適用 できる差。

シナリオ C: AI エージェント経由の野放し追加

1. Cursor で AI に「機能実装して」と依頼
2. AI が必要と判断した MCP サーバー / Python ライブラリを 開発者の許可を取らず に追加
3. その中に侵害版が混入
4. → Safe Chain の alias を通らない経路で入る場合がある
5. → EDR は気づかない

---

結論: 第1層を完成させる3点併存

第1層 (IDE/ローカル) =
  ✅ 既存 EDR        — OS レベルの脅威 (ランサム/トロイ等)
  ✅ Safe Chain     — CLI 経由のパッケージインストール
  🆕 Endpoint       — CLI 以外のすべて (拡張/AI/MCP/Docker内/etc)

3つは互いに対象が違うので、競合ではなく補完関係。Endpoint は第1層を新しくするのではなく、完成させる ためのものです。

開発者として実利の面で言えば、3つを重ねて初めて自分の Mac は 「自分が選んだもの以外は入らない」 状態に近づきます。

「1つで全部足りる」発想は、攻撃面が広がりすぎた今の時代では成り立ちません。

---

関連記事

• Aikidoのスキャン: IDE、PR、Actions の3層防御 — 前回定義した3層モデル
• Aikido Endpoint Protection、正式リリース — 本当の敵は「シャドーAI」だった — 背景とコンセプト編
• Aikido のフリープラン、どこまで使える? — 料金プランの境界線

参考リンク

• Aikido Endpoint Protection ドキュメント
• Fake Clawdbot VS Code 拡張の検知レポート
• Aikido Intel フィード