目次を表示する

AIセキュリティ 2026 ─ 開発からプロダクトまでの防衛術

サプライチェーンと自律実行 ─ axiosとReplitに学ぶ

第4章: サプライチェーンと自律実行 ─ axiosとReplitに学ぶ

Lethal Trifectaの完全成立とサプライチェーン事件

ここまで個別のCVEとMCPの攻撃を見てきた。本章では視点を1つ上げて、サプライチェーン汚染とAI自律実行が交わる地点を扱う。なぜここが重要かというと、AIエージェントがnpm installを自律的に走らせる時代では、人間のレビューを経ずに数千マシンで同時に侵害が拡大するからだ。

軸となる2つの事件：

  • axios npm 侵害（2026年3月31日）― 直近のサプライチェーン攻撃の代表例
  • Replit DB削除事件（2025年7月）― 自律実行の暴走の象徴

これらと、間にあるいくつかの事件を順に見ていく。

axios npm 侵害（2026年3月31日）─ AIエージェントが拡散速度を変えた

2026年3月31日、北朝鮮の脅威グループ Sapphire Sleet が axios maintainer のアカウントを乗っ取り、[email protected] と [email protected] にバックドアを注入した。Microsoft、CISAがそれぞれAlertを発出。(Microsoft: Mitigating axios npm compromise, CISA Alert)

axios は週間ダウンロード数が膨大なパッケージで、被害範囲は単一のCVEとしては最大級になった。

事件のメカニズム自体は、過去のtj-actions等と構造的に同じだ。しかし、今回は被害拡大の速度が違った。Elastic Security Labsの解析によれば、悪意あるRATは npm install 開始から1.1秒後に実行を開始した。(Elastic: Axios RAT analysis)

なぜ速度が問題になるか。AIコーディングエージェントは「依存追加」「セキュリティアップデート」「retry on install error」のような操作を人間の判断を介さずに実行する。エージェントが「依存をupgradeしておきますね」と判断してから1.1秒で侵害が完了する。人間の介入の余地がない。

sequenceDiagram
    participant Dev as 開発者
    participant Agent as AIエージェント
    participant npm as npm registry
    participant RAT as RAT (悪意ペイロード)
    Dev->>Agent: 「依存を最新にして」
    Agent->>npm: npm install axios
    Note over npm: 汚染された[email protected]取得
    npm->>Agent: install完了
    Agent->>RAT: postinstall実行（1.1秒）
    RAT->>RAT: ~/.aws, ~/.ssh, env を窃取
    RAT->>Attacker: 外部送信
    Note over Dev: ここでようやく<br/>「あれ何か変」と気付く

根本原因：

  1. npm の信頼モデルが maintainer 単位（accountをロストすれば即終わり）
  2. AIエージェントが npm install を自律実行できる
  3. postinstall script の実行を止める標準的な仕組みがまだ普及していない

脱出法：

  • npm install --ignore-scripts をデフォルト化（エージェント設定でも強制）
  • npm audit signatures で provenance 検証
  • npm@10以降の --package-lock-only ＋ 別工程での実体取得 と検証
# ✅ AIエージェントに使わせるinstallコマンドの例
npm ci --ignore-scripts && \
  node ./scripts/verify-package-provenance.js && \
  npm rebuild  # postinstall を意図的に走らせる場合だけ別工程で

Slopsquatting / Hallucinated Package ─ AIが幻覚で攻撃に加担する

Seth Larson（Pythonセキュリティリリースマネージャ）が「slopsquatting」と命名した攻撃。LLMがコード生成時に幻覚で「もっともらしいが存在しないパッケージ名」を生成する性質を、攻撃者が先回りして利用する。

ある研究で 16モデル × 756,000サンプル のコード生成を分析した結果：

  • 約20% の生成コードで、存在しないパッケージが推奨された
  • そのうち 43% が10回以上同じ幻覚を再現した（つまり攻撃者にとって狙い撃ちしやすい）

実例として、架空の huggingface-cli パッケージが攻撃者によって登録されたあと、3か月で30,000+ ダウンロード を記録した。(Trend Micro: Slopsquatting)

根本原因：

  • LLMの幻覚は決定論的に再現されやすい
  • 開発者は「AIが言ってるんだから多分ある」と信じてしまう
  • npm/PyPI の typosquatting 検知は人間のtypoを前提にしており、LLM hallucinationは射程外

脱出法：

  • AIが提案したパッケージは人間が必ず最新ダウンロード数とpublisherを確認する
  • AIエージェントに「存在検証なしのinstallを禁止」のルールを与える（後述）
  • 組織の private registry を使い、ホワイトリスト方式に切り替える
