AIにおけるサプライチェーン攻撃：最近のインシデントがAIインフラセキュリティについて明らかにするもの

2026年3月24日、FutureSearch社の研究者は日常業務に取り組んでいました。その業務とは、プロジェクトのためにPythonパッケージをインストールすることでした。数分もしないうちに、ワークステーションは異常な動作を始めました。 

メモリ使用量が大幅に増加しました。未知のプロセスが出現し、システムはクラッシュしました。研究者は、AIエコシステムに対してこれまで仕掛けられた中で最も高度なソフトウェアサプライチェーン攻撃の1つを、知らず知らずのうちに解き放ってしまったのです。この攻撃は数ヶ月間活動しており、その存在が公に認識される前に何千もの開発環境を感染させていました。 

本稿では、発生した事象を検証し、AIツールがいかにこの種の攻撃に対して特に脆弱であるかを説明します。また、エンジニアリングチームが自身を保護する方法についても議論します。

何が起こったのか：3段階にわたるサプライチェーン攻撃

少なくとも2025年12月から活動し、Wizの研究者によってこの進行中の攻撃の9つのフェーズにわたって追跡されてきた「TeamPCP」と特定された脅威アクターグループは、最終的な目標を直接標的にしませんでした。その代わりに、この脅威アクターグループは慎重な、 多段階のサプライチェーン攻撃。

ステップ1： 3月19日、TeamPCPは、多くのプロジェクトのCI/CDパイプラインに統合されている、広く利用されているオープンソースのセキュリティスキャナーであるTrivyを侵害しました。

ステップ2： その足がかりを利用して、彼らは1日あたり約340万回ダウンロードされている人気のあるLLMプロキシライブラリのメンテナーのPyPI公開認証情報を入手しました。

ステップ3： 3月24日、彼らはそのパッケージの悪意のある2つのバージョンをPyPIにアップロードしました。侵害されたバージョンは、PyPIがそれらを隔離するまで約3時間公開されていました。

これが現代のサプライチェーン攻撃の決定的な特徴です。 攻撃者はあなたを直接侵害する必要がないのです。 彼らはあなたのツールが信頼している誰かを侵害し、その信頼を利用して残りの道を突き進むのです。

ペイロードの内部：3段階の侵害

悪意のあるパッケージは、Snykのセキュリティ研究者が詳細に文書化した高度な3段階のペイロードを実行しました。

ステージ1 — 情報収集。 ペイロードは、SSH秘密鍵、AWSおよびGCPのアクセス認証情報、Azureサービスプリンシパル、Kubernetes設定、.envファイル、Git認証情報、データベースパスワード、シェル履歴、CI/CDシークレット、暗号通貨ウォレットのシードフレーズなど、見つけられるものすべてを密かに収集しました。

ステージ2 — 暗号化とデータ流出。 収集されたデータは暗号化され、攻撃者が制御するサーバーに送信されました。このプロセス中に、一時ファイル（session.key、payload.enc、tpcp.tar.gz）がシステムの一時ディレクトリに作成されました。

ステージ3 — 永続化とラテラルムーブメント。 ペイロードは、「System Telemetry Service」というsystemdサービスを装ったバックドアPythonスクリプトをインストールしました。この永続化スクリプトは、新しいコマンドを求めて5分ごとに攻撃者が制御するURLをポーリングし、kube-system内のすべてのノードに特権ポッドをデプロイすることで、Kubernetesクラスター全体に拡散することが可能でした。

これを特に危険にしたのは、その配信メカニズム、つまり.pthファイルでした。Pythonパス設定ファイルは、pip自体、CI/CDビルドステップ、テストランナーなど、Pythonプロセスが起動するたびに自動的に実行されます。 アプリケーションを実行する必要はありませんでした。 パッケージをインストールしただけで、ペイロードが実行されました。

AIインフラが特別な標的となる理由

