Slopsquattingと⁠は？なぜ危険なのかと対策方法を徹底解説

Slopsquattingとは何か

出発点は registry の異常ではなく『AI がもっともらしい package 名を invent すること』です

Slopsquatting は、AI コーディングツールや LLM が存在しない package 名、あるいは利用されていない library 名を、実在するかのように提案してしまうことから始まります。利用者がそれを「便利な dependency の候補」と思って install しようとすると、もし攻撃者が同じ名前で package を先に登録していれば、そのまま開発フローへ危険物を取り込むことになります。つまり本質は package registry そのものより、AI が invent した依存関係を人間が信じることです。

ここで重要なのは、AI が悪意を持って package 名を作るわけではないことです。モデルは文脈から、ありそうな package 名、ありそうな namespace、ありそうな import path をもっともらしく補完します。その補完が「存在確認済み」だと誤解されると、初めて supply chain risk になります。したがって Slopsquatting は、モデル hallucination と人間の review 省略が重なって成立する問題です。

dependency confusion や悪意ある package と、主役が違います

依存関係混乱 は、既存 package の namespace や解決順が混ざる問題です。悪意ある npm / PyPI パッケージ は、public registry にある package 自体が危険であることを主役にします。Slopsquatting はそのどちらとも違い、AI が最初の入口を作る点が特徴です。存在しない package 名を出した時点では、まだ攻撃は起きていません。そこに攻撃者が名前を合わせてくることで、初めて危険が現実化します。

そのため対策も少し違います。dependency confusion 対策だけでは、「そもそもその package は実在するのか」という確認が弱いと抜けます。悪意ある package 対策だけでは、「AI が invent した dependency を人間が正しいと思う」入口を塞げません。Slopsquatting は、AI コーディング時代に追加で必要になった review 観点です。

なぜ AI コーディングで起きやすいのか

AI は『それらしい名前』を平然と出すため、存在確認が抜けると危険です

package hallucination が危険なのは、名前の見た目が自然だからです。とくにフレームワーク名、company 名、utility 名、validation 名などが組み合わさると、「たしかにありそうだ」と感じやすくなります。人間が普段から package 名を大量に覚えているわけではないので、AI が出した import path や install command をそのまま受け入れると、存在確認が抜けます。つまり Slopsquatting は、技術的な exploit というより、依存関係 review の認知負荷が AI で下がりすぎる問題です。

既存の Vibe Coding のセキュリティ や AI生成コードの脆弱性 が扱うように、AI コーディングでは「まず動かす」流れが強くなります。Slopsquatting はその中で dependency の review が置き去りになるケースだと整理すると、現場の人にも伝わりやすくなります。

話題性だけでなく、研究ベースで実際に観測されています

このテーマはバズワードではなく、最近の研究でもかなり具体的に扱われています。We Have a Package for You!↗ は、AI-assisted development の文脈で hallucinated package がどのようにリスクになるかを分析しています。さらに Importing Phantoms↗ や Library Hallucinations in LLMs↗ は、モデルが存在しない dependency を提案する現象と、その downstream risk を調べています。

つまり読者が押さえるべきなのは、「そんな変な package 名を誰が信じるのか」ではありません。AI コーディングでは、便利さのために dependency 追加の friction が下がるので、普段なら確認するはずの存在確認が飛びやすいことこそが問題なのです。

最新の研究は何を示しているのか

USENIX の論文は、AI-assisted development と package 誘導の組み合わせを問題にしています

We Have a Package for You!↗は、package suggestion が AI-assisted development の中でどのように攻撃面になり得るかを扱っています。ここで重要なのは、registry 攻撃単独ではなく、開発者のワークフローに AI が入ったことで package intake が変質していると捉えている点です。つまり issue の本質は package の名前だけではなく、提案から導入までの流れが短くなり、人間 review が薄くなることにあります。

この見方をすると、Slopsquatting は dependency confusion の特殊形ではなく、AI コーディング特有の入り口を持つ supply chain risk だと理解しやすくなります。だから記事でも、「何が同じで何が違うか」を切り分けて書く必要があります。

arXiv の recent papers も、hallucinated package は現実的な運用課題だと示しています

Importing Phantoms↗は、hallucinated package の import をどう捉えるかを整理し、Library Hallucinations in LLMs↗ は、モデルが存在しない library を提案する現象を広く捉えています。ここでの実務的なポイントは、生成モデルの出力を信頼している限り、package 名の存在確認を人手 review に戻さないと抜けるということです。モデルが高性能になっても、存在確認の責任がモデルへ委譲できるわけではないと理解した方が安全です。

この研究群は、Slopsquatting を「話題の新語」としてではなく、AI コーディングの現場で review 項目に追加すべき real-world risk として扱う根拠になります。だから記事では、攻撃手順よりも、どこで確認を戻すべきかへ重点を置く方が読者に役立ちます。

