Slopsquatting: спросил ИИ — установил вирус
NewsMakerЭто выглядит как библиотека...но её никогда не существовало.
Большие языковые модели уже стали неотъемлемой частью современного программирования. Автодополнение кода, помощь в построении логики, генерация скриптов — всё это даёт ощутимую прибавку в скорости и удобстве. Однако наряду с преимуществами появилась новая угроза , получившая название «slopsquatting». Она не связана с классическими ошибками пользователей — напротив, виной всему становится сам искусственный интеллект.
Суть проблемы в том, что генераторы кода, такие как Copilot, ChatGPT или Cursor, иногда рекомендуют несуществующие пакеты. В реальности их никогда не было, но имена звучат вполне правдоподобно. Если такой пакет регистрирует злоумышленник, а ничего не подозревающий разработчик вставляет его в проект, получается идеальный сценарий для внедрения вредоносного кода в чей-то сервер, приложение или CI/CD-процесс.
Термин «slopsquatting» ввёл разработчик Python Software Foundation Сет Ларсон, а позже его популяризировал Эндрю Несбитт. В отличие от классического typosquatting , где делается ставка на опечатки, тут всё держится на вымыслах ИИ. Ошибка не случайна, а запрограммирована на уровне модели.
Новое исследование стало первым масштабным анализом данного явления. В ходе эксперимента специалисты протестировали 16 моделей, включая GPT-4, GPT-3.5, CodeLlama, DeepSeek, WizardCoder и другие. Было сгенерировано более полумиллиона фрагментов кода на Python и JavaScript — и почти 20% содержали пакеты, которых не существует.
Особенно часто грешили этим модели с открытым кодом — у них средний процент ложных рекомендаций составил 21,7%, тогда как у коммерческих он не превышал 5,2%. Самыми «фантазийными» оказались CodeLlama 7B и 34B — там каждый третий пример содержал несуществующий импорт.
Примечательно, что такие ошибки нередко повторяются. Почти 60% ложных пакетов воспроизводились при повторной генерации, а 43% — вообще стабильно появлялись в каждом из десяти повторов одного и того же запроса. Это делает такие пакеты удобной мишенью: достаточно понаблюдать за работой модели, выбрать популярную выдумку и зарегистрировать её.
Чем выше у модели параметр temperature, тем креативнее (а значит, и ошибочнее) становится результат. В некоторых случаях доля ложных зависимостей превышала долю настоящих. Также выяснилось, что многословные модели с обширными рекомендациями ошибаются чаще, чем лаконичные, предпочитающие проверенные библиотеки.
Ещё одна особенность — большинство ложных названий звучат правдоподобно. Исследователи отмечают, что только 13% — это обычные опечатки. Более трети выглядят как производные от реально существующих пакетов, а около 50% — полностью вымышленные, но при этом убедительные. Отличить их на глаз — практически невозможно.
В редких случаях выдуманный пакет оказывается реальным, но в другой экосистеме: например, среди несуществующих Python-библиотек оказалось 8,7%, которые реально существуют в npm. Также проверили, не были ли некоторые из них удалены ранее с PyPI — таких оказалось менее 0,2%.
Есть и обнадёживающие выводы. Некоторые модели, например GPT-4 Turbo и DeepSeek, способны распознать собственные ошибки — в тестах они обнаруживали до 75% своих ложных рекомендаций. Это открывает путь к самопроверке и фильтрации, которая могла бы срабатывать до показа результата пользователю.
Исследование строилось на двух наборах промтов: один составлен на основе реальных вопросов со Stack Overflow, другой — из описаний популярных библиотек. Такие запросы максимально приближены к повседневной практике программистов.
Учёные не стали регистрировать обнаруженные ложные пакеты, чтобы не подрывать доверие к реестрам. Однако даже без этого их работа ясно показывает: масштаб проблемы реален, а угроза — не гипотетическая.
Особенно опасной ситуация становится в эпоху vibe coding — нового подхода, где разработчик не пишет код, а формулирует намерения, а за реализацию отвечает ИИ. При таком подходе становится ещё проще установить фейковую зависимость: пользователь даже не будет знать, что она была сгенерирована, а не выбрана вручную.
Чтобы защититься от slopsquatting-атак, недостаточно искать только известные угрозы. Необходимо отслеживать подозрительные или только что опубликованные пакеты, анализировать их поведение ещё до установки, а также сканировать зависимости и блокировать подозрительные библиотеки до их попадания в разработку. Это даёт шанс опередить злоумышленников в гонке за контроль над цепочкой поставок.
Большие языковые модели уже стали неотъемлемой частью современного программирования. Автодополнение кода, помощь в построении логики, генерация скриптов — всё это даёт ощутимую прибавку в скорости и удобстве. Однако наряду с преимуществами появилась новая угроза , получившая название «slopsquatting». Она не связана с классическими ошибками пользователей — напротив, виной всему становится сам искусственный интеллект.
Суть проблемы в том, что генераторы кода, такие как Copilot, ChatGPT или Cursor, иногда рекомендуют несуществующие пакеты. В реальности их никогда не было, но имена звучат вполне правдоподобно. Если такой пакет регистрирует злоумышленник, а ничего не подозревающий разработчик вставляет его в проект, получается идеальный сценарий для внедрения вредоносного кода в чей-то сервер, приложение или CI/CD-процесс.
Термин «slopsquatting» ввёл разработчик Python Software Foundation Сет Ларсон, а позже его популяризировал Эндрю Несбитт. В отличие от классического typosquatting , где делается ставка на опечатки, тут всё держится на вымыслах ИИ. Ошибка не случайна, а запрограммирована на уровне модели.
Новое исследование стало первым масштабным анализом данного явления. В ходе эксперимента специалисты протестировали 16 моделей, включая GPT-4, GPT-3.5, CodeLlama, DeepSeek, WizardCoder и другие. Было сгенерировано более полумиллиона фрагментов кода на Python и JavaScript — и почти 20% содержали пакеты, которых не существует.
Особенно часто грешили этим модели с открытым кодом — у них средний процент ложных рекомендаций составил 21,7%, тогда как у коммерческих он не превышал 5,2%. Самыми «фантазийными» оказались CodeLlama 7B и 34B — там каждый третий пример содержал несуществующий импорт.
Примечательно, что такие ошибки нередко повторяются. Почти 60% ложных пакетов воспроизводились при повторной генерации, а 43% — вообще стабильно появлялись в каждом из десяти повторов одного и того же запроса. Это делает такие пакеты удобной мишенью: достаточно понаблюдать за работой модели, выбрать популярную выдумку и зарегистрировать её.
Чем выше у модели параметр temperature, тем креативнее (а значит, и ошибочнее) становится результат. В некоторых случаях доля ложных зависимостей превышала долю настоящих. Также выяснилось, что многословные модели с обширными рекомендациями ошибаются чаще, чем лаконичные, предпочитающие проверенные библиотеки.
Ещё одна особенность — большинство ложных названий звучат правдоподобно. Исследователи отмечают, что только 13% — это обычные опечатки. Более трети выглядят как производные от реально существующих пакетов, а около 50% — полностью вымышленные, но при этом убедительные. Отличить их на глаз — практически невозможно.
В редких случаях выдуманный пакет оказывается реальным, но в другой экосистеме: например, среди несуществующих Python-библиотек оказалось 8,7%, которые реально существуют в npm. Также проверили, не были ли некоторые из них удалены ранее с PyPI — таких оказалось менее 0,2%.
Есть и обнадёживающие выводы. Некоторые модели, например GPT-4 Turbo и DeepSeek, способны распознать собственные ошибки — в тестах они обнаруживали до 75% своих ложных рекомендаций. Это открывает путь к самопроверке и фильтрации, которая могла бы срабатывать до показа результата пользователю.
Исследование строилось на двух наборах промтов: один составлен на основе реальных вопросов со Stack Overflow, другой — из описаний популярных библиотек. Такие запросы максимально приближены к повседневной практике программистов.
Учёные не стали регистрировать обнаруженные ложные пакеты, чтобы не подрывать доверие к реестрам. Однако даже без этого их работа ясно показывает: масштаб проблемы реален, а угроза — не гипотетическая.
Особенно опасной ситуация становится в эпоху vibe coding — нового подхода, где разработчик не пишет код, а формулирует намерения, а за реализацию отвечает ИИ. При таком подходе становится ещё проще установить фейковую зависимость: пользователь даже не будет знать, что она была сгенерирована, а не выбрана вручную.
Чтобы защититься от slopsquatting-атак, недостаточно искать только известные угрозы. Необходимо отслеживать подозрительные или только что опубликованные пакеты, анализировать их поведение ещё до установки, а также сканировать зависимости и блокировать подозрительные библиотеки до их попадания в разработку. Это даёт шанс опередить злоумышленников в гонке за контроль над цепочкой поставок.