LLM03:2025 サプライチェーン (Supply Chain)

説明

LLM サプライチェーンはさまざまな脆弱性の影響を受けやすく、トレーニングデータ、モデル、デプロイメントプラットフォームの完全性に影響を及ぼす可能性があります。これらのリスクは偏った出力、セキュリティ侵害、システム障害を引き起こす可能性があります。従来のソフトウェアの脆弱性はコードの欠陥や依存関係などの問題に焦点を当てていますが、ML ではリスクはサードパティの事前トレーニング済みモデルやデータにも及びます。

これらの外部要素は改竄やポイズニング攻撃によって操作される可能性があります。

LLM の作成は専門的なタスクであり、多くの場合、サードパーティモデルに依存します。オープンアクセス LLM の台頭や、"LoRA" (Low-Rank Adaptation) や "PEFT" (Parameter-Efficient Fine-Tuning) などの新しいファインチューニング手法により、特に Hugging Face などのプラットフォーム上で、新たなサプライチェーンリスクをもたらします。最後に、オンデバイス LLM の出現により、LLM アプリケーションの攻撃対象領域とサプライチェーンリスクが増加します。

ここで説明されているリスクの一部は「LLM04 データおよびモデルポイズニング」でも説明されています。このエントリでは、リスクのサプライチェーンの側面に焦点を当てています。 簡単な脅威モデルは こちら にあります。

リスクの一般的な例

1. 従来のサードパーティパッケージの脆弱性

古くなったコンポーネントや非推奨のコンポーネントなどは、攻撃者が悪用して、LLM アプリケーションを侵害できます。これは "A06:2021 – Vulnerable and Outdated Components" に似ていますが、コンポーネントがモデルの開発時やファインチューニング時に使用されるとリスクが高まります。 (参照リンク: A06:2021 – Vulnerable and Outdated Components)

2. ライセンスのリスク

AI 開発にはさまざまなソフトウェアやデータセットのライセンスが関係することがよくあり、適切に管理しないとリスクが生じます。さまざまなオープンソースライセンスとプロプライエタリライセンスはそれぞれ異なる法的要件を課します。データセットライセンスは使用、配布、商利用を制限することがあります。

3. 古くなったモデルや非推奨のモデル

もはやメンテナンスされていない古くなったモデルや非推奨のモデルを使用すると、セキュリティ問題につながります。

4. 脆弱な事前トレーニング済みモデル

モデルはバイナリブラックボックスであり、オープンソースとは異なり、静的検査ではセキュリティの保証がほとんどできません。脆弱な事前トレーニング済みモデルには、モデルリポジトリの安全性評価では特定されていない隠されたバイアス、バックドア、その他の悪意のある機能を含む可能性があります。脆弱なモデルは、汚染されたデータセットと、ロボトミーとも呼ばれる ROME などの技法を使用した直接的なモデル改竄の両方によって作成される可能性があります。

5. 弱いモデル来歴

現在のところ、公開されているモデルには強力な来歴保証がありません。モデルカードと関連ドキュメントはモデル情報を提供し、ユーザーを信頼させますが、モデルの起源についての保証はありません。攻撃者は、モデルリポジトリのサプライヤアカウントを侵害したり、同様のアカウントを作成してソーシャルエンジニアリング技法と組み合わせて、LLM アプリケーションのサプライチェーンを侵害できます。

6. 脆弱な LoRA アダプタ

LoRA は一般的なファインチューニング技法であり、事前トレーニング済みレイヤを既存の LLM にボルト固定することでモジュール性を高めます。この手法は効率性を高めますが、悪意のある LoRA アダプタが事前トレーニング済みのベースモデルの完全性とセキュリティを損なうという新たなリスクを生み出します。これは、共同モデルマージ環境だけでなく、アダプタをダウンロードしてデプロイ済みモデルに適用できる vLMM や OpenLLM などの一般的な推論デプロイメントプラットフォームから LoRA のサポートを悪用する場合にも発生する可能性があります。

7. 共同開発プロセスの悪用

共有環境でホストされている共同モデルマージおよびモデル処理サービス (変換など) は、共有モデルの脆弱性をもたらすために悪用される可能性があります。 モデルマージは Hugging Face で非常に人気があり、モデルマージされたモデルは OpenLLM リーダーボードの上位を占めており、レビューをバイパスするために悪用される可能性があります。 同様に、会話ボットなどのサービスは操作に対して脆弱であり、モデルに悪意のあるコードをもたらすことが証明されています。

8. デバイス上の LLM モデルのサプライチェーンの脆弱性

