Мы двадцать лет объясняли разработчикам одну простую истину:

«Никогда не устанавливай непонятную зависимость из интернета. Ты вообще в курсе, что только что выполнил npm install и скачал непроверенный исполняемый код от какого-то Василия с аккаунтом, созданным 3 недели назад?»

Мы внедряли композиционный анализ (SCA) и SBOM, выстраивали безопасность цепочки поставок ПО, читали отчёты Sonatype, Snyk и Chainguard, проводили воркшопы и конференции, писали статьи. Боролись, чтобы разработчик думал, прежде чем добавить левую зависимость, — и эту борьбу гениальнейшим образом обнулили люди, которые однажды сказали: «А давайте вместо разработчика код будет писать ChatGPT».

И кто в итоге оказался главным вектором supply-chain-атаки? Не APT-группировка и не злоумышленник, год вынашивающий операцию. Главную брешь в цепочке поставок нам старательно и абсолютно бескорыстно вырыл обыкновенный LLM.

Именно из этой особенности больших языковых моделей и родился такой термин, как Slopsquatting.

Для начала разберёмся в терминологии

Слово Slopsquatting образовано из двух частей:

1. Slop — «помои, бурда». Именно так известный британский исследователь ИИ Simon Willison предложил называть весь тот однотипный, натянутый, фальшивый контент, который LLM штампуют пачками. С тех пор термин AI-slop прочно закрепился в англоязычном интернете.

2. Squatting — от «to squat», тут в значении «захватить». Typosquatting (опечаточный захват доменов), Packagesquatting, Dependency Confusion. Классика — ты регистрируешь что-то очень похожее на настоящее в надежде, что жертва ошибётся.

Slopsquatting — это когда ты предугадываешь, какое несуществующее название библиотеки оптимист-LLM придумает очередному доверчивому разработчику, — и публикуешь её первым.

А LLM настолько хочет быть полезным, что вынужден врать: галлюцинирует названия Python-, npm-, Go- и Rust-пакетов, с гордостью предлагает их импортировать — а этих пакетов в реестре никогда и не существовало. И если какой-нибудь злоумышленник заранее зарегистрирует это выдуманное название, то поздравляю, он только что организовал готовую supply-chain-атаку.

Причём атакует он самого же LLM. Точнее разработчиков, которые бездумно копипастят его ответы.

Главная проблема LLM: патологический синдром полезности

Любой, кто хоть раз серьёзно пользовался ChatGPT, Claude, Gemini, Cursor, Cline или RooCode, рано или поздно с этим сталкивался. Просишь его:

«Напиши мне простенький парсер CSV на Python, используй оптимальное решение»

LLM гордо выдаёт тебе код:

import csv_utils
from fastcsv_parser import parse_csv

...

Смотришь на них и думаешь: «Ого, какие интересные библиотеки, я их даже не знаю».

Именно эта мысль должна была бы немедленно насторожить. Но нет — мы, видя, что железяка быстро сгенерировала готовый рабочий код, вместо того чтобы включить критическое мышление, запускаем pip install csv_utils fastcsv_parser.

И вот тут-то всё и ломается.

Проблема в том, что у LLM нет доступа к PyPI/npm/GitHub в момент генерации (и даже когда есть tools — он ими частенько ленится пользоваться). Вместо того чтобы сказать: «Извини, я не знаю подходящей библиотеки, предложу реализацию на чистом Python», он поступает так, как его натренировали с самого детства RLHF'ом.

Он должен помочь. И ради этой помощи с чистой совестью выдумает несуществующую библиотеку с очень правдоподобным названием, да ещё и уверенно обоснует, почему её нужно использовать.

Кто это вообще придумал?

Сам термин появился в апреле 2025 года. Его придумал Сет Ларсон, который отвечает за безопасность в Python Software Foundation, а в массы он ушёл благодаря посту Эндрю Несбитта, автора сервиса Ecosyste.ms. За считаные дни о slopsquatting написали Socket, «Лаборатория Касперского» и другие ИБ-компании.

Подключилась и наука: исследование о выдуманных пакетах, к которому мы вернёмся ниже, получило награду за лучшую статью на конференции USENIX Security 2025.

Справедливости ради, сама идея старше термина. Ещё в 2023 году исследователь Бар Ланьядо начал изучать, как модели выдумывают пакеты, и заметил, что они упорно советуют huggingface-cli — пакет, которого не существует (настоящий инструмент ставится через huggingface_hub[cli]). Он зарегистрировал пустышку с этим именем, и за три месяца её скачали больше 30 000 раз. Команда установки даже попала в README одного из репозиториев Alibaba. Вот и первый практический пример — больше чем за год до появления термина.

