2026年に何が起きたのか — Trivy・axios侵害の全体像

2026年3月、ソフトウェアサプライチェーンを狙った大規模な攻撃が連鎖的に発生しました。最初の起点は、コンテナやIaCの脆弱性スキャナーとして広く利用されている「Trivy」です。

攻撃者グループ「TeamPCP」は、まずTrivyのGitHub Actionsワークフローの設定不備を突いてPersonal Access Tokenを窃取しました。2026年2月28日に始まった第1次攻撃では、リポジトリのPrivate化やリリース済みパッケージの削除が行われています。さらに3月19日の第2次攻撃では、窃取したトークンを用いてtrivy-actionやsetup-trivyのGitタグが悪意あるファイルへ差し替えられ、CVE-2026-33634として採番される深刻なインシデントとなりました。

この侵害は単体で終わりませんでした。TrivyをCI/CDパイプラインに組み込んでいたLLMプロキシライブラリ「LiteLLM」では、侵害済みのTrivyがGitHub Actionsランナー上で実行された結果、PyPIの認証トークンが外部に送信されてしまいます。攻撃者はこのトークンを使い、3月24日にLiteLLMのPyPIにマルウェア入りのv1.82.7およびv1.82.8を公開しました。

そして3月31日、週間1億ダウンロードを超えるHTTPクライアントライブラリ「axios」がnpmで侵害されます。攻撃者はaxiosのリードメンテナーのnpmアカウントを乗っ取り、axios@1.14.1とaxios@0.30.4という悪意あるバージョンを直接公開しました。GitHubリポジトリには対応するコミットもタグも存在しない、完全に不正な公開でした。

npm installはなぜ危険なのか — postinstallと推移的依存の構造的問題

axios侵害の手口は極めてシンプルでありながら、npmの構造的な問題を鮮明に浮かび上がらせるものでした。

攻撃者がaxiosのpackage.jsonに加えた変更は、dependenciesへの1行の追加だけです。「plain-crypto-js@4.2.1」という偽パッケージが依存関係に加えられ、npm installを実行するだけでaxios本体とともに自動的にインストールされる状態となりました。

plain-crypto-jsのpackage.jsonには、postinstallスクリプトが定義されていました。npmはパッケージのインストール後にこのスクリプトを自動実行するため、「node setup.js」というコマンドが利用者の端末上で動作します。このsetup.jsこそがマルウェア本体であり、Windows・Linux・macOSいずれの環境でも動作するRAT（Remote Access Tool）を展開するものでした。

GMO Flatt Securityの取締役副社長 Co-CTOである米内貴志氏は、「npm installは拾ってきたexeファイルをクリックする、任意のコード実行のようなもの」と表現しています。postinstallをはじめとするlifecycle scriptsの自動実行は、かつてMicrosoft WordやExcelのマクロ自動実行が有効だった時代にマクロウイルスが猛威を振るったのと、構造的に同じ問題を抱えているのです。

さらに厄介なのが、推移的依存（Transitive Dependency）の存在です。開発者が1つのパッケージをインストールしたつもりでも、そのパッケージがさらに別のパッケージに依存しており、依存関係は多段に連なっています。axiosの場合、直接依存するパッケージだけで17万2243件に上ります。その先にある間接的な依存関係まで含めれば、事実上axiosに依存していないNode.jsプロジェクトはほとんど存在しないと言えるでしょう。

「自分は使っていないから安全」が通用しない理由

「axiosは使っていないから大丈夫」「LiteLLMには依存していないから関係ない」。そう考えたくなる気持ちは理解できます。しかし米内氏は、「影響はあると考えるべきです」と繰り返し強調しています。

前述の推移的依存の問題に加え、2026年のインシデントが示した重大な変化は、攻撃が「連鎖前提」で設計されている点です。reviewdogやtj-actionsへの2025年の攻撃では、広範囲への連鎖的な意図はそれほど見えませんでした。しかしTeamPCPによるTrivyへの攻撃では、1つの侵害を足がかりにダウンロード数の多いパッケージを意図的に選択し、効果的に連鎖を広げていく戦略が明確に見て取れます。

もう1つの見逃せないリスクは、AIエージェントへの委譲です。開発現場ではAIの活用が急速に進み、環境構築やパッケージのインストールをAIに任せる場面が増えています。「あるツールを使うことを許すか、許さないかの判断を、どんどん自らの手から離していっている」と米内氏は警鐘を鳴らしています。人間であれば「これは怖いかも」と感じる操作でも、AIはためらうことなく実行してしまいます。

