2026年3月、axiosなど広く使われるパッケージが相次いで侵害された。ZOZOの情報セキュリティ部はこれを受け、「怪しいパッケージに気をつけましょう」という呼びかけをやめ、全社員のnpm install自体をレジストリごと差し替える方向に舵を切った。個人の注意力に頼らず、構造で強制するという設計を読み解く。
MDM経由で全社のパッケージインストールを検疫プロキシへ通す実装の勘所と、「気をつけて」でなく「経路を差し替えて強制する」という設計思想を、個人の開発環境にも取り入れるための視点。
2026年3月、axiosをはじめとする広く使われるパッケージがサプライチェーン攻撃で侵害された。ZOZO TECH BLOG「見守りパンダ降臨——Takumi Guardを全社展開」は、この事例を引き合いに「開発環境におけるセキュリティ対策の重要性が高まっている」と書き出す。
対策として選ばれたのは、悪意あるパッケージの検知・ブロックツールTakumi Guard（GMO Flatt Security提供）の全社展開だった。対応エコシステムはnpm・PyPI・RubyGems・Go・Packagistの5つ。著者は情報セキュリティ部の兵藤氏で、SOC業務の自動化を扱った「考えさせない」サブエージェント設計と同じ著者・同じ部署による記事だ。
この実装が面白いのは、「怪しいパッケージを見分けてください」という判断を開発者に求めていない点にある。判断させる代わりに、npm installやpip installが向かう先そのものを検疫プロキシに差し替えてしまう。
.npmrcを丸ごと検疫プロキシへ向け替えるNPM_CONFIG_USERCONFIG=/tmp/.npmrcを設定し、レジストリをhttps://npm.flatt.tech/に、認証には専用のauthTokenを割り当てる。開発者が普段どおりnpm installを打つだけで、パッケージは自動的にTakumi Guardの検疫を経由する。
PIP_INDEX_URLを差し替えるnpmだけでなくPyPI側でも同様に、環境変数PIP_INDEX_URLをプロキシ経由のURLへ書き換える。エコシステムごとに個別の「注意喚起」を出すのではなく、インストールの入口そのものを共通の仕組みで差し替えている。
ここが核心。「怪しいパッケージに気をつけて」は、結局のところ全員が毎回正しく判断できるかに賭けるガイドラインだ。Takumi Guardの設計はその賭けをやめ、判断を求めず、経路そのものを検疫の内側に差し替えることで解決している。
ZOZOはMDMとしてMicrosoft Intuneを利用している。Macには「run shell scripts」機能でシェルスクリプトを配布し、定期実行によって設定が上書きされないようにする。Windowsには検出スクリプトをダミー扱いにし、deploy-remediationsで修復スクリプトとして配布する——OSごとにIntuneの機能を使い分けて同じ検疫設定を届けている。
厄介だったのはシークレットの扱いだった。Intuneでシェルスクリプトを配布する場合、認証トークンをうまく扱えないという制約があり、トークンのローテーションと発行量の定期確認という運用でカバーしている。コンテナ利用時にも同種の落とし穴があり、--mount=type=secretでトークンをコンテナ内部に渡す際、別のRUNで実行するとトークンがイメージレイヤーに残ってしまうというリスクに気をつけて実装されている。
さらにTakumi Guard自体が日々アップデートされるため、追従が止まれば検疫の意味が薄れる。そこでGitHub Actions経由でIntuneのラッパースクリプトを自動更新する仕組みを組み、手動更新に頼らない体制にしている。
個人開発者がMDMで全デバイスを統制することはできない。だが「気をつける」を求めず「経路を強制的に差し替える」という設計思想そのものは、規模を問わず応用が効く。