開発チームは何を確認すべきか

Slopsquatting の対策は、package を全部 suspicious に見ることではありません。AI が提案した依存関係は「便利な候補」であって、review 済み dependency ではないという前提に戻すことが重要です。つまり install 前に package の実在、maintainer、作成時期、利用実績、private mirror への取り込み可否を確認し、feature review と dependency review を分ける必要があります。

dependency confusion や悪意ある package との内部リンクで理解が深まります

実務では、Slopsquatting を単独で理解するより、依存関係混乱、悪意ある npm/PyPI パッケージ、ソフトウェアサプライチェーン攻撃 と合わせて見る方が役立ちます。本記事はその中で、「AI が invent した package 名が最初の入口になる」という位置づけです。ここを切り分けておくと、review checklist も作りやすくなります。

また、AI コーディングを使う現場では、依存関係 review を個人の注意力へ寄せないことが大切です。allowlist、private mirror、intake review、変更通知、maintainer 監視を組み合わせた方が、AI の速度と両立しやすくなります。

AIで作ったサービスを ASM診断 PRO で点検するなら

ASM診断 PRO は、Slopsquatting そのものを防ぐ製品ではありません。package 名の存在確認や registry の intake review は、依存関係管理の領域だからです。それでもこの記事で「ASM診断 PRO」を訴求できるのは、依存関係を安全にしても、公開後の接点が安全とは限らないからです。AI コーディングで速く作ったサービスは、preview host、beta route、Swagger、login page、staging、管理画面のような接点が残りやすく、dependency review だけではそこまでは見えません。

Slopsquatting のような supply chain リスクに意識が向くと、チームはどうしても「何を install したか」の確認へ寄ります。しかし利用者や攻撃者が触るのは、最終的に internet-facing になった host や path です。たとえ package intake を丁寧にしても、AI が作った admin route や preview host が残れば、別の attack surface が残ります。だから依存関係 review と外部観点での公開面点検は、分けて両方回した方が安全です。

ASM診断 PRO を使うと、外から見える login page、preview host、staging、古い subdomain、API docs を洗い出し、どの接点が今も残っているかを整理できます。AI コーディング時代の supply chain 対策は、package を安全にすることと、公開面を棚卸しすることを切り離さない方が運用しやすくなります。

既存の 外部接続点の可視化 や 外部公開資産のオーナー管理 と合わせれば、dependency 側で起きた事故と、公開運用側で残った接点を同じ改善サイクルへ戻しやすくなります。AI で作ったサービスほど、依存関係確認に加えて、公開面も無料で一度点検する流れを持つ価値があります。

よくある質問（FAQ）

Slopsquatting は dependency confusion と同じですか

同じではありません。dependency confusion は既存 package の解決順や namespace が主役ですが、Slopsquatting は AI が存在しない package 名を出すことが出発点です。

AI が提案した package は全部危険だと考えるべきですか

いいえ。危険なのは『AI が提案したから正しいはずだ』とみなして存在確認を飛ばすことです。候補として扱い、registry と来歴を確認すればかなり抑制できます。

private mirror を使っていれば十分ですか

かなり有効ですが十分ではありません。mirror に何を取り込むかの intake review が弱ければ、hallucinated package を内部へ持ち込む可能性は残ります。

Slopsquatting は AI コーディング特有の問題ですか

package 名の typo や誤認は昔からありましたが、存在しない dependency を AI が大量にもっともらしく提案する点が、現在の AI コーディング時代の特徴です。

依存関係 review が通っていれば公開後の確認は不要ですか

不要ではありません。dependency 側が安全でも、AI で作った preview host、管理画面、staging が残れば別の公開リスクが残ります。

まとめ

Slopsquatting とは、AI が invent した package 名を人間が信じ、攻撃者がその名前を registry に用意することで成立する supply chain risk です。つまり本質は package 自体の特殊性ではなく、AI コーディングで dependency intake の friction が下がりすぎることにあります。dependency confusion や悪意ある package と近い領域ですが、出発点が AI の hallucination である点が大きく違います。

実務では、AI が提案した import や install command を「候補」として扱い、存在確認、maintainer、作成時期、利用実績、private mirror への取り込みを review へ戻すことが重要です。速く作れるからこそ、dependency review を feature review から分け、allowlist と intake gate を持たないと、hallucinated package がそのまま本番 build へ入る危険があります。Slopsquatting の対策は、AI を疑うことではなく、AI の提案を review なしで採用しないことにあります。

さらに AI で作ったサービスでは、dependency review が通っていても、preview host、管理画面、staging、公開 docs のような接点が残ることがあります。だから supply chain 側の統制と外部観点での公開面点検を分けて持つ方が安全です。AI コーディング時代の守りは、package を安全にすることと、公開後の接点を棚卸しすることを一つの release discipline として運用するところまで含めて設計する必要があります。