攻撃者の練度も向上しています。盗み取ったトークンの中からCI/CD関連のものを意図的に選別したり、検知を回避するためにforkやタグの偽装を使い分けたりと、守る側の出方をうかがいながら手口を進化させている状況です。

今すぐ実践できる5つの防御策

危機感を持つことは重要ですが、具体的な行動に移さなければ意味がありません。ここでは、開発現場が今すぐ導入できる5つの対策を紹介します。

1. min-release-ageの設定

npm 11.10.0以降で導入された設定で、公開から一定期間が経過していないパッケージのインストールを拒否できます。.npmrcに「min-release-age=7」と記載するだけで、公開から7日未満のパッケージがブロックされます。今回のaxios侵害は約3時間で検知・削除されており、この設定があれば被害を回避できた可能性が高いと言えます。pnpmでも「minimumReleaseAge」として同等の設定が利用可能です。

2. npm ci --ignore-scriptsの活用

CI環境ではnpm installの代わりにnpm ciを使用し、--ignore-scriptsオプションでpostinstallなどのlifecycle scriptsの自動実行を無効化します。ビルドに必要なスクリプトのみを、@lavamoat/allow-scriptsなどのツールでホワイトリスト管理するのが理想的です。

3. GitHub ActionsのSHAピニング

GitHub Actionsで外部アクションを参照する際は、バージョンタグではなくコミットSHAで固定します。Trivyの事案ではタグの参照先が悪意あるコミットに差し替えられましたが、SHAピニングであればタグの改ざんによる影響を受けません。

4. lockfileの厳格運用

package-lock.jsonを確実にリポジトリにコミットし、CI環境ではnpm ciでlockfileに記録された依存関係のみを解決します。lockfileが存在する環境では、新規に公開された悪意あるバージョンを意図せず取得するリスクを低減できます。

5. ビルドとデプロイの分離

ビルドの瞬間が最もリスクの高いフェーズです。ビルドジョブには本番環境への権限を持たせず、アーティファクトだけを接点としてデプロイジョブと分離します。万が一ビルド環境が侵害されても、本番環境の認証情報が漏洩するリスクを構造的に排除できます。

牧歌的な開発文化からの脱却 — セキュリティ意識のアップデート

米内氏は、現在のソフトウェア開発における依存関係の扱いを「牧歌的」と表現しています。SaaSを導入する際にはセキュリティチェックシートで厳密に確認するのが当たり前なのに、package.jsonへの1行追加に稟議を求める組織は存在しません。攻撃者がどちらを狙うかは明白です。

もちろん、パッケージ導入のたびに正式な稟議を通すのは現実的ではありません。しかし、少なくとも以下の「覚悟」を持つことが求められています。

まず、新バージョンが公開されてもすぐには導入しないクールダウン期間の設定です。数日から1週間程度の猶予を設け、コミュニティの力を借りて安全性が確認されてから導入する習慣をつけましょう。前述のmin-release-ageはこのアプローチを技術的に支援する仕組みです。

次に、npmレジストリプロキシの活用です。GMO Flatt Securityが提供するTakumi Guardのようなツールは、npmのレジストリプロキシとして動作し、不正なパッケージのインストールをブロックします。今回のaxios侵害では、攻撃開始から約2時間でブロックが開始されたと報告されています。

そしてCI/CD環境の監視体制の整備です。PCにEDRを導入するのと同様に、GitHub ActionsランナーなどのDevOps系エンドポイントについても、侵害前提でログやテレメトリを収集し、インシデントレスポンスに備える必要があります。

SBOMの導入も依存関係の「把握」には有効ですが、不正なパッケージが混入される手法に対しては不完全です。依存関係の可視化にとどまらず、受け入れ評価の強化、依存の固定、アーキテクチャの堅牢化、エンドポイント統制という多層的なアプローチが求められています。

ソフトウェアサプライチェーンのセキュリティは、もはや一部のセキュリティ専門家だけの問題ではありません。npm installを日常的に実行するすべての開発者が、「踏み抜ける地雷がどこにでもある」という前提のもとで、開発環境への向き合い方をアップデートすべき時が来ています。