Trivy、LiteLLM、Axiosのソフトウェアサプライチェーン侵害事案を考察～CI/CD環境のソフトウェアサプライチェーン侵害と連鎖とは？

改めて明らかになったソフトウェアサプライチェーンリスク

2026年2月から3月にかけて攻撃が行われたとされるセキュリティスキャナ「Trivy^※」のサイバー被害事案は、新たにソフトウェアサプライチェーンリスクに警鐘を鳴らすこととなりました。そしてこのリスクは引き続き進行形で事態が収まったとは言えない状況です。
※Aqua Securityが開発・提供するコンテナイメージ向けのセキュリティスキャナ。

（参考情報）
「Update: Ongoing Investigation and Continued Remediation」（2026年4月1日更新。Aqua Security）

昨今のサービスは、外部のライブラリやパッケージを組み合わせ、GitHubなどのリポジトリサービスで管理を行い、CI/CDと呼ばれる自動化の仕組みを使ってテスト、配布、リリースを行っています。こうした仕組みは開発の速度を上げ、便利となる一方で、いずれかの一つの”点”が破られると、広く長く影響が連鎖し得る弱点を持ち合わせています。この問題はソフトウェアサプライチェーンリスクとして扱われていますが、単に「怪しいソフトウェアが入って悪さをする」だけの話に留まりません。

（関連記事）
サプライチェーン攻撃とは？～攻撃の起点別に手法と事例を解説～

開発における自動テストや自動リリースの仕組みそのものが侵害されることで、今まで通り正規で動作していたサービスやソフトウェアが突如悪意を持った動きを持ち、さらにその侵害環境で盗み出された情報を攻撃者が更に悪用する事態となっています。侵害を受けたリポジトリから更に異なるリポジトリへと侵害が連なり、次にどのような影響が発生し、どのリポジトリが悪意を持った動きをするのか、備える必要があります。

リポジトリ、CI/CD、公開トークン、タグ、リリースの工程、ソフトウェアをユーザの手元まで正規に届ける仕組みそのものが攻撃対象として狙われ、実際に悪用された攻撃が広まっている現状です。

これらのインシデント事例は他人事ではなく、開発やサービスを提供する組織においては次にいつ自分事としてインシデントが起きるかを踏まえた対策が必要です。このような問題を踏まえて、この1か月の期間に何が起きたのか、連なった侵害事例について整理し、今後利用するユーザが取るべき対策と考え方について記載します。

Trivyのリポジトリ侵害～攻撃の流れ

2026年2月28日に観測されたTrivyのリポジトリに対する攻撃は、ワークフロー設定不備を突いた攻撃とされています。公式発表によると、ワークフローとはPull Requestなどの処理に応じて内部で処理が行えるもので、外部から持ち込まれたコードや指示が、内部の認証情報に触れられてしまったものでした。

結果、2月から3月上旬にかけてのTrivyリポジトリに対する攻撃では、リポジトリがPrivate化(非公開)とされ、リリース済みパッケージが削除されました。さらに一時的にOpenVSXのTrivy VS Code拡張機能にも不審なアーティファクトが混ざっていた報告が挙げられています。この時、ワークフローの処理を悪用し、攻撃として悪用することで、Personal Access Token (認証トークン)を盗んだとされています。

この段階で、Trivyに対する開発/公開基盤への初期侵入に対する対策として、認証情報のローテーションによる沈静化が見えていました。しかしその後、不幸にも2度目の攻撃へと繋がってしまいます。公式のアドバイザリによると、ローテーションを行っている間の数日間において、攻撃者が新たにローテーションされた認証情報を持ち出した可能性があると言及されています。

（参考情報）※公式のアドバイザリ。
「Trivy ecosystem supply chain temporarily compromised」（2026年4月６日閲覧。aquasecurity/trivy）

2度目の侵害は3月19日の攻撃から始まり、1度目の攻撃で取得された認証情報を用いた攻撃により、TrivyのリポジトリであるGitHubに攻撃が及びました。この攻撃がTrivyを利用していた他組織のCI/CD環境に影響が及ぶ侵害となり、Trivyを用いてコードやコンテナイメージを公開する前に、自動的にスキャンを行い、安全性チェックを行っていた環境が被害を受けることとなりました。

