2026年3月24日、盗まれたメンテナーの認証情報を使って、LiteLLM（1.82.7および1.82.8）のバックドア付きバージョン2つがPyPIに公開されました。マルウェアはSSHキー、AWS/GCP/Azureの認証情報、Kubernetesのシークレットを盗みました。 .pthファイルを通じて永続的なバックドアを展開しました。DSPy、MLflow、CrewAI、そしてOpenHandsはいずれも、下流の依存関係として、改ざんされたバージョンを取得していました。

もしあなたが今、LiteLLMを本番環境で運用しているなら、この投稿はあなたのためのものです。

TL;DR - 評価する価値のある5つの代替案

1. Bifrost（Go、オープンソース）- コンパイル済みバイナリ、Pythonのサプライチェーン（供給網）上の露出がゼロ
2. TensorZero（Rust）- サブミリ秒のオーバーヘッド、コンパイル済みで推論に特化
3. Cloudflare AI Gateway - 管理サービス、自社ホスティング不要
4. Kong AI Gateway - AIルーティング用プラグイン付きのエンタープライズAPIゲートウェイ
5. Direct Provider SDKs - 場合によっては、ゲートウェイ自体が不要なこともあります

実際に何が起きたのか

Snykの詳細な解説には全タイムラインが記載されていますが、短くまとめるとこうです：

攻撃者は盗まれたPyPIの認証情報を使って、LiteLLMの2つの悪意あるバージョンを公開しました。バックドアは、パッケージをインストールまたは更新したあらゆるマシンから、環境変数、クラウド認証情報、SSHキー、K8sのシークレットを収集しました。さらに、73の侵害されたGitHubアカウントを使って、開示（ディスクロージャー）用のissueにノイズを大量に投げ込み、そして攻撃者は盗まれたメンテナーの認証情報を使ってissueを完全にクローズしました。

LiteLLMは1日あたり340万回以上のダウンロードがあります。これは非常に大きな影響範囲です。

代替案で見るべきポイント

リストに入る前に、あなたが評価すべきことは以下です：

サプライチェーンのリスク。 これらの攻撃を招きやすい依存関係エコシステムを持つ言語で、そのツールは書かれていますか？ PythonのPyPIは、サプライチェーン侵害のパターンを目にしてきました。GoやRustのようなコンパイル型の言語は、実行時の依存関係解決を伴わない単一のバイナリを生成します。

オーバーヘッド。 すべてのLLM呼び出しをプロキシ経由でルーティングしているなら、そのプロキシのレイテンシが重要になります。リクエストあたり1〜2msを超えるものは、規模が大きくなるにつれて積み上がっていきます。

オープンソース。 コードを監査できますか？ 自社ホスティングできますか？ バイナリをベンダリング（同梱）できますか？

マルチプロバイダ対応。 ゲートウェイの本質は、OpenAI、Anthropic、Bedrock、Azureなどにまたがってルーティングを、単一のAPIを通じて行うことです。

5つの代替案

1. Bifrost（Go、オープンソース）

サプライチェーンのセキュリティが最優先の懸念であるなら、最初に検討すべきのはこれです。

BifrostはGoで書かれています。コンパイル済みバイナリが手に入ります。Pythonの実行環境がなく、pipインストールがなく、しかも一夜にして汚染され得る推移的依存関係ツリーもありません。 npx -y @maximhq/bifrost 経由で実行するか、Dockerイメージを取得して、30秒で稼働できます。

# ローカルにインストールして実行
npx -y @maximhq/bifrost

# もしくは Docker を使用
docker run -p 8080:8080 maximhq/bifrost

# 内蔵の Web インターフェースを開く
open http://localhost:8080

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role": "user", "content": "こんにちは、Bifrost!"}]
  }'

実際にはこういうことです： LLM ゲートウェイは PyPI サプライチェーン攻撃への露出がゼロです。これで終わり。

性能数値：リクエストあたり 11µs のルーティングオーバーヘッド。5,000 RPS でベンチマーク済みです。これは、Python ベースのプロキシより約 50 倍高速です。

標準で手に入るもの：

• ゼロ設定セットアップ。 NPX または Docker。設定ファイルは不要です。localhost:8080 の Web UI がプロバイダーのセットアップ、API キー、モニタリングをビジュアルに扱います。
• OpenAI 互換 API。 すべてのリクエストが OpenAI の形式に従います。既存のコードを Bifrost に向け、openai/gpt-4o-mini を anthropic/claude-sonnet-4-20250514 に差し替えてください。統合コードは変更不要です。
• 4 階層の予算階層。 組織、チーム、プロジェクト、個人キーの各レベルで支出上限を設定できます。複数チームが 1 つのゲートウェイを共有する場合に便利です。
• Weaviate によるセマンティックキャッシュ。 類似したクエリをキャッシュし、繰り返しやほぼ重複するプロンプトがトークンを消費しないようにします。
• MCP サポート。 Model Context Protocol でエージェントを構築している場合、Bifrost がネイティブに対応します。

メリット：

• コンパイル済みの Go バイナリ。Python/PyPI サプライチェーン攻撃に耐性あり
• オーバーヘッド 11µs、5,000 RPS のスループット
• ビジュアル設定とモニタリングのための Web UI
• ゼロ設定で起動（NPX または Docker）
• オープンソースで完全に監査可能

デメリット：

• Kong や Cloudflare と比べると新しいプロジェクト
• コミュニティが小さい（ただし急速に成長中）

