はじめに——「信頼していたツールが汚染される」時代が来た
「脆弱性スキャナを入れているから大丈夫」「公式マーケットプレイスから入れたツールだから安全」——2026年3月、そんな常識が根底から覆される事件が立て続けに発生しました。
脆弱性スキャナのTrivy自体が侵害され、その汚染がCheckmarx、さらにAIゲートウェイのLiteLLMへと連鎖。AIエージェントのスキルマーケットプレイスClawHubでは1,184件の悪意あるスキルが検出。AIコーディングツールClaude Codeでは設定ファイル経由のリモートコード実行脆弱性（CVE-2025-59536）が報告されました。
CrowdStrike 2026 Global Threat Reportによると、AI対応攻撃は前年比89%増加し、平均侵入横展開時間はわずか29分にまで短縮されています。
本記事は、サプライチェーン攻撃入門（概念編）の続編として、2026年3月に発生した実際のインシデントを時系列で解析し、中小企業が今日から実装できる具体的な防御策を提供します。
2026年1月〜3月：主要インシデントの時系列
まず、わずか2か月の間に何が起きたかを時系列で整理します。「AIツールのサプライチェーン攻撃」がいかに現実の脅威であるかが明確になるはずです。
ClawHavocキャンペーン（2026年1月〜2月）
オープンソースAIエージェント「OpenClaw」のスキルマーケットプレイスClawHubが攻撃の舞台となりました。
| 日付 | 出来事 |
|---|---|
| 1月27日 | ClawHub上に最初の悪意あるスキルが出現（未検知） |
| 1月31日 | 攻撃者「hightower6eu」が大量アップロードを開始。単独で677件の悪意あるパッケージを公開 |
| 2月1日 | Koi SecurityがClawHavocキャンペーンを命名。2,857件中341件（11.9%）の悪意あるスキルを検出 |
| 2月2日 | Snykが「clawhub」という名前の偽スキル（7,743ダウンロード）を発見。翌日削除されるも「clawdhub1」として再出現 |
| 2月5日 | Snykが3,984件のスキルを全件スキャン。36%にプロンプトインジェクション、1,467件に悪意あるペイロードを確認 |
| 2月7日 | OpenClawがVirusTotalとパートナーシップを締結。3,016サンプルの日次スキャンを開始 |
| 2月16日 | 悪意あるスキル数が824件に増加（レジストリ全体は10,700件超）。Antiy CERTが累計1,184件の悪意あるスキルを確認 |
| 2月17日 | ClineのCLI v2.3.0がnpmで侵害され、約4,000台の開発者マシンにOpenClawを無断インストール |
主なペイロードはAtomic macOS Stealer（AMOS）で、ブラウザの認証情報、Keychain、暗号通貨ウォレット、SSHキー、Telegramのセッションデータを窃取する能力を持っていました。
Claude Code設定ファイル脆弱性（2025年9月〜2026年1月）
Check Point Researchが報告した脆弱性は、AIコーディングツール特有の新しい攻撃ベクトルを示しました。
| CVE | CVSS | 攻撃ベクトル | 修正状況 |
|---|---|---|---|
| CVE-2025-59536 | 8.7 | Hooks / MCP設定ファイル経由のリモートコード実行。信頼ダイアログ表示前にコード実行 | 修正済み（v1.0.111） |
| CVE-2026-21852 | 5.3 | ANTHROPIC_BASE_URLの環境変数操作によるAPIキー窃取 | 修正済み |
攻撃の流れは以下の通りです。攻撃者がリポジトリに悪意ある.claude/settings.jsonや.mcp.jsonを仕込み、開発者がそのリポジトリをクローンしてClaude Codeを起動すると、ユーザーが信頼ダイアログを確認する前にシェルコマンドが実行されるというものでした。
TeamPCPサプライチェーン連鎖攻撃（2026年3月20日〜24日）
最も深刻な事件が、セキュリティツールそのものを狙ったTeamPCPの攻撃です。わずか5日間で3つのプロジェクトが連鎖的に侵害されました。
| 日付 | 標的 | 手法 |
|---|---|---|
| 3月20日 | Trivy（脆弱性スキャナ） | GitHub Actionsの設定不備を悪用し、CI/CDシークレットを窃取。76/77のバージョンタグを悪意あるコミットに差し替え。感染バイナリv0.69.4を公式チャネルで配布（CVE-2026-33634、CVSS 9.4） |
| 3月23日 | Checkmarx KICS / AST | 窃取した認証情報でGitHub Actionsを侵害。Open VSX上の拡張機能（cx-dev-assist 1.7.0、ast-results）も汚染 |
| 3月24日 | LiteLLM（AIゲートウェイ） | TriviのCI/CD依存関係経由で侵害。PyPI上にv1.82.7/v1.82.8を公開。認証情報の収集、Kubernetes横展開、永続的バックドアの3段階ペイロードを展開 |
LiteLLMはOpenAI、Anthropic、Bedrockなど100以上のLLM APIへの統合インターフェースを提供するPythonライブラリで、PyPIでの累計ダウンロード数は約4.8億回に達します。少なくとも1,000以上のエンタープライズSaaS環境が影響を受けたと報告されています。
TeamPCPはTelegramチャンネルで「これらの企業はサプライチェーンを保護するために作られたのに、自分自身さえ守れない」と声明を出しており、攻撃が今後も継続することを示唆しています。
攻撃の構造分析——4段階キルチェーン
上記のインシデントに共通する攻撃パターンを4段階のキルチェーンとして整理します。
第1段階：パッケージレジストリ / 設定ファイルの侵害
攻撃の入口は、開発者が「信頼している」場所です。
| 攻撃パターン | 実例 |
|---|---|
| マーケットプレイス汚染 | ClawHub上の偽スキル（google-qx4、solana-wallet-tracker等） |
| 設定ファイル注入 | .claude/settings.json、.mcp.jsonへの悪意あるHooks/MCP設定 |
| バージョンタグ差し替え | Trivyの76タグを悪意あるコミットに書き換え |
| 正規パッケージの直接侵害 | LiteLLMのPyPIパッケージへの悪意あるバージョン公開 |
第2段階：CI/CDパイプライン汚染
第1段階で得た認証情報を使い、開発パイプラインそのものを汚染します。TeamPCPの事例では、Trivyの脆弱性スキャンは正常に動作しながら裏でシークレットを窃取するという巧妙な手法が使われました。正常な出力が表示されるため、多くの利用者は侵害に気づけませんでした。
第3段階：認証情報の窃取
CI/CDランナーのメモリから環境変数・シークレットを抽出し、自己ホストされたシステムではクラウド基盤の認証情報を探索します。窃取データは暗号化された上で攻撃者のインフラに送信されるか、被害者のGitHubアカウントに作成された公開リポジトリにリリースファイルとしてアップロードされます。
第4段階：クラウド環境への横展開
LiteLLMの事例では、単なる認証情報の窃取にとどまらず、Kubernetes環境への横展開ツールキットが展開されました。特権Podを各ノードにデプロイし、永続的なsystemdバックドア（sysmon.service）を設置して、50分ごとに追加のペイロードを取得する仕組みが構築されていました。
AIエージェント固有のリスク——なぜ従来のセキュリティツールでは守れないのか
従来のサプライチェーン攻撃（例：npmパッケージの汚染）と、AIエージェントのサプライチェーン攻撃には決定的な違いがあります。
設定ファイルが「実行レイヤー」になる
従来のリポジトリ設定ファイルは、フォーマットや環境変数の定義といった受動的なメタデータでした。しかし、AIツールの設定ファイルはHooks（シェルコマンド実行）やMCPサーバー（外部ツール連携）を定義するため、実質的な実行レイヤーとして機能します。
Check Point Researchが指摘するように、「リスクはもはや信頼できないコードの実行だけではない。信頼できないプロジェクトを開くこと自体がリスクになった」のです。
SKILL.mdファイルという新しい攻撃ベクトル
AIエージェントのスキルは、コードではなく自然言語の指示書（SKILL.md）で能力を定義します。従来のアプリケーションセキュリティツールは、コードやコンテナをスキャンしますが、マークダウンファイルに書かれた英語の指示文の意図を検証することはできません。
1Passwordの分析が端的に述べています。「人々はマークダウンファイルが危険だとは思わない。人々はセットアップ手順を素早く実行するよう訓練されている。人々は『最多ダウンロード』を正当性の代理指標として信頼する」。
スキル/プラグインの信頼モデルの脆弱性
AIエージェントのスキルは、エコシステム間でポータブルです。OpenClaw向けに作られた悪意あるスキルは、CursorやCodexなど同じAgent Skills形式をサポートする他のフレームワークでも動作する可能性があります。さらに、2.9%のスキルは実行時に外部エンドポイントからコンテンツを動的に取得・実行するため、レビュー時点では無害に見えても、攻撃者がホスト側のコンテンツを更新するだけで攻撃ロジックを変更できます。
中小企業が今すぐ実装できる防御策
これらのインシデントは大規模な攻撃ですが、中小企業でも今日から始められる具体的な防御策があります。それぞれの対策を「すぐできること（今日）」「1週間以内」「1か月以内」の3段階に分けて紹介します。
対策1：パッケージバージョンのピン留めとハッシュ検証
今日からできること：
TeamPCPの攻撃が成功した最大の理由は、Gitタグが「可変参照」であることです。タグはいつでも別のコミットに差し替えられます。GitHub Actionsでは、バージョンタグではなくコミットSHA（ハッシュ値）で固定してください。
# ❌ 危険：タグは差し替え可能 - uses: aquasecurity/trivy-action@v0.69.4 # ✅ 安全：コミットSHAで固定 - uses: aquasecurity/trivy-action@a1b2c3d4e5f6...
同様に、Pythonのrequirements.txtやNode.jsのpackage-lock.jsonでも、バージョン範囲指定ではなく固定バージョンとハッシュ値を使用しましょう。
# requirements.txt のハッシュピン留め例 litellm==1.82.6 --hash=sha256:abc123...
対策2：依存関係のロックファイル管理
1週間以内に実施：
以下のロックファイルをバージョン管理（Git）に含め、CI/CDパイプラインではnpm ci（npm installではなく）やpip install --require-hashesを使用してください。
| 言語/ツール | ロックファイル | CI/CDコマンド |
|---|---|---|
| Node.js | package-lock.json | npm ci |
| Python | requirements.txt（ハッシュ付き） | pip install –require-hashes -r requirements.txt |
| Go | go.sum | go mod verify |
対策3：MCP/スキルの手動検証チェックリスト
今日からできること：
AIエージェントのスキルやMCPサーバーを導入する前に、以下のチェックリストを確認してください。
| チェック項目 | 確認内容 | 赤信号の例 |
|---|---|---|
| 開発者の身元 | GitHubアカウントの作成日、過去の活動履歴 | アカウント作成から1〜2週間、他のリポジトリなし |
| 前提条件の確認 | SKILL.mdやREADMEの「Prerequisites」セクション | 外部URLからのバイナリダウンロード指示、ターミナルへのコマンド貼り付け指示 |
| コードの確認 | スクリプト内の外部通信、ファイルアクセス | .envファイルの読み取り、webhook.siteへの送信、base64エンコードされたペイロード |
| 権限の確認 | 要求されるファイルシステム・ネットワークアクセス | ルートディレクトリへのアクセス、SSH鍵ディレクトリの読み取り |
| 動的取得の確認 | 実行時に外部から追加コードを取得するか | rentry.coやpastebin系サービスからのコード取得 |
SnykのmcpスキャンツールやAI-BOMコマンドも、MCP/スキルの安全性確認に活用できます。
対策4：CI/CDパイプラインのセキュリティゲート設計
1か月以内に実施：
CI/CDパイプラインに以下のセキュリティゲートを追加しましょう。
CI/CDセキュリティゲート設計例： 1. 依存関係チェックゲート - ロックファイルの変更を自動検知 - 新規依存関係の追加にはレビュー必須 - ハッシュ不一致でビルドを停止 2. シークレット漏洩防止ゲート - 環境変数の最小権限化 - シークレットの有効期限設定 - CI/CDランナーからの外部通信を制限 3. アーティファクト整合性ゲート - ビルド成果物の署名検証 - コンテナイメージのダイジェスト固定 - リリースバイナリのハッシュ公開・検証
特にTeamPCPの事例で教訓となるのは、シークレットのローテーションは「原子的（完全な一括更新）」に行う必要があるという点です。Trivyの事例では初回の修復が不完全だったため、攻撃者が残存する認証情報を使って再侵害しました。
対策5：AIツール設定ファイルのセキュリティ管理
今日からできること：
Claude Codeの脆弱性で明らかになった通り、.claude/settings.jsonや.mcp.jsonは実行可能なコードと同等に扱う必要があります。
AIツール設定ファイルのセキュリティルール： ✅ コードレビュー対象に追加： .claude/settings.json .mcp.json .cursor/settings.json SKILL.md ✅ 変更検知アラートの設定： 上記ファイルへの変更をPRレビュー必須に ✅ 未知のリポジトリでは： - AIツールをサンドボックス環境で起動 - 信頼ダイアログは必ず内容を確認してから応答 - 設定ファイルを事前に手動確認
関連記事：MCPセキュリティ入門、MCPサーバーの安全な運用
「信頼できないものは動かさない」原則の社内ルール化テンプレート
ここまでの対策を社内ルールとして定着させるためのテンプレートを提供します。自社の状況に合わせて修正してお使いください。
【社内ルール：AIツール・外部パッケージの安全利用規程】 ■ 基本原則 「検証されていないツール・パッケージ・スキルは、業務環境で実行しない」 ■ 導入前チェック（必須） 1. 新規パッケージ・スキル・MCP サーバーの導入には、 セキュリティ担当者（または指定されたレビュアー）の承認を必須とする 2. 導入前に以下を確認する： □ 開発元の身元と信頼性（GitHubアカウント歴、組織所属） □ ダウンロード数・スター数だけで判断しない □ SKILL.md / README の前提条件に外部バイナリダウンロード指示がないか □ コード内に不審な外部通信・ファイルアクセスがないか ■ バージョン管理（必須） 1. GitHub Actionsはコミット SHA で固定する（タグ指定禁止） 2. pip / npm の依存関係はロックファイルとハッシュで固定する 3. ロックファイルは必ず Git 管理する ■ CI/CD セキュリティ（必須） 1. シークレットは最小権限で付与し、有効期限を設定する 2. 自己ホスト型ランナーでは、実行後にシークレットの自動ローテーションを行う 3. 依存関係の変更を含む PR はセキュリティレビューを必須とする ■ AIツール利用（必須） 1. 未知のリポジトリでAIコーディングツールを起動する場合は サンドボックス環境を使用する 2. .claude/settings.json、.mcp.json、SKILL.md への変更は コードレビューの対象とする 3. AIツールの信頼ダイアログには、内容を確認せずに「許可」を押さない ■ インシデント対応 1. 侵害が疑われる場合は直ちにデバイスを業務利用から切り離す 2. 認証情報（APIキー、SSHキー、クラウドトークン）を即座にローテーションする 3. CI/CD パイプラインの実行履歴を確認し、不審なジョブがないか検証する
関連記事：AIエージェントの鍵管理・認証情報管理、シャドーツール接続リスク、インシデント対応計画の策定
よくある質問（Q&A）
Q1. 中小企業がサプライチェーン攻撃の標的になることはあるの？
あります。TeamPCPの攻撃はTrivyやLiteLLMという広く使われているオープンソースツールを狙っており、大企業だけでなく、これらのツールを使っているすべての組織が影響を受けます。むしろ中小企業のほうがセキュリティ体制が手薄なため、攻撃者にとっては「踏み台」として狙いやすいとも言えます。
Q2. GitHub Actionsでタグ固定からSHA固定に変更するのは大変？
技術的には簡単です。使用中のActionsのタグが指すコミットSHAを調べ（git ls-remoteコマンドで確認可能）、ワークフローファイルのバージョン指定をSHAに書き換えるだけです。更新時にSHAを確認する手間は増えますが、タグ差し替え攻撃を完全に防げます。
Q3. ClawHubやMCPマーケットプレイスは使わないほうがいい？
「使わない」ではなく「検証してから使う」が正解です。ClawHubはVirusTotalとの連携や報告機能の強化など対策を進めています。重要なのは、マーケットプレイスの「キュレーション済み」というブランディングを安全性の保証と混同しないことです。本記事のチェックリストを活用し、導入前に必ず検証してください。
Q4. すでにLiteLLMのv1.82.7やv1.82.8を使っていた場合は？
直ちにシステムを隔離し、LiteLLMの環境変数や設定ファイルに存在していたすべての認証情報をローテーションしてください。~/.config/sysmon/sysmon.pyが存在しないか確認し、checkmarx[.]zoneへの通信がないかネットワークログを確認してください。不審な点があれば、環境全体を初期化することを推奨します。
Q5. セキュリティ予算が限られている場合、何から始めればいい？
コストゼロでできる最優先事項は以下の3つです。(1) GitHub ActionsのSHA固定、(2) ロックファイルのGit管理、(3) AIツール設定ファイルのコードレビュー対象化。これだけでもTeamPCPタイプの攻撃リスクを大幅に低減できます。
まとめ——「信頼しているから安全」の時代は終わった
2026年3月の一連のインシデントは、AIツールのサプライチェーン攻撃が理論ではなく現実であることを決定的に証明しました。
特に重要な教訓は3つです。
1. セキュリティツール自体が攻撃の標的になる。Trivyは脆弱性を検知するツールですが、そのTrivy自体が侵害されました。「セキュリティツールを入れているから安全」という思考は危険です。
2. 設定ファイルは実行可能コードと同じ扱いが必要。AIツールの普及により、.jsonやmarkdownファイルが直接的な攻撃ベクトルになりました。コードレビューの対象を拡大してください。
3. 修復は「原子的」に行う。認証情報のローテーションが不完全だと、攻撃者に再侵害の機会を与えます。TeamPCPの事例はこの教訓を明確に示しています。
AIツールの活用を止める必要はありません。しかし、「信頼の前に検証する」姿勢を組織に根付かせることが、これからのAI活用時代に不可欠です。
関連記事
- AIエージェントのサプライチェーン攻撃入門——概念と一般的対策
- MCPセキュリティ——Model Context Protocolの安全な活用
- MCPサーバーの安全な運用ガイド
- AIエージェントの鍵管理・認証情報管理ガイド
- シャドーツール接続——従業員が勝手にAIツールを繋ぐリスク
- AI生成コードのセキュリティ脆弱性対策ガイド
- AIガードレール設計——安全なAIシステムの構築
- ゼロトラスト設計とAIエージェント
- AIセキュリティインシデント対応計画の策定
- NHI（Non-Human Identity）管理ガイド
免責事項：本記事は2026年3月26日時点の公開情報に基づく情報提供であり、特定の製品やサービスの推奨・批判を目的とするものではありません。各インシデントの詳細は変化する可能性があるため、最新情報は各公式ソースで確認してください。記載されているセキュリティ対策は一般的なガイダンスであり、自社環境への適用には専門家への相談を推奨します。
コメント