この段階で影響を受けた対象とバージョンは、TrivyのGitHub上のバイナリであるv0.69.4、関連するGitHub Actionsのtrivy-action, setup-trivyのタグ^※が対象となりました。このタグの参照先が、攻撃者により悪意のあるファイルへと差し替えられたことで、多くの組織において被害が出たものと推測されます。
※タグ（git tag）：プログラムのバージョン管理のため、参照しやすいように特定のバージョンに名称を付けるコマンドおよびその属性情報。

GitHub Actionsのworkflowにより、CI/CDとなるビルド、テスト、スキャン、デプロイ等の作業を自動化する際、workflowと呼ばれるYAML^※定義ファイルを用いて、一連の処理を定義した動作に沿って自動化することができます。今回の悪用では、このYAMLに書いたtrivy-action等のタグの参照先が悪意あるものに置き換えられたため、利用者であるCI/CDユーザ側はYAMLの変更や設定の変更を行わずして、workflowの処理が実行された際に悪意あるファイルが実行されてしまう形となりました。
※YAML：構造化データやオブジェクトを文字列にシリアライズするためのデータ形式の1つ。

CI/CDパイプライン環境および開発配布基盤となるrunnerでは、作成したプログラムの公開処理や、外部サービスへのアクセスを担うためのトークンや認証情報を扱う場合があります。例として、公開しているGitHubリポジトリへGitHub APIを利用したリリースを行う、関連するソフトウェアリポジトリやパッケージ公開配布サービス(PyPIやnpm)にアップロードしpublishする動作などが挙げられます。これらの処理は必ず認証を必要とするため、多くの場合でrunnerにはトークンや認証情報が含まれている状態となります。この状態のrunnerにおいて、悪意あるファイルであるマルウェアが実行されることで、情報の窃取に繋がりました。

攻撃者は窃取したトークンや認証情報を悪用し、それらを足掛かりに、さらに別のリポジトリやパッケージの侵害へと攻撃を広げました。このインシデントはCVE-2026-33634としてCVEが採番され管理されています。

（参考情報）
「CVE-2026-33634」（2026年3月23日。The MITRE Corporation）

繋がった複数の侵害とその連鎖

2026年3月19日のTrivyの侵害からは、同攻撃者による活動とみられる多くのパッケージ公開配布サービスを経由した攻撃と侵害が観測されたため、影響度の大きいとみられるパッケージへの侵害について解説します。

Checkmarx KICSの侵害 – OpenVSXおよびGitHub Actions (3月23日)

Checkmarx KICSは、Infrastructure as Codeの開発サイクルにおける、脆弱性、コンプライアンス、構成ミスを検出ツール、セキュリティチェックサービスです。

3月23日12時53分(UTC)にOpen VSX(Visual Studio Codeのマーケットプレイス)においてマルウェアを含んだバージョンが公開され、15時41分(UTC)まで公開されていました。その後、12時58分(UTC)にCheckmarx/kick-github-actionの全35タグが書き換えられる乗っ取りが発生し、16時50分(UTC)頃までGitHub Actionsを経由したタグの参照が影響を受けたものと判明しています。いずれもCheckmarx社のセキュリティアップデートにおいて情報が取りまとめられ、公開されています。
C&Cの通信先はcheckmarx[.]zoneのドメインが用いられており、Trivy侵害時のペイロードと同じRSA-4096公開鍵とデータ漏えいファイル名を含んでいることから、同インフラが共有されているものと推測されています。

（参考情報）※Checkmarxのセキュリティアップデート。
「Checkmarx Security Update」（2026年3月24日。Checkmarx Ltd.）

LiteLLMの侵害 - PyPI (3月24日)

LiteLLMはLLM(大規模言語モデル)のAPIに対するアクセスを管理し、統一的に用いることが可能となるAIゲートウェイです。
3月24日10時39分(UTC)にLiteLLMのPyPIにマルウェアを含んだv1.82.7が公開、その後10時52分(UTC)に悪意ある.pthファイルが追加されたバージョンが公開されました。この公開は16時00分(UTC)頃のPyPIからの削除完了まで続いていたとされます。この侵害に関する情報はLiteLLMのセキュリティアップデートにおいて情報が取りまとめられ、影響と対応について公開されています。

（参考情報）※LiteLLMのセキュリティアップデート。
「Security Update: Suspected Supply Chain Incident」（2026年3月24日。liteLLM）

LiteLLM v1.82.7では、LiteLLMパッケージ内のproxy_server.pyに悪意あるコードが混入しており、LiteLLMプロキシの起動時に不正コードが実行される状態となっていました。さらにv1.82.8では、.pthファイルを悪用する仕組みが追加され、Pythonの起動時にLiteLLM_init.pthが処理される環境では、LiteLLMプロキシの起動有無にかかわらず不正コードが実行され得る状態となりました。C&Cの通信先はmodels.litellm[.]cloudのドメインが用いられており、窃取情報が送信されることが確認されています。

