Slopsquattingとは — AI幻覚を悪用するサプライチェーン攻撃

Slopsquatting（スロップスクワッティング）は比較的新しい攻撃手法ですが、ソフトウェア開発のワークフローと深く結びついているため、注意が必要です。ここでは仕組み、見分け方、実務で使える予防策とインシデント対応を具体的に述べます。

Slopsquattingとは

SlopsquattingはAIの「幻覚（hallucination）」を悪用した攻撃です。まずAIツールが存在しないオープンソースのパッケージ名を提案します。攻撃者はその繰り返し出現する幻覚を観測し、同じ名前で悪意あるパッケージを作成してパブリックなリポジトリにアップロードします。

開発者が普段使っているAIプラットフォームにパッケージの提案を求めると、AIが幻覚として生成した名前が返されることがあります。もしその名前が既に攻撃者によって悪意あるパッケージとして公開されていれば、開発者は意図せずそれを依存関係に組み込み、実行環境にマルウェアを持ち込んでしまう可能性があります。

重要な特徴は次の通りです。

• 攻撃はAIモデルの出力（幻覚）に依存する。
• 幻覚で繰り返されるパッケージ名が狙われる。
• 攻撃者は既存の信頼されるリポジトリ（例：npm、PyPI、GitHub）に偽パッケージを公開する。
• 開発者が検証を怠ると、マルウェアが組み込まれ、実行された環境に被害が及ぶ。

研究でわかったこと（要点）

ある調査によると、16の主要なコード生成AIモデルのうち、推奨されたパッケージの約20%が存在しなかったと報告されました。また、幻覚として生成されたパッケージ名のうち43%は、同一プロンプトを10回実行しても毎回繰り返し出現したという指摘があります。調査ではCodeLlamaが比較的多くの幻覚を示し、GPT-4 Turboは最も少なかったとされています。

これらの観察は「幻覚が再現性を持つ」ことを示しています。再現性があるほど攻撃者は狙いを定めやすく、偽パッケージの命名と配置が成功しやすくなります。

気をつけるべき兆候（五つ）

開発者レベルで即座に確認できるチェックリストを示します。これらは必ずしも偽パッケージを確実に見抜ける訳ではありませんが、危険性の判断に有効です。

1. わずかな綴り違い（スライト・ミススペル）
   • 正規のパッケージと一文字だけ違う名前は要注意です。だが多くの幻覚名は元の正規名とまったく別の新規名の場合もあります。
2. ディスカッションやフィードバックがない
   • 評価やIssues、スターがほとんどないパッケージは、新規の正当な公開か偽パッケージか判断が難しい。慎重に扱ってください。
3. 他の開発者からの警告
   • 検索やSNSでそのパッケージ名を検索し、警告や報告がないか確認する習慣を持ちましょう。
4. 別のAIプラットフォームで推奨されない
   • 同じプロンプトで複数のAIに問い合わせ、推奨が一貫しているかを確認します。もし片方だけが提案するなら追加調査を。
5. 説明が曖昧・混乱している
   • ホスティングサイト上の説明文が不自然、または動作説明や導入例が無い場合は警戒が必要です。

最も重要な予防策（優先度順）

ここでは現場で直ちに実行できる具体的な対策を示します。どれも導入コストは比較的低く、効果は高いです。

1) サンドボックス環境でのテスト実行（最優先）

• 実行前の依存関係はまず安全な隔離環境で動作させてください。ローカルの仮想マシン（VirtualBox、VMware）やクラウド上の隔離環境を利用します。Replitのように多言語をサポートするオンライン環境も有効です。
• サンドボックスはネットワークアクセス（外部通信）やファイルI/Oを制限しておくと、安全性がさらに高まります。

2) パッケージスキャンの導入

• ダウンロード前にパッケージをスキャンするツールを利用します。例としてSocketのブラウザ拡張は複数サイトでスキャン可能で、Chrome系ブラウザ・Firefoxで利用できます。
• CIパイプラインに静的解析・ソフトウェア構成分析（SCA）ツールを組み込み、依存関係の安全性チェックを自動化します。

3) AI提案の人間による検証（必須）

• AIは補助ツールと位置付け、提案されたパッケージは必ず人間が検証してから採用するポリシーを組織内で徹底してください。
• 検証プロセスには次を含めます：公式リポジトリの有無、公開履歴、メンテナ情報、利用実績、外部の評判。

重要: AIへの過度な依存は攻撃の温床になります。AIはアイデア出しや下書き、検索補助に留めるべきです。

追加の防御策（エンタープライズ向け）

• 依存関係のホワイトリスト化（allowlist）: 承認済みのレジストリやパッケージ名のみ使う運用。
• パッケージ署名と検証: 署名済みパッケージのみを許可するポリシー。
• バージョン固定（pinning）: 不明な最新バージョンを自動で取り込まない。
• レジストリミラーの利用: 組織内ミラーからのみパッケージを取得させる。

これらは導入に運用コストがかかりますが、被害発生のリスクと比較すると有効です。

現場で使える簡易チェックリスト（役割別）

