AIツールのサプライチェーン攻撃とは｜LiteLLM事件に学ぶ企業のセキュリティ防衛策
「自社で使っているAIライブラリが、ある日突然マルウェアに変わる」——そう言われてもピンとこないかもしれません。しかし2026年3月、まさにその事態が現実に起こりました。AIプロキシツールとして月間数百万回ダウンロードされるLiteLLMが攻撃者に侵害され、悪意のあるコードが正規パッケージとして配布されたのです。
この事件は、AI活用を進める企業にとって対岸の火事ではありません。本記事では、LiteLLM事件の全容を解説した上で、中小企業がAIツールを安全に導入・運用するための具体的な防衛策を紹介します。DX推進とセキュリティの両立を目指すすべてのビジネスパーソンに読んでいただきたい内容です。
サプライチェーン攻撃とは — なぜAIツールが狙われるのか
サプライチェーン攻撃とは、ソフトウェアの開発・配布プロセスそのものに侵入し、正規のアップデートやライブラリに悪意のあるコードを仕込む攻撃手法です。通常のサイバー攻撃はターゲット企業のシステムを直接狙いますが、サプライチェーン攻撃はその企業が「信頼して使っている」ツールやライブラリを経由して侵入します。
この攻撃手法が特に厄介なのは、被害者が自ら脅威を招き入れてしまうという点にあります。普段使い慣れたツールをアップデートしただけ、あるいは新しいパッケージをインストールしただけで、マルウェアに感染する可能性があるのです。利用者は正規のソフトウェアを使っている認識なので、異変に気づくまでに時間がかかるケースが多くなります。
AIツールが狙われやすい3つの理由
近年、AIツールやライブラリがサプライチェーン攻撃の標的として集中的に狙われています。その背景には、以下の3つの構造的な理由があります。
- 急速な普及と依存度の高さ：生成AIブームを背景に、LiteLLMのようなAI関連ライブラリは短期間で爆発的にダウンロード数が伸びています。1つのライブラリを侵害するだけで、何百万もの開発者・企業に一斉にマルウェアを配布できるため、攻撃者にとって費用対効果が非常に高いのです
- 複雑な依存関係：AIツールは多数のオープンソースライブラリに依存しています。依存関係の「深さ」を把握しきれていない組織が多く、間接的に利用しているライブラリが侵害されても気づけないリスクがあります
- 機密情報へのアクセス：AIツールはAPIキー、クラウドトークン、データベースの認証情報など、高い権限を持つ機密情報にアクセスするケースが多く、攻撃者にとって「宝の山」となっています
LiteLLM攻撃の全容 — 月間数百万DLのライブラリが侵害された手口
2026年3月に発覚したLiteLLMへのサプライチェーン攻撃は、その巧妙さと影響範囲の広さから、セキュリティ業界に大きな衝撃を与えました。事件の全容を時系列で整理します。
攻撃の起点：セキュリティスキャナーTrivyの侵害
攻撃の起点は、LiteLLM自体ではなく、Trivyというオープンソースのセキュリティスキャナーでした。TrivyはAqua Security社が開発するコンテナ脆弱性スキャンツールで、多くのCI/CDパイプラインに組み込まれています。
攻撃者グループTeamPCPは、2026年3月19日にTrivyのGitHub Actionリポジトリに侵入し、Gitタグを書き換えて悪意のあるバージョン（v0.69.4）を正規リリースに偽装しました。このTrivyはLiteLLMのCI/CDパイプラインでセキュリティチェックに使われていたため、そこからLiteLLMの開発環境への侵入が可能になったのです。
LiteLLMへの侵害：認証情報の窃取と横展開
Trivyの侵害を足がかりに、TeamPCPはLiteLLMのメンテナーのPyPI（Python Package Index）認証情報を窃取しました。これを使い、2026年3月24日にLiteLLMのバージョン1.82.7と1.82.8を、バックドア入りのパッケージとしてPyPIに公開しました。
この悪意あるパッケージに仕込まれたペイロードは、3段階の攻撃を実行する設計でした。
- 認証情報の収集：SSHキー、クラウドサービスのトークン、Kubernetesのシークレット、暗号資産ウォレット、.envファイルなど、システム上のあらゆる機密情報を探索・収集する
- 横展開：Kubernetes環境では特権ポッドを全ノードにデプロイし、クラスター全体に侵害を拡大する
- 永続化：systemdバックドアをインストールし、攻撃者のサーバーから追加のバイナリを取得できる状態を維持する
影響範囲と対応
LiteLLMは1日あたり約340万回ダウンロードされており、クラウドセキュリティ企業Wizの調査によると、全クラウド環境の約36%にLiteLLMが存在するとされています。悪意あるバージョンは公開から約3時間でPyPIにより隔離されましたが、その短時間の間にインストールした企業や開発者への影響が懸念されています。
セキュリティ各社は、該当バージョンをインストールした可能性がある場合、すべての認証情報（APIキー、SSHキー、クラウドトークンなど）を直ちにローテーション（変更）することを強く推奨しています。
中小企業にとってのリスク — 「うちは関係ない」が一番危険
「うちはAIの開発なんてしていないから関係ない」——そう思った方もいるかもしれません。しかし、サプライチェーン攻撃のリスクはAI開発企業だけの問題ではありません。
AIツールを「使っている」だけで対象になる
現在、多くの企業がSaaS型のAIツールを業務に導入しています。チャットボット、文章生成、データ分析、翻訳など、AIを活用したサービスの内部では、LiteLLMのようなライブラリが基盤として使われているケースが少なくありません。
つまり、自社で直接AIライブラリを使っていなくても、利用しているSaaS製品やクラウドサービスがそのライブラリに依存していれば、間接的に被害を受ける可能性があるのです。自社の契約しているツールの裏側で何が動いているかを把握していない限り、「自分には関係ない」とは言い切れません。
中小企業ほどダメージが大きい理由
大企業にはセキュリティ専門チームや24時間監視体制がありますが、中小企業ではそうした体制が整っていないことが一般的です。以下の理由から、中小企業ほどサプライチェーン攻撃のダメージが深刻化しやすい傾向があります。
- 検知の遅れ：セキュリティ専任者がいないため、異常に気づくまでに時間がかかる
- 復旧リソースの不足：認証情報の一斉変更やシステム再構築に割ける人員・予算が限られている
- 事業継続への直結：顧客データの漏洩やシステム停止が、直接的な売上減少・信用失墜につながる
- サプライチェーン全体への波及：取引先のシステムと連携している場合、自社の被害が取引先にも飛び火する
LiteLLM事件は「わずか3時間」で隔離されましたが、その3時間の間に自動アップデートが走っていた場合、被害はすでに発生しています。自動化の恩恵を受けている裏側で、自動化がリスクを増幅させるという構図を理解しておく必要があります。
AIツール導入時のセキュリティ防衛策5選
ここからは、中小企業でも実行可能な具体的なセキュリティ防衛策を5つ紹介します。すべてを一度に導入する必要はありませんが、優先度の高いものから段階的に取り入れてください。
1. 依存パッケージのバージョン固定とロックファイルの活用
最も基本的かつ効果の高い対策が、利用するライブラリのバージョンを固定することです。Pythonであればrequirements.txtでバージョンを厳密に指定し、Node.jsであればpackage-lock.jsonをリポジトリに含めます。
バージョン範囲指定（例：litellm>=1.82.0）を使っていると、最新バージョンが自動的にインストールされるため、悪意あるバージョンが公開された瞬間に被害に遭うリスクがあります。完全一致指定（例：litellm==1.82.6）にすることで、意図しないバージョンがインストールされることを防げます。
新しいバージョンへの更新は、リリースノートとコミット履歴を確認した上で、テスト環境で検証してから本番に適用する運用を徹底しましょう。
2. 脆弱性スキャンツールの導入
プロジェクトが依存しているライブラリに既知の脆弱性や侵害報告がないかを自動的に検査する仕組みを導入しましょう。代表的なツールには以下があります。
- GitHub Dependabot：GitHubリポジトリの依存パッケージを自動監視し、脆弱性が発見されるとプルリクエストで通知・修正を提案する
- Snyk：オープンソースの脆弱性データベースと照合し、リアルタイムでセキュリティリスクを検出する
- pip-audit（Python向け）：Pythonパッケージの脆弱性をコマンドラインから検査できるツール
これらのツールは無料プランでも基本的な機能を利用でき、設定の手間も最小限です。GitHub Dependabotであればリポジトリの設定画面から数クリックで有効化できます。
3. SBOM（ソフトウェア部品表）の作成
SBOM（Software Bill of Materials）とは、ソフトウェアに含まれる全コンポーネントの一覧表です。自社のプロジェクトがどのライブラリに依存しているかを可視化することで、侵害が発覚した際に「自社が影響を受けるかどうか」を即座に判断できます。
2026年3月のNSA（米国国家安全保障局）によるガイダンスでも、AI導入時にはSBOMの作成と管理が強く推奨されています。すべての依存関係を洗い出し、直接的な依存だけでなく間接的な依存（依存の依存）も含めて把握することが重要です。
4. CI/CDパイプラインのセキュリティ強化
LiteLLM事件では、CI/CDパイプラインに組み込まれたTrivyのGitHub Actionが攻撃の起点となりました。この教訓を踏まえ、以下の対策を検討してください。
- GitHub Actionのバージョンをコミットハッシュで固定する：タグ指定（例：
@v2）だとタグの書き換えで偽装される可能性がある。コミットハッシュ（例：@abc123...）で固定すれば、この攻撃を防げる - ビルド環境のネットワークアクセスを制限する：ビルド中に外部サーバーへデータを送信する通信をブロックすることで、認証情報の外部流出を防ぐ
- シークレットの最小権限化：CI/CDで使用するトークンやAPIキーの権限を、必要最小限に絞る
5. 認証情報の定期ローテーションと分離管理
万が一サプライチェーン攻撃を受けた場合に被害を最小化するための「ダメージコントロール」策です。
- APIキーやトークンを定期的にローテーション（変更）する：窃取された認証情報の有効期限を短くすることで、攻撃者が利用できる時間を制限する
- .envファイルや認証情報をリポジトリに含めない：シークレット管理サービス（AWS Secrets Manager、HashiCorp Vaultなど）を活用する
- 本番環境と開発環境で認証情報を分離する：開発環境が侵害されても本番データへのアクセスを防ぐ
LiteLLM事件でセキュリティ各社が「全認証情報の即時ローテーション」を推奨したように、日頃からローテーションの手順を整備しておくことが、有事の際の対応スピードを大きく左右します。
よくある質問（FAQ）
Q. サプライチェーン攻撃は自社で検知できますか？
完全な検知は困難ですが、脆弱性スキャンツールの導入やSBOMの管理、CI/CDパイプラインでのセキュリティチェックを組み合わせることで検知の確率を大幅に高められます。GitHub DependabotやSnykのような無料ツールでも、既知の侵害パッケージへのアラートを受け取ることが可能です。異常な通信やプロセスを検知するためのランタイム監視も有効です。
Q. オープンソースのAIライブラリは使わないほうがいいですか？
オープンソースを一律に避ける必要はありません。むしろ、オープンソースはコードが公開されているため、クローズドなソフトウェアよりも問題発見が早いというメリットがあります。実際、LiteLLMの事件も公開から約3時間で検知・隔離されました。重要なのは、オープンソースを使う際のリスク管理体制を整えることです。
Q. SaaSサービスを使っている場合、自社で対策は必要ですか？
SaaSの場合、ライブラリの管理はサービス提供者の責任範囲ですが、自社でも契約先のセキュリティ対策状況を確認することが重要です。SBOMの提供を求める、インシデント対応体制や脆弱性管理プロセスを確認する、データの暗号化やアクセスログの提供状況を把握する——こうした確認を契約時に行うことで、リスクを低減できます。
Q. 社内にエンジニアがいない場合はどうすればいいですか？
エンジニアがいなくても、以下の対策は実施可能です。（1）利用しているSaaS/ツールのセキュリティ情報メールを購読する、（2）パスワードやAPIキーの定期変更ルールを設ける、（3）セキュリティ診断サービスを年1回以上利用する。より高度な対策については、外部のセキュリティ専門家やDX支援サービスへの相談を検討してください。
まとめ
2026年3月のLiteLLM事件は、AIツールのサプライチェーン攻撃が「理論上のリスク」ではなく「現実の脅威」であることを明確に示しました。本記事の要点を整理します。
- サプライチェーン攻撃は、信頼されたソフトウェアの更新やライブラリを経由してマルウェアを配布する攻撃手法
- LiteLLM事件では、セキュリティスキャナーTrivyの侵害を起点に、月間数百万DLのAIライブラリにバックドアが仕込まれた
- AIツールを「使っている」だけの企業も間接的な被害を受ける可能性があり、中小企業ほどダメージが深刻化しやすい
- 防衛策として、バージョン固定、脆弱性スキャン、SBOM作成、CI/CDセキュリティ強化、認証情報のローテーションが有効
- 「うちは関係ない」という認識が最大のセキュリティリスク。まずは自社のAIツール利用状況の棚卸しから始めることが重要
DXの推進とセキュリティの確保は、トレードオフではなく両立すべきものです。AIツールの恩恵を最大限に活かしながら、リスクを適切にコントロールする体制を構築していきましょう。
株式会社Sei San SeiのBPaaS（業務自動化）サービスでは、セキュリティを考慮したAIツール選定・導入設計を支援しています。業務自動化に興味はあるが、セキュリティ面が不安だという方は、BPaaSサービスの詳細ページをご覧ください。お気軽にご相談ください。