問題点を一文で表すと
次回は AIアシスタントがインストールするパッケージを推奨しますでは、そのパッケージが実際に存在するかどうかを実際に確認するつもりですか？ほとんどの開発者は確認していません。提案と検証の間のこのギャップこそが、スロップスクワッティング攻撃の始まりであり、スロップスクワッティングの進化と実践的なスロップスクワッティング防止策の両方を理解することが、AppSecおよびDevSecOpsチームにとって真の優先事項となっている理由です。
スロップスクワッティング攻撃とは何ですか？
スロップスクワッティング攻撃は、 しゃがんだ （一般的なスペルミスなどによって正規のドメイン名やパッケージ名を模倣したドメイン名やパッケージ名を登録する行為。 リクエスト リクエスト（ユーザー自身のタイプミスによって直接そのパッケージにたどり着けることを期待して）しかし、重要な違いは、そのミスの発生源にあります。タイプスクワッティングは人間のタイプミスを悪用します。スロップスクワッティング攻撃は、大規模言語モデルが犯すミスを悪用します。つまり、LLMは完全に正当に聞こえるがどの公開レジストリにも存在しないパッケージ名を「幻覚」し、攻撃者は善意の人が登録する前にその正確な名前を登録することで、最初にそこにたどり着きます。
典型的なスロップスクワッティング攻撃の仕組みは単純であり、その単純さこそが効果を発揮する理由である。
- 開発者がAIアシスタントにコーディングの問題解決を依頼する。
- このモデルは、これまで存在しなかったパッケージをインポートしたり、インストールを推奨したりするソリューションを生成します。
- 複数のモデルが同じ架空の名前を繰り返し使用していることに気づいた攻撃者は、悪意のあるコードを仕込んだパッケージをnpm、PyPI、またはその他の公開レジストリに登録します。この瞬間、架空の名前が実際のスロップスクワッティング攻撃へと発展します。
- 次に同じ提案を受けた開発者がそれを検証せずにインストールすると、そのパッケージは正式に公開され、開発者の環境へのバックドアとなる。
「スロップスクワッティング」という用語は、Pythonソフトウェア財団のセキュリティ開発者であるセス・ラーソンによって造語され、アンドリュー・ネスビットによって広められたもので、まさにこのパターン、つまり「パッケージの幻覚」が攻撃ベクトルに転用される様子を説明するために用いられた。
スロップスクワッティングの進化：研究上の好奇心がどのようにして現実の脅威へと発展したか
スロップスクワッティングの進化で注目すべき点は、その概念そのものだけではなく、研究上の観察から、記録され測定可能な攻撃形態へと、いかに急速に移行したかということである。
2023年：最初の警告サイン。 セキュリティ研究者のバー・ラニャド いくつかのLLMが繰り返しパッケージを推奨していることに気付いた ハグフェイスクリ存在しないパッケージは、 pip install -U “huggingface_hub[cli]”) リスクを実証するために、彼はそのパッケージの空のファイルを公開レジストリにアップロードした。すると、宣伝を一切行わなかったにもかかわらず、3か月以内に3万回以上ダウンロードされた。この架空の名前は、アリババの研究に関連するリポジトリのREADMEにも登場し、こうした「偽の」名前が実際のドキュメントに紛れ込み、その後に続くスロップスクワッティング攻撃の舞台を整える可能性があることを早期に示していた。
2024年：リスクは研究者のブログ記事から主流のテクノロジー報道へと移行する。 月2024で、 登録 AIモデルが自信満々にソフトウェアパッケージ名を生成し、開発者がそれをダウンロードする様子が報じられた。その中にはマルウェアが仕込まれている可能性のあるものもあった。この報道は、技術的な内容よりも、それが示唆したことの方が重要だった。huggingface-cliの事例はもはや単発的な珍しいケースではなく、主流のテクノロジー系メディアが注目するほど深刻なパターンの最初の兆候であり、1年後に大規模な学術研究によってその規模が確認されることになる。
2025年：この問題に関する初の厳密かつ大規模な測定。 紙 「あなたにぴったりのパッケージをご用意しました！コード生成型LLMによるパッケージ幻覚の包括的分析」 (Spracklen et al.、 USENIX セキュリティ シンポジウムでは、商用（GPT-4、GPT-3.5）とオープンソース（CodeLlama、DeepSeek、WizardCoder、Mistral）の両方を含む16のコード生成モデルを、576,000のPythonおよびJavaScriptコードサンプルでテストしました。この結果は、スロップスクワッティングの進化における明確な転換点を示しており、逸話からデータへと移行しています。
- 19.7% モデルが推奨したパッケージの中には、存在しないものがあった。
- オープンソースモデルははるかに頻繁に幻覚を起こした（21.7% 平均して）市販モデルよりも5.2%).
- 最も悪質なCodeLlama 7BとCodeLlama 34Bは、出力の3分の1以上で幻覚を呈していた。
- テストされたすべてのモデルで、研究者たちは 205,000 種類の幻覚的なパッケージ名複数の生態系にわたる持続的な不法占拠攻撃を支えるのに十分な大きさの水たまり。
- 予防に特に重要な詳細が1つあります。おおよそ 38% 幻覚で作成された名前は実際のパッケージと非常によく似ているため、一目でそれとわかる可能性は低くなります。
この研究で明らかになった重要な点、そしておそらくスロップスクワッティングの進化が衰退するどころか加速している理由でもあるのは、架空の名前がランダムではなく、試行のたびに変わるわけでもないという点です。同じモデルは、類似のプロンプトを与えられた場合、同じ架空の名前を繰り返す傾向があるため、攻撃者は推測する必要がありません。モデルの動作を観察し、繰り返し出現する名前を特定し、実際の開発者よりも先に登録すればよいのです。この再現性に関する追跡分析では、研究者が同一のプロンプトをそれぞれ10回ずつ再実行したところ、架空のパッケージ名の43%が毎回出現し、58%が複数回出現したことが判明しました。これは、ほとんどの架空の名前が単発のノイズではなく、再現可能なアーティファクトであることを示しています。この再現性こそが、単発の架空の名前をスケーラブルなスロップスクワッティング攻撃へと変える要因なのです。
2026年：孤立したパッケージから自律型エージェントへ。 今年は、スロップスクワッティングがもはや開発者が提案をコピー＆ペーストするだけにとどまらないことを示す最も明確な証拠が得られた。 ピップインストール or npmインストール コマンド。2026年1月、研究者 チャーリー・エリクセン Aikido Security では、AI コーディング エージェントがすでに幻覚の npm パッケージを参照する指示を拡散していたことが判明しました。 react-codeshift （2 つの実際のツールを混同していると思われる名前、 jscodeshift (NAIST) と react-codemod）は237のリポジトリに存在し、エージェントは毎日インストールを試みている。エリクセンは、攻撃者が悪用する前に、防御的に自らその名前を登録した。別件では、という実際の悪意のあるパッケージが 未使用のインポート正当なものの代わりに幻覚として現れる eslintプラグインの未使用インポートは、npm がセキュリティ ホールドをかけたにもかかわらず、2026 年初頭には依然として週あたり約 233 のダウンロードを記録しており、スロップスクワッティング攻撃がフラグ付けされた後でもどれだけ長く被害者を引きつけ続けることができるかを示しています。さらに最近では、2026 年 7 月に、研究者らは「HalluSquatting」と呼ばれる関連技術について説明しました。これは、AI の幻覚とプロンプトの注入を連鎖させることで、ユーザーに代わって幻覚のリソースを取得する AI コーディング エージェントを乗っ取り、攻撃者が提供したコードを実行させるもので、スロップスクワッティングの進化を、受動的なインストールのリスクから、エージェント開発ワークフロー内の能動的なリモート コード実行ベクトルへと拡張しています。
なぜ「バイブコーディング」がスロップスクワッティング攻撃の表層を拡大させたのか
AIが生成するコードがニッチな手法であれば、スロップスクワッティング攻撃はそれほど問題にならないだろう。しかし、そうではない。コーディングアシスタント、自律型エージェント、そして開発者がコードを実行する前にレビューする時間がますます少なくなる「バイブコーディング」ワークフローの台頭により、ソフトウェア攻撃の対象領域は2つの具体的な方法で変化しており、どちらもスロップスクワッティングの進化を加速させている。
- 参入の起点はもはや開発者だけではない。 かつてタイポスクワッティング攻撃は、一人のユーザーが入力ミスをすることに依存していました。しかし現在では、そのミスはモデル自体の内部で発生し、同様の質問をする数百人もの開発者に伝播し、同じ誤った推奨事項を受け取ることで、単一のタイポスクワッティング攻撃の影響力が大幅に拡大しています。
- 攻撃対象領域は、サプライチェーンの上位へとさらに拡大した。 人間が書いたコードを監視するだけではもはや十分ではありません。チームは、AIアシスタントが提案する依存関係、接続するMCPサーバー、そして人間の直接的なレビューなしにパッケージを自律的にインストールするエージェントも監視する必要があります。リポジトリと人間のコードをレビューするために構築された従来のAppSecは、 commits は、開発者、AI、パッケージレジストリ間のこの新しい相互作用を監視するように設計されておらず、まさにそこにスロップスクワッティング攻撃が潜んでいるのです。
だからといって、生成型AIが本質的に安全でないというわけではありません。これは、従来のセキュリティツールでは検知できない新たなタイプのサプライチェーンリスクをもたらすことを意味します。そして、あらゆる外部依存関係に適用しているのと同じ検証原則、つまり、デフォルトで信頼せず、ソースを検証し、開発者一人ひとりの記憶力や注意深さに頼るのではなく、その検証を自動化することが求められます。この自動化こそが、真の意味でのスロップスクワッティング防止戦略の基盤となるのです。
スロップスクワッティング防止策：チームが今日からできること
朗報は、スロップスクワッティング防止には特別なツールは必要ないということです。必要なのは、既に存在する依存関係管理の実践を体系的に適用することです。しかし、多くのチームは、信頼できるAIがコードを「提案」した途端に、その実践を怠ってしまいます。効果的なスロップスクワッティング防止アプローチは、通常、以下の要素を組み合わせたものです。
- 新しいパッケージをインストールする前に、手動で検証してください。特にAIアシスタントの提案である場合は注意が必要です。公式レジストリに登録されているか、誰が管理しているか、いつ公開されたか、ダウンロード数が本物かどうかを確認してください。この習慣は、どのチームにとっても最も安価なスロップスクワッティング防止策です。
- AIが生成したコードは、デフォルトで安全だと決して思い込まないでください。 動作するコードスニペットだからといって、その依存関係が正当であるとは限りません。依存関係のレビューはコードレビューの一部であるべきであり、例外であってはなりません。
- ロックファイルとハッシュ検証を使用する 正確なバージョンを固定し、サイレントアップデートによって、最初に監査されたパッケージとは異なるパッケージが置き換えられるのを防ぐ。
- 既知のCVEを超えるリスクパターンを検出する依存関係スキャンを展開する異常なパッケージ、既存のパッケージ名と疑わしいほど似た名前、実績のない新しいメンテナー、または異常な動作をするインストールスクリプトなどが挙げられます。履歴がほとんどなく、既存のパッケージ名に酷似した名前の新規公開パッケージは、これまでに報告されているスロップスクワッティング攻撃のほとんどのパターンに当てはまります。
- 公的登録簿も同様に懐疑的に扱うcism は他の検証されていない外部情報源と同様です。 事実 ピップインストール or npmインストール エラーが発生しないことは、正当性の証明にはなりません。
- 開発チームを育成する AI支援コーディングは、インストールされる内容を検証する責任をなくすものではなく、単にワークフローに組み込む必要のある手順を追加するだけであり、これはあらゆる本格的な不正利用防止計画の一環として不可欠である。
これらの対策はどれもそれ自体は目新しいものではありません。変わったのは規模です。依存関係の提案がStack Overflowや同僚からではなく、何千人もの異なる開発者に対して同じ誤ったエラーを繰り返す可能性のあるモデルから来る場合、手動検証は依然として必要ではありますが、それだけでは不十分になります。そのため、より多くのチームが、このスロップスクワッティング防止のレイヤーを自動化しています。 ソフトウェア構成分析（SCA）ツーリング個々の開発者の規律に任せるのではなく、
これはcisどうして ASPM プラットフォーム ような ザイゲニ タイポスクワッティング、依存関係の混同、既知の悪意のあるパッケージなど、疑わしい依存関係の検出機能を、同じオープンソースおよびAI依存関係分析に組み込む。 pipelineつまり、スロップスクワッティングの防止は、AIアシスタントが新しい依存関係を提案するたびに、すべての開発者がそれをチェックすることを覚えておくことに依存するものではありません。
FAQ
スロップスクワッティング攻撃とタイポスクワッティング攻撃は同じものですか？
厳密には違います。どちらも偽のパッケージ名を登録してインストールするユーザーを騙すという点では共通していますが、エラーの発生源が異なります。タイポスクワッティングは人間の入力ミスを悪用するのに対し、スロップスクワッティング攻撃はAIモデルが作り出した（幻覚のような）パッケージ名を悪用し、攻撃者がそのパッケージが正式に存在する前に登録してしまうのです。
パッケージマネージャーは、このような攻撃を自動的に防ぐことができるのでしょうか？
完全に防ぐことはできません。まさにそれが、スロップスクワッティング対策がパッケージマネージャーのレベルにとどまらない理由です。攻撃者が開発者がインストールを試みる前に偽のパッケージを登録した場合、たとえ悪意のあるパッケージであっても、パッケージが実際に存在するため、インストールはエラーなく完了します。効果的な対策には、パッケージの出所と動作に関する追加的な検証が必要です。
これはオープンソースモデルのみに影響するのでしょうか？
いいえ。Spracklenらの研究では、市販モデルを含むテスト対象となったすべてのモデルで幻覚が見られましたが、その発生率は市販モデルに比べて著しく低く（5.2%に対し、オープンソースモデルでは21.7%）、完全に問題のないモデルは存在しません。そのため、AI支援コーディング全体の成長に伴い、スロップスクワッティングの進化も加速しているのです。
これは理論上のリスクなのか、それとも既に悪用されているのか？
その ハグフェイスクリ ある研究者がアップロードした空のパッケージが、何の宣伝もなしに3ヶ月で3万回以上ダウンロードされた事例は、リスクが単なる理論上のものではないことを示している。つまり、架空の名前が様々なプロンプトで十分に一貫していれば、誰かがそれを実際のスロップスクワッティング攻撃に利用できてしまうのだ。
