Каждая пятая рекомендация AI-ассистента по установке пакетов — галлюцинация. Злоумышленники уже научились этим пользоваться: они регистрируют «фантомные» имена пакетов и наполняют их малварью. В 2025 году slopsquatting перешёл из теоретической угрозы в реальные атаки с тысячами жертв. Это руководство объясняет, как защитить себя и свою организацию.
Когда вы спрашиваете AI-ассистента «какой пакет использовать для парсинга YAML в Python?» или «порекомендуй библиотеку для валидации email в Node.js», модель формирует ответ на основе паттернов из обучающих данных. Иногда она рекомендует реальные пакеты. Но в 5-20% случаев — генерирует имя, которое звучит правдоподобно, но не соответствует ни одному реальному пакету.
Критически важная деталь: эти галлюцинации предсказуемы. Одна и та же модель генерирует одни и те же «фантомные» имена для одних и тех же типов запросов. Если GPT-4 однажды порекомендовал несуществующий python-yaml-parser, он будет рекомендовать его снова и снова — разным пользователям, в разное время.
Slopsquatting эксплуатирует именно эту предсказуемость. Злоумышленник систематически опрашивает модели, собирает «фантомные» имена, регистрирует их в NPM или PyPI и наполняет вредоносным кодом. Когда следующий разработчик получит ту же рекомендацию и выполнит pip install — вредоносный код будет исполнен на его машине.
Доверие к AI-инструментам — главная причина успеха slopsquatting-атак. Разработчики привыкли к тому, что AI-ассистенты дают полезные и точные рекомендации в большинстве случаев. Когда инструмент, который обычно работает правильно, рекомендует пакет — естественная реакция — установить его, не задумываясь.
Это принципиально отличается от ситуации с поисковыми системами, где пользователь привык фильтровать результаты. AI-ассистент даёт один конкретный ответ, и он выглядит авторитетно. «ChatGPT рекомендует» звучит убедительнее, чем «нашёл на Stack Overflow» — хотя на практике AI может быть менее надёжен.
Дополнительный фактор — скорость работы. В современном темпе разработки проверка каждого пакета воспринимается как избыточная трата времени. «Модель рекомендует — устанавливаю — двигаюсь дальше». Этот рабочий стиль идеально подходит для slopsquatting-атак.
К 2025 году slopsquatting вышел за рамки теоретической угрозы. Несколько случаев получили широкую огласку.
huggingface-cli — вредоносный пакет на PyPI, зарегистрированный после того, как LLM-модели начали стабильно рекомендовать pip install huggingface-cli для работы с Hugging Face Hub. Официальный пакет называется huggingface_hub, но модели галлюцинировали альтернативное имя. До обнаружения пакет был скачан более 30 000 раз. Внутри — инфостилер, крадущий токены и учётные данные.
react-codeshift — аналогичная ситуация в NPM. AI-модели рекомендовали несуществующий react-codeshift (реальный инструмент — jscodeshift). Злоумышленник зарегистрировал имя, и вредоносный пакет был обнаружен в package.json 237 публичных репозиториев на GitHub. Каждый из этих репозиториев мог быть клонирован другими разработчиками, создавая каскадный эффект.
Исследование arXiv 2501.19012 показало, что из 576 000 сгенерированных LLM образцов кода почти половина ссылалась на несуществующие пакеты. Масштаб проблемы колоссален.
Защита от slopsquatting требует комбинации технических и организационных мер. Ниже — семь конкретных шагов, ранжированных по эффективности.
Организация определяет белый список разрешённых пакетов и их версий. Любая зависимость, не входящая в allowlist, блокируется на уровне CI/CD. Новые пакеты добавляются только через процесс одобрения с проверкой security-командой.
Это единственная мера, которая фундаментально решает проблему: если пакет не в списке, он не будет установлен — независимо от того, рекомендует его AI или нет. Allowlist требует начальных инвестиций, но окупается многократно.
Файлы package-lock.json, poetry.lock, Pipfile.lock фиксируют точные версии и хеши всех зависимостей. Это предотвращает подмену пакетов: даже если злоумышленник перехватит имя, хеш не совпадёт. Pinning версий ("lodash": "4.17.21" вместо "lodash": "^4.17.0") запрещает автоматическое обновление до непроверенных версий.
Lockfile должен коммититься в репозиторий и проверяться при каждом CI-запуске. Команда npm ci (вместо npm install) использует именно lockfile и падает при расхождении.
Перед установкой любого нового пакета — проверьте его метаданные. Три ключевых индикатора:
Проверка занимает 30 секунд на npmjs.com или pypi.org и может спасти от компрометации.
Традиционные SCA-инструменты (Snyk, Dependabot) проверяют известные уязвимости в известных пакетах. Для slopsquatting этого недостаточно. Инструменты нового поколения — Socket.dev, Phylum — анализируют поведение пакета при установке: сетевые подключения, доступ к файловой системе, выполнение shell-команд, обфусцированный код.
Интеграция Socket.dev в CI/CD-пайплайн добавляет автоматическую проверку каждой новой зависимости и блокирует PR с подозрительными пакетами.
AI-ассистенты и AI-агенты не должны автоматически выполнять npm install или pip install для пакетов, которых нет в текущих зависимостях проекта. Рекомендация — да. Автоматическая установка — нет.
Если вы используете AI-IDE с агентом (Cursor, Windsurf, Copilot Workspace), настройте его так, чтобы установка новых пакетов требовала явного подтверждения. Если такой настройки нет — это серьёзный пробел в безопасности инструмента.
Изменения в package.json, requirements.txt, go.mod и аналогичных файлах должны проходить такой же тщательный code review, как и бизнес-логика. Новая зависимость — это новый код в вашем проекте, который выполняется с теми же привилегиями.
При ревью зависимостей проверяйте: зачем нужен пакет (есть ли альтернатива в текущих зависимостях?), кто его поддерживает, давно ли он существует, насколько активно обновляется.
Настройте автоматические алерты на появление новых зависимостей в PR. GitHub Actions, GitLab CI, любая CI-система может сравнивать package.json текущей ветки с основной и генерировать уведомление при добавлении новых пакетов.
Каждая новая зависимость — это событие, которое должно быть замечено и проверено. Автоматический мониторинг превращает «надеюсь, кто-то заметит» в «система гарантированно предупредит».
Все перечисленные меры защиты предполагают, что между рекомендацией 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 в разработке.