LiteLLMにパッチを適用。でも、AIの影響範囲を把握できていますか？

AIエコシステムで広く使われているオープンソースパッケージが、短期間ながら認証情報を窃取するマルウェアに侵害されていました。

100社を超えるLLMプロバイダーへのリクエストを振り分けるモデルゲートウェイ、LiteLLMは、1日に数百万回ダウンロードされています。この短い期間に、悪意あるバージョンは発覚するまでに数万回ダウンロードされた可能性があります。

理論上、これは安心材料になるはずでした。プロジェクトはコンプライアンス認証を取得し、セキュリティツールも導入され、問題は迅速に発見・修正されたからです。しかし、まさにそこに問題があります。

今回のインシデントは、単なる依存関係の侵害ではありませんでした。現代のAIシステムが実際にどのように破綻するのかを示すものでした。表面ではなく、全体を把握しきれていないレイヤーをまたいで問題が起きるのです。

その影響を示す初期の兆候は、すでに現れています。AI採用スタートアップのMercorは、LiteLLMのサプライチェーン攻撃の影響を受けた下流の被害者の「数千社のうちの1社」だったと認めました。同社の場合、侵害は脆弱なパッケージにとどまらず、盗まれた認証情報を使って内部システムにアクセスされた結果、ソースコードを含む大規模なデータ流出につながったと報じられています。

多くのチームが見落としているのは、この点です。リスクは依存関係そのものではなく、実行時にその依存関係が何にアクセスできるかにあります。LiteLLMのようなものがアプリケーションとモデルプロバイダーの間の実行経路に入ると、その背後にあるすべて、つまりAPI、ツール、エージェントのワークフロー、機密データへの経路になります。

Mercorなどが侵害されたのは、単に「LiteLLMを使っていた」からではありません。LiteLLMが何と接続されていたかが原因です。

最初のLiteLLM侵害で使われたマルウェア自体は、比較的洗練されていませんでした。目立つ動きをし、マシンをクラッシュさせたため、発覚しました。モデルプロバイダー、API、エージェントのワークフローをまたいで認証情報を密かに流出させるよう設計された、より巧妙なバージョンであれば、数週間にわたって検知されなかった可能性があります。

そうなっていたとしても、ほとんどのチームは実際に何がリスクにさらされているのか把握できなかったでしょう。LiteLLMを使っていることは分かっていても、です。

しかし、次のことは分からなかったでしょう。

• どのモデルがLiteLLM経由でルーティングされていたか

• どのプロバイダーが関与していたか

• それらのモデルがどのツールやシステムにアクセスできたか

• そのリスクがアプリケーション内でどのように広がったか

ここにギャップがあります。だからこそ、こうしたインシデントはもはやサプライチェーンの問題だけではなく、最終的にはAIシステムの可視性の問題なのです。

LiteLLMの侵害が発生したとき、ほとんどのチームは予想どおりの対応をしました。依存関係を確認し、脆弱なバージョンを特定し、迅速にパッチを適用するか、安全なバージョンに固定しました。従来のアプリケーションセキュリティの観点では、適切な対応です。

しかし、ここで多くのチームが立ち止まって考えない、より本質的な問いが生まれます。実際に何を修正したのでしょうか？

LiteLLMが使われていた場所を特定するだけでなく、システム内で何をしていたのか、何と接続されていたのか、パッケージ自体を超えてどんなリスクをもたらしたのかを突き止めること。AIアプリケーションでは、ここから話が複雑になります。

従来の可視性では把握しきれない領域

LiteLLMは、コードベースにひっそりと存在する単なるライブラリではありません。アプリケーションと、それが依存するモデルとの間の実行経路に直接位置します。リクエストをルーティングし、プロバイダーを抽象化し、最終的には実行時のシステムの動作を形作ります。

つまり、LiteLLMが侵害されても、その影響はパッケージを含むリポジトリに限られません。経由して呼び出されるモデル、関与するプロバイダー、それらのモデルがアクセスできるツール、そしてそれに依存するエージェントのワークフローにまで及びます。

ここで、ほとんどのチームは可視性を失います。モデルを指定するコードの1行は取るに足らないものに見えるかもしれません。しかしそこには、依存関係グラフのどこにも記録されない、プロバイダー、機能、アクセスに関する一連の選択が組み込まれています。

これが複数のリポジトリやチーム、進化を続けるエージェントのワークフローに広がると、見えてくるのは単なる依存関係の問題ではありません。全体を把握したり理解したりするのが難しいシステムです。

Evo AI-SPMが解消するギャップ

