現実となったAIサプライチェーン攻撃：自動車OEMが今知っておくべきこと

このブログのポイント： AIサプライチェーン攻撃は、開発者がAIツールに対して無意識のうちに寄せている信頼を悪用します。改ざんされたパッケージを通じて認証情報を盗み出し、クラウド環境内で侵害を横展開し、永続的な足がかりを大規模に築きます。自動車OEMやTier-1サプライヤーにとって、このリスクはSDV（ソフトウェア定義車両）の開発を支えるパイプラインへと直接及びます。2026年に発生したLiteLLMの侵害は、攻撃グループTeamPCPによるものとされ、Wiz Researchによる調査ではクラウド環境の36%で確認されました。一つのバックドア入りパッケージが、エコシステム全体へ連鎖的に影響を及ぼし得ることを示した事例です。AI開発ツールの依存パッケージも攻撃者の標的となる今、基幹インフラと同様にセキュリティ管理の対象として扱うことが求められています。

AIサプライチェーン攻撃は新たな攻撃対象領域（アタックサーフェス）として広がりつつあり、多くのセキュリティチームが防御の備えを十分に整えられていない領域でもあります。AIを活用した開発ツールが急速に普及したことで、依存関係は複雑に絡み合った広大なネットワークを形成し、たった一つのパッケージが侵害されるだけで、何百万ものシステムに気づかれないままバックドアが仕込まれかねない状況が生まれています。

企業向けソフトウェアを狙う従来型のサプライチェーン攻撃とは異なり、AIサプライチェーン攻撃はこの分野ならではの力学につけ込みます。開発者はAIツールを無条件に信頼し、広範な権限を与えたままクラウドネイティブ環境に展開し、頻繁に更新します。その際、基幹インフラに対して払うような厳しい検証を経ないことも少なくありません。

リスクにさらされる範囲は広大です。 トレンドマイクロ の推計によると、LiteLLMは1日あたり340万回ダウンロードされるほど広く使われていたツールで、侵害を受けた際には、悪意あるバージョンも検知されるまでに4万回以上インストールされていました。Wiz Research の調査では、2026年初頭に調査したクラウド環境の36%でこの侵害されたパッケージが確認されています。攻撃者がこれほどの規模でパッケージにバックドアを仕込むと、被害は一つの組織にとどまりません。エコシステム全体にわたって、永続的な足がかりが築かれることになります。

LiteLLMへのサプライチェーン攻撃の手口

AIサプライチェーン攻撃が実際にどのように展開するのかを理解するため、VicOneの自動車サイバー脅威リサーチラボはTeamPCPによる攻撃キャンペーンを詳しく分析しました。一つの侵害されたコンポーネントが、複数の段階に構造化された攻撃チェーンを通じて、クラウド環境全体へ大規模に連鎖していく様子がここから読み取れます。

2026年初頭、セキュリティ研究者の間でTeamPCPと呼ばれている攻撃グループによるものとされる高度な攻撃を、 Snyk と Wiz の研究者がそれぞれ独自に発見しました。この攻撃はたった一つの侵害された依存パッケージを起点に、開発環境から本番システムまで広範囲にわたる認証情報の窃取へと拡大していきました。

ステージ1：信頼されたCI/CDアクションの乗っ取り

TeamPCPはまず、CI/CDパイプラインに組み込まれて広く使われているセキュリティスキャンツール、 aquasecurity/trivy-action （GitHub Action）を侵害しました。攻撃者の管理下にあるコードを指す悪意あるタグを送り込むことで、開発者のワークフローからPyPIのAPIトークンを盗み出します。この一手によって、正規のメンテナーになりすましてパッケージを公開できる状態を手に入れました。

ステージ2：汚染されたパッケージの公開

TeamPCPは盗み出したPyPIトークンを使い、 litellm （バージョン1.82.7および1.82.8）の悪意あるバージョンを公開し、もう一つのクラウドセキュリティツールである kicsも標的にしました。これらのパッケージは、正規版とまったく同じ機能を保ったままでした。バックドアは .pth ファイルに隠されていました。.pthファイルはPythonのパス設定を担う仕組みで、インタープリタの起動時に任意のコードを実行します（MITRE ATT&CK T1546.018）。この手法は仮想環境を作り直しても残り続け、通常の pip list の出力には現れずアプリケーションのコードが動き出す前に実行されるため、とりわけ気づかれにくいものです。

