スロップスクワッティングとは？AIが提案するパッケージの確認と対策

スロップスクワッティングとは、生成AIが挙げた実在しないパッケージ名を第三者が先に登録し、それを入れた開発者にコードを実行させるサプライチェーン攻撃だ。

防ぐには、AIが挙げた名前を入れる前に、次の3か所で照合する。

スロップスクワッティングとパッケージのハルシネーション

スロップスクワッティングは、パッケージ名のハルシネーションを悪用する。その名前を第三者が先に登録し、誰かが確かめずに入れたときに被害になる。

AIによるパッケージ名のハルシネーション

ハルシネーションは、生成AIが事実と異なる内容をもっともらしく出力することだ。コード生成では、PyPIやnpmに存在しないパッケージ名をpip installの行やimport文に書くことがある。

モデルは登録簿を照会せず、学習したデータの傾向から名前を組み立てる。後述のSpracklenらの論文では、実在しなかった名前のうち、最も近い実在の名前と1〜2文字違いのものは13.4%にとどまり、48.6%は6文字以上違っていた。

スロップスクワッティングとタイポスクワッティングの違い

語を広めたAndrew Nesbittのブログによれば、2025年4月にPython Software FoundationのSeth Larsonが提案した。打ち間違いを狙う「タイポスクワッティング」をもじった名前だが、狙う名前の出どころが違う。

スロップスクワッティングがAIサプライチェーン攻撃になる条件

被害までには、次の3つがそろう必要がある。

3が起きなければ、未登録の名前のインストールはエラーで止まる。一方、第三者が先に登録した名前はエラーなく入るため、気づきにくい。

スロップスクワッティングの研究結果と実被害の確認状況

研究では誤提案の多さと再現性が測られている。以下の数字は実験の値で、攻撃の発生件数とは別のものだ。

研究で観測されたパッケージ名のハルシネーション

Spracklenらは論文「あなた向けのパッケージがあります！」（USENIX Security 2025）で、16種のモデルにPythonとJavaScriptのコードを計576,000件書かせ、挙がった名前約223万件を2024年1月10日時点のPyPIとnpmの一覧と照合した。実在しない名前の割合は、商用モデル（3種）の平均で5.2%、オープンなモデル（13種）で21.7%だった。誤提案が出た依頼500件を10回ずつ繰り返すと（Python、4モデル）、58%の名前は2回以上出た。

2026年には、独立研究者のChurilovが同じ方法での再評価をarXivに公開した（査読前）。対象は2025年10月〜2026年3月に公開された5つのモデルだ。5モデルすべてが挙げた名前は127件で、うち53件は登録簿の確認を経ても第三者が登録できる状態だったという。

研究結果と実被害の確認範囲

Lasso SecurityのBar Lanyadoは2024年3月の報告で、AIが繰り返し挙げるhuggingface-cliという名前で空のパッケージをPyPIに登録し、3か月で3万件を超えるダウンロードがあったと書いている。大手IT企業の研究用リポジトリの説明書にも、この名前の導入手順が載っていた。

AIエージェントが名前を広げた例もある。Aikido SecurityのCharlie Eriksenは2026年1月の報告で、npmに存在しなかったreact-codeshiftを1月14日に登録したと書いている。実在する2つのツールの名前を混ぜた名前で、2025年10月にAIで作られたエージェント用の手順書（スキル）に入り、コピーやフォークで237のリポジトリに広がっていた。登録後も1日1〜4件のダウンロードが続き、Eriksenはエージェントが手順書どおりに実行したものと見ている。

この2件は研究者が先に名前を確保したもので、登録したパッケージに害のあるコードは入っていなかった。

悪意あるパッケージの例も報告されている。Aikido Securityは2026年2月の記事で、ESLintのプラグインeslint-plugin-unused-importsと似た名前のunused-importsを、npm上の悪意あるパッケージとして挙げた。npmでは現在、セキュリティ上の保留を示すパッケージに置き換わっている。ただし同社も、作成者の意図は証明できないとしている。

欧州連合サイバーセキュリティ機関（ENISA）は2026年3月の技術勧告で、スロップスクワッティングを新しい攻撃経路に挙げた。公的機関が実際の侵害被害として確認した発表は、2026年11月1日時点で我々の調べた範囲では見つからなかった。発生の有無までは判断できない。

スロップスクワッティング対策：AIが提案したパッケージの確認と導入承認

スロップスクワッティング対策の中心は、新しい依存関係を加える場面で、AIの提案も人が選んだ部品と同じ審査に通すことだ。

AI提案パッケージの配布元・公開履歴の確認

登録簿に名前があるだけでは安全とはいえない。OWASPのチートシートが挙げる保守状況や利用の広さに加え、冒頭の図の3か所で同じ名前かを照合する。

• 最近登録されたばかりで更新がほとんどない名前は、採用前に理由を確かめる
• npmの来歴（provenance）があれば、npm audit signaturesでソースとビルドへのつながりを確かめる。npmは、来歴で悪意あるコードの有無までは確かめられないとしている

パッケージ導入の承認と検証環境

新しいパッケージを追加する変更は、追加者と別の担当者が承認する。プルリクエストのレビューで、依存関係ファイルの差分を見る運用が使える。

OWASPは同じチートシートで、審査済みの部品だけを置く社内リポジトリを使い、それを迂回できないようにすることと、ビルドを使い捨ての隔離環境で行うことを勧めている。初めて入れる部品は、認証情報を置かず、社内ネットワークにつながらない環境で先に試す。

AIエージェントにコマンド実行を任せている場合は、パッケージの追加に人の確認を挟む。エージェントが読む手順書も、Eriksenが勧めるようにコードと同じくレビューし、書かれた名前が実在し想定した配布元のものかを確かめる。

すでに入れたOSSの配布物に悪意あるコードが混入した実例と、インストールしていた場合の対処は、LiteLLMの改ざんの記事で扱っている。

スロップスクワッティングに備える依存関係の管理

依存関係は、AIが選んだパッケージを把握し、必要性と範囲を見直し、CI/CDで自動の管理をかけて備える。ENISAも同じ勧告でこれを勧めている。

• 台帳（SBOMなど）に、取得元の登録簿、固定したバージョン、承認者、承認日、AIの提案かどうかを残す
• npmではnpm ciを使う。ロックファイルとpackage.jsonが食い違うとエラーで止まり、ロックファイルを書き換えない
• pipではハッシュ確認モード（--require-hashes）を使う。すべての依存関係のバージョン固定とハッシュの記録が要り、記録と違うファイルは入らない
• 公開から一定期間たたないバージョンを入れない設定を使う。pnpmのminimumReleaseAge（分単位）やnpmのmin-release-age（日単位）がある
• CIで、台帳にないパッケージの追加を検出したら止める