エージェントに依存を足させる前提のサプライチェーン対策: 公開直後の版を入れない・評価した版に固定する・ビルドとデプロイを分ける

どんな時に使う？

• エージェントが npm install や pip install を自分で実行する
• 2026年3月の axios・LiteLLM のような侵害で、自分のプロジェクトが巻き込まれたか分からなかった
• 推移的依存（依存の依存）まで把握できていない

「不使用だから OK」ではない理由（Flatt Security の整理）

1. 直接依存になくても、推移的依存に入っていることがある
2. 攻撃の手口は使い回せる。次は別のパッケージで起きる
3. AI に任せるほど、何に依存しているかを人が把握できない場面が増える

4本の柱

1. 受け入れ評価（Dependency Cooldown）: 公開から一定期間は入れない。スライドの例:
   bash

   npm install --min-release-age=3d        # npm v12+
   uv add --exclude-newer "3 days" <pkg>   # uv
   pinact run --min-age 3                  # GitHub Actions

   講演者の私見では、短くて3日、余裕をもって7日。ただし待てば安全とは限らない（潜伏する検体もある）

2. 依存の固定: npm ci（lockfile どおり）、pip install --require-hashes -r requirements.txt、GitHub Actions は SHA で固定。axios の件では ^1.14.0 が悪性の 1.14.1 を引き込んだが、lockfile＋npm ci なら防げた
3. 構造の堅牢化: ビルド（外部コードが動く場所）とデプロイ（本番の権限を持つ場所）を分け、成果物だけを受け渡す
4. CI/CD の記録: 端末と同じように、CI でどのプロセスがどこへ通信したかを残す。侵害が公表されたあとに過去のジョブを検索できる

エージェント向けの書き方の例（AGENTS.md／CLAUDE.md）

• 「依存を追加・更新するときは、公開から7日以上たった版を選ぶ。lockfile を必ず更新し、npm ci で確認する」
• 「curl ... | sh のようなインストール手順は実行せず、相談する」

注意点

• レジストリのプロキシでブロックする方法（スライドでは Flatt Security の Takumi Guard を紹介）もある。どの層に任せるかはチームで決める
• 関連: npm/pnpm: minimum-release-age でサプライチェーン攻撃を避けつつ、緊急パッチだけ一時的に解除する、GitHub Actions: pinact で uses: をコミット SHA に固定する、pnpm の「ビルドスクリプトを無視しました」は全部許可せず、Claude に1件ずつ仕分けさせる

出典

• @flatt_security 2026-04-07: @flatt_security · 2026-04-07
• 米内 貴志「axios, LiteLLM...不使用だったのでOK、ではない。『次に備える』ソフトウェアサプライチェーン侵害への対策」（Speaker Deck）: speakerdeck.com