影響を受けたパッケージは、無作為に選ばれたものではありませんでした。現代のソフトウェアスタックにおいて最も特権的な位置の1つは、大規模言語モデル（LLM）プロキシとAIゲートウェイです。LLMゲートウェイをインストールして設定すると、アプリケーションと使用されているAIサービスプロバイダーの間に直接位置することになります。OpenAI APIキー、Anthropic認証情報、AzureおよびGoogle Cloud Platformのサービスアカウントにアクセスできます。環境変数、そして多くの場合、シークレットマネージャーにもアクセスできます。これは設計によるものであり、リクエストのルーティング、レート制限の適用、使用状況のログ記録に必要です。これは意図された動作です。

これはまた、LLMゲートウェイやその依存関係のいずれかが侵害された場合、攻撃者がAIインフラ全体を完全に可視化できることを意味します。Sonatypeの研究者は、このインシデントに関するレポートで次のように述べています。「LiteLLMは通常、アプリケーションと複数のAIサービスプロバイダーの間に直接位置するため、APIキー、環境変数、その他の機密性の高い設定データにアクセスできることがよくあります。この位置にあるパッケージを侵害することで、攻撃者は上流システムを直接侵害することなく、貴重なシークレットを傍受し、流出させることができます。」

コンプライアンスフレームワークがこれを検知できなかった理由

関連するパッケージは、SOC 2 Type 1およびISO 27001の認証を取得していました。これは、これらのフレームワークを批判するためではなく（それらは重要であり、それらを追求するチームは正しいことをしています）、構造的なギャップを示しているため、検討する価値があります。

コンプライアンスフレームワークは、チェックリストに基づいて実施内容を監査します。アクセス制御、データ処理、インシデント対応を対象としています。通常、CI/CDパイプラインのセキュリティスキャナーが、PyPI公開認証情報を盗むためにピボットした脅威アクターによって侵害されたかどうかは調査しません。

標準的なpipのハッシュ検証でさえ、この攻撃を検知することはできませんでした。侵害されたバージョンに含まれる悪意のある.pthファイルは、パッケージのRECORDファイルに一致するハッシュとともに正しく宣言されていました。 そのパッケージは、PyPIが提供するすべての整合性チェックを通過しました。 それは、たまたま武器化された有効なパッケージでした。

これは サプライチェーンセキュリティ AIエコシステムが特に埋めるべきギャップがあります。問題は単に「私たちのシステムは安全か？」ということだけではありません。「システムを構築し、保護するために使用するツールは安全か？」という問いなのです。

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

Evaluating an AI Gateway?

A practical guide used by platform & infra teams

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

TrueFoundryがこの問題をどう考えているか

TrueFoundryでは、 サプライチェーンセキュリティ は、MLOpsプラットフォームを設計する上で後回しにされるものではなく、最優先事項です。

企業がモデルや LLMゲートウェイ をTrueFoundryを通じてデプロイする際、私たちは異なる種類の問いを投げかけます。単に「このエンドポイントは安全か？」ではなく、「このスタック内のいずれかのコンポーネントが侵害された場合、その影響範囲はどの程度か？」と。

私たちの構築方法を形作るいくつかの原則があります。

インフラストラクチャはお客様のVPC内で稼働します。 AIインフラストラクチャがお客様自身のクラウド境界内で稼働する場合、シークレット情報が外部システムに送信されることはありません。エコシステム内のどこかの依存関係が侵害されたとしても、ネットワーク境界内からデータ流出のエンドポイントに到達することはできません。

依存関係は固定され、監査されています。 ビルドごとに最新版を自動的に取得するのではなく、TrueFoundryはプラットフォームスタック全体で、固定されレビュー済みの依存関係を維持しています。これにより、サプライチェーン攻撃の特定の種類の経路が排除されます。

コンポーネントの分離が影響範囲を制限します。 スタックのある層が侵害されても、自動的に別の層へのアクセスが許可されることはありません。最小権限の原則が、インフラストラクチャレベルで適用されます。

