Вы просите ИИ дописать интеграцию с очередным сервисом. Через пару секунд готов аккуратный код, а в первых строках стоит команда pip install aws-helper-sdk. Сборка проходит, тесты зелёные, вы идёте дальше. Проблема в том, что пакета aws-helper-sdk никогда не существовало: имя выдумала модель. А месяц назад это имя зарегистрировали на PyPI и начинили вредоносным кодом, потому что знали: модель будет предлагать его снова и снова.

Так работает слопсквоттинг, атака на цепочку поставок, собранная специально под эпоху ИИ-кодинга. Термин в 2025 году придумал Сет Ларсон из Python Software Foundation, популяризировал Эндрю Несбитт. В отличие от большинства страшилок про безопасность, у этой темы есть измерения, документация и сработавшие случаи в реальных реестрах.

Что такое слопсквоттинг

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

Тайпсквоттинг требовал ошибки. Слопсквоттинг эксплуатирует доверие

Тайпсквоттинг знает каждый, кто ставит пакеты: атакующий публикует expres и ждёт, что кто-то однажды опечатается при вводе express. Расчёт на невнимательность работает, но редко, потому что большинство людей всё-таки пишут правильно.

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

Масштаб: 19,7% рекомендаций ведут в пустоту

Считать это мысленным экспериментом уже нельзя. Исследование «We Have a Package for You!» (Спраклон и соавторы, USENIX Security 2025) прогнало 576 000 сгенерированных фрагментов кода через 16 языковых моделей и проверило каждый рекомендованный пакет на существование. 19,7% рекомендаций указывали на пакеты, которых нет в реестрах. Почти каждая пятая.

В абсолютных числах это 205 474 уникальных выдуманных имени, готовых к захвату. Проблема системная: она воспроизвелась у всех протестированных генераторов, отличалась только частота. Разброс между моделями тоже измерен: открытые модели выдумывали чаще, до 22%, коммерческие реже, а лучший результат показал GPT-4 Turbo с 3,59%. Переоценка 2026 года на новых фронтирных моделях сузила диапазон до 4,6–6,1%. Прогресс очевиден, но до нуля не дошёл никто: граница сегодня проходит где-то между «одной из двадцати» и «одной из пяти».

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

Галлюцинации предсказуемы. В этом всё дело

Если бы модели выдумывали имена случайно, атака была бы бессмысленной. Зарегистрировать 205 тысяч имён и надеяться, что придёт человек именно к твоему, невозможно: шум защищал бы пользователей.

Но галлюцинации не случайны. В том же исследовании авторы взяли 500 промптов, которые однажды уже породили фейковый пакет, и прогнали каждый ещё по десять раз. 43% выдуманных имён возвращались при каждом повторе. Тот же вопрос, та же модель, тот же придуманный пакет, снова и снова.

Картина повторяется и между моделями: переоценка 2026 года нашла 127 имён, которые пять разных фронтирных моделей выдумали идентично. Разные инструменты, одни и те же фантомные зависимости.

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

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

Почему привычные защиты это пропускают

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

Детекторы тайпсквоттинга работают на строковой похожести: сколько правок отделяет expres от express по расстоянию Левенштейна. Против опечаток это разумно. Но имена из слопсквоттинга не опечатки: только около 13% выдуманных имён близки к реальным пакетам по дистанции редактирования, ещё около 38% это склейки из двух реальных названий, а почти половина не похожа ни на что существующее. Имя aws-helper-sdk ни на что не опирается, оно просто звучит правдоподобно. Выдавать правдоподобное за реальное, это ровно то, что языковая модель умеет лучше всего. Защита, построенная под человеческую ошибку, слепа к машинной, и в этой щели всё и происходит.

Что атака работает, видно по живому примеру: слопсквоттнутый пакет ещё в феврале 2026 года скачивали примерно 233 раза в неделю даже после того, как npm наложил на него security hold. Люди и их агенты продолжали тянуть его из реестра.