LiteLLMの事案については、こちらにて当社リサーチ情報が公開されています。

（関連記事）
AIゲートウェイがバックドアに：LiteLLMサプライチェーン侵害の内幕

Telnyxの侵害 - PyPI (3月27日)

Telnyxは音声通話やSMSなどを提供する通信プラットフォームサービスであり、狙われたTelnyxパッケージはAPIを利用するためのPython SDKパッケージでした。
3月27日3時51分(UTC)にTelnyxのPyPIにマルウェアを含んだ4.87.1および4.87.2が公開されました。公開は4時7分まで続いたとされ、該当時間帯にPyPIにてインストールやアップデート、あるいはPythonコードにおいてimportした場合に影響が及びました。C&Cの通信先は他事案と異なり、ドメインではなく83.142.209[.]203:8080のIPアドレスが用いられていました。

Telnyxの事案については、こちらにて当社リサーチ情報が公開されています。

（関連記事）
サイバー犯罪グループTeamPCPによるTelnyx攻撃、LiteLLMを超えた戦術の変化を示す

いずれの攻撃者も攻撃インフラから紐づけることが可能であり、Trivyの二度目の侵害(3月19日)からの日付、および各公開情報と公式のリリース内容から、同一の攻撃者であるものとみられます。TeamPCPと名乗るこの攻撃者がTrivyおよび続く攻撃においてどれほどの認証情報と侵害が行えているかは定かではないものの、今後も攻撃が続く可能性について意識しなければなりません。

異なる攻撃軸で発生したAxiosのソフトウェアサプライチェーン侵害

Trivyから続くGitHub Actionsに関する侵害が報じられる中、3月31日に報じられているAxiosのパッケージの侵害についても同様で、盗まれた情報が更に次のサイバー攻撃に繋がる可能性がある点に留意しなければなりません。

侵害が発生したAxiosは、TypeScriptやJavaScriptで利用できるHTTPクライアントライブラリであり、ブラウザやNode.jsによるサーバとの通信を行うために実装に用いられます（オープンソース）。
3月31日0時21分(UTC)から3時25分(UTC)にかけてnpmの侵害を受けており、axios@1.14.1とaxios@0.30.4のバージョンが悪意ある動作を行うバージョンでした。対象バージョンには依存関係が追加されておりplain-crypto-js@4.2.1が処理されることでマルウェアが動作します。

（関連記事）
Axios NPMパッケージ侵害：週1億以上のダウンロードを誇るJavaScript HTTPクライアントにサプライチェーン攻撃

開発者のアカウントを侵害したことによる、npmを用いた攻撃の展開となりnpmレジストリ上で侵害されたAxiosバージョンが配布されていた期間中に、その侵害のバージョンを取得した場合に影響を受けます。具体的には、開発者が新規にプロジェクトをセットアップしてnpm installコマンドを実行した場合、npm install axiosコマンドでAxiosを新規に導入した場合、npm update等によりAxiosが侵害版(1.14.1 / 0.30.4)へ更新された場合、または依存関係の再解決により侵害版が取得された場合が該当します。

npmでAxiosをインストールする際、npmはAxiosのpackage.jsonを参照し、そこに記載された依存関係を解決します。そのため、dependenciesに記載されたパッケージはAxios本体とあわせて自動的にインストールされます。今回の事案では、悪意あるplain-crypto-jsがAxiosのpackage.jsonのdependencies^※に1行追加されており、その結果、Axiosインストール時にplain-crypto-jsも同時にインストールされてしまいます。Axiosの1.14.0と1.14.1(悪意あるバージョン)の差分としては、Axiosのpackage.jsonにおいて、1行追加されていたことのみとなります。
※dependencies：ソフトウェア開発におけるタスク間の相互関係性を表す用語。Node.jsやnpmにおいては、本番環境でアプリケーションが稼働する際に使用するサーバや認証アダプタなどの関係を記述したライブラリのことを指す。

画面：侵害前と侵害後のdependenciesの箇所の違い（左:侵害前、右:侵害後。トレンドマイクロでの再現。一部を省略しています)