これらは特別なエンジニアリングではありません。AIツール業界がこれまで十分に真剣に受け止めてこなかった脅威モデルに適用される規律なのです。 脅威はファイアウォールを介して来るのではありません。requirements.txtを介して来るのです。

チームが今すぐすべきこと

PythonベースのAIツールを使用している場合（LLMを構築するほとんどすべてのチームがそうであるように）、以下の行動を直ちに優先すべきです。

1. インストールされているパッケージのバージョンを確認する。 pip show litellm | grep Version を実行してください。出力が1.82.7または1.82.8を示す場合、システムが侵害されていると見なし、その場で安易にアップグレードしないでください。ペイロードはすでに実行されている可能性があります。既知のクリーンなマシンで、クリーンな状態から再構築してください。

2. マシンおよびCIランナー全体で.pthファイルを監査する。

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

3. 永続化アーティファクトを確認する。

ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
systemctl --user status sysmon.service 2>/dev/null
ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc 2>/dev/null

4. 認証情報を積極的にローテーションする。 影響を受けたマシンがクラウド認証情報、SSHキー、APIキー、Kubernetesサービスアカウントトークン、またはデータベースパスワードにアクセスできた場合、それらすべてを今すぐローテーションしてください。評価するのではなく、ローテーションしてください。このペイロードは、AWS Secrets Manager、SSM Parameter Store、およびすべての名前空間にわたるKubernetesクラスターシークレットを特に標的としていました。

5. Kubernetesで悪意のあるPodを確認する。

kubectl get pods -A | grep "node-setup-"

kube-system名前空間内のnode-setup-{node_name}という名前のPodは、このキャンペーンによる既知の侵害の兆候です。

6. プライベートパッケージレジストリへの移行。 PyPIは依存関係解決の唯一の選択肢ではありません。ピン留めされたハッシュと承認ワークフローを備えたプライベートパッケージミラーは、この種の攻撃ベクトル全体を排除します。Artifactory、AWS CodeArtifact、Google Artifact Registryなどのツールが仲介役として機能します。

7. CI/CDサプライチェーンを攻撃対象領域として扱う。 TeamPCPキャンペーンにおける最初の侵害は、ターゲットライブラリ自体ではなく、そのライブラリのCIパイプラインで使用されていたセキュリティスキャナーに対するものでした。ビルドインフラストラクチャ、GitHub Actions、およびサードパーティ統合はすべて、攻撃対象領域の一部です。それらを適切に監査してください。

より広範なパターン：これは孤立したものではない

この事例が特に興味深いのは、それが日和見的な攻撃ではなかったという点です。むしろ、TeamPCPは少なくとも2025年12月からこの周到なキャンペーンを実行してきました。LiteLLMを攻撃する前に、TeamPCPはAquaのTrivyセキュリティスキャナー（3月19日）、CheckMarxのVS Code拡張機能とGitHub Actions（3月23日）、そして自己増殖型ワームを含む複数のNPMパッケージを侵害していました。

使用されたRSAキーペアは他のすべての攻撃で使用されたものと同一であり、tpcp.tar.gzバンドルの名前やtpcp-docsプレフィックス付きのGitHubリポジトリも同様であることに注意してください。このことは、TeamPCPが組織的にキャンペーンを実行しているプロの脅威アクターであることを示唆しています。

ここでの示唆は、このキャンペーンによって侵害されたチームが過失を犯したわけではないということです。むしろ、彼らは非常に人気があり、十分にレビューされたオープンソースソフトウェアを活用するというベストプラクティスに従っていました。

したがって、この事例が興味深いのは、TeamPCPが特定の組織の防御における弱点を特定したわけではないという点です。むしろ、TeamPCPは、より広範なAIエコシステムがその依存関係チェーン内の信頼にアプローチする方法における弱点を特定したのです。

AIインフラが解決すべき信頼の問題

