Slopsquatting: практическое руководство по защите от атак через галлюцинации AI

SAID, март 2026 | Supply Chain Security | ~13 мин чтения

Почти каждая пятая рекомендация AI-ассистента по установке пакетов — галлюцинация: в среднем 19,7% предложенных LLM имён пакетов не существуют (у коммерческих моделей — около 5%). Эти «фантомные» имена предсказуемы, а значит, злоумышленник может заранее зарегистрировать их в реестре и начинить вредоносным кодом. Исследователи безопасности уже доказали, что сценарий работает: пустой PoC-пакет huggingface-cli собрал более 30 000 скачиваний за три месяца, а фантомное имя react-codeshift разошлось по 237 репозиториям, прежде чем его защитно занял исследователь. Это руководство объясняет, как защитить себя и свою организацию.

19,7%
рекомендованных LLM пакетов — галлюцинации (21,7% у open-source-моделей, ~5% у коммерческих)
30 000+
скачиваний безвредного PoC-пакета huggingface-cli за три месяца
237
репозиториев, куда разошлось фантомное имя react-codeshift

Проблема: AI стабильно ошибается одинаково

Когда вы спрашиваете AI-ассистента «какой пакет использовать для парсинга YAML в Python?» или «порекомендуй библиотеку для валидации email в Node.js», модель формирует ответ на основе паттернов из обучающих данных. Иногда она рекомендует реальные пакеты. Но в заметной доле случаев — в среднем в 19,7%: около 5% у коммерческих моделей и 21,7% у открытых — генерирует имя, которое звучит правдоподобно, но не соответствует ни одному реальному пакету.

Критически важная деталь: эти галлюцинации в значительной мере предсказуемы. В эксперименте Spracklen et al. 43% «фантомных» имён воспроизводились во всех десяти повторных прогонах одного и того же запроса, а 58% — более одного раза. Если модель однажды порекомендовала несуществующий python-yaml-parser, велика вероятность, что она порекомендует его снова — разным пользователям, в разное время.

Slopsquatting эксплуатирует именно эту предсказуемость. Злоумышленник систематически опрашивает модели, собирает «фантомные» имена, регистрирует их в NPM или PyPI и наполняет вредоносным кодом. Когда следующий разработчик получит ту же рекомендацию и выполнит pip install — вредоносный код будет исполнен на его машине.

Почему разработчики попадаются

Доверие к AI-инструментам — главная причина, по которой slopsquatting срабатывает. Разработчики привыкли к тому, что AI-ассистенты дают полезные и точные рекомендации в большинстве случаев. Когда инструмент, который обычно работает правильно, рекомендует пакет — естественная реакция — установить его, не задумываясь.

Это принципиально отличается от ситуации с поисковыми системами, где пользователь привык фильтровать результаты. AI-ассистент даёт один конкретный ответ, и он выглядит авторитетно. «ChatGPT рекомендует» звучит убедительнее, чем «нашёл на Stack Overflow» — хотя на практике AI может быть менее надёжен.

Дополнительный фактор — скорость работы. В современном темпе разработки проверка каждого пакета воспринимается как избыточная трата времени. «Модель рекомендует — устанавливаю — двигаюсь дальше». Этот рабочий стиль идеально подходит для slopsquatting-атак.

Реальные случаи: уже не теория

Подтверждённых slopsquatting-атак с реальными жертвами публично пока не задокументировано. Но два получивших широкую огласку эксперимента исследователей безопасности доказали: цепочка атаки работает от начала до конца, и от настоящей атаки её отделяет только содержимое пакета.

huggingface-cli — исследовательский PoC Бара Ланьядо (Bar Lanyado) из Lasso Security. Заметив, что LLM-модели стабильно рекомендуют pip install huggingface-cli для работы с Hugging Face Hub (официальный пакет называется huggingface_hub), исследователь в декабре 2023 года зарегистрировал галлюцинированное имя на PyPI и загрузил под ним пустой, безвредный пакет. За три месяца он собрал более 30 000 реальных скачиваний, а команда установки фантомного пакета попала в README публичного репозитория Alibaba (GraphTranslator). Вредоносного кода в пакете не было — но имя было свободно, и на месте исследователя мог оказаться злоумышленник с инфостилером.

react-codeshift — случай в npm, обнаруженный в январе 2026 года Чарли Эриксеном (Charlie Eriksen) из Aikido Security. LLM «склеила» имя из двух реальных инструментов — jscodeshift и react-codemod. Фантомное имя появилось в одном коммите из 47 AI-сгенерированных skill-файлов для coding-агентов, который никто не проверял, и через форки разошлось по 237 публичным репозиториям на GitHub. Всё это время имя оставалось незанятым в npm — зарегистрировать пакет с любой начинкой мог кто угодно. Эриксен защитно занял его сам; и после этого пакет продолжал получать ежедневные скачивания — AI-агенты, выполняя инструкции из skill-файлов, устанавливали его автоматически.