依存関係先であるplain-crypto-jsのpackage.jsonにはscriptsであるpostinstallが定義されていました。この定義内容に基づいてnpmが”node setup.js”を実行し、悪意あるJavaScriptがnpmを実行した端末上で動作しました。postinstallは通常ではビルドや追加ファイルの生成、環境の確認等に用いられるものが悪用された形となります。

画面：plain-crypto-js@4.2.1のpackage.jsonの内容（トレンドマイクロでの再現）

このsetup.jsがマルウェアの本体であり悪意ある処理が含まれていました。package.jsonに対するわずかな記述のみでAxiosとplain-crypto-jsの依存関係を通じて自動実行されてしまう仕組みとなっていました。シンプルな手口でありながら、npmを利用して開発環境やツールを構築していた端末が影響を受け得る脅威であると言えます。この攻撃はWindows、Linux、MacOSいずれに対してもpackage.jsonに記載されたsetup.jsで動作し、環境を判定後に、環境毎に悪意あるRAT(Remote Access Tool)が実行される仕組みでした。

plain-crypto-jsについては2026年3月30日5時57分(UTC)に新たにnpmへと登録されたパッケージであり、登録時には無害な状態でした。その後23時59分(UTC)に悪意あるファイルを持った4.2.1のバージョンが作成され、攻撃に至っています。攻撃までの流れについて下記図に流れを記述します。

図：Axiosのリポジトリ侵害～開発環境侵害までの流れの例（公開情報をもとにトレンドマイクロで作成）

各組織がとるべき対策と姿勢

ここまで記述した事例は2026年3月の1か月間で発生した事案であり、急速なソフトウェアサプライチェーンの被害報告と攻撃者からの攻撃手法としての価値が高まっている状況と言えます。これらのソフトウェア開発、CI/CD環境のシステム利用者、ソフトウェアやツールを利用する我々がどのような対策と考えを持つべきなのかについて記載します。

被害の確認と情報収集の実施

このようなパッケージやソフトウェアサプライチェーンのインシデント事案においては、公式リリースやコミュニティで推奨される対策と確認方法について実施することが最優先です。根本的な原因と被害有無を含む影響確認を行い、早期に対処しなければなりません。今回の場合、悪用されたパッケージバージョンが自組織で使われていないか、インストールされ動作した痕跡がないか等を確認し、影響を確認した場合は封じ込めと、認証情報のローテーション等（後述）を行う必要があります。

認証情報等のローテーション

被害に遭ってしまった端末、プロジェクトで利用していたクラウドサービスの認証情報、関連のAPIやAPIトークン、業務と紐づいたコミュニケーションツールなどの連携情報のシークレットキー、SSHの認証鍵情報、GitHubリポジトリのトークンなどが盗まれる対象となります。

影響を受けた環境では、パスワードの変更だけではなく、上述したトークン等の情報もすべて無効化、ローテーション、再発行が必要となります。
このような対応は、ソフトウェアサプライチェーン攻撃に限らず、情報窃取型マルウェア(インフォスティーラー)の被害に遭った時も同様の動きが必要です。マルウェアの排除等による封じ込めを行った後に、即座に認証情報の変更を行いましょう。封じ込め前に行った認証に関する情報は攻撃者がすでに入手している可能性が高いです。

GitタグとパッケージのSHAピニング(SHA pinning)

今回のTrivyの事案では、Gitタグに紐づいたコミット内容が悪意あるものに置き換えられたことが一つの要因になっています。GitHub ActionsではSHAピニングと呼ばれる、特定のコミットを指定することができ、タグの変更が行われた場合も確実に特定のコミットを参照するため、悪意あるものに置き換えられた際の改ざん被害に遭う可能性を回避することができます。

リポジトリへの取得に関する最小公開期間を設定する (クールダウン)

直近のインシデント事例においても、数時間で公開停止に至っているパッケージが多い状況でした。脆弱性の対処や、新機能の追加など様々な観点から最新版が推奨されることが多いことは事実ですが、昨今の状況を鑑みるとセキュリティリスクが内包されている可能性は否定できず、最新版の公開から一定期間待つことで攻撃者による開発環境侵害やマルウェアの影響を受けづらくなると考えられます。

各パッケージマネージャーにおいては、設定により期間や公開後の時間や日数を設定することが可能です。数日間の期間を設けることで高い効果を得られるものが期待できます。しかし、一定の期間を空ければ必ず回避できるわけではなく、他の対策とともに適用することが重要です。

以下は主要なパッケージマネージャーと、その該当する最小公開期間(クールダウン)を設定するオプションの項目名称です。

