Проверяем пакеты, которые предлагает языковая модель

Генерация кода с помощью LLM ускоряет создание прототипов, скриптов и прикладных сервисов. Вместе с кодом модель часто предлагает команды pip install или npm install. Такое имя выглядит убедительно: оно похоже на привычный пакет, соответствует задаче и иногда сопровождается готовым примером импорта. Однако модель способна сгенерировать зависимость, которой никогда не было в реестре.

Эта ошибка создаёт отдельный риск для цепочки поставки. Злоумышленник может зарегистрировать выдуманное имя в PyPI или npm, добавить вредоносный код и дождаться следующей аналогичной рекомендации. Такой сценарий называют slopsquatting: имя для атаки возникает из ответа модели, а затем становится приманкой в публичном реестре.

От галлюцинации к установке вредоносного пакета

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

Наличие пакета в реестре уже ничего не доказывает. На момент проверки имя может быть занято атакующим. PyPI и npm позволяют публиковать проекты, однако регистрация сама по себе не подтверждает репутацию автора, возраст пакета и безопасность его установочных хуков. Для Python и JavaScript это критично: установка зависимости способна выполнить код на рабочей машине или в CI.

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

Масштаб проблемы в генерации кода

В исследовании 16 коммерческих и открытых моделей было получено 576 тысяч образцов Python- и JavaScript-кода. Модели выдали 2,23 миллиона рекомендаций зависимостей; 440 445 из них, или 19,7%, оказались вымышленными. В набор вошло 205 474 уникальных имени.

Эта цифра показывает долю рекомендаций пакетов, а не долю ответов с ошибкой: один фрагмент кода мог содержать несколько библиотек. Тем не менее величина риска заметна даже для команд, которые используют ассистентов только как подсказку. Средняя минимальная доля галлюцинаций у коммерческих моделей составила 5,2%, у открытых — 21,7%. В рамках эксперимента GPT-4 Turbo показала 3,59%, а лучший результат среди открытых моделей был у DeepSeek 1B — 13,63%.

Свежесть задачи повышала вероятность ошибки. Для вопросов и пакетов, появившихся в течение последнего года, все 16 проверенных на Python моделей давали более высокую долю вымышленных имён; средний прирост составил 10%. В новых областях у модели меньше устойчивых данных о реальных зависимостях, поэтому привычка доверять знакомому имени становится особенно опасной.

Повторяемость делает атаку практичной

Случайное вымышленное слово представляет меньшую ценность, чем название, которое модель повторяет для похожих запросов. В отдельной проверке 500 задач с ранее обнаруженной галлюцинацией отправляли повторно по десять раз. В 43% случаев система воспроизводила исходное имя во всех десяти ответах. Ещё в 39% оно больше не появлялось. Хотя бы два повторения встретились у 58% галлюцинаций.

Эти результаты объясняют механику slopsquatting. Атакующему требуется найти устойчивую рекомендацию, зарегистрировать её и рассчитывать на совпадение задачи у другого разработчика. Названия при этом часто привязаны к конкретной модели: 81% уникальных вымышленных имён встретились лишь у одной из 16 систем. Инвентаризация рисков полезна для каждого используемого помощника отдельно.

Простая опечатка объясняет лишь часть случаев. Только 13,4% вымышленных имён отличались от ближайшего реального пакета на один-два символа. Почти половина отличалась минимум на шесть символов. Встречается и перенос библиотек между экосистемами: среди имён для Python-кода 8,7% были настоящими пакетами из npm. Поиск имени в интернете без проверки нужного реестра и языка даёт ложное ощущение безопасности.

Контур проверки для команды и CI

Полезный базовый процесс можно собрать из нескольких простых правил:

1. Добавляйте зависимость через review. В pull request фиксируйте назначение пакета, конкретное имя, версию, реестр и владельца проекта. Команда должна понимать, зачем библиотека входит в граф зависимостей.
2. Проверяйте происхождение. Смотрите дату первой публикации, историю релизов, поддерживающую организацию, число загрузок, репозиторий исходников и документацию. Новый пакет с именем из подсказки заслуживает повышенного внимания.
3. Сверяйте экосистему. Импорт Python-модуля, пакет PyPI и JavaScript-пакет npm могут иметь разные имена. Проверка должна идти по правильному реестру и формату установки.
4. Ограничивайте автоматизацию. Разрешайте новые пакеты через allowlist, внутренний прокси или утверждённый каталог. Lock-файлы, проверка хэшей и запрет произвольных установок в CI сокращают поверхность атаки.
5. Анализируйте поведение. Инструменты SCA, аудит транзитивных зависимостей и изолированная установка помогают обнаружить подозрительные install-скрипты, сетевую активность и нежелательные изменения файлов.

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

Что дают дополнительные проверки модели

Попросить LLM перепроверить собственный ответ иногда полезно. В эксперименте GPT-4 Turbo, GPT-3.5 и DeepSeek распознавали свои галлюцинации с точностью выше 75%. При этом часть ошибок сохранялась, а CodeLlama заметно хуже отличала вымышленные имена. Самопроверка подходит как дополнительный сигнал, однако не заменяет проверку реестра и review.

Подача модели списка проверенных пакетов до генерации снизила долю галлюцинаций: у DeepSeek Coder 6.7B с 16,14% до 12,24%, у CodeLlama 7B с 26,28% до 13,40%. Дообучение дало ещё более сильное сокращение, но у DeepSeek снизило показатель pass@1 на HumanEval с 51,4% до 25,3%. Безопасная архитектура ассистента сочетает подсказки из проверенного каталога, самопроверку и независимый контроль зависимостей на стороне проекта.

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