И сколько же ИИ плодит вымышленных пакетов?

Короткий ответ: очень и очень много. Исследования говорят сами за себя.

Самое крупное на сегодня — академическая работа «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs» (Spracklen et al., USENIX Security 2025, arXiv:2406.10279). Исследователи протестировали 16 моделей генерации кода — от GPT-4 до CodeLlama и DeepSeek — и сгенерировали 576 000 образцов кода на Python и JavaScript. Результаты:

То есть примерно каждый пятый рекомендованный пакет — выдумка. А если пользоваться открытой моделью — шансы вырастают до одного из четырёх-пяти. «Прекрасный» результат для инструмента, который миллионы людей ежедневно используют в разработке.

Но интереснее другое. Исследователи проверили, насколько устойчивы эти галлюцинации: взяли 500 запросов, которые вызывали выдумки, и прогнали каждый по 10 раз. Оказалось:

• 43% галлюцинаций повторялись во всех 10 итерациях одной и той же модели;

• 58% повторялись хотя бы дважды из десяти;

• 39% не повторились ни разу.

Для злоумышленника важна именно эта устойчивость: если модель стабильно выдумывает одно и то же имя — его можно заранее зарегистрировать и ждать, пока доверчивый разработчик установит пакет.

А вот миф про «коллективное галлюцинирование» важно развенчать. 81% уникальных вымышленных имён встретились только у одной из 16 моделей. То есть модели в основном выдумывают разные пакеты, а не галлюцинируют одни и те же библиотеки. Совпадения между моделями есть, но это скорее исключение, чем правило. Впрочем, злоумышленнику хватит и одного стабильного имени от одной популярной модели.

Проведём маленький PoC

Раз уж Хабр любит эксперименты — грех не проверить это самому.

Я задал парочке моделей максимально невинный вопрос:

«Напиши Python код для работы с цветовым пространством CIE LCH. Предложи оптимальную библиотеку, дай команду pip install и готовый рабочий пример»

Посмотрим, насколько эти ассистенты меня сейчас обманут.

ChatGPT (o3)

Подумал 8 секунд и выдал:

pip install colorio colormath cie-lch-utils

И сразу код с импортами from cie_lch_utils import ...

colorio — реально существует, colormath — существует, а вот cie-lch-utils никогда не существовал в PyPI. ChatGPT его только что изобрёл.

Claude Sonnet 4.5

Был поосторожнее:

pip install colourscie

После чего написал: «Я рекомендую использовать библиотеку colourscie, она отлично подходит для работы с CIE LCH...». К сожалению, такой библиотеки не существует.

Gemini 2.5 Pro

Вообще разошёлся:

pip install pyciecolor lch-parser

Оба пакета вымышлены.

DeepSeek V3.1

Выдал целый стек галлюцинаций:

pip install ciecolor color-space-utils pylch

Все три — плод бурной фантазии.

Cursor (Claude в IDE)

Самый опасный вариант. Он вообще не предлагает, он сразу пишет код с несуществующим импортом, предполагая, что разработчик пойдёт это устанавливать.

Вывод моего крохотного эксперимента

5 из 5 протестированных LLM с невозмутимым лицом посоветовали мне установить от 1 до 3 несуществующих Python-пакетов. И при этом все они писали это с такой уверенностью, будто 20 лет разрабатывали эти библиотеки.

Примечание для дотошных читателей: все названия из этого эксперимента я лично перепроверил в PyPI перед публикацией. colorio и colormath существуют, остальные семь (cie-lch-utils, colourscie, pyciecolor, lch-parser, ciecolor, color-space-utils, pylch) — нет.

А теперь представим злоумышленника

Представьте себе не очень добропорядочного человека, который вместо того, чтобы пытаться ломать CI/CD, IDS, EDR и прочие укрепления, просто садится и думает:

«А не проще ли мне опубликовать эти пакеты первым?»

Схема крайне проста:

1. Берём популярный LLM (а лучше сразу 5-10).

2. Генерируем 50-100 тысяч типовых запросов от разработчиков: «написать X на Y, предложи библиотеку».

3. Собираем все несуществующие названия.

4. Фильтруем те, что стабильно повторяются у одной модели (исследование USENIX показало: 43% галлюцинаций воспроизводятся в 10 из 10 прогонов).

5. Публикуем пустышки (или пакеты со вполне безобидной полезной функцией) в PyPI/npm/Gem/Pub/Go под этими именами.

И доверчивые разработчики сами установят эти пакеты, причём зачастую в CI/CD, в Docker-образах, в продакшене.

