сlopsquatting · ИБ · LLM · галлюцинации · supply-chain · безопасность кода · Python · AI15 октября в 11:32 · 4 мин

Slopsquatting: как LLM создали новый вектор supply-chain-атак

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

# Slopsquatting: как мы 20 лет учили разработчиков не доверять пакетам, а потом доверились LLM

История с Slopsquatting — это сатирическое подтверждение того, что благие намерения, помноженные на человеческую лень, рождают уязвимости. После двух десятилетий воспитания культуры Supply Chain Security, ИБ-сообщество столкнулось с фактом: главным вектором атаки стала собственная потребность ИИ быть «полезным».

Анатомия термина: почему бурада опасна

Термин Slopsquatting возник в апреле 2025 года и является гибридом двух понятий. Slop («помои») — это общепринятое в индустрии название для однотипного, фальшивого контента, который генерируют модели. Squatting (от англ. «захват») — классический метод кибератак, при котором злоумышленник регистрирует ресурс, похожий на оригинал (например, *Typosquatting* или *Dependency Confusion*). Slopsquatting превращает хаос генеративного ИИ в инструмент социальной инженерии.

Суть метода проста: LLM, стремясь дать готовое решение, часто «галлюцинирует» — выдумывает названия библиотек, которых никогда не существовало. Если злоумышленник предугадывает эти выдумки и регистрирует их в реестрах пакетов (PyPI, npm, Go) первым, он получает готовую точку входа для компрометации всего проекта, просто потому, что разработчик установил пакет по рекомендации нейросети.

Методология: как модели выдумывают несуществующее

Проблема кроется в архитектурных ограничениях современных LLM. У них нет прямого доступа к реестрам пакетов (PyPI, npm, GitHub) в момент генерации текста, чтобы проверить существование библиотеки. Более того, даже с подключенными инструментами поиска, многие модели ленятся использовать их, предпочитая полагаться на свои внутренние веси.

Подобно тому как модели проходили обучение через RLHF (обучение с подкреплением), их мотивация — быть максимально полезными. Вместо того чтобы честно сказать: «Я не знаю такой библиотеки, вот код на чистом Python», они выбирают путь выдумки. Они создают правдоподобные имена, такие как fastcsv_parser или huggingface-cli, и обосновывают их необходимость с авторитетным тоном.

Статистика исследований 2025 года, опубликованных на конференции USENIX Security, шокирует: около 19,7% всех рекомендованных пакетов LLM не существуют в реальности. Для открытых моделей этот показатель возрастает до 21,7%. Атака возможна благодаря стабильности ошибок: если запрос генерирует одну и ту же выдумку в разных итерациях, злоумышленнику достаточно захватить это имя один раз, чтобы ждать доверчивого разработчика.

Пример экспериментов: В ходе тестирования пяти популярных моделей (ChatGPT, Claude, Gemini, DeepSeek и Cursor) все они без заикания предложили установить несуществующие пакеты для работы с цветовыми пространствами. Например, cie-lch-utils или pylch — названия, которые существуют только в вымышленном мире модели.

Тактика атаки и защита от иллюзий

Алгоритм Slopsquatting-атаки выглядит предельно логично для злоумышленника: 1. Сбор данных: Генерация тысяч запросов к LLM для получения списка вымышленных библиотек. 2. Фильтрация: Отбор тех названий, которые стабильно повторяются у одной модели. 3. Реестрация: Быстрая публикация пустых пакетов под этими именами в публичных реестрах. 4. Установка: Доверчивый разработчик копирует код в репозиторий, выполняет pip install и вводит систему в эксплуатацию.

Большинство существующих систем безопасности (SCA-сканеры, Dependabot) не могут вовремя предотвратить такую атаку, так как новые вымышленные пакеты не содержат известных уязвимостей и исходят от обычных аккаунтов. Они созданы специально для того, чтобы остаться незамеченными.

Как защититься

К сожалению, автоматические методы защиты здесь ограничены. Эффективная стратегия требует сдвига парадигмы: * Принцип Zero Trust к ИИ: Никогда не доверяйте рекомендациям модели на слово. Всегда проверяйте наличие пакета в официальном реестре (PyPI, npm) перед установкой. * Промпт-инжиниринг: Настройте модели так, чтобы они обязаны указывать точные ссылки или предупреждать о том, что внешнюю библиотеку они предложить не могут. * Ручная валидация: Внедрите обязательную проверку зависимостей для всех пакетов, предложенных ИИ-ассистентами.

Главный вывод остается суровым: мы обучили ИИ врать, вознаграждая за полезность, и теперь эта ложь начинает работать как реальный механизм распространения вредоносного ПО. В эпоху вайб-кодинга и автоматизации верификация — это не опция, а единственная гарантия безопасности.

Первоисточники

Habr AI ↗
← Вернуться в эфир