Дальше включается распространение, и оно хуже одиночных установок. Команда из ответа модели утекает в README, в туториал, в прилично выглядящий гайд, и оттуда расходится по всем, кто копирует. Задокументированы случаи, когда команды для несуществующих пакетов просачивались в официальные материалы организаций. Одна галлюцинация, скопированная в популярный текст, превращается в тысячи установок.

Есть и структурная причина, почему поверхность атаки такая широкая. Около 90% опенсорса «спит»: миллионы заброшенных форков и экспериментов, на которые никто не смотрит. Люди ходят по протоптанным тропам, а модели семплируют весь интернет, включая забытые углы. Оттуда и всплывают имена, которых нет, но которые звучат так, будто должны быть.

Почему модели вообще выдумывают пакеты

Механизм простой, если представлять, на чём модели учились. В обучающих данных миллионы README, фрагментов документации и примеров кода, где рядом стоят слова вроде aws, helper, sdk, middleware, fastapi. Генератор, натренированный продолжать такие последовательности, собирает из горячих кусочков имя, которое статистически выглядит уместно в этом месте. Не потому, что модель «помнит» несуществующий пакет, а потому, что интерполирует между реальными. Отсюда и правдоподобность, и отсюда же доля склеек, которую фиксируют исследователи.

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

Это касается не только Python

Слопсквоттинг не привязан к одной экосистеме. Тот же механизм работает где угодно, где имя пакета можно занять бесплатно и мгновенно: в npm, crates.io, Maven, RubyGems. Документированный случай со 233 скачиваниями в неделю пришёл как раз из npm. Для npm ситуация дополнительно острее из-за postinstall-скриптов: установка пакета там может выполнить произвольный код ещё до того, как вы откроете редактор. Заражение не ограничивается сломанной сборкой, оно начинается прямо в момент npm install.

Что делать: защита от слопсквоттинга

Волшебной таблетки нет. Честная защита складывается из нескольких скучных слоёв и одной установки в голове, и установка здесь важнее всего остального.

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

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

Пиньте и хешируйте зависимости: lock-файлы вроде poetry.lock и package-lock.json, фиксированные версии, а где можно, обязательные хеши через pip install --require-hashes. Ничто не должно попадать в сборку без вашего осознанного решения.

Поставьте гейт между моделью и реестром: приватный реестр, allow-list, dependency firewall. Пусть ИИ предлагает что угодно, реально устанавливается только проверенное. В CI сканируйте новые зависимости и отправляйте каждое новое имя на человеческий взгляд, а заодно просканируйте собственные README и документацию: галлюцинированные команды установки распространяются копипастой, и ваши доки часть этого канала.

Отдельный пункт про агентов. Если автономный кодинг-агент сам выполняет команды установки, он вытянет малварь без единого человека в контуре. Агент, который умеет устанавливать, может быть слопсквоттнут на машинной скорости. Ставьте установку за проверку или подтверждение и не разрешайте агенту ставить незнакомые пакеты самостоятельно.

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

Часто задаваемые вопросы

Что такое слопсквоттинг простыми словами?

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

Почему сканеры уязвимостей не спасают от слопсквоттинга?

Они ищут сигнатуры и похожесть на известные имена, а слопсквоттнутый пакет до момента установки формально чист: он просто новый и малоизвестный. Обнаружить его должен процесс, а не сканер. Проверка имени до установки, allow-list и ревью новых зависимостей человеком закрывают то, что инструменты не видят.

Нужно ли отказаться от ИИ-ассистентов из-за этого?

Нет. Меняется не инструмент, а процесс проверки: код от ИИ остаётся черновиком, а имена пакетов в нём утверждениями, требующими подтверждения. Десяток секунд на проверку того, что пакет существует, покрывает почти весь риск. Слепо доверять строкам install не стоило и раньше.

Как понять, что пакет безопасен, а не просто существует?

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

Итог

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

Примерно каждый пятый рекомендованный моделью пакет не существует (у новых моделей реже, но никогда ноль), и указывают такие имена в пустоту предсказуемо. Именно поэтому атакующий может стоять на другом конце, когда вы придёте.

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

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