デバイス上の LLM モデルは、侵害された製造プロセスや、デバイス OS やファームウェアの脆弱性を悪用してモデルを侵害することで、サプライ攻撃対象領域を拡大します。攻撃者が改竄されたモデルでアプリケーションをリバースエンジニアして再パッケージ化できます。

9. 不明確な利用規約とデータプライバシーポリシー

モデル運営者の利用規約とデータプライバシーポリシーが不明確であると、アプリケーションの機密データがモデルのトレーニングに使用され、その後、機密情報の暴露につながります。これは、モデル供給者が著作権で保護された素材を使用することによるリスクにも当てはまる可能性があります。

予防および緩和戦略

  1. 信頼できるサプライヤのみを使用して、利用規約やプライバシーポリシーを含む、データソースとサプライヤを慎重に審査します。サプライヤのセキュリティとアクセスを定期的にレビューおよび監査して、セキュリティ態勢や利用規約に変更がないことを確認します。

  2. OWASP Top Ten の "A06:2021 – Vulnerable and Outdated Components" に記載されている緩和策を理解して適用します。これは、脆弱性スキャン、管理、パッチ適用コンポーネントを含みます。機密データにアクセスできる開発環境では、その環境にもこれらのコントロールを適用します。 (参照リンク: A06:2021 – Vulnerable and Outdated Components)

  3. サードパーティのモデルを選択する際には、包括的な AI レッドチームと評価を適用します。Decoding Trust は LLM のための信頼できる AI ベンチマークの一例ですが、モデルは公表されているベンチマークをパスするようにファインチューニングできます。特にモデルを使用する予定のユースケースにおいて、広範な AI レッドチームを使用してモデルを評価します。

  4. ソフトウェア部品表 (Software Bill of Materials, SBOM) を使用してコンポーネントの最新インベントリを維持し、最新で正確な署名付きインベントリを確保して、デプロイされたパッケージの改竄を防止します。SBOM を使用して、新しいゼロデイの脆弱性を迅速に検出して警告できます。AI BOM と ML SBOM は新しい分野であり、OWASP CycloneDX を始めとするオプションを評価すべきです。

  5. AI ライセンスのリスクを緩和するには、BOM を使用して関連するすべての種類のライセンスのインベントリを作成し、すべてのソフトウェア、ツール、データセットの定期的な監査を実施して、BOM を通じてコンプライアンスと透明性を確保します。自動ライセンス管理ツールを使用してリアルタイムに監視し、ライセンスモデルについてチームをトレーニングします。BOM で詳細なライセンスドキュメントを維持し、Dyana などのツールを活用してサードパーティソフトウェアの動的解析を実行します。

  6. 検証可能なソースからのモデルのみを使用し、署名とファイルハッシュによるサードパーティのモデル完全性チェックを使用して、強力なモデルの来歴の欠如を補います。同様に、外部から提供されるコードにはコード署名を使用します。

  7. 共同モデル開発環境に対して厳格な監視と監査を実施し、不正使用を防止して迅速に検出します。"HuggingFace SF_Convertbot Scanner" は、使用する自動スクリプトの一例です。 (参照リンク: HuggingFace SF_Convertbot Scanner)

  8. 提供されたモデルとデータに対する異常検出と敵対的堅牢性テストは、「LLM04 データおよびモデルポイズニング」で説明されているように改竄とポイズニングの検出に役立ちます。理想的には、これは MLOps と LLM パイプラインの一部であるべきですが、これらは新しい技法であり、レッドチーム演習の一部として実装する方が簡単かもしれません。

  9. パッチ適用ポリシーを実装して、脆弱なコンポーネントや古くなったコンポーネントを緩和します。アプリケーションが、保守されているバージョンの API と基盤モデルに依存していることを確保します。

  10. AI エッジにデプロイされたモデルを完全性チェックで暗号化し、ベンダー認証 API を使用してアプリやモデルの改竄を防ぎ、認識できないファームウェアのアプリケーションを終了します。

攻撃シナリオの例

シナリオ #1: 脆弱な Python ライブラリ

攻撃者は脆弱な Python ライブラリを悪用して LLM アプリを侵害します。これは最初の Open AI データ侵害で起きました。PyPi パッケージレジストリに対する攻撃は、モデル開発環境にマルウェアを含む侵害された PyTorch 依存関係をダウンロードするようにモデル開発者を仕向けました。この種の攻撃のより巧妙な例としては、多くのベンダーが AI インフラストラクチャを管理するために使用している Ray AI フレームワークに対する Shadow Ray 攻撃があります。この攻撃では、五つの脆弱性が悪用されて、多くのサーバーに影響を及ぼしたと考えられています。

シナリオ #2: 直接改竄

