Проблема в одном предложении.
В следующий раз Искусственный интеллект-помощник рекомендует пакет для установки.Вы действительно собираетесь проверить, существует ли этот пакет? Большинство разработчиков этого не делают. Именно этот разрыв между предложением и проверкой является отправной точкой для атак типа «slopsquatting», и именно поэтому понимание как эволюции slopsquatting, так и практических методов его предотвращения стало настоящим приоритетом для команд AppSec и DevSecOps.
Что такое нападение с использованием приседаний?
Атака с приседанием — это вариант Typosquatting (Практика регистрации доменного имени или имени пакета, имитирующего легитимное имя с помощью распространенной орфографической ошибки, например) запросы вместо Запросы(надеясь, что собственная опечатка пользователя приведет его прямо к нужному месту), но с важным отличием в источнике ошибки. Тайпосквоттинг использует ошибки, допускаемые людьми при наборе текста. Атака slopsquatting использует ошибки, допускаемые большими языковыми моделями: LLM «выдумывает» имя пакета, которое звучит совершенно легитимно, но не существует ни в одном общедоступном реестре, и злоумышленник получает его первым, зарегистрировав именно это имя раньше, чем кто-либо с благими намерениями.
Механизм типичной атаки с использованием невнимательного подхода прост, и именно эта простота делает её эффективной:
- Разработчик просит ИИ-помощника помочь решить задачу по программированию.
- Модель генерирует решение, которое импортирует или рекомендует установить пакет, которого никогда не существовало.
- Злоумышленник, заметивший, что несколько моделей постоянно повторяют одно и то же вымышленное имя, регистрирует этот пакет в npm, PyPI или другом общедоступном реестре, содержащий вредоносный код. Именно в этот момент вымышленное имя превращается в реальную атаку с использованием сквоттинга.
- Следующий разработчик, получивший такое же предложение и не проверивший его, устанавливает теперь уже реальный пакет, который представляет собой бэкдор в его среде.
Термин «slopsquatting» был придуман Сетом Ларсоном, штатным разработчиком по безопасности в Python Software Foundation, и популяризирован Эндрю Несбиттом для описания именно этой модели поведения: «галлюцинация в виде пакета», превращенная в вектор атаки.
Эволюция в стиле «слопсквоттинга»: как исследовательская любопытство превратилось в реальную угрозу.
Примечательно в эволюции сквоттинга не только само понятие, но и то, как быстро оно превратилось из исследовательского наблюдения в задокументированный, измеримый вид нападения.
2023 год: Первый тревожный сигнал. Исследователь в области безопасности Бар Ланьядо заметили, что несколько магистров права неоднократно рекомендовали пакет под названием Huggingface-кли, которого не существует (реальный пакет устанавливается с помощью pip install -U “huggingface_hub[cli]”Чтобы продемонстрировать риск, он загрузил пустую версию этого пакета в публичный реестр. В течение трех месяцев она получила более 30 000 загрузок без какой-либо рекламы. Вымышленное имя даже появилось в файле README репозитория, связанного с исследованиями Alibaba, что с самого начала показало, как эти «поддельные» имена могут проникать в реальную документацию и создавать почву для последующих атак с использованием сквоттинга.
2024 год: Риск перемещается из поста исследователя в блоге в основные новостные ленты технологических компаний. В марте 2024, Регистр Сообщалось о том, как модели ИИ уверенно придумывали названия программных пакетов, которые затем скачивали разработчики, причем некоторые из них потенциально были заражены вредоносным ПО. Эта информация имела меньшее значение с технической точки зрения и больше — с точки зрения того, что она сигнализировала: случай с huggingface-cli перестал быть единичным случаем; это был первый признак достаточно серьезной закономерности, на которую обратила внимание ведущая технологическая пресса, еще до того, как крупномасштабное академическое исследование подтвердило бы масштабы проблемы годом позже.
2025 год: Первое строгое, крупномасштабное измерение проблемы. Бумаги «У нас для вас есть пакет! Комплексный анализ галлюцинаций, связанных с пакетами, с помощью программ генерации кода на основе LLM-технологий». (Спраклен и др., представлено на USENIX Безопасность В ходе исследования (Symposium) были протестированы 16 моделей генерации кода, как коммерческих (GPT-4, GPT-3.5), так и с открытым исходным кодом (CodeLlama, DeepSeek, WizardCoder, Mistral), на 576 000 примерах кода на Python и JavaScript. Полученные результаты знаменуют собой важный этап в эволюции «слопсквоттинга», превращая его из анекдота в данные:
- 19.7% Некоторые из пакетов, рекомендованных моделями, отсутствовали.
- Модели с открытым исходным кодом гораздо чаще демонстрировали галлюцинации (21.7% в среднем) чем коммерческие модели (5.2%).
- Худшие нарушители, CodeLlama 7B и CodeLlama 34B, более чем в трети своих выступлений демонстрировали галлюцинации.
- По всем протестированным моделям исследователи зафиксировали более 205 000 уникальных вымышленных названий посылокдостаточно большой водоём, чтобы обеспечить возможность для продолжительных самовольных нападений в различных экосистемах.
- Одна деталь, особенно важная для профилактики: примерно 38% Гадюренные названия очень напоминали реальные посылки, что снижает вероятность того, что кто-либо заметит их с первого взгляда.
Важная деталь исследования, и, вероятно, причина того, что эволюция «слопсквоттинга» ускорилась, а не затихла, заключается в том, что вымышленные имена не случайны и не меняются при каждой попытке. Одни и те же модели, как правило, повторяют одни и те же вымышленные имена при аналогичных запросах, а это значит, что злоумышленнику не нужно гадать. Ему достаточно наблюдать за поведением модели, идентифицировать имена, которые постоянно повторяются, и зарегистрировать их раньше, чем это сделает реальный разработчик. Последующий анализ этой повторяемости показал, что когда исследователи повторно запускали идентичные запросы десять раз каждый, 43% вымышленных имен пакетов появлялись при каждом запуске, а 58% повторялись более одного раза, что свидетельствует о том, что большинство вымышленных имен являются повторяющимися артефактами, а не разовым шумом. Именно эта повторяемость превращает разовую вымышленную личность в масштабируемую атаку «слопсквоттинга».
2026: От изолированных пакетов к автономным агентам. В этом году появились самые убедительные доказательства того, что самовольное использование чужих ресурсов больше не ограничивается копированием и вставкой предложенных решений разработчиками. пип установить or Установка npm команда. В январе 2026 года исследователь Чарли Эриксен В компании Aikido Security обнаружили, что агенты искусственного интеллекта уже распространили инструкции, ссылающиеся на вымышленный пакет npm. react-codeshift (название, которое, по всей видимости, объединяет два реальных инструмента,) jscodeshift и react-codemod), распространенный в 237 репозиториях, и агенты до сих пор ежедневно пытаются его установить. Эриксен зарегистрировал это имя самостоятельно, в целях защиты, прежде чем злоумышленник смог бы использовать его в своих целях. Отдельно был обнаружен реальный вредоносный пакет под названием неиспользованные импортыгаллюцинации вместо законных eslint-plugin-unused-importsНесмотря на то, что npm ввел блокировку по безопасности, приложение продолжало фиксировать примерно 233 еженедельных загрузки в начале 2026 года, что свидетельствует о том, как долго атака с использованием slopsquatting может привлекать жертв даже после того, как она была обнаружена. Совсем недавно, в июле 2026 года, исследователи описали аналогичную технику, получившую название «HalluSquatting», которая связывает галлюцинацию ИИ с внедрением подсказки, так что агент ИИ, получающий галлюцинированный ресурс от имени пользователя, может быть перехвачен для выполнения предоставленного злоумышленником кода, расширяя эволюцию slopsquatting от пассивного риска установки до активного вектора удаленного выполнения кода внутри рабочих процессов разработки агентов.
Почему «вайб-кодирование» расширило возможности для атак с использованием несанкционированного доступа к информации.
Атаки с использованием небрежного сквоттинга не имели бы большого значения, если бы код, генерируемый ИИ, был нишевой практикой. Но это не так. Появление программных помощников, автономных агентов и рабочих процессов «визуального кодирования», когда разработчики проверяют все меньше и меньше кода перед его запуском, изменило поверхность атаки на программное обеспечение двумя конкретными способами, и оба ускоряют эволюцию небрежного сквоттинга:
- Теперь точкой входа является не только разработчик. Раньше атака с использованием опечаток основывалась на ошибке одного человека. Теперь же ошибка может возникнуть внутри самой модели и распространиться на сотни разных разработчиков, которые задают похожие вопросы и получают одну и ту же мнимую рекомендацию, многократно увеличивая масштаб одной атаки с использованием опечаток.
- Область атаки сместилась выше по цепочке. Уже недостаточно просто наблюдать за кодом, написанным человеком. Командам также необходимо следить за зависимостями, которые предлагает ИИ-помощник, за серверами MCP, к которым он подключается, и за агентами, которые устанавливают пакеты автономно без прямого контроля со стороны человека. Традиционная система безопасности приложений, созданная для проверки репозиториев и действий человека, commits никогда не был разработан для наблюдения за этим новым взаимодействием между разработчиком, ИИ и реестром пакетов, именно там сейчас и скрываются атаки типа "slopsquatting".
Всё это не означает, что генеративный ИИ по своей природе небезопасен. Это означает, что он вносит новый тип риска в цепочку поставок, для выявления которого традиционные инструменты безопасности не были предназначены, и который требует тех же принципов проверки, которые мы уже применяем к любой внешней зависимости: не доверяйте по умолчанию, проверяйте источник и автоматизируйте эту проверку, вместо того чтобы полагаться на память или бдительность каждого разработчика. Эта автоматизация является основой любой реальной стратегии предотвращения несанкционированного доступа к данным.
Предотвращение неловких приседаний: что могут сделать команды уже сегодня
Хорошая новость в том, что для предотвращения «небрежного захвата прав» не требуются экзотические инструменты. Для этого необходимо систематически применять уже существующие методы обеспечения «гигиены зависимостей», которые многие команды начинают игнорировать, как только им «предлагает» нужный код искусственный интеллект. Эффективный подход к предотвращению «небрежного захвата прав» обычно сочетает в себе следующее:
- Перед установкой каждого нового пакета необходимо вручную проверить его целостность.Особенно если это предложение от ИИ-помощника. Убедитесь, что оно существует в официальном реестре, кто его поддерживает, когда оно было опубликовано и соответствуют ли данные о количестве загрузок действительности. Эта единственная привычка — самый дешевый способ предотвращения некачественного использования ресурсов, доступный любой команде.
- Никогда не следует считать, что сгенерированный ИИ код по умолчанию безопасен. Тот факт, что фрагмент кода «работает», не означает, что его зависимости являются корректными. Проверка зависимостей должна быть частью проверки кода, а не исключением из неё.
- Используйте файлы блокировки и проверку хеша. чтобы зафиксировать точные версии и предотвратить замену пакета в ходе скрытого обновления на другой, отличный от того, который был первоначально проверен.
- Внедрите сканирование зависимостей, которое выявляет закономерности рисков, выходящие за рамки известных уязвимостей CVE.Аномальные пакеты, названия, подозрительно похожие на существующие, новые сопровождающие без опыта работы или скрипты установки с необычным поведением. Недавно опубликованный пакет практически без истории, название которого очень похоже на что-то «почти» знакомое, — это именно та схема, которая лежит в основе большинства задокументированных на данный момент атак с использованием сквоттинга.
- Относитесь к государственным реестрам с тем же скептицизмом.cism, как и любой другой непроверенный внешний источник. Дело в том, что пип установить or Установка npm Если ошибка не возникает, это не является доказательством легитимности.
- команды разработчиков поездов Следует отметить, что программирование с использованием ИИ не снимает ответственности за проверку того, что устанавливается; оно просто добавляет этап, который необходимо включить в рабочий процесс в рамках любого серьезного плана предотвращения самовольного присвоения чужого имущества.
Сами по себе эти меры не являются новыми. Изменился масштаб: когда предложение по поводу зависимости поступает уже не со Stack Overflow или от коллеги, а от модели, способной воспроизводить одну и ту же вымышленную ошибку для тысяч разных разработчиков, ручная проверка, хотя и остается необходимой, перестает быть достаточной. Именно поэтому все больше команд автоматизируют этот уровень предотвращения ошибок типа «slopsquatting» (неправильное использование чужих ресурсов) в своих проектах. Анализ состава программного обеспечения (SCA) инструментарий, вместо того чтобы оставлять это на усмотрение отдельных разработчиков.
Это предварительноcisпочему именно ASPM Платформы , такие как Ксигени Встроить в один и тот же инструмент анализа зависимостей с открытым исходным кодом и использованием ИИ средства обнаружения подозрительных зависимостей, включая тайпсквоттинг, путаницу зависимостей и известные вредоносные пакеты. pipelineТаким образом, предотвращение несанкционированного использования зависимостей не зависит от того, насколько каждый разработчик помнит проверять это каждый раз, когда ИИ-помощник предлагает новую зависимость.
FAQ
Является ли атака с использованием невнятной речи тем же самым, что и атака с использованием опечатки?
Не совсем. Оба варианта предполагают регистрацию поддельного имени пакета, чтобы обмануть того, кто его устанавливает, но источник ошибки различен. Тайпосквоттинг использует ошибки ввода, допущенные человеком. Атака слопсквоттинг использует имена пакетов, придуманные (выдуманные) моделями ИИ, которые злоумышленник затем регистрирует еще до того, как они законно существуют.
Может ли менеджер пакетов автоматически предотвратить подобные атаки?
Не в полной мере, и именно поэтому предотвращение сквоттинга не может ограничиваться уровнем менеджера пакетов. Если злоумышленник зарегистрирует вымышленный пакет до того, как разработчик попытается его установить, установка завершится без ошибок, потому что пакет действительно существует, даже если он вредоносный. Эффективная профилактика требует дополнительной проверки происхождения и поведения пакета.
Это касается только моделей с открытым исходным кодом?
Нет. В исследовании Спраклена и др. галлюцинации были обнаружены во всех протестированных моделях, включая коммерческие, хотя и со значительно меньшей частотой (5.2% против 21.7% для оцененных моделей с открытым исходным кодом). Ни одна модель не свободна от этой проблемы полностью, и отчасти поэтому эволюция «слопсквоттинга» идет в ногу с ростом программирования с использованием ИИ в целом.
Это теоретический риск или он уже был использован в корыстных целях?
Huggingface-кли В одном из таких случаев пустой пакет, загруженный исследователем и скачанный более 30 000 раз за три месяца без какой-либо рекламы, показывает, что риск не просто теоретический: вымышленное имя достаточно, чтобы оно достаточно часто повторялось в разных контекстах, чтобы кто-то смог превратить его в реальную атаку с использованием несанкционированного доступа.