GitHub | Docs | Website

2. TensorZero（Rust）

TensorZero は同じ「コンパイル済み言語、Python ランタイムなし」というアプローチを Rust 側から行います。リクエストあたりサブミリ秒未満のオーバーヘッドです。完全機能のゲートウェイであることよりも、推論の最適化と構造化された生成により重点が置かれています。

特に推論時の最適化（プロンプトキャッシュ戦略、構造化出力の強制）を探していて、かつコンパイル済みバイナリによるサプライチェーン上の利点も欲しい場合、TensorZero は評価する価値があります。

メリット：

• Rust のバイナリ。Go と同等のサプライチェーン安全性
• 推論待ちのオーバーヘッドがサブミリ秒未満
• 強力な推論最適化機能

デメリット：

• フル機能の API ゲートウェイより範囲が狭い
• エコシステムが小さく、連携数も少ない
• 複数チームのガバナンス機能への注力が弱い

3. Cloudflare AI Gateway

何も自前でホストしたくないなら、Cloudflare AI Gateway が最も手軽な選択肢です。Cloudflare のエッジネットワーク上で動作します。コンテナを 1 つもデプロイせずに、キャッシュ、レート制限、ログを利用できます。

サプライチェーンの問題はここで別物になります。パッケージをインストールしているわけではありません。マネージドサービスを呼び出しています。攻撃面は「依存関係を誰かが汚染できるか」から「Cloudflare のインフラを信頼できるか」へと移行します。ほとんどのチームにとっては、そのトレードを受け入れられるものです。

メリット：

• 運用負荷ゼロ、完全にマネージド
• 世界規模のグローバル・エッジネットワークで低遅延
• セルフホスティング不要、インストールするパッケージもなし
• 標準の分析とログ

デメリット：

• オープンソースではないため、ルーティングロジックを監査できない
• Cloudflare のエコシステムへのベンダーロックイン
• セルフホスト型の選択肢に比べてカスタマイズは限定的
• 価格は大量トラフィック時に予測不能にスケールする可能性

4. Kong AI Gateway

Kong は長年にわたり API ゲートウェイの管理を行ってきました。AI Gateway プラグインは、すでに実戦投入済みのプラットフォームの上に LLM ルーティング、レート制限、認証を追加します。

あなたのチームがすでに他の API トラフィックのために Kong を運用しているなら、プラグインとして AI ルーティングを追加するのは理にかなっています。AI と非 AI を含めて、1 つのゲートウェイで済みます。しかし、ゼロから始める場合は Kong の運用上の複雑さが大きな負担になります。これはエンタープライズ向けのツールであり、エンタープライズのセットアップ要件があります。

メリット：

• 成熟していて実戦投入済みの API 管理プラットフォーム
• 認証、レート制限、トランスフォームのための豊富なプラグインエコシステム
• 強力なエンタープライズサポートとドキュメント
• AI と非 AI API トラフィックを 1 つのゲートウェイで扱える

デメリット：

• LLM ルーティングだけが必要なチームには運用の負担が重い
• 単純なユースケースに対して構成の複雑さが高い
• エンタープライズの価格が高くなりがち
• LLM ルーティングだけが目的なら過剰

5. Direct Provider SDKs

率直に言うと、ゲートウェイは不要かもしれません。

ある 1 つのプロバイダー（たとえば OpenAI）を 1 つのサービスから呼び出すだけなら、途中にプロキシを追加するとレイテンシ、複雑さ、そして監視対象が増えます。プロバイダーの SDK をそのまま使うのが最善です。

マルチプロバイダーのルーティング、統合ログ、予算コントロールを失います。しかし、シンプルさを得て、インフラコンポーネントを丸ごと排除できます。

メリット：

• 追加レイテンシやインフラがゼロ
• 追加の攻撃面がない
• 最もシンプルなアーキテクチャ
• プロバイダー固有の機能に直接アクセスできる

デメリット：

• マルチプロバイダーのフェイルオーバーがない
• 統一ログやコスト計測がない
• プロバイダー切り替えにはコード変更が必要
• 集中レート制限や予算コントロールがない

比較テーブル

今週やるべきこと

今日： LiteLLM のバージョン 1.82.7 または 1.82.8 を動かしていないか確認してください。該当する場合は、そのマシンがアクセスできたすべての認証情報をローテーションしてください。SSH キー、クラウド IAM キー、K8s シークレット、データベースのパスワード。全部です。

今週： LLM インフラの依存関係ツリーを監査してください。pip list を実行し、何が何を引き込んでいるかを確認します。推移的な依存関係（transitive dependencies）の中に、サプライチェーン攻撃が隠れます。

今月： あなたの LLM ゲートウェイが、そもそも Python パッケージである必要があるのかを評価してください。プロダクションのトラフィックをルーティングしているなら、Bifrost のようなコンパイル済みバイナリは、リスクのカテゴリ全体を取り除きます。セットアップとテストにかかるのは 30 秒です。

LiteLLM のインシデントは机上のリスクではありませんでした。実際に起きて、プロダクションシステムに影響し、攻撃者は開示を積極的に抑え込みました。あなたの LLM ゲートウェイは、あなたのアプリケーションと、保有するすべての API キーの間に存在します。信頼できるものを選んでください。

リンク：

• LiteLLM のサプライチェーン攻撃に関する Snyk 記事
• Bifrost GitHub
• Bifrost Docs
• Bifrost の Web サイト