# ✅ AGENTS.md / .cursor/rules / CLAUDE.md に書くべきルール例
依存パッケージの追加について:
- npm/PyPIにある既知のパッケージのみ追加してよい
- 追加前に以下を必ずユーザーに見せて承認をもらう:
  1. パッケージ名
  2. 最新バージョン
  3. 週間ダウンロード数（< 1000 は要警戒）
  4. メンテナのアカウント
  5. リポジトリURL
- 「思い出した」「だいたいこれで動くはず」での追加は禁止

tj-actions/changed-files (CVE-2025-30066) ─ GitHub Actions経由のsecrets漏洩

2025年3月14-15日、GitHub Actions の人気アクション tj-actions/changed-files が侵害された。コミットSHAでpinしていなかった23,000+ リポジトリが影響を受け、ランナーメモリのsecretsがログにダンプされた。(Wiz: tj-actions analysis)

教訓：GitHub Actionsを @v1 のような タグ参照ではなく、コミットSHAでpinする。

# ❌ 危険：タグはmaintainerが書き換え可能
- uses: tj-actions/changed-files@v45

# ✅ 安全：コミットSHAでpin
- uses: tj-actions/changed-files@a284dc1814e3fbfcc1dd2ca5b1f1e3f5bca5e4de # v45.0.7

Dependabotがコミットpinの自動更新をサポートしているので、運用負荷は最小化できる。

GhostAction（2025年9月）─ AIで信頼性を装うworkflow汚染

GitGuardianが発見したキャンペーン。327ユーザ・817リポジトリで、攻撃者が**「Add Github Actions Security workflow」という説得力のある名前**のworkflowをPRで提案。マージされるとPyPI/npm/DockerHub のトークン3,325件が外部送信された。

読みどころ：攻撃者はAI生成と思しきcommit messageと、セキュリティ向上を装うworkflow名を使い、レビュー担当者の警戒心を下げた。「AIで生成された安全そうなコード」が、もはや警戒対象になる時代だ。

運用ルール：

  • 外部コントリビューターからの workflow 追加は専門レビュアー必須
  • Bot生成PRに「ai-generated」ラベルを付ける文化を定着させ、レビュー時間をむしろ増やす

MaliciousCorgi（2026年1月）─ VS Code Marketplace 経由

Koi Security が発見。「ChatGPT - 中文版」「ChatGPT - ChatMoss」という拡張がVS Code Marketplaceで合計150万installを獲得。中国サーバへ全ファイルの開閉・編集を送信していた。

教訓：

  • Marketplace install数は信頼の指標にならない（培養可能）
  • VS Code拡張の権限を install 前に確認する習慣
  • 組織で許可拡張のホワイトリスト管理

Hugging Face nullifAI（2025年2月）─ MLモデル経路のサプライチェーン

ReversingLabs/JFrogが発見。7-zip圧縮されたPyTorch picklesがPicklescan検知を回避し、ロード時にリバースシェルを起動。pickleの構造的な弱点を悪用した。

教訓：

  • pickle形式のモデルは、ロード = 任意コード実行と同義
  • 信頼できないモデルは safetensors 形式のみに限定する
  • Hugging Face で削除されたmodel namespaceの再取得攻撃（Model Namespace Reuse, Palo Alto Unit 42）にも注意

Replit DB削除事件（2025年7月）─ 自律実行の限界

「はじめに」で触れた事件を、本章でもう一度深掘りする。Jason Lemkin（SaaStr創業者）がReplit上で検証していたとき、AIコーディングエージェントが**「コードフリーズ中、何も変更しないこと」と明示された指示を破って**本番DBを削除した。1,200を超えるエグゼクティブのレコードと1,190社近い企業データが消えた。AI Incident Database #1152として記録。

ここで重要なのは、AIが3つのことを同時にやった点：

  1. 明示的な指示違反（「変更するな」を破った）
  2. destructive action の自律実行（DROP系操作）
  3. 虚偽報告（「ロールバック不可能」と回答、実際は可能）

これは古典的なソフトウェアバグでは説明できない挙動だ。「LLMの判断」「LLMのツール実行権限」「LLMの自然言語応答」が組み合わさって生まれる、新種の運用リスクだ。

graph TD
    Lemkin[Jason Lemkin: <br/>'コードフリーズ中、変更禁止'] --> Agent[Replit AI Agent]
    Agent -->|判断| Decide[判断: 'これは推奨される修正'<br/>指示を上書き]
    Decide -->|destructive tool| DB[本番DB削除]
    Agent -->|応答| Lie[応答: 'ロールバック不可能']
    Real[実際: ロールバック可能] -.- Lie
    style Lie fill:#fcc
    style DB fill:#fcc

事件後、Replitは以下を導入した：

  • dev/prod DB の自動分離
  • Planning-only モード（ツール実行を伴わない設計討議のためのモード）
  • ロールバック手順の常時提示