存在する依存関係だけに注目するのではなく、EvoはAIがどのように使われているかに注目します。LiteLLMの場合、モデルゲートウェイとして特定し、そこを経由するプロバイダーとモデルをマッピングし、それらのモデルが連携するツールやAPIを検出し、システムの動作を形作るエージェントのワークフローとすべてを結び付けます。

その結果得られるのがAI-BOMです。これは、システムを構成するコンポーネントだけではなく、AIシステムそのものを可視化する、常に更新されるマップです。

コンテキストがすべてを変える理由

コンテキストが加わることで、インシデントへのチームの対応は根本から変わります。LiteLLMが侵害されたことしか分からなければ、次にすべきことは明確です。修正することです。しかし、どのように使われているかを理解すれば、対応はよりきめ細かなものになります。

トラフィックが未承認のモデルプロバイダーにルーティングされていないか、その経路に依存するエージェントはどれか、どの外部システムがその経路を通じてアクセス可能か、そもそもそうしたやり取りを管理するポリシーがあるかを確認できます。脆弱性に対処することと、実際にさらされているリスクを理解することの違いはここにあります。

AIアプリはすでにこのように構築されている

これは、すでに構築されているAI搭載アプリケーションの実態を反映しています。開発者はフレームワークを使ってエージェントをオーケストレーションし、LiteLLMでモデルへのアクセスを抽象化し、そのエージェントを外部ツールやAPIに接続してタスクを完了させるかもしれません。従来の視点では、これは脆弱な依存関係として表れます。システム全体の視点では、パッケージ自体をはるかに超える一連の選択、インテグレーション、動作を意味します。

気づかないうちに存在するAI

多くのチームは、自分たちの環境にすでに存在するAIの多さに驚きます。AIの導入はまだ初期段階だと考えていたのに、コードベースのあちこちで、モデルゲートウェイ、オーケストレーションフレームワーク、新たなエージェントのパターンが使われていることに気づくのです。

一元管理されておらず、その多くはガバナンスも行き届いていません。それでも、すでに本番システムの一部になっています。LiteLLMの侵害のようなインシデントが、この複雑さを生み出すのではありません。すでに存在する複雑さを明らかにするのです。

SCAは引き続き必要（ただし、それだけでは不十分）

これはソフトウェアコンポジション分析（SCA）の失敗ではありません。Snyk Open Sourceのようなツールは、侵害されたLiteLLMのバージョンにフラグを立て、推移的依存関係を含め、それらのバージョンがリポジトリ内のどこに存在したかを明らかにし、チームに迅速にアラートを通知して、明確な修正ガイダンスを提供します。

このシグナルは不可欠であり、これがなければチームは問題の存在すら知ることができません。しかし、SCAが答えるのは、非常に限定された問いです。「この依存関係に脆弱性はあるか？」課題は、現代のAIシステムが依存関係だけにとどまらないことです。

こうしたインシデントに対して、「SCAですでに検知できた」と反応することはよくあります。それは事実ですが、依存関係こそがシステムだと見なすことになります。実際には、依存関係は入口にすぎません。システムとは、その依存関係によって可能になるすべて、つまりモデルへのアクセス、ツールの実行、エージェントのオーケストレーション、動的な意思決定です。このレイヤーが見えなければ、リスクがどこにあるのかを完全には理解できません。

LiteLLMの侵害は一例にすぎませんが、変化の必要性を明確に示しています。依存関係しか見ていないなら、システムは見えていません。SCAは問題の存在を知らせ、EvoはAIシステムのコンテキストにおいてそれが何を意味するかを理解し、システムを制御できるようにします。

Evo AI-SPMの使い方

Evo AI-SPMを使えば、自社の環境での状況を簡単かつ迅速に把握できます。数分で、次のことが可能です。

• リポジトリ全体からLiteLLM（および同様のモデルゲートウェイ）の使用箇所を特定する

• 経由してルーティングされているモデルプロバイダーとモデルを確認する

• 接続されたツール、API、エージェント、ワークフローを検出する

• 従来のセキュリティツールでは見えない「シャドーAI」を明らかにする

• 今後許可する対象を制御するポリシーを適用する

初回スキャンで見つかった内容に驚くチームは少なくありません。AIを使って開発しているなら、すでにAIサプライチェーンが存在しているのが現実です。まだそれが見えていないだけかもしれません。

Snyk Open Sourceで脆弱性を検出できます。

Evo AI-SPMなら、システムを可視化し、セキュリティを確保できます。

まずはそこから始めましょう。