Масштаб проблемы измерило исследование Spracklen et al. (USENIX Security 2025, arXiv:2406.10279): из 576 000 образцов кода, сгенерированных 16 моделями, в среднем 19,7% рекомендованных пакетов не существовали — всего 205 474 уникальных фантомных имени. По структуре 38% таких имён напоминали реальные пакеты, в том числе из чужих экосистем, 13% были опечатками, а около половины — чистыми фабрикациями.

Практическое руководство по защите

Защита от slopsquatting требует комбинации технических и организационных мер. Ниже — семь конкретных шагов, ранжированных по эффективности.

1. Allowlist пакетов — самая надёжная мера

Организация определяет белый список разрешённых пакетов и их версий. Любая зависимость, не входящая в allowlist, блокируется на уровне CI/CD. Новые пакеты добавляются только через процесс одобрения с проверкой security-командой.

Это единственная мера, которая фундаментально решает проблему: если пакет не в списке, он не будет установлен — независимо от того, рекомендует его AI или нет. Allowlist требует начальных инвестиций, но окупается многократно.

2. Lockfile и pinning версий — обязательно

Файлы package-lock.json, poetry.lock, Pipfile.lock фиксируют точные версии и хеши всех зависимостей. Это предотвращает подмену пакетов: даже если злоумышленник перехватит имя, хеш не совпадёт. Pinning версий ("lodash": "4.17.21" вместо "lodash": "^4.17.0") запрещает автоматическое обновление до непроверенных версий.

Lockfile должен коммититься в репозиторий и проверяться при каждом CI-запуске. Команда npm ci (вместо npm install) использует именно lockfile и падает при расхождении.

3. Проверка метаданных: дата, скачивания, maintainers

Перед установкой любого нового пакета — проверьте его метаданные. Три ключевых индикатора:

Проверка занимает 30 секунд на npmjs.com или pypi.org и может спасти от компрометации.

4. SCA нового поколения в CI/CD

Традиционные SCA-инструменты (Snyk, Dependabot) проверяют известные уязвимости в известных пакетах. Для slopsquatting этого недостаточно. Инструменты нового поколения — Socket.dev, Phylum — анализируют поведение пакета при установке: сетевые подключения, доступ к файловой системе, выполнение shell-команд, обфусцированный код.

Интеграция Socket.dev в CI/CD-пайплайн добавляет автоматическую проверку каждой новой зависимости и блокирует PR с подозрительными пакетами.

5. Запрет автоматической установки AI-рекомендованных пакетов

AI-ассистенты и AI-агенты не должны автоматически выполнять npm install или pip install для пакетов, которых нет в текущих зависимостях проекта. Рекомендация — да. Автоматическая установка — нет.

Если вы используете AI-IDE с агентом (Cursor, Windsurf, Copilot Workspace), настройте его так, чтобы установка новых пакетов требовала явного подтверждения. Если такой настройки нет — это серьёзный пробел в безопасности инструмента.

6. Зависимости — часть обязательного code review

Изменения в package.json, requirements.txt, go.mod и аналогичных файлах должны проходить такой же тщательный code review, как и бизнес-логика. Новая зависимость — это новый код в вашем проекте, который выполняется с теми же привилегиями.

При ревью зависимостей проверяйте: зачем нужен пакет (есть ли альтернатива в текущих зависимостях?), кто его поддерживает, давно ли он существует, насколько активно обновляется.

7. Мониторинг новых зависимостей в pipeline

Настройте автоматические алерты на появление новых зависимостей в PR. GitHub Actions, GitLab CI, любая CI-система может сравнивать package.json текущей ветки с основной и генерировать уведомление при добавлении новых пакетов.

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

Особая опасность для AI-агентов

Все перечисленные меры защиты предполагают, что между рекомендацией AI и установкой пакета есть человек, который принимает решение. Но современные AI-агенты (Cursor Agent, Devin, Claude Code в автономном режиме) способны устанавливать зависимости самостоятельно, без участия человека.

Для AI-агентов slopsquatting — катастрофический риск, потому что вся цепочка атаки полностью автоматизирована: AI генерирует «фантомное» имя, злоумышленник регистрирует его, другой AI устанавливает. Ни на одном этапе человек не участвует.

Если ваша организация использует AI-агентов, критически важно:

Что будет дальше

Slopsquatting — новый класс атак, и индустрия только начинает вырабатывать ответы. NPM и PyPI обсуждают механизмы верификации новых пакетов; LLM-провайдеры экспериментируют с валидацией рекомендуемых пакетов; появляются специализированные инструменты для обнаружения «фантомных» имён.

Но пока эти решения не стали стандартом, ответственность за защиту лежит на командах разработки. Allowlist, lockfile, проверка метаданных, SCA нового поколения, запрет автоматической установки, code review зависимостей, мониторинг — семь шагов, которые можно внедрить уже сегодня.

Slopsquatting будет усиливаться пропорционально росту adoption AI-инструментов. Чем больше разработчиков полагаются на рекомендации AI, тем выше ROI для злоумышленников. Защита от slopsquatting — не опция, а необходимость для любой организации, использующей AI в разработке.

Источники

Как SAID решает эту проблему: Slopsquatting — одна из ключевых угроз, которую SAID адресует системно: