スロップスクワッティングとは何ですか？

スロップスクワッティングとは何ですか？ これは攻撃です 悪意のある攻撃者が、AIコーディングアシスタントが幻覚で認識するパッケージ名を正確に登録し、それらのパッケージにマルウェアをロードして、開発者がインストールするのを待つというケースです。これは例外的なケースではありません。 USENIXセキュリティ2025、 57万6000件のコードサンプルにおいて、AIコーディングモデルが推奨したパッケージのうち19.7%は実在せず、研究者らはテスト対象となったモデル全体で20万5000件を超える架空の名前を記録した。

スロップスクワッティングとは何か（そしてスロップスクワッティングの意味が実際にはどのようなものか）を理解することは重要です。なぜなら、それは単なるAIの癖ではないからです。スロップスクワッティングはAI時代の後継者であり、 しゃがんだただし、決定的な違いが1つあります。タイポスクワッティングは人間の入力ミスに依存するのに対し、スロップスクワッティングはモデルのミスに依存し、攻撃者が大規模に悪用できるほど予測可能な形で繰り返されるミスに依存します。このガイドでは、スロップスクワッティングとは何か、パッケージレビューで検出できるよりも速く拡散する理由、それが生み出すリスク、そして組織が本番環境に到達する前にそれを発見して防止する方法について説明します。

スロップスクワッティングの意味：定義 #

スロップスクワッティングとは、正式には、大規模な言語モデルが誤認するパッケージ名、もっともらしく聞こえるがどの公開レジストリにも存在しない架空の名前を登録し、悪意のあるコードをロードする行為を指す。 実際の開発者がAIの提案に基づいてインストールする前に.

この用語は、タイポスクワッティング（一般的なスペルミスによって実際のパッケージ名を模倣したパッケージ名を登録すること）の概念を、生成AIの特定の失敗モードに拡張したものです。タイポスクワッティングが人間のタイプミスを悪用するのに対し、スロップスクワッティングは AIモデルの幻覚n: コーディングアシスタントが、実際には存在しないパッケージに対して pip install または npm install を推奨し、プロンプト全体で同じ架空の名前が繰り返し出現することに気づいた攻撃者が、それを最初に登録します。

スロップスクワッティングとは、実際には次のような意味を持つ。AIの提案を信頼する以外に人為的なミスを一切必要とせず、モデルのミスを悪用可能なエクスプロイトに変えるサプライチェーン攻撃である。これは理論上の話ではない。2023年に無害なテストとして仕掛けられたたった1つの偽パッケージが、何の宣伝もなしに3ヶ月で3万回以上ダウンロードされ、このパターンを悪用する悪意のある亜種が現在、公開レジストリで実際に活動していることが確認された。

スロップスクワッティングとタイポスクワッティング：違いは何ですか？ #

スロップスクワッティングとタイポスクワッティングは、同じ結果（開発者が正規のパッケージだと信じて悪意のあるパッケージをインストールしてしまう）をもたらすが、エラーの原因は根本的に異なる。

タイポスクワッティングは、人間の入力ミスに依存しています。開発者が「requests」と入力しようとして「requests」と入力してしまうと、そのスペルミスのある名前を登録していた攻撃者が待ち構えています。リスクは、開発者のたった1回のキー入力、ほんの一瞬の不注意に左右されます。

スロップスクワッティングは、人間のミスを完全に排除し、モデルのミスに置き換えます。このミスは、同様のプロンプトを受け取ったすべての開発者に対して大規模に繰り返されます。追跡分析の結果、研究者が同一のプロンプトをそれぞれ10回実行したところ、偽のパッケージ名の43%が毎回出現し、58%が複数回出現したことがわかりました。この再現性こそが、スロップスクワッティングを悪用可能にする要因です。攻撃者はタイプミスを推測する必要はありません。モデルが繰り返し出現する偽の名前を観察し、実際の開発者よりも先にそれを登録するだけでよいのです。

最大の違いは規模です。タイポスクワッティングされたパッケージは、入力ミスを待ちます。一方、スロップスクワッティングされたパッケージは、同じAIが生成した推奨事項が次の開発者、その次の開発者、さらにその次の開発者へと、同じモデルを使用するすべての組織に届くのを待ちます。

なぜスロップスクワッティングスプレッドなのか？ #

スロップスクワッティングが蔓延する理由は、タイポスクワッティングが常にそうであったのと同じである。攻撃者は、開発者がデフォルトで信頼している予測可能なパターンを悪用するのだ。新しいのは、その信頼の規模である。

AI支援コーディングの台頭自律型エージェントや、開発者がコードを実行する前にレビューする頻度がますます少なくなる「バイブコーディング」ワークフローの普及により、ソフトウェアの攻撃対象領域は2つの具体的な方法で変化しました。

侵入経路はもはや開発者だけにとどまりません。タイポスクワッティング攻撃は、たった一人の入力ミスから始まることがあります。スロップスクワッティングはモデル内部から発生し、同様の質問をする数百人もの開発者に拡散し、同じ誤った推奨事項を受け取ることで、単一の攻撃の影響力を拡大させてしまう可能性があります。

攻撃対象領域はさらに上位に広がっています。人間が書いたコードをレビューするだけではもはや十分ではありません。チームは、AIアシスタントが提案する依存関係、接続先のMCPサーバー、そして人間の直接的なレビューなしにパッケージを自律的にインストールするエージェントも監視する必要があります。リポジトリと人間のコードをレビューするために構築された従来のアプリケーションセキュリティは、 commits は、開発者、AI、パッケージレジストリ間のこの新しい相互作用を観察するように設計されておらず、まさにそこにスロップスクワッティングが潜んでいます。