AIエコシステムは、非常に短期間で驚くべきものを構築しました。それを可能にしたスピードとオープンさ、つまり「pip install」して共有し、互いの成果の上に構築するという文化は、真に価値があり、維持するに値します。

しかし、スピードだけでは サプライチェーンのセキュリティ 負債を生み出します。最新のAIスタックの攻撃対象領域は、公開しているエンドポイントだけではありません。それは、依存関係ツリー内のすべてのパッケージ、CI/CDパイプライン内のすべてのツール、ビルド時または実行時にシークレットにアクセスできるすべてのオープンソースコンポーネントです。

このギャップを埋めるには、影響を受けるチームによるインシデント対応の改善だけでは不十分です。AIインフラエコシステム全体（メンテナー、プラットフォームベンダー、企業、セキュリティチーム）が、サプライチェーンの出所を最優先のエンジニアリング課題として扱うことが求められます。

マシンがクラッシュした研究者は、AIインフラを標的とした数か月にわたるキャンペーンを露呈させるとは思ってもいなかったでしょう。日常的なpip installを実行した開発者も同様です。それが ソフトウェアサプライチェーン攻撃の性質です。それらが発覚する頃には、損害はすでに発生していることがよくあります。

AI業界はより良いものを構築できます。そうする必要があります。

よくある質問 

ソフトウェアサプライチェーン攻撃とは何ですか？

ソフトウェアサプライチェーン攻撃は、脅威アクターが最終ターゲットの上流にある信頼されたコンポーネント（開発ツール、オープンソースライブラリ、CI/CDパイプラインなど）を侵害し、そのコンポーネントの下流のすべてのユーザーに悪意のあるコードを配布するためにそれを利用する際に発生します。組織を直接攻撃するのではなく、攻撃者は、開発者が広く使用されているパッケージやツールに置いている暗黙の信頼を悪用します。 

AIおよびMLチームは、サプライチェーン攻撃からインフラをどのように保護できますか？

AIおよびMLインフラをサプライチェーン攻撃から保護するには、いくつかの補完的な対策が必要です。チームは、公開PyPIから直接プルするのではなく、固定された依存関係ハッシュを持つプライベートパッケージレジストリ（AWS CodeArtifact、Google Artifact Registry、Artifactoryなど）を使用する必要があります。Pythonのsite-packagesディレクトリ内の.pthファイルを定期的に監査することで、悪意のある追加を早期に発見できます。LLMゲートウェイやモデル提供コンポーネントを含むAIインフラをプライベートVPC内で実行することで、依存関係が侵害された場合でも、攻撃者が外部サーバーに認証情報を持ち出す能力を制限できます。MLスタックのソフトウェア部品表（SBOM）を維持することで、新しいインシデントが公開された際に、露出をより迅速に特定できます。最後に、CI/CDパイプライン自体も攻撃対象領域として扱うべきです。セキュリティスキャナーやGitHub Actionsを含む、ソフトウェアの構築と保護に使用されるツールは、より広範なサプライチェーンキャンペーンの一部として侵害される可能性があり、実際に侵害されてきました。

サプライチェーン攻撃のリスクを軽減するためのセキュアなLLMゲートウェイの評価において、チームが考慮すべき要素は何ですか？

LLMゲートウェイは組織のVPC内で機能する必要があります。このようにすることで、依存関係が侵害された場合でも、データ流出経路がなくなります。依存関係は、公開レジストリを使用してインストール時に解決されるのではなく、固定され監査されるべきです。認証情報は環境変数で管理するのではなく、クラウドプロバイダーのネイティブシークレットマネージャーを通じて管理する必要があります。すべてのモデル呼び出し、キー使用、および構成変更の監査ログも実行されるべきです。このようにすることで、異常な動作を容易に特定できます。TrueFoundryはこれらすべての設定をデフォルトで備えているため、自己管理型のオープンソースツールと比較して攻撃対象領域を削減します。