Slopsquatting — принципиально новый тип атаки на цепочку поставок программного обеспечения. AI-модели стабильно галлюцинируют одни и те же имена пакетов, а злоумышленники регистрируют эти «фантомные» имена и наполняют их малварью. 5-20% запросов на генерацию кода содержат ссылки на несуществующие пакеты — и каждый из них может стать вектором атаки.
Термин «slopsquatting» появился в 2024 году и образован от двух слов: «slop» — жаргонное обозначение некачественного или ошибочного AI-контента, и «squatting» — техника захвата имён (по аналогии с typosquatting, когда регистрируются домены с опечатками). Slopsquatting объединяет две проблемы: предсказуемость AI-галлюцинаций и открытость реестров пакетов для регистрации.
В отличие от typosquatting, где злоумышленник рассчитывает на опечатки разработчика, slopsquatting эксплуатирует ошибки AI-модели. Жертва не делает опечатку — она следует рекомендации инструмента, которому доверяет. Это делает атаку особенно эффективной: разработчик не подозревает, что рекомендованный пакет может быть вредоносным, потому что он получил совет от «умного» инструмента.
Механизм slopsquatting-атаки состоит из нескольких этапов, каждый из которых элегантно прост:
Ключевая особенность: галлюцинации LLM предсказуемы. Одна и та же модель генерирует одни и те же «фантомные» имена для одних и тех же запросов. Это означает, что злоумышленник может заранее и с высокой точностью определить, какие имена будут рекомендованы жертвам.
Исследования показывают, что от 5 до 20 процентов ответов LLM на запросы о генерации кода содержат ссылки на несуществующие пакеты. Точный процент зависит от модели, языка программирования и формулировки запроса, но даже 5% — это колоссальная поверхность атаки, учитывая масштабы использования AI-инструментов для разработки.
Если предположить, что миллионы разработчиков ежедневно используют AI для написания кода, и каждый пятый запрос содержит галлюцинированный пакет, речь идёт о сотнях тысяч потенциальных установок вредоносного кода ежемесячно. При этом каждая такая установка может привести к компрометации не только машины разработчика, но и продакшн-системы, в которую попадёт заражённая зависимость.
Исследователи из Университета Техаса в Сан-Антонио (arXiv 2501.19012) провели масштабный эксперимент: они сгенерировали 576 000 образцов кода с помощью 16 различных LLM. Результат — 440 445 ссылок на пакеты, из которых 205 474 были несуществующими. Почти половина всех рекомендованных пакетов — фантомы.
Обнаруженные вредоносные slopsquatting-пакеты содержали несколько типов полезной нагрузки:
Инфостилеры. Самый распространённый тип: при установке пакет собирает пароли из браузеров, токены аутентификации, SSH-ключи, содержимое файлов .env и ~/.aws/credentials, и отправляет их на сервер злоумышленника. Инфостилер маскируется под легитимный код — например, как «телеметрия» или «проверка обновлений».
Бэкдоры. Пакет устанавливает обратное соединение (reverse shell) к серверу злоумышленника, давая ему постоянный доступ к машине разработчика. Бэкдор может активироваться не сразу, а через определённое время или по команде, что затрудняет обнаружение.
Криптомайнеры. Менее опасный, но более заметный тип: пакет запускает майнинг криптовалюты в фоновом режиме, потребляя ресурсы процессора и видеокарты. Криптомайнеры обычно обнаруживаются быстрее из-за заметного влияния на производительность.
Загрузчики. Пакет сам по себе безвреден, но скачивает и выполняет дополнительную полезную нагрузку с внешнего сервера. Это позволяет злоумышленнику обходить статический анализ: при проверке пакет выглядит чистым, а вредоносный код доставляется позже.
Slopsquatting — не теоретическая угроза. К 2025 году зафиксированы множественные случаи реальной эксплуатации.
huggingface-cli. Пакет с этим именем появился на PyPI как результат slopsquatting: LLM-модели стабильно рекомендовали pip install huggingface-cli для работы с Hugging Face Hub, хотя официальный пакет называется huggingface_hub. Злоумышленник зарегистрировал «фантомное» имя и наполнил его инфостилером. До обнаружения пакет был скачан более 30 000 раз.
react-codeshift. Аналогичная ситуация в экосистеме NPM: AI-модели рекомендовали несуществующий пакет react-codeshift (реальный инструмент — jscodeshift). Злоумышленник зарегистрировал имя, и пакет был обнаружен в 237 репозиториях на GitHub — разработчики добавили его в зависимости, следуя рекомендациям AI.
Эти случаи показывают, что slopsquatting работает и на практике, и в масштабе. Тысячи разработчиков установили вредоносные пакеты, доверившись рекомендациям AI-инструментов.
Если для человека-разработчика slopsquatting — серьёзная, но потенциально обнаружимая угроза (можно заметить незнакомый пакет, проверить его на NPM), то для автономных AI-агентов это катастрофический риск.
Современные AI-агенты (Cursor Agent, Devin, Claude Code, GitHub Copilot Workspace) могут самостоятельно устанавливать зависимости как часть выполнения задачи. Агент решает, что для решения задачи нужен пакет X, выполняет npm install X или pip install X, и продолжает работу. Человек может вообще не участвовать в этом процессе.
Это создаёт полностью автоматизированную цепочку атаки:
Ни на одном этапе человек не принимает решения и не имеет возможности заметить атаку. Это делает slopsquatting одной из самых масштабируемых supply chain атак в истории.
Slopsquatting идеально подходит для автоматизации. Злоумышленник может создать пайплайн, который:
Весь процесс может быть автоматизирован от начала до конца. Стоимость атаки минимальна: API-вызовы к LLM дешевы, регистрация пакетов бесплатна, а потенциальная отдача — доступ к тысячам машин разработчиков — несоизмеримо выше.
Традиционные инструменты анализа состава ПО (Software Composition Analysis, SCA) — Snyk, Dependabot, Renovate — проверяют известные уязвимости в известных пакетах. Они работают с базой данных CVE и advisory. Но slopsquatting-пакеты — это не «известные пакеты с уязвимостями». Это новые пакеты, зарегистрированные злоумышленником, которые пока не находятся ни в одной базе.
Для SCA-инструмента slopsquatting-пакет выглядит как легитимный: он зарегистрирован в реестре, имеет валидный package.json или setup.py, содержит работающий код. Вредоносная нагрузка может быть обфусцирована, закодирована в base64, или загружаться с внешнего сервера — всё это затрудняет статический анализ.
Новое поколение инструментов — Socket.dev, Phylum — анализирует поведение пакета при установке: сетевые подключения, доступ к файловой системе, выполнение shell-команд. Это более эффективный подход, но он тоже не идеален: продвинутые слоп-сквоттинг-пакеты могут использовать отложенную активацию или запускать вредоносный код только при определённых условиях.
До тех пор, пока индустрия не решит проблему на уровне инфраструктуры, каждый разработчик должен уметь выявлять потенциально вредоносные пакеты. Основные признаки:
postinstall в package.json или setup.py. Легитимные пакеты редко выполняют сложные действия при установке.Единственный надёжный способ защиты от slopsquatting на уровне организации — это allowlist (белый список) разрешённых пакетов. Вместо того чтобы пытаться обнаружить вредоносные пакеты (blocklist-подход), организация определяет список одобренных зависимостей и запрещает всё остальное.
Allowlist-подход требует начальных инвестиций: необходимо провести аудит текущих зависимостей, создать процесс одобрения новых пакетов, настроить инструменты для контроля. Но он фундаментально решает проблему: если пакет не в списке, он не будет установлен — независимо от того, рекомендует его AI или нет.
Для AI-агентов allowlist-подход критически важен. Если агент может устанавливать только пакеты из заранее одобренного списка, slopsquatting-атака становится невозможной. Агент может рекомендовать «фантомный» пакет, но система просто не позволит его установить.
Внедрение allowlist в организации — это не просто техническая мера. Это изменение культуры: от «устанавливаю что хочу» к «добавляю зависимости через процесс одобрения». Такой подход может замедлить начальную разработку, но он многократно окупается предотвращением инцидентов.
Slopsquatting будет только усиливаться по мере роста adoption AI-инструментов для разработки. Чем больше разработчиков и агентов полагаются на рекомендации LLM, тем выше отдача от slopsquatting-атак. Реестры пакетов (NPM, PyPI) пока не имеют эффективных механизмов противодействия, хотя дискуссия активно ведётся.
Возможные направления защиты на уровне инфраструктуры: LLM-провайдеры могут верифицировать рекомендуемые пакеты перед выдачей ответа; реестры могут ввести механизмы верификации для новых пакетов, имена которых похожи на распространённые галлюцинации; AI-IDE могут встраивать проверку пакетов перед установкой.
Пока эти меры не реализованы, ответственность за защиту лежит на разработчиках и организациях. Allowlist, проверка метаданных, SCA нового поколения, запрет автоматической установки — все эти меры должны стать стандартной практикой.