直接改竄して、誤った情報を拡散するモデルを公開します。これは、PoisonGPT がモデルのパラメータを直接変更することで Hugging Face の安全機能をバイパスする実際の攻撃です。

シナリオ #3: 人気モデルのファインチューニング

攻撃者は人気のオープンアクセスモデルをファインチューンして、主要な安全機能を削除し、特定のドメイン (保険) で高いパフォーマンスを発揮します。このモデルは安全性ベンチマークで高いスコアを獲得するようにファインチューンされていますが、非常にターゲットを絞ったトリガーがあります。攻撃者はそれを Hugging Face にデプロイして、ベンチマーク保証に対する信頼を悪用し、被害者が使用してしまいます。

シナリオ #4: 事前学習済みモデル

LLM システムは徹底的な検証を行うことなく、広く使用されているリポジトリから事前学習済みモデルをデプロイします。侵害されたモデルは悪意のあるコードを導入し、特定のコンテキストで偏った出力を引き起こし、有害な結果や操作された結果につながります。

シナリオ #5: 侵害されたサードパーティサプライヤ

侵害されたサードパーティサプライヤは、Hugging Face のモデルマージを使用して LLM にマージされている、脆弱な LoRA アダプタを提供します。

シナリオ #6: サプライヤへの侵入

攻撃者はサードパーティサプライヤに侵入し、vLLM や OpenLLM などのフレームワークを使用してデプロイされたオンデバイス LLM との統合を目的とした LoRA (Low-Rank Adaptation) アダプタの製造を侵害します。侵害された LoRA アダプタは、隠れた脆弱性と悪意のあるコードを含むように微妙に変更されています。このアダプタが LLM とマージされると、攻撃者にシステムへの秘密のエントリポイントを提供します。悪意のあるコードはモデル動作中にアクティブになる可能性があり、攻撃者は LLM の出力を操作できるようになります。

シナリオ #7: CloudBorne 攻撃と CloudJacking 攻撃

これらの攻撃はクラウドインフラストラクチャをターゲットとして、共有リソースと仮想レイヤの脆弱性を活用します。CloudBorne は共有クラウド環境のファームウェアの脆弱性を悪用し、仮想インスタンスをホストする物理サーバーを侵害します。CloudJacking はクラウドインスタンスの悪意のある制御や悪用を指し、重要な LLM デプロイメントプラットフォームへの不正アクセスにつながる可能性があります。どちらの攻撃もクラウドベースの ML モデルに依存するサプライチェーンにとっては重大なリスクとなり、侵害された環境が機密データを開示したり、さらなる攻撃を容易にする可能性があります。

シナリオ #8: LeftOvers (CVE-2023-4969)

LeftOvers は漏洩した GPU ローカルメモリを悪用して機密データを復元します。攻撃者はこの攻撃を使用して、本番サーバーや開発ワークステーション、ラップトップ内の機密データを盗み出すことができます。

シナリオ #9: WizardLM

WizardLM の削除後、攻撃者はこのモデルへの関心を悪用し、同じ名前でマルウェアやバックドアを含むモデルの偽バージョンを公開します。

シナリオ #10: モデルマージ/フォーマット変換サービス

攻撃者はモデルマージまたはフォーマット変換サービスで攻撃を仕掛け、一般に公開されているアクセスモデルを侵害してマルウェアを注入します。これはベンダーである HiddenLayer によって公開された実際の攻撃です。

シナリオ #11: モバイルアプリのリバースエンジニアリング

攻撃者はモバイルアプリをリバースエンジニアして、モデルを改竄されたバージョンに置き換え、ユーザーを詐欺サイトに誘導します。ユーザーはソーシャルエンジニアリング技法を介して直接アプリをダウンロードするよう促されます。これは「予測 AI に対する実際の攻撃」であり、現金認識、ペアレンタルコントロール、顔認証、金融サービスなどに使用される人気のセキュリティおよびセーフティクリティカルなアプリケーションを含む 116 の Google Play アプリに影響を与えました。 (参照リンク: real attack on predictive AI)

シナリオ #12: データセットポイズニング

攻撃者は一般に公開されているデータセットを改竄して、モデルをファインチューンする際にバックドアを作成します。バックドアはさまざまな市場の特定の企業を微妙に優遇します。

シナリオ #13: 利用規約とプライバシーポリシー

LLM 事業者は利用規約とプライバシーポリシーを変更して、モデルトレーニングにアプリケーションデータを使用することから明示的にオプトアウトすることを要求し、機密データが記憶されることになります。

参考情報リンク

関連するフレームワークと分類

インフラストラクチャデプロイメント、適用される環境制御、その他のベストプラクティスに関する包括的な情報、シナリオ戦略については、このセクションを参照してください。

Last updated