Слопсквоттинг: новая угроза AI-инструментов для бизнеса
Из 576 000 образцов кода, сгенерированных AI-инструментами в ходе исследования, 19,7% содержали несуществующие пакеты — именно это и становится точкой входа для атак нового типа, получивших название слопсквоттинг.
Слопсквоттинг — это атака на программную цепочку поставок, эксплуатирующая склонность больших языковых моделей (LLM) к галлюцинациям. Когда разработчик просит AI-ассистента написать код, модель может порекомендовать несуществующий программный пакет с правдоподобным названием. Если злоумышленник заблаговременно зарегистрировал пакет под таким именем и наполнил его вредоносным кодом, этот код попадает прямо в продукт компании.
Название объединяет два понятия: «AI slop» — некачественный, галлюцинирующий вывод языковых моделей — и «typosquatting» — давно известную практику регистрации доменов или пакетов с опечатками в названиях популярных библиотек. Разница принципиальна: от опечаток реестры пакетов уже умеют защищаться, а от галлюцинаций — нет.
Почему существующая защита не работает
Реестры программных пакетов годами выстраивали защиту от классического тайпосквоттинга: система отслеживает схожие по написанию имена и блокирует публикацию подозрительных пакетов. Например, попытка зарегистрировать «crossenv» как имитацию популярного «cross-env» будет остановлена автоматически.
Слопсквоттинг обходит эту защиту, потому что AI-модели придумывают не опечатки, а новые, несуществующие имена — достаточно правдоподобные, чтобы разработчик не усомнился. Названия вроде «cross-env-extended» или «mpn install cross-env file» не являются вариантами реальных пакетов, поэтому реестр не идентифицирует их как угрозу.
Дополнительная проблема — устойчивость галлюцинаций. Языковые модели генерируют статистически наиболее вероятный ответ, а не проверяют факты. Одно и то же несуществующее имя пакета модель может воспроизводить снова и снова в ответ на похожие запросы. Это означает, что злоумышленнику достаточно один раз изучить, какие имена часто «изобретает» конкретная модель, зарегистрировать эти пакеты — и тысячи разработчиков по всему миру могут получить заражённый код, даже не подозревая об этом.
Вредоносный пакет способен оставаться незамеченным в производственной среде месяцами и даже годами. Исследование 31 267 уязвимостей в 14 675 пакетах на 10 языках программирования показало: количество выявляемых уязвимостей растёт на 98% в год, а средняя продолжительность их жизни увеличилась на 85% — то есть дыры закрываются всё медленнее.
Какие AI-инструменты несут наибольший риск
Уязвимость присуща всем языковым моделям без исключения, однако степень риска существенно различается. Согласно результатам исследования, охватившего 30 различных систем, проприетарные модели генерируют галлюцинированные пакеты в четыре раза реже, чем открытые. GPT-4.0 Turbo показал уровень галлюцинаций 3,59%, тогда как лучший из протестированных открытых вариантов — DeepSeek 1B — достиг 13,63%.
Для бизнеса это означает, что выбор AI-инструмента для разработки напрямую влияет на уровень риска. Компании, использующие открытые модели из соображений экономии или гибкости, статистически подвергаются значительно большей угрозе.
При этом авторы исследования предупреждают: как только злоумышленники осознают разрыв в уязвимости между проприетарными и открытыми моделями, они могут целенаправленно атаковать и проприетарные системы через манипуляции с данными или запросами.
Отдельного внимания заслуживает явление вайб-кодинга — практики, при которой разработчик генерирует код с минимальной проверкой, полностью доверяя AI-ассистенту. По данным, приведённым в исходной публикации, более 40% кода, который разработчики добавляют в проекты, создаётся с участием AI, а 72% из тех, кто пробовал такие инструменты, используют их ежедневно. Чем шире распространяется эта практика без встроенной верификации, тем масштабнее становится потенциальная поверхность атаки.
Что может сделать бизнес прямо сейчас
Угроза слопсквоттинга затрагивает любую компанию, где разработчики используют AI-ассистентов при написании кода. Это касается как крупных технологических команд, так и небольших компаний, которые привлекают подрядчиков или используют внутренние инструменты автоматизации.
- Внедрить автоматическую проверку всех пакетов, которые рекомендует AI, по официальным реестрам перед их установкой.
- Установить правило: ни один пакет, предложенный языковой моделью, не устанавливается без ручной проверки существования в официальном источнике.
- Включить мониторинг необычных установок пакетов в систему безопасности разработки.
- При выборе AI-инструментов для разработки учитывать уровень галлюцинаций модели как один из критериев оценки риска.
- Провести аудит уже используемых зависимостей на предмет пакетов с нетипичными или сомнительными именами.
Важно понимать, что речь идёт не о гипотетической угрозе будущего. Атакующие уже знают о тенденции LLM к галлюцинациям и могут использовать её системно. Пассивность в этом вопросе — это не нейтральная позиция, а принятие риска по умолчанию.
Руководителям, отвечающим за разработку продуктов или автоматизацию, стоит также пересмотреть договорённости с подрядчиками: если внешняя команда использует AI-инструменты без верификации пакетов, уязвимость возникает в вашем продукте, независимо от того, кто написал код.
Практический вывод: введите обязательное правило в регламент разработки — каждый пакет, рекомендованный AI-инструментом, должен быть проверен вручную в официальном реестре до установки, а ответственность за эту проверку должна быть закреплена за конкретным участником команды.