はじめに
本記事は、脆弱性スキャナー「Trivy」の公式ツール侵害から連鎖的に発生しているサプライチェーン攻撃に関する第 4 弾の解説記事です。これまでの事件の推移については、以下の関連記事をご参照ください。
GitHub Actions、npm、Docker Hub、Kubernetes（K8s）へと被害を拡大させてきた本攻撃は、ついに Python エコシステム（PyPI）に到達しました。人気の Python パッケージ「litellm」が侵害され、バックドアが仕込まれたバージョンが公開される事態となっています。
本記事では、この攻撃の連鎖構造（スノーボール効果）の恐ろしさと、litellm に仕込まれたバックドアの技術的挙動を解説し、開発およびインフラエンジニアが取るべき対策を提示します。
- Trivy 侵害から litellm への感染拡大（スノーボール効果）の構造
- litellm（1.82.7 および 1.82.8）に仕込まれたバックドアの挙動
- 自社環境への影響確認とコードレベルの防御策
- CI/CD パイプラインを保護するための実践的チェックリスト
PyPI への感染拡大と「スノーボール効果」の恐怖
今回の事件は、脅威アクターである TeamPCP が、広く利用されている Python パッケージ「litellm」のバージョン 1.82.7 および 1.82.8 に悪意のあるバックドアを混入させたものです。
CI/CD の Trivy 侵害から litellm への連鎖構造
特筆すべきは、litellm が侵害された根本原因です。セキュリティベンダーの調査により、litellm の開発チームが CI/CD ワークフロー内で Trivy を利用していたことが、侵害の入り口となった可能性が高いと指摘されています。
つまり、第一弾の事件で Trivy の GitHub Actions から窃取された認証情報が、そのまま次の標的（litellm）への攻撃に転用されたことになります。この「ある環境での侵害が、次のターゲットの鍵を開ける」という連鎖は、ソフトウェアサプライチェーンにおける最悪のシナリオです。
参考: TeamPCP Backdoors LiteLLM Versions 1.82.7–1.82.8 Likely via Trivy CI/CD Compromise
“The open source supply chain is collapsing in on itself,” Gal Nagli, head of threat exposure at Google-owned Wiz, said in a post on X. “Trivy gets compromised → LiteLLM gets compromised → credentials from tens of thousands of environments end up in attacker hands → and those credentials lead to the next compromise. We are stuck in a loop.” （「オープンソースのサプライチェーンは内側から崩壊しつつある」と、Google 傘下 Wiz の脅威エクスポージャー責任者である Gal Nagli 氏は X の投稿で述べました。「Trivy が侵害される → LiteLLM が侵害される → 何万もの環境からの認証情報が攻撃者の手に渡る → そしてそれらの認証情報が次の侵害につながる。私たちはループから抜け出せずにいます。」）
https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html
TeamPCP の犯行声明とオープンソースサプライチェーンの危機
この一連の攻撃は、GitHub Actions、Docker Hub、npm、Open VSX、そして今回の PyPI と、すでに 5 つの主要なエコシステムに感染を広げています。
さらに、攻撃者である TeamPCP は Telegram チャンネルにおいて、「今後数ヶ月でさらに多くのお気に入りセキュリティツールやオープンソースプロジェクトを標的にする」と公然と犯行声明を出しています。これは単発のインシデントではなく、オープンソースインフラストラクチャ全体を標的とした継続的かつ組織的なキャンペーン（スノーボール効果）に発展していることを意味します。
ともさん、ありがとうございます！ ご指定の文字フォーマットルール（半角スペース、全角括弧の例外対応、半角コロンの扱い）と引用ルールを厳格に適用し、「セクション 2」と「セクション 3」を執筆しました。
Python の .pth ファイルを悪用した非常に巧妙なバックドアの仕組みを客観的に解説し、開発現場ですぐに実行すべきインシデントレスポンス（影響確認と遮断）を太字で強調しています。
litellm バックドア（1.82.7 / 1.82.8）の技術的挙動
TeamPCP によって侵害された litellm のバージョン 1.82.7 および 1.82.8 は、非常に高度で破壊的な 3 段階のペイロード（認証情報収集、Kubernetes の横展開、永続的なバックドア）を含んでいます。
.pth ファイルを悪用したプロセス起動時のバックグラウンド実行
バージョン 1.82.7 では、悪意のあるコードはモジュールのインポート時に実行されるように仕組まれていました。しかし、続くバージョン 1.82.8 では、Python 環境におけるより攻撃的なベクトルが追加されています。
攻撃者はパッケージのルートに悪意のある litellm_init.pth を組み込みました。Python のインタプリタは起動時に site-packages 内の .pth ファイルを自動的に処理するため、litellm が直接インポートされなくても、環境内で Python プロセスが起動するたびにペイロードが実行されてしまいます。
参考: TeamPCP Backdoors LiteLLM Versions 1.82.7–1.82.8 Likely via Trivy CI/CD Compromise “Python .pth files placed in site-packages are processed automatically by site.py at interpreter startup,” Endor Labs said. “The file contains a single line that imports a subprocess and launches a detached Python process to decode and execute the same Base64 payload.” （Endor Labs は「site-packages に配置された Python の .pth ファイルは、インタプリタの起動時に site.py によって自動的に処理されます」と述べています。「このファイルには、subprocess をインポートし、分離された Python プロセスを起動して同じ Base64 ペイロードをデコードして実行する 1 行が含まれています。」）
https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html
Kubernetes クラスターの横展開と特権 Pod による永続化
実行されたペイロードは、SSH キーやクラウドの認証情報、Kubernetes のシークレット、.env ファイルなどを収集し、暗号化されたアーカイブ（tpcp.tar.gz）として models.litellm[.]cloud へ外部送信（Egress）します。
さらに、収集した Kubernetes のサービスアカウントトークンを利用してクラスター内のすべてのノードを列挙し、それぞれに特権（Privileged）を持った Pod を展開します。この特権 Pod はホストのファイルシステムに侵入（chroot）し、Trivy 侵害の際にも確認された sysmon.py を systemd のユーザーサービスとして全ノードにインストールすることで、クラスター全体を永続的に支配下に置きます。
自社環境への影響確認とコードレベルの防御策
オープンソースのサプライチェーンを悪用したこの攻撃からインフラを保護するためには、迅速な影響範囲の特定と封じ込め（コンテインメント）が不可欠です。
侵害バージョンの特定とクリーンなバージョンへの切り戻し
Python バックエンドや CI/CD 環境を運用しているチームは、依存関係の即時監査を行う必要があります。
すべての稼働環境（ローカル、CI/CD ランナー、本番の Kubernetes クラスター）において litellm（1.82.7 または 1.82.8）がインストールされていないか監査し、発見された場合は対象ホストをネットワークから隔離したうえで、直ちにクリーンなバージョンへ切り戻す対応が必須です。
不正な Egress 通信（models.litellm[.]cloud 等）のネットワーク遮断
マルウェアによる情報の持ち出しや、次の指示を仰ぐ C2 サーバーとの通信を断ち切ることが重要です。
インフラ管理者は、ネットワークログやプロキシのログを調査し、models.litellm[.]cloud や checkmarx[.]zone への不審なアウトバウンド通信が存在しないか確認すると同時に、ファイアウォールレベルでこれらのドメインへの通信を直ちに遮断する必要があります。また、Kubernetes クラスター内に不正な特権 Pod が作成されていないか監査し、発見された場合はノード上の永続化メカニズム（systemd の sysmon.service）を完全に除去しなければなりません。
CI/CD パイプラインを保護するための実践的チェックリスト
Trivy や KICS といったセキュリティスキャナーの侵害が、自社の成果物（litellm など）にマルウェアを混入させる原因となった事実は、DevOps 運用に根本的な見直しを迫るものです。
参考: TeamPCP Backdoors LiteLLM Versions 1.82.7–1.82.8 Likely via Trivy CI/CD Compromise
“TeamPCP is escalating a coordinated campaign targeting security tools and open source developer infrastructure, and is now openly taking credit for multiple follow-on attacks across ecosystems,” Socket said. “This is a sustained operation targeting high-leverage points in the software supply chain.” （Socket は「TeamPCP はセキュリティツールとオープンソースの開発者インフラを標的とした組織的なキャンペーンをエスカレートさせており、現在、エコシステム全体での複数の追撃攻撃を公然と主張しています」と述べています。「これは、ソフトウェアサプライチェーンのてこ入れ効果の高いポイントを標的とした持続的な作戦です。」）
https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html
Trivy 等のセキュリティツール実行時における権限の最小化
CI/CD パイプライン上で動作するサードパーティ製の Action やツールに対して、リポジトリへの過剰な書き込み権限や、クラウドリソースへの強大なアクセス権を付与することは極めて危険です。
インフラエンジニアは、GitHub Actions 等のワークフローにおいて GITHUB_TOKEN の権限を「読み取り専用（read-only）」をデフォルトとし、セキュリティスキャナーの実行コンテキストに不要な管理者権限やクラウドアカウントの認証情報（AWS IAM ロールなど）を渡さない設計を徹底する必要があります。
認証情報の流出を前提とした Secrets ローテーションと監査体制
もはや「ツールは安全である」という前提は成り立ちません。侵害の連鎖（スノーボール効果）を断ち切るためには、万が一パイプラインが侵害されても被害を最小化する「ゼロトラスト」のアプローチが求められます。
具体的には、永続的な Personal Access Token（PAT）の利用を廃止して短寿命なトークン（OIDC による一時的な認証など）へ移行し、Trivy などの侵害が疑われる期間に稼働していたパイプラインの全 Secrets を即座に無効化（ローテーション）する手順をインシデントレスポンス計画に組み込むことが、サプライチェーン攻撃を防ぐ最後の砦となります。
まとめ
本記事では、Trivy 侵害から波及した Python パッケージ（litellm）へのバックドア混入と、連鎖するサプライチェーン攻撃の脅威について解説しました。
- Trivy の CI/CD 侵害を起点に litellm がバックドア化され、PyPI へ被害が拡大した。
- バックドアは .pth ファイルを悪用し、プロセス起動時にバックグラウンドで自動実行される。
- 被害を防ぐため、litellm（1.82.7 または 1.82.8）の監査とクリーンなバージョンへの切り戻しを行う。
- 侵害を前提とし、CI/CD ツールに対する権限の最小化と Secrets の短寿命化を徹底する。
以上、最後までお読みいただきありがとうございました。