ステージ3：検知されにくい永続的な情報窃取

埋め込まれたインプラントは、インストールされると models.litellm.cloudとの間で暗号化されたコマンド&コントロール（C2）通信を確立しました。このドメインは、正規のLiteLLMインフラに紛れ込むよう意図的に名付けられたものです。インプラントはAPIキー、クラウドの認証情報、各種シークレットを含む環境変数を収集し、AES-256とRSAで暗号化したうえで攻撃者の管理下にあるインフラへ送信しました。

インプラントにはコンテナ化された環境間を横方向に移動できるKubernetesワームの機能も組み込まれており、当初侵害されたワークロードの範囲をはるかに超えて被害が及ぶ範囲を拡大させました。

LiteLLMはGitHubのissue #24512でこのインシデントを認め、バージョン1.82.7と1.82.8の使用を避けるよう注意を促すとともに、すべての利用者に対して認証情報を直ちに更新するよう呼びかけました。

LiteLLMは特殊なケースではない

LiteLLMは特殊なケースではありません。攻撃者がAI開発のエコシステムを狙う動きがより広い範囲で加速していることの表れです。VicOneの2026年 自動車サイバーセキュリティレポート Crossroadsによると、2025年には自動車業界全体で610件のサイバーインシデントが報告され、そのうち161件（26%）が複数の子会社にまたがる「グローバルインシデント」へと発展しました。この発生率は2024年から3倍以上に増えています。次に挙げる攻撃活動を見ると、AIサプライチェーン攻撃の手口が、パッケージ、パイプライン、そして新たに広がりつつあるAIのワークフローにわたってすでに形になりつつあることが分かります。

これらの攻撃活動に共通するのは： いずれも開発者がAIツールのエコシステムに無意識のうちに寄せている信頼を悪用している点です。狙われる対象は、パッケージレジストリ、CI/CDアクション、エージェントのマーケットプレイス、AIコーディングアシスタントとさまざまです。攻撃対象領域は、多くのセキュリティチームが対策を整える速さを上回って拡大しています。

トレンドマイクロとCycodeの研究者は、TeamPCPの調査を踏まえて「TeamPCPが仕組んだ連鎖型の攻撃は、開発ツールに潜む脆弱性とセキュリティ対策を強化する必要性を浮き彫りにしている」と述べています。

AIサプライチェーン攻撃が大きなリスクをもたらす4つの構造的特性

AIサプライチェーン攻撃がもたらすリスクは、従来のソフトウェアの依存関係の範囲を超えています。そのリスクは、AI開発ツールの使われ方に潜む4つの構造的な特性によって増幅されます。

信頼の増幅

開発者やセキュリティチームは、AIツールを初めから信頼できるものとして扱いがちです。LiteLLMやLangChainといったライブラリが採用されるのは、まさにモデルのルーティング、APIキーの管理、クラウドとの連携など、複雑で中核的な処理を担っているからです。この層が侵害されると、追加で権限を昇格させる必要もないまま組織のAI基盤の中でも最も重要度の高い領域に直接アクセスされてしまいます。

過大な権限を持つ実行環境

AIのワークロードは通常、広範なIAM（Identity and Access Management：IDとアクセスの管理）権限、広いネットワークアクセス、そして多くの場合は強い権限を持つサービスアカウントを備えたクラウドネイティブ環境に展開されます。Kubernetesのポッド上で動く侵害されたAIパッケージは、クラスターのシークレット、クラウドプロバイダーのAPI、内部サービスにまでアクセスできることがあります。いずれも、従来のデスクトップアプリケーションには決して開かれることのない領域です。AIのワークロードは、もともとこうした強い権限を前提に動作するよう設計されており、設定ミスによって生じている状態ではありません。

更新の速さとエコシステムの変化の激しさ

AIツールのエコシステムは急速に進化します。新しいモデルのリリース、各種連携、性能の向上にともなって更新が頻繁に行われ、新しいバージョンを早く取り入れなければというプレッシャーが生まれます。この更新の速さがあるために依存パッケージのバージョンを固定しておくことが難しくなり、攻撃者は悪意あるバージョンを検知される前に公開し、また引っ込めやすくなります。TeamPCPの攻撃はまさにこの隙を突いたものでした。

気づかれにくい永続化の手口

