今週、複数のAIモデルへのリクエストをルーティングするために開発者が使用するオープンソースライブラリLiteLLMがサプライチェーン攻撃を受けた。LiteLLMのインシデント報告書とDatadogによる後の分析によると、悪意あるコードを含む2つのPyPIリリースが公開された。分析の結果、この不正な公開は、公式ソフトウェアアップデートの公開に使用される保守担当者アカウントが侵害されたことに起因する可能性が高く、3月初旬に開示されたより広範なTrivy侵害に関連している可能性があるという。
このLiteLLMのケースにおけるサイバー攻撃は、「サプライチェーン」攻撃の一例である。サプライチェーン攻撃とは、一人ひとりに毒を盛ろうとするのではなく、信頼された食品工場に毒を忍び込ませるようなものだ。工場を信頼していれば、自ら問題を内部に持ち込むことになる。
現代のソフトウェアは信頼の上に成り立っており、その多くは日常的だが機密性の高い作業を処理するオープンソースコードに置かれている。今回のケースでは、その信頼がチェーンの重要なポイントで崩れた。Pythonの主要パッケージリポジトリであるPyPIに悪意あるパッケージがアップロードされ、感染したシステムから環境変数、SSHキー、データベースパスワードなどの認証情報を検索するコードが仕込まれていた。
LLM脆弱性の影響範囲
LiteLLMは、Pythonエコシステムの忘れ去られた片隅に埋もれたニッチなアドオンではない。アプリケーションと大規模言語モデルの間のトラフィックレーンに位置しており、企業が最も失いたくない種類の認証情報、すなわちクラウドキー、APIトークン、データベース機密情報、アプリケーションパスワード、インフラストラクチャメタデータにアクセスできる。その位置にあるソフトウェアが汚染されると、影響範囲はそれをインストールしたチームをはるかに超えて広がる可能性がある。
LiteLLMの調査担当者は、侵害の原因を自社の開発パイプライン内で使用されているTrivy依存関係、つまりセキュリティスキャンワークフローにまで遡った。Trivyは、コンテナとコードの脆弱性をスキャンするための標準ツールである。今回のケースでは、ツール自体、またはその操作に関連する認証情報が侵害された。これにより、攻撃者は公式のビルドプロセスをバイパスし、悪意あるコードを直接PyPIリポジトリにアップロードすることができた。
LiteLLMライブラリの2つの特定バージョン、1.82.7と1.82.8が影響を受けた。これらのバージョンは、3月24日のおよそ6時間の間、ダウンロード可能な状態にあった。この間に特定のバージョンを指定、つまり「ピン留め」せずに標準的なインストールコマンドを実行した開発者は、感染したコードを取り込んだ。悪意あるペイロードは、静かな泥棒として機能するように設計されていた。システムをクラッシュさせたり、操作を停止させたりすることはなかった。代わりに、アプリケーションが実行されるのを待ち、その後メモリとファイルシステムをスキャンして高価値のターゲットを探した。
ターゲットには、AWS、Google Cloud、Azureの認証情報が含まれていた。これらのキーは、クラウドインフラストラクチャのマスタースイッチである。これらのキーを所有することで、攻撃者は高額なリソースを立ち上げたり、データを流出させたり、他の内部システムに移動したりすることができる。ペイロードはまた、Kubernetesトークンとデータベースパスワードも探していた。ミドルウェア層をターゲットにすることで、攻撃者は複数のダウンストリームアプリケーションからのトラフィックを傍受する位置に自らを置いた。このアプローチは、個々のアプリケーションを1つずつ攻撃するよりもはるかに効率的である。
財務的および運用上の影響は深刻である。攻撃者がクラウド認証情報にアクセスできれば、暗号資産マイニング操作を開始したり、高コストのAIインスタンスをプロビジョニングしたりすることで、クラウド予算を枯渇させることができる。さらに深刻なのは、データ盗難の可能性である。盗まれたAPIキーは、AIモデルによって処理される独自のトレーニングデータ、顧客情報、内部コミュニケーションへのアクセスを許可する可能性がある。
この攻撃は、2020年のSolarWindsインシデントを彷彿とさせる。SolarWindsでは、ソフトウェアアップデートが侵害され、政府および企業ネットワークに侵入するために使用された。どちらのケースでも、ソフトウェアベンダーに置かれた信頼が侵入ポイントとなった。ここでの違いは、スピードとAIエコシステムへの特定の焦点である。企業が生成AIの統合を急ぐ中、コストとモデルの互換性を管理するためにLiteLLMのようなライブラリに大きく依存している。この依存関係は、脅威アクターが悪用したがる単一障害点を生み出す。
AI依存関係の高いコスト
このインシデントからの影響は、ソフトウェアエンジニアリング実践における一般的な見落としを浮き彫りにしている。多くの開発者は、ソフトウェア依存関係にあまり注意を払わず、特定のバージョン番号を指定せずにライブラリをインストールしている。ピン留めされていない依存関係として知られるこの実践は、ソフトウェアパッケージマネージャーが利用可能な最新バージョンを自動的に取得することを許可する。ピン留めされていない依存関係とは、パッケージマネージャーに「すでにチェックしたバージョンXをください」ではなく「最新バージョンをください」と伝えることを意味する。これは、最新バージョンが望まないものになるまでは時間を節約する。これにより最新機能へのアクセスが保証される一方で、侵害されたアップデートへの扉も開かれる。
LiteLLMのケースでは、依存関係をバージョン1.82.6以前にピン留めしていた組織は安全だった。公式Dockerイメージを実行していた組織も保護されていた。なぜなら、イメージが要件をピン留めしていたからである。脆弱性は、攻撃期間中にシステムがPyPIから最新アップデートを取得することを許可していた組織にのみ存在した。この区別は、企業のセキュリティチームにとって重要である。これは、厳格な依存関係管理が単なるベストプラクティスではなく、サプライチェーン攻撃に対する必要な防御であることを示唆している。
AI分野は、その急速なイノベーションのペースのために特に脆弱である。企業はしばしば、厳格なサプライチェーン監査よりも市場投入のスピードを優先している。この急ぎは、セキュリティが時に後回しにされる環境を生み出す。LiteLLM侵害は、このアプローチの再評価を迫る。これは、ビルドインフラストラクチャが強化されていなければ、よく保守されたオープンソースプロジェクトでさえ侵害される可能性があることを示している。
AIエコシステム全体に広がるセキュリティの波紋
LiteLLM侵害の影響は、直接の被害者を超えて広がった。AI分野全体で、この侵害は広く使用されているインフラストラクチャコンポーネントの安全性について新たな疑念を引き起こした。LiteLLMはサプライチェーンを見直す間、新しいリリースを一時停止した。これは、その背後にあるツールが信頼できなくなると、継続的デリバリーがはるかに複雑になるという、より大きな問題を物語るステップである。
この分野の他の企業は、おそらく自社の依存関係の緊急監査を実施しているだろう。Trivyへの攻撃は、脅威アクターが開発者がソフトウェアを保護するために使用するツールをターゲットにしていることを示唆している。これは、セキュリティツール自体が侵害のベクターになるというパラドックスを生み出す。これは、ますます複雑になっているいたちごっこである。
このインシデントはまた、Pythonエコシステム全体のセキュリティ態勢についての疑問も提起する。PyPIはPythonパッケージの中心的なハブであり、ここでの侵害は膨大な数のプロジェクトに影響を与える。悪意あるパッケージの削除は迅速だったが、それらをインストールした人々にとっては、すでに被害が発生していた。現代のデプロイメントパイプラインのスピードは、人間が気づく前に侵害されたコードが本番環境に入る可能性があることを意味する。
AI分野における以前のインシデントとの比較は、洗練度が増している傾向を示している。以前の攻撃は、トレーニングデータを汚染したり、モデル出力を操作するためにプロンプトを注入したりすることに焦点を当てていた。この攻撃は、モデルをサポートするインフラストラクチャをターゲットにしている。これは、知能を攻撃することから配管を攻撃することへのシフトである。このシフトには、異なる防御策のセットが必要である。企業は今や、あらゆるサードパーティコードが侵害される可能性があると想定し、影響範囲を制限する戦略を実装しなければならない。
新しいセキュリティの現実をナビゲートする
バイブコーディングと「ハンズオフ」開発の時代において、優れたセキュリティ実践を維持することはますます困難になるだろう。企業は、サプライチェーンに対してゼロトラストアプローチを採用しなければならない。組織はまた、異常な動作を検出するためにランタイム監視を実装すべきである。LiteLLMのケースでは、悪意あるペイロードが外部サーバーにデータを流出させようとした。ネットワーク監視ツールは、この異常なトラフィックパターンにフラグを立てることができたはずである。行動分析は、静的コード分析をバイパスする攻撃を捕捉するための強力なツールである。
この侵害は、ほとんどのチームがソフトウェアがどのように組み立てられ、出荷されるかについて限られた可視性しか持っていないという問題にスポットライトを当てた。どのパッケージをインストールしたかを知るだけでは十分ではない。それがどこから来たのか、どのように構築されたのか、どの他のコンポーネントが一緒に来たのかを知る必要がある。そこで、ソフトウェア部品表、つまりSBOMのようなツールが有用になる。これらは、セキュリティチームにアプリケーション内に実際に何があるのか、そしてトラブルがどこに広がる可能性があるのかについて、より良いアイデアを与える。
LiteLLMの侵害は、AIブームの背後にあるソフトウェアが、テクノロジー業界の他の部分と同じ古い攻撃経路にさらされていることを思い出させるものである。企業がAIを日常業務により深く押し進めるにつれて、サポートインフラストラクチャのセキュリティはバックオフィスの問題ではなくなり、ビジネスリスクになる。予防はクリーンアップよりも安価であり、通常ははるかに痛みが少ない。業界にとって、今の真の課題は、新製品の出荷にもたらすのと同じ緊急性でセキュリティを扱うことができるかどうかである。
