LiteLLMサプライチェーン侵害に学ぶ、AI依存ライブラリ緊急対応プレイブック

今回の事案が重い理由

GIGAZINEなどで報じられたLiteLLM関連の事案は、単なる脆弱性修正の延長ではありません。AIミドルウェアは、モデルAPIキー、プロンプト文脈、ルーティング情報といった高機密データの通り道に位置します。

そのため、依存ライブラリ侵害はアプリ単位の不具合ではなく、AI制御プレーン全体の信頼性問題に直結します。

初動6時間でやるべきこと

最初のゴールは原因究明の完了ではなく、被害拡大の停止です。

影響バージョンを参照するCI/CDを一時停止
アーティファクトプロキシで該当バージョンを遮断
高権限シークレット（モデル鍵、クラウド鍵、Gitトークン）を優先ローテーション
該当バージョンを導入したワークロードを隔離
ログ、ビルド成果物、実行履歴を保全

「詳細が固まってから鍵を回す」は遅すぎます。推定でもよいので優先度順に回してください。

依存経路の可視化が勝負

LiteLLMのようなライブラリは、直接依存だけでなく転移依存として潜みます。

APIバックエンドの直接依存
社内エージェント基盤経由の転移依存
Notebookや検証スクリプトにのみ存在
lockfile未統一環境で部分的に混入

SBOM、lockfile、パッケージミラーのログを統合し、「どこで・いつ・どの版が使われたか」を短時間で引けるようにします。

秘密情報ローテーションの実務設計

全鍵一斉回転は混乱を招きます。影響半径で段階化します。

Tier 1（即時）

本番モデルAPIキー
デプロイ権限を持つCI資格情報
書き込み可能なSCMトークン

Tier 2（当日）

ステージング共通鍵
社内サービス間連携鍵

Tier 3（48時間以内）

低重要度・長尾トークン
棚卸しで残存確認された旧鍵

各ローテーションに「担当者・時刻・検証結果」を紐づけ、後から追えるようにします。

ハント観点（検知クエリ）

ビルド環境から通常外ドメインへの通信
深夜帯に集中するシークレット参照
依存インストール直後の不審プロセス起動
install hook経由での外部送信

サプライチェーン攻撃では、インストール時実行が最初の侵入口になることが多いです。

再展開は「信頼ゲート付き」で戻す

クリーンランナーで再ビルド
信頼済みミラーから依存解決
チェックサムと来歴情報を検証
Canaryで監視を強化して展開
異常通信なしを確認後に段階拡大

汚染疑いのあるランナー上での上書き修復は、原則避けるべきです。

今月中に入れるべき恒久対策

Build面

ハッシュ固定付きインストールの強制
CIで未固定依存を禁止
来歴未検証パッケージをビルドゲートで拒否

Secret面

静的キー依存を減らし短命IDへ移行
環境別・用途別の鍵分離
ビルド基盤のEgress許可先を最小化

Monitoring面

依存バージョン急変アラート
新規install script検出
依存更新イベントと異常通信の相関監視

経営向け報告で必要な要素

露出期間（開始・終了）
影響可能性のあるシステム範囲
ローテーション完了率
確定影響と未確定範囲
追加済み再発防止策

経営層には、技術詳細より「リスク水準が下がった根拠」を示すことが重要です。

まとめ

今回の教訓は明確です。AIリスクはモデル本体だけでなく、ミドルウェアと依存供給網に集中しています。LiteLLM事案を機に、依存信頼モデル、鍵の寿命設計、ビルド完全性をTier 1運用へ引き上げるべきです。

単発対応で終えるのではなく、次の侵害で被害半径を最小化できる設計に置き換えることが、実務的に最も価値の高い対応です。