Pythonの .pth ファイルを悪用する手口を使うと、通常の依存関係の一覧には現れないままインタープリタの起動時にコードを実行できます。この永続化の仕組みは仮想環境を作り直しても残り続け、 pip listにも表示されずアプリケーションのコードが動き出す前に実行されます。多くのエンドポイント検知ソリューションは .pth ファイルを監視していないため、この経路は一般的なセキュリティツールではほとんど検知されないまま残ります。

重要なポイント： AIツールは、高い展開密度、強い権限でのクラウドアクセス、そして開発者が無意識に寄せる信頼が重なり合うことで、大規模な認証情報の窃取と永続的なアクセスを実現する格好の経路になります。その被害が及ぶ範囲は、一般的なソフトウェアの脆弱性をはるかに上回ります。

自動車OEMがとりわけ大きなリスクを抱える3つの要因

OEMやTier-1サプライヤーにとってAIサプライチェーン攻撃は、SDVを支える開発パイプライン、サプライヤーのエコシステム、クラウドサービスを直接おびやかす脅威です。一般的なソフトウェアセキュリティの問題がたまたま周辺的に影響してくる、という程度の話ではありません。

VicOneの調査では、この脅威を自動車業界にとってとりわけ重大なものにしている、自動車ならではの3つの増幅要因を特定しています。

サプライヤーの階層間にある脆弱性の差

自動車のサプライチェーンは多層にわたり、各社が密接に依存し合っています。サイバーセキュリティの導入状況は階層によって大きく異なります。Perforceの調査によると、OEMとTier-1サプライヤーではロボティクスや自動化の導入率が51〜62%に達する一方、Tier-2やTier-3のサプライヤーでは23〜31%にとどまっています。ツールの成熟度に見られるこの差は、下位の階層ほどセキュリティ対策が弱いという状況に直結しています。過去のインシデントデータも、そのリスクの大きさを裏づけています。2022年初頭に自動車業界で発生したサイバーインシデントのうち67.3%は、サプライヤーを標的としたものだったと、Automotive Logisticsは報告しています。Tier-2サプライヤーで侵害されたAIの依存パッケージは、OEM側で何の警告も出ないまま、上流のOEMの生産ワークフローへと波及していくおそれがあります。

Tier-1環境へのエージェント型AI導入がもたらすリスク

Tier-1サプライヤーは、ソフトウェアの開発、テスト、統合のワークフローを自動化するために、エージェント型のAIフレームワークをますます活用するようになっています。こうした環境は新たな種類のリスクを生み出します。Agat Softwareの調査によると、エージェント同士の通信を可視化できている組織は現在わずか24.4%にとどまり、展開済みのエージェントの半数以上はログを取らずに動いています。1組織あたり平均37のエージェントが展開され、45.6%のチームが複数のエージェントでAPIキーを使い回している状況を踏まえると、サプライヤー1社の環境内だけでも攻撃対象領域はかなり大きくなり得ます。こうした環境では、適切な管理や把握のないまま稼働しているエージェントも紛れ込みやすく侵害が気づかれないまま長期化するため、正式に検知・対処されたインシデントと比べ、発見が遅れたケースでは平均67万ドル多くのコストがかかっています。

ISO/SAE 21434とUNECE WP.29のもとでの規制リスク

ISO/SAE 21434と自動車サイバーセキュリティ国際基準UN R-155のもとで事業を行うOEMは、開発のツールチェーンやサプライヤーとの関係を含め車両のライフサイクル全体をカバーするサイバーセキュリティ管理システム（CSMS）の維持を求められます。AIサプライチェーンの侵害によって認証情報が盗まれたり、開発環境に不正アクセスされたりした場合、それは単なるセキュリティインシデントにとどまりません。これらの枠組みのもとでは、対応の記録、根本原因の分析、サプライヤーの責任の明確化が求められるコンプライアンス上の事案にもなり得ます。

VicOneのお客様にとっての実践的な意味合い： AIサプライチェーンのリスクは、独立したソフトウェアセキュリティの問題として切り離さず、既存のCSMSのガバナンス構造に組み込む必要があります。開発環境は、車両のセキュリティ境界の一部です。

セキュリティチームが今取るべき対策

AIサプライチェーンのリスクに対処するには、AIツールを基幹インフラの依存関係と同じ厳格さで扱う必要があります。VicOneは、開発環境でAIツールを扱うOEMとサプライヤーに、次の対策を推奨します。