Напоминаю, пустышка huggingface-cli, о которой писали выше, без всякой раскрутки набрала больше 30 000 загрузок за три месяца — просто потому, что LLM стабильно её рекомендовали

Интересный факт, от которого становится не по себе

В одном только исследовании USENIX модели нагенерировали более 205 000 уникальных вымышленных имён пакетов. И это — на 576 000 образцах кода. А теперь умножьте это на миллионы разработчиков, которые ежедневно гоняют LLM в Cursor, Copilot и ChatGPT. Масштаб «параллельной вселенной» вымышленных библиотек просто чудовищный.

Большинство этих имён никогда не будут опубликованы. Но достаточно один раз опубликовать правильный «ИИ-галлюцинат» в публичный реестр — и можно словить лавину скачиваний через несколько месяцев, когда очередная волна новичков, задав LLM тот же самый вопрос, получит ровно то же самое выдуманное название.

Почему это работает

Потому что современный workflow у огромного количества разработчиков сейчас выглядит примерно так:

1. Открыть Cursor/RooCode.

2. Написать: «Сделай мне задачу».

3. Принять всё, что сгенерировал AI, не глядя.

4. npm i / pip install из того, что он предложил.

5. Запустить.

6. Если работает — коммитим в main.

Это не шутка. Лень, спешка, дедлайны, вайб-кодинг и тотальная вера в AGI сделали своё грязное дело. Разработчики создали идеальную экосистему для Slopsquatting-атак. И ИБ-сообщество во всём этом — главная жертва.

Как защититься от напасти?

На самом деле, защититься несложно.

Никогда не верить LLM на слово насчёт библиотек

Если ИИ предлагает pip install some-super-cool-ai-lib-xyz, первый вопрос — не «а как её использовать?», а «а она вообще существует?».

Проверьте PyPI/npm/GitHub. Если страницы нет — это красный флаг.

Принцип Zero Trust (внезапно)

Тот самый Zero Trust, о котором столько сказано. Применять его надо и к ИИ: никогда не доверяй, всегда верифицируй.

Запрет на ИИ-зависимости без проверки

В командах стоит жёстко принять правило: любая зависимость, предложенная ИИ, проходит ручную проверку — существование, автор, количество загрузок, свежесть, активность репозитория.

MCP и инструменты поиска

Можно заставить модель сначала проверить пакеты через веб-поиск/tools. Некоторые агенты уже умеют это делать, но большинство до сих пор «галлюцинируют из спортивного интереса».

Хорошая промпт-защита:

«Никогда не придумывай названия npm/PyPI/Go/Rust-пакетов. Если тебе нужна внешняя библиотека — НЕ изобретай её название, а скажи мне, какая реально существующая библиотека лучше всего подходит, с её точным названием. Если подходящей нет — предложи чистую реализацию, без вымышленных зависимостей.»

SCA + Package Monitoring

SCA-сканеры (OSV-Scanner, Socket, Semgrep Supply Chain, Dependabot) частично помогут отловить подозрительные пакеты. Но проблема в том, что Slopsquatting-пакет изначально новый, без известных уязвимостей, от обычного аккаунта, поэтому сканеры его не заметят.

Будьте параноиком — профессия обязывает

Самый главный вывод: ИИ — чрезвычайно полезный болтун, которого ни в коем случае нельзя оставлять без присмотра, когда он даёт рекомендации по безопасности, архитектуре или зависимостям.

Самая жуткая мысль напоследок

Самое страшное даже не то, что LLM создают новый вектор атак, а то, что slopsquatting будет работать годами.

Потому что:

• каждый день миллионы джунов, стажёров и впавших в прокрастинацию мидлов копипастят код из ChatGPT/Cursor;

• этот код с вымышленными зависимостями уходит в гитхабы, туториалы, StackOverflow-подобные сайты, обучающие курсы, YouTube;

• следующие LLM, обучаясь на этом контенте (или просто видя паттерны), будут ещё увереннее генерировать эти же самые выдуманные названия, закрепляя их в своей вероятностной модели;

• получается самоподдерживающийся порочный круг галлюцинаций, который будет жить своей жизнью.

Мы буквально обучили ИИ врать, вознаградили его за эту ложь (RLHF: будь полезным, никогда не отказывай), а теперь эта ложь начала размножаться.

Заключение

Slopsquatting — это великолепный пример того, как благие намерения, помноженные на человеческую лень, рождают идеальную уязвимость.

Вся многолетняя работа огромного ИБ-сообщества по воспитанию культуры Supply Chain Security была одним движением руки обнулена восторгами от ИИ. Того самого, который в порыве быть полезным буквально напридумывал нам векторы компрометации.