不法占拠のリスク #

不法占拠は、互いに複合的に作用する様々な側面でリスクを生み出し、その傾向は衰えるどこ​​ろか加速している。

• 繰り返し可能な悪用。 幻覚で生成される名前はランダムではないため、同じ偽名がセッションやモデルをまたいで予測可能な形で繰り返し出現します。攻撃者は推測する必要はなく、モデルの動作を観察し、繰り返し出現する名前を記録するだけで済みます。これにより、一度限りの幻覚が、拡張可能で再現性のある攻撃へと変化します。
• エージェントによる増殖。 スロップスクワッティングは、開発者が推奨インストールコマンドをコピー＆ペーストするだけにとどまらない。2026年1月、研究者たちは、AIコーディングエージェントが架空のnpmパッケージを参照する指示を既に237のリポジトリに拡散させており、エージェントは毎日そのパッケージのインストールを試み続けていることを発見した。しかも、この間違いに気づく人間は誰もいない。
• 名前類似性回避。 偽装されたパッケージ名の約38%は実際のパッケージ名と酷似しているため、開発者が一目で偽装に気づく可能性は低くなります。信頼できる依存関係とたった1文字だけ異なる悪意のあるパッケージ名は、一見すると怪しく見えず、まるで自分で入力ミスをしたかのように見えます。
• 検出後も継続的に曝露される。 正規のESLintプラグインを置き換えた偽のパッケージは、レジストリがセキュリティホールドをかけた後も毎週ダウンロード数を記録し続けており、不正にインストールされたパッケージにフラグを立てても、すぐにインストールを阻止できるわけではないことを示している。

不法占拠が隠れる場所 #

スロップスクワッティングの最も厄介な点は、攻撃が発生した瞬間には攻撃のように見えないことです。攻撃者がパッケージを登録すると、そのパッケージは実際に存在することになるため、通常のpipインストールやnpmインストールが正常に完了したように見えます。

不法占拠は通常、以下の経路で発生します。

• AIによるコーディングアシスタントと副操縦士。 脆弱性の根源は、正規の動作するコードと並べて提示される、架空のパッケージ名という最初の提案にある。周囲のコードに異常は見られないが、それは通常、コード自体に問題がないからだ。問題なのは、依存関係だけが偽物なのである。
• 自律型コーディングエージェント。 人間のレビューなしに依存関係をインストールするエージェント型ワークフローは、開発者が名前を確認するために一時停止するという唯一のチェックポイントを排除してしまうため、本来であればプロジェクトに到達する前に誤ったパッケージを検出することができなくなる。
• 検証手順のないパッケージマネージャー。 pip installもnpm installも、対象パッケージが存在して悪意のあるパッケージであってもエラーを発生させません。パッケージマネージャーの観点からは何も問題がないため、インストールは正常に完了します。

スロップスクワッティングを発見し、防止する方法 #

不適切なコードの使用を防ぐには、特別なツールは必要ありません。必要なのは、AIがコードを「提案」したからといって、既存の依存関係管理の実践を緩めるのではなく、体系的に適用することです。

新しいパッケージをインストールする前に、必ず内容を確認してください。特にAIアシスタントが提案してきたものについては、公式レジストリに登録されているか、誰が管理しているか、いつ公開されたか、ダウンロード数が本物に見えるかなどを確認してください。

AIが生成したコードはデフォルトで安全だと決して思い込まないでください。動作するコードだからといって、その依存関係が正当であるとは限りません。依存関係のレビューはコードレビューの一部であるべきであり、例外であってはなりません。

既知のCVE以外のリスクパターンを検出する依存関係スキャンを導入します。例えば、異常なパッケージ、既存のパッケージと疑わしいほど類似した名前、実績のない新規メンテナー、または異常な動作をするインストールスクリプトなどです。

ガバナンス層としてAI-SPMを適用する。 AIセキュリティ態勢管理とは、まさにこのようなAIに起因するリスクを大規模に捕捉するために設計された手法であり、AIが示唆する依存関係を継続的に発見し、人間が手動で確認する必要が生じる前にスコアリングを行うものです。

Xygeniでスロップスクワッティングから身を守る #

開発者の注意深さだけでは、不適切なパッケージの混入を防ぐことはできません。「AIが提案するすべてのパッケージを検証する」という方針は、依存関係の提案が人間のレビュープロセスでは追いつけないほど速いペースで届く組織では、通用しません。

ザイジェニの このアプローチは、これを連続検出問題として扱います: AI Inventory and AI BOM AI によって導入されたすべての表面 依存関係全体 SDLCこれにより、AIアシスタントが実際に提案およびインストールしたもののライブレコードがチームに提供されます。Xygeni Shieldは、 MEW（マルウェア早期警告）は、署名が存在する前に、スロップスクワッティングされたものを含む悪意のあるパッケージを検出してブロックし、署名ベースのスキャナーが残すまさにそのギャップを埋めます。

もしあなたのチームがAIコーディングアシスタントを使用しているなら、既に「スロップスクワッティング」問題は発生しています。問題は、次に発生する架空の名前がインストールされる前に検出されるかどうかです。

FAQ #