マネージャ名称	設定項目の名称(オプション)
npm	min-release-age
pnpm	minimumReleaseAge
uv	exclude-newer
Bun	minimumReleaseAge
pip	uploaded-prior-to (ver26.0以降)

利用するpackage.jsonの依存関係管理と把握

package.jsonは依存するパッケージ等を明記する定義ファイル、レシピとなるファイルです。このファイルに書かれたバージョンの処理に基づいて依存関係が解決されるため、「可能な範囲で狭く運用する」ことが重要となります。
特に多い記述として「 ^1.14.0 」と書かれた依存関係定義が存在した場合、メジャーバージョンが1の場合は最新版を取得する動きとなり、1.14.1がリリースされたタイミングで依存解決してしまいます。

package-lock.jsonによる依存関係の固定

package-lock.jsonは依存関係を固定することができるファイルです。環境差異を減らすことができ、依存関係のツリーが記録されているため、lockfileが環境内に存在した場合、”npm install”や”npm update”コマンドを実行した際、新規に公開された悪意あるバージョンの持つパッケージを取得するリスクを減らすことができます。
チームやプロジェクトでの開発の場合は、lockfileを活用して共有(コミット)する運用を行っているものと思われます。これらの運用はセキュリティ面でも安全であると言えます。

トラフィックのゲートウェイ経由での管理と制限

システムが動作する端末やサーバにおいて、不要な通信をゲートウェイやプロキシで制御し、限定的な通信のみ許可することも重要な対策となります。万一悪意あるパッケージやアップデートを取得し実行してしまった場合も、認証情報が盗まれる可能性を減らすことが期待できます。
ただし、従来信用しているリポジトリやクラウドサービス等を悪用する攻撃者も存在するため、必ず防げる対策とはなり得ません。ネットワークレベルの対策として取り入れ、監視と通知を行うことを検討してください。日頃よりプロキシなどの制御を行っておくことで、今回のインシデント事案のようなC&Cサーバへの封じ込めも行うことができます。

システムの動作に不要な実行ファイルの動作制限と通信制限、動作の記録と検知

TrivyやAxiosのソフトウェアサプライチェーンのインシデント事案に限らず、サイバー攻撃に備えたファイルの実行制限と通信制限は優位に働くことが期待できます。一部ユーザやソフトウェアの動作を妨げる可能性があるため、導入と運用にはチューニングが必要となりますが、悪用されやすい実行ファイルを予め設定しておくことで効果を発揮します。

今回のソフトウェアサプライチェーンでは、依存関係により解決されたplain-crypto-js@4.2.1のpostinstallに記載されたsetup.jsが実行されることから、端末上での侵害が始まりました。また、curlを介して実行と通信を行ったことが確認されています。curlの実行制御、あるいはcurlがインターネットへ通信できないよう設定することで被害を未然に防げる可能性が高まります。これらのエンドポイント型の制御は、アプリケーションコントロールやファイアウォールといった機能で利用できることが一般的ですので、お使いのセキュリティ製品の機能を確認することをお勧めします。（トレンドマイクロのTrendAI Vision Oneでは、Standard Endpoint ProtectionまたはServer Workload Protectionといった機能で活用できます）。

図：Axiosの事例を例としたWindows環境でのTrendAI Vision Oneによる防ぎ方の例

また、インシデント事案に巻き込まれた際の迅速な影響調査の確認と、早期に気づくための取り組みとして、EDRによるログ検知および監視、Sysmon等を利用したより詳細なログの記録と保管が優位に働くことが期待できます。

今回のソフトウェアサプライチェーンのインシデント事案は、CI/CDやコンテナ、開発環境だけの問題ではありません。影響は、手元のラップトップ端末や業務用のアプリケーションサーバにも波及してくる可能性があります。普段は開発を行わない環境であっても、「便利だから入れている」、「簡単なツールは手元で作ってしまう」といった理由で、npmなどのパッケージマネージャーを使う場面は十分にありえます。だからこそ、「使うな」と一律に禁止することではなく、使うのであれば脅威を正しく理解し、守るべき姿勢と対策を持つことが重要です。

サイバー攻撃への備えも、ソフトウェアサプライチェーンへの備えも、いずれも組織がポリシーやルールとともに技術的対策を定め、正しく取り組んでいくことが重要です。サプライチェーン被害の連鎖に巻き込まれず、次なる被害を生まないためにも、改めてチームや組織で話し合い、セキュリティポリシーとガイドラインを更新していきましょう。