開発者のチェック（毎回）

• AIが提案したパッケージ名をコピペして公開情報を検索したか
• リポジトリにstars・issues・コミット履歴があるか
• サンドボックスで実行して怪しい挙動がないか確認したか

セキュリティエンジニアのチェック（CI / レビュー）

• SCAツールでのスキャン結果はOKか
• 署名や信頼できるソースからの入手かどうか
• 依存関係のトランスポアレンシー（間接依存含む）を確認

マネージャー / チームリードの責務

• AI利用ポリシーの周知と教育を行ったか
• 依存ポリシー（allowlist/denylist）の導入と運用を進めているか

ミニSOP：slopsquatting疑い時の標準手順

1. そのパッケージの使用を一時停止。
2. パッケージ名で検索し、既知の警告がないか確認。
3. サンドボックスでインストール→実行→挙動ログを収集。
4. SCAツールでソースコード・バイナリのスキャンを実行。
5. 異常が見つかれば、当該コミット／PRをリバートし、影響範囲を特定。
6. レポートを作成し、社内と外部（リポジトリホスト、AIベンダー）へ通知。

インシデント対応（実践的な手順）

1. 検知：開発者または自動化ツールが疑惑を報告。
2. 分離：該当ノード・CIジョブを切断し、被害が拡大しないよう隔離する。
3. 証拠保全：ログ、ネットワークキャプチャ、インストール済みファイルを保存。
4. 影響範囲の精査：どのビルド、どの環境で実行・展開されたかを追跡。
5. 回復：悪意ある依存を削除してビルドを再作成。必要ならロールバック。
6. 報告と学習：外部通報（リポジトリホスト、AIベンダー）、社内レトロスペクティブで対策を更新。

ロールバックのヒント

• 影響リリースが特定できる場合は即時ロールバック。自動化されたデプロイならロールバック手順を事前に用意しておく。
• さらに被害が疑われる場合は秘密情報の再生成（APIキー／シークレットのローテーション）を行う。

テストケースと受入基準（サンプル）

• テスト1: AIが提案したパッケージをダウンロードし、サンドボックス内で30分間実行して異常なネットワーク接続が発生しないこと。
• テスト2: SCAツールでクリティカルな脆弱性や既知のマルウェアシグネチャが検出されないこと。
• 受入基準: すべての自動テストを通過し、リポジトリに少なくとも3つの独立した正の指標（スター、フォーク、コミット履歴）を確認できること。

判断のためのメンタルモデル（ヒューリスティック）

• 「再現性」: AIが同じ名前を繰り返し生成しているか？
• 「露出」: 外部からの参照や実績はあるか？
• 「説明責任」: パッケージに責任を持つ人（メンテナ）の情報はあるか？
• 「最小権限」: その依存を取り込むと何ができるようになるかをレビューする（原則、最小特権）。

いつこの対策が効かないか（カウンター例）

• 攻撃者が既に長期間存在するように見せかけた偽のコミット履歴やスターを作成している場合、単純な「履歴で安全性を判断する」手法は失敗します。
• 組織が自前の内部ミラーを使っていない、或いはCIにスキャンが組み込まれていない場合、自動化された検出が間に合わないことがあります。

用語集（ワンライン）

• 幻覚（hallucination）: AIが事実とは異なる情報を自信ありげに生成する現象。
• Typosquatting: タイポ（綴り間違い）を利用したドメイン/パッケージの偽装攻撃。
• SCA: ソフトウェア構成分析。依存関係の脆弱性管理手法。

まとめと行動項目

• SlopsquattingはAIの幻覚を悪用した現実的なリスクです。再現性のある幻覚が攻撃者の命名戦略と一致するとリスクが高まります。
• まずはAIの提案を盲信せず、サンドボックス実行・パッケージスキャン・人間による検証を必ず行ってください。
• 企業レベルではallowlist、署名検証、依存の固定化、CIでの自動スキャン導入を推奨します。

重要: もしslopsquattingの犠牲になったら、被害情報を共有して他の開発者を守ることが重要です。リポジトリのサポートやAIベンダーに通報し、警告を拡散してください。

付録：短いチェックリスト（コピーして使える形式）

• AI提案パッケージの名前を検索した
• リポジトリのスターとコミット履歴を確認した
• サンドボックスでインストールおよび動作確認を実施した
• SCAスキャンを通過した
• 署名/公式ソースを確認した

付録：外部通報テンプレート（例文）

件名: 偽パッケージの報告 — [パッケージ名]

本文:

• 発見日時: YYYY-MM-DD
• 発見方法: AI提案による
• 該当パッケージ: [パッケージ名]（リンク）
• 影響: 開発環境での依存に使用され、サンドボックスで疑わしい挙動を確認
• 添付: 実行ログ／SCA結果

お願い: 当該パッケージの調査と必要な対処（削除、警告表示等）をお願いします。

参考（読むと役立つトピック）

• AIの幻覚問題に関する研究メモ
• SCAツールとCI統合のベストプラクティス
• ソフトウェア供給網（SBOM）と依存管理