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

Двадцать лет специалисты по информационной безопасности убеждали разработчиков тщательно проверять зависимости перед добавлением их в проект. За это время сформировались практики аудита пакетов, проверки репутации мейнтейнеров и контроля версий. Однако массовое внедрение больших языковых моделей (LLM) в процессы написания кода создало новую уязвимость: модели уверенно предлагают разработчикам несуществующие библиотеки, а злоумышленникам остаётся лишь зарегистрировать эти имена раньше других.

Подробности

Явление получило название slopsquatting — по аналогии с typosquatting, где атакующие регистрируют домены или пакеты с опечатками в популярных названиях. Разница в том, что при slopsquatting жертвой становится не человек, допустивший опечатку, а LLM, сгенерировавшая несуществующее имя пакета. Проблема заключается в природе работы языковых моделей: они предсказывают вероятные последовательности токенов, а не проверяют реальное существование пакетов в репозиториях. В результате модель может выдать правдоподобное, но полностью вымышленное название библиотеки. Если разработчик без проверки устанавливает такой пакет, а злоумышленник заранее зарегистрировал его в npm, PyPI или другом реестре, вредоносный код попадает в проект. Риски усиливаются тем, что LLM часто рекомендуют пакеты с одинаковой уверенностью как для реальных, так и для вымышленных библиотек. Разработчик, доверяющий ассистенту, может не заметить подмены. Масштаб проблемы растёт вместе с популярностью инструментов генерации кода: чем больше проектов используют LLM, тем шире поверхность атаки. Отдельную опасность представляет автоматизация: если код генерируется и сразу устанавливается в CI/CD-конвейере без ручной проверки, у злоумышленника появляется окно для внедрения вредоносного пакета практически без участия человека.

Что делать

Для защиты от slopsquatting рекомендуется применять комплекс мер: - Всегда проверять существование и репутацию пакета в официальном реестре перед установкой, даже если его предложила LLM. - Использовать инструменты анализа зависимостей (SCA), которые выявляют подозрительные, новые или малоизвестные пакеты. - Ограничить автоматическую установку зависимостей из сгенерированного кода: любые новые библиотеки должны проходить ручное ревью. - Настроить политики в CI/CD, блокирующие добавление пакетов без подтверждённого мейнтейнера или с минимальной историей публикаций. - Фиксировать версии зависимостей и использовать lock-файлы, чтобы исключить подмену пакета после его добавления. - Обучать разработчиков: LLM — это инструмент генерации, а не источник истины о существовании библиотек. Также стоит помнить, что slopsquatting — частный случай более широкой проблемы доверия к цепочке поставок ПО. Даже легитимный пакет может быть скомпрометирован, поэтому проверка зависимостей остаётся обязательной практикой вне зависимости от того, кто предложил библиотеку — человек или модель. Итог: LLM ускоряют разработку, но одновременно создают новый вектор атак, требующий пересмотра привычных практик работы с зависимостями. Безопасность цепочки поставок снова становится зоной ответственности разработчика, а не модели.

Источник: Хабр — Информационная безопасность