運用ルール（あなたの組織でも今日から適用できる）：

  • AIエージェントを 本番環境に直接アクセスさせない
  • DB操作系は必ず staging で確認 → 人間承認 → prod 適用
  • destructive action（DROP, DELETE, rm, force push）には特権昇格に相当する承認フローを設ける

Lethal Trifecta が完全に揃う環境

第1章で導入した Lethal Trifecta を、ここまでの事件でなぞる。

事件①プライベートデータ②untrustedコンテンツ③外部通信
axios 侵害env, ssh, AWS creds汚染npmパッケージRAT がC2へ送信
Slopsquattingdev環境LLM hallucinationinstall scriptが任意HTTPS
tj-actionsGH Actions secrets改変actionログ経由で漏出
GhostActionGH Actions secrets偽workflow PRwebhookへPOST
MaliciousCorgiローカルファイル全部拡張本体中国サーバへ送信
postmark-mcpメール本文改変MCPBCC で攻撃者へ
Replit本番DB（明示的指示違反）（指示違反による destructive action）

綺麗なくらい全部揃っている。だからこそLethal Trifectaは「3つを同時に許さない」という原則として効く。

防衛策の統合 ─ 4層モデル

サプライチェーン × 自律実行 への対策を4層で整理する。

1. Provenance（出自）
   - npm: provenance attestations 必須
   - GitHub Actions: コミットSHA pin
   - PyPI: TUF / Sigstore
   - MLモデル: safetensors 限定、署名検証

2. Sandbox（隔離）
   - DevContainer + ネットワーク allowlist
   - postinstall script の無効化
   - destructive action の sandbox 内でのドライラン

3. Approval Gate（承認ゲート）
   - 依存追加の人間レビュー
   - destructive action の明示的承認
   - Plan Mode で「実行前に計画を提示」
   - prod 環境への直接アクセス禁止

4. Observability（観測）
   - npm install 時の outbound 通信監視
   - AIエージェントのツール呼び出しログ
   - secrets 流出検知（GitGuardian 等）
   - DB操作の audit log

AIエージェント運用のチェックリスト

axios + Replit から学んだルールを、組織のAGENTS.mdに書くテンプレート：

# AI Agent運用ルール

## destructive action（必ず人間承認）
- DROP TABLE / DELETE FROM / TRUNCATE
- rm -rf / git push --force / npm publish
- AWS/GCP/Azure リソース削除
- secrets 系の値の出力

## 自律install禁止リスト
- npm install --ignore-scripts を必ず付ける
- 新規パッケージは publisher と週間DLを確認
- Slopsquatting対策: AIが「初めて聞くパッケージ名」を提案したら必ず存在検証

## prod環境
- AIエージェントから prod DB / prod インフラへの直接アクセス禁止
- prod 用の secrets はホストOSにも保存しない（vault経由）

## 緊急停止
- ctrl+C / killall で即停止できる状態を常に維持
- 長時間タスクは「進捗ログ + 30分ごとの中断確認」を強制

検証方法

□ npm install --ignore-scripts がデフォルトか
□ GitHub Actions が全部コミットSHA pinされているか
□ npm provenance を確認しているか（npm audit signatures）
□ AIエージェントから prod 環境へのアクセス経路を物理的に塞いでいるか
□ destructive action の人間承認フローがあるか
□ secrets が vault 経由になっているか（ホストOSに置いていないか）
□ MLモデルが safetensors 形式に統一されているか
□ AIエージェントのツール呼び出しがログ集約されているか
□ AGENTS.md / CLAUDE.md に運用ルールが明記されているか

本章の要点

#要点
1axios npm 侵害（2026-03）は被害拡大速度が桁違い。AIが自律的に install するから人間介入の余地がない
2Slopsquatting は「LLMの幻覚を攻撃ベクタ化」する新型。43%の幻覚が再現性を持つ
3GitHub Actions はコミットSHAでpin、postinstall script はデフォルト無効化
4postmark-mcp、MaliciousCorgi、nullifAI の事例は「配布チャネルそのものが攻撃面」
5Replit DB削除事件は「指示違反 + destructive action + 虚偽報告」の三段重ね、自律実行の象徴
6Lethal Trifecta は本章のすべての事件で綺麗に揃う
7防衛は「Provenance / Sandbox / Approval Gate / Observability」の4層

効いている根本原理

本章は 原理2（Lethal Trifecta） が最も濃く効いた章だった。原理3（最小権限） はprod環境への直接アクセス禁止に、原理4（Defense in Depth） はProvenance + Sandbox + Approval Gate + Observabilityの4層に対応する。

ここまでで第1部「開発プロセスを守る」は完了だ。次の第5章から第2部に入り、今度はあなたが世に出すAIプロダクトを守る側に視点を切り替える。同じ4原理が、まったく同じ式として効くのを見ていく。