• 依存パッケージを厳格に管理する： 本番環境ではバージョンを正確に固定し（例：litellm>=1.0ではなくlitellm==1.82.6のように指定する）、ロックファイルを使い、ハッシュ値でパッケージの完全性を検証します。バージョンを固定しない運用は、日常的なインストールの中で意図せず悪意ある更新を取り込んでしまうリスクを高めます。

• CI/CDパイプラインで可変な参照を点検する： 外部のGitHub Actionでは、バージョンタグへの依存を避け、代わりにコミットSHAを指定します（例：uses: action@abc1234）。どのシークレットをどのワークフローに渡すかを制限し、PyPIトークンは必要最小限の権限で特定のパッケージだけに絞ります。

• PyPIやnpmでパッケージの異常な挙動を監視する： Socket.dev、Phylum、Snykといったツールを使うと、新たに公開されたパッケージのバージョンに含まれる不審な特徴を検知できます。想定外の通信、ファイルの改変、実行時の挙動の変化などが対象です。更新の速いエコシステムでは早期の検知が決定的に重要になります。

• AIエージェントのスキルマーケットプレイスは信頼できない入力として扱う： AutoGPT、CrewAI、Clineといったエージェント型のAIフレームワークを使っている場合は、サードパーティのライブラリに対するのと同じ審査基準を、エージェントの機能にも適用します。エージェント間の通信経路を点検し、展開したすべてのエージェントにログ取得を義務づけます。

• AIエージェントの展開状況を可視化する： 現在、エージェントの半数以上がログを取らずに動いていることを踏まえると、展開済みのエージェントとその権限、外部との通信パターンを一覧として把握しておくことは高度な対策ではなく、まず土台として欠かせない基本の対策です。

• AIサプライチェーンのインシデントが起きたら認証情報を更新する： 影響を受けた環境からアクセスできる認証情報は、すべて侵害された可能性があると考えます。問題のパッケージに直接紐づくものだけでなく、APIキー、サービストークン、クラウドの認証情報を速やかに更新します。

• サプライヤーへのセキュリティ要件をAIツールにも広げる： ISO/SAE 21434のもとで、OEMはサプライチェーン全体のサイバーセキュリティ要件に責任を負います。Tier-1やTier-2のサプライヤーが使うAIツールも、依存関係の管理方法やインシデント対応の義務を含めてサプライヤーのセキュリティ評価の対象に含めることを推奨します。

AIサプライチェーンを守るために

LiteLLMのインシデントは、決してたまたま起きた特殊な事例ではなく、これから本格化する流れを示す一つの節目といえます。攻撃者はAI開発のツールチェーンを価値の高い標的と見定め、それを突くために複数の段階を踏む技術的に高度な攻撃へと力を注いでいます。2025年には自動車業界で610件のサイバーインシデントが確認され、26%がグローバルインシデントへと発展しており、詳細は VicOneの2026年 自動車サイバーセキュリティレポート Crossroadsに記録されています。自動車業界はすでに、脅威の水準が高まった環境のなかで事業を続けており、そうした環境に、十分に統制されていないAIツールを見合うセキュリティ対策なしで持ち込むことは、技術部門だけの問題ではなく組織全体に及ぶリスクです。

OEMにとってこのリスクは、開発環境、サプライヤーのエコシステム、そしてSDVを支えるクラウドサービスにまで広がります。このつながりのどこかで依存パッケージが侵害されると、社内システムの外へ、さらには生産のワークフローへと脆弱性が波及し、車両の安全、規制への適合、ブランドの信頼にまで影響が及ぶおそれがあります。

AIがインフラとして社会に根付きつつある今、サプライチェーンのセキュリティは設計の段階から組み込み、継続的に維持し続けるものとして扱わなければなりません。インシデントへの事後対応だけに頼る体制では、拡大し続けるリスクには追いつけないとVicOneは考えています。基幹のソフトウェアサプライチェーンと同じ厳格さでAIの依存パッケージを管理する組織は、この脅威が進化するなかでも着実な優位性を保てるでしょう。

重要なポイント： AIサプライチェーン攻撃は2026年にクラウド環境で被害が確認された現実の脅威であり、将来への備えとして先送りできるものではありません。AIツールのガバナンスを既存のCSMSの枠組み、サプライヤー要件、インシデント対応のプロセスに今のうちに組み込むことで、OEMとサプライヤーはISO/SAE 21434やUN R-155のもとでのリスクとコンプライアンス上の責任を着実に軽減できます。