Материал

AI-агент добавил зависимость: slopsquatting, package hallucination и dependency confusion

Как ИИ превратил выдуманные пакеты в новый вектор атак на software supply chain — и что с этим делать до merge

Зачем читать эту статью

Раньше зависимость попадала в проект сознательно: разработчик находил пакет, читал README, смотрел на звёзды на GitHub и принимал решение. Сегодня AI-ассистент делает это за него. Claude Code, Cursor, Copilot, Devin — все они генерируют pip install и npm install как часть кода. Иногда пакет, который они рекомендуют, не существует в природе. Иногда он уже существует — потому что атакующий зарегистрировал его раньше, чем разработчик заметил проблему.

Это не теоретический риск. Это уже происходит в продакшн-репозиториях крупных компаний. И это меняет то, как AppSec-команда должна смотреть на PR с зависимостями.

Что такое package hallucination

Большие языковые модели не имеют доступа к реальному состоянию PyPI или npm в момент генерации ответа. Когда разработчик просит «добавить rate limiting для Flask», модель выдаёт правдоподобное имя пакета, основанное на статистических паттернах обучающих данных — не на проверке реестра. Если такого пакета не существует, это называется галлюцинацией зависимости (package hallucination, или hallucinated dependency).

Галлюцинации бывают нескольких типов:

  1. Полностью выдуманные имена — пакет никогда не существовал ни в одном реестре. Исследование USENIX 2025 показало, что таких уникальных имён среди галлюцинаций — более 205 000 [2].
  2. Кросс-экосистемные ошибки — модель рекомендует npm-пакет в Python-контексте или наоборот. Около 8,7% галлюцинированных Python-пакетов оказались реальными JavaScript-пакетами [5].
  3. Устаревшие имена — пакет существовал, но был удалён из реестра. Таких среди галлюцинаций всего 0,17% — подавляющее большинство просто выдумано [5].

Исследователи из Техасского университета Сан-Антонио и Вирджинского политехнического института проверили 16 моделей (включая GPT-4, Claude, CodeLlama, DeepSeek, Mistral) на двух наборах промптов и получили 576 000 кодовых сэмплов. Итог: в среднем 19,7% рекомендованных пакетов не существуют [2]. CodeLlama 7B и 34B галлюцинируют в более чем трети выводов; GPT-4 Turbo показал наилучший результат — 3,59%.

Важная характеристика галлюцинаций — повторяемость. При повторном запуске одного и того же промпта одно и то же несуществующее имя появляется в 43% случаев во всех 10 попытках, и в 58% — хотя бы в одной [2]. Это не случайный шум. Это предсказуемая мишень.

Что такое slopsquatting

Изображение

Слопсквоттинг — это атака, которая эксплуатирует повторяемость галлюцинаций. Злоумышленник:

  1. Несколько раз запрашивает у LLM код для определённой задачи.
  2. Фиксирует несуществующие имена пакетов, которые модель выдаёт стабильно.
  3. Регистрирует эти имена в PyPI или npm с вредоносной нагрузкой.
  4. Ждёт, пока другой разработчик задаст похожий вопрос, получит тот же ответ и выполнит pip install или npm install.

Термин ввёл Сет Ларсон, Developer-in-Residence в Python Software Foundation, в апреле 2025 года [3]. Слово сложено из «AI slop» (низкокачественный выхлоп ИИ) и «typosquatting» (регистрация опечаточных вариантов). Popularized через Mastodon Эндрю Несбиттом из Ecosyste.ms [3].

Отличие от классического тайпсквоттинга принципиальное. Тайпсквоттинг ставит на человеческую ошибку при вводе — react-ruter вместо react-router. Слопсквоттинг ставит на ошибку модели: атакующий не угадывает опечатку, а предсказывает галлюцинацию. Список мишеней шире и стабильнее, чем список опечаток. По классификации MITRE ATT&CK это T1195.001 — компрометация зависимостей и инструментов разработки [6].

Реальные кейсы: не теория

huggingface-cli — 30 000 загрузок пустого пакета

В конце 2023 года Бар Ланядо из Lasso Security заметил, что LLM-модели стабильно галлюцинируют имя huggingface-cli. Реальный CLI устанавливается командой pip install -U "huggingface_hub[cli]" — это не отдельный пакет. Ланядо зарегистрировал пустой пакет с именем huggingface-cli на PyPI и добавил аналитику загрузок.

За три месяца пакет получил более 30 000 аутентичных загрузок [7]. Alibaba скопировала ошибочную команду установки в README публичного репозитория GraphTranslator [7]. Пакет был безвредным — это был эксперимент. Но та же схема с вредоносной нагрузкой скомпрометировала бы тысячи машин.

react-codeshift — 237 репозиториев через форки

Галлюцинация слияния jscodeshift и react-codemod породила несуществующий пакет react-codeshift. 47 AI-сгенерированных «навыков» на GitHub рекомендовали его, и через форки имя распространилось в 237 репозиториев до того, как кто-либо заметил [8].

unused-imports — реальный вредонос под галлюцинированным именем

Реальное имя нужного пакета — eslint-plugin-unused-imports. LLM стабильно рекомендовал более короткое unused-imports. Под этим именем существует вредоносный пакет, сейчас находящийся под security hold в npm [8]. Классический пример: атакующий зарегистрировал галлюцинированное имя до того, как реестр успел его заблокировать.

Dependency confusion: AI-версия классической атаки

Dependency confusion — это атака, при которой злоумышленник регистрирует в публичном реестре пакет с именем, совпадающим с внутренним или несуществующим пакетом организации. Если пакет-менеджер настроен на проверку публичного реестра раньше внутреннего (или вместо него), атакующий пакет устанавливается вместо легитимного.

В классическом варианте (описан Алексом Бирсаном в 2021 году) атакующий угадывал имена внутренних пакетов через открытые источники — error-логи, package.json в публичных репо. AI-версия 2024–2025 годов меняет механику: теперь список потенциальных мишеней поставляет сам LLM. Атакующему не нужно угадывать. Достаточно отправить несколько промптов и зафиксировать галлюцинации [9].

В 2025 году ведущие LLM рекомендовали некорректные версии зависимостей — попросту выдумывая ответ — в 27% случаев, открывая дверь для dependency confusion [10].

По данным Sonatype, в 2025 году в открытых реестрах было обнаружено более 454 000 новых вредоносных пакетов — рост на 156% год к году [4]. Атаки перестали быть оппортунистическими и стали промышленными кампаниями. Половина из них сосредоточена в npm [4].

Почему это стало хуже с AI-агентами

До прихода agentic coding разработчик всё же читал команду установки перед выполнением. AI-агент — Claude Code, Cursor, Devin, OpenAI Codex CLI — может выполнить pip install или npm install автономно, без подтверждения человека. Когда агент действует в режиме «принять все изменения», цепочка «галлюцинация → регистрация → установка» срабатывает без единого человеческого решения [11].

Пять решений, которые раньше составляли supply chain-защиту — выбор пакета, проверка легитимности, проверка поддержки, ревью в PR, мониторинг — сворачиваются в одно действие: принять предложение AI [12]. По данным Endor Labs, AI-агент производит чистый прирост в 98 уязвимостей через выбор зависимостей там, где человек — чистое снижение на 1 316 [12].

Исследование Trend Micro 2025 года показало, что даже Claude Code CLI, OpenAI Codex CLI и Cursor с MCP-валидацией снижают, но не устраняют риск [11]. Реальная верификация через PyPI-lookup не решает проблему: злоумышленник может зарегистрировать пакет до того, как будет выполнена проверка [11].

Параллельно быстро растёт экосистема MCP-серверов (Model Context Protocol, открытый стандарт, введён в конце 2024 года). По данным Endor Labs, среди более 10 000 GitHub-репозиториев с MCP-серверами 82% используют чувствительные API без достаточных контролей безопасности, а 41% не имеют явной лицензии [1].

Анатомия атаки: шаг за шагом

Так выглядит полная цепочка слопсквоттинг-атаки с точки зрения злоумышленника:

  1. Атакующий отправляет промпты к целевой LLM, имитируя разработчика: «Напиши Python-обёртку для OrientDB», «Добавь JWT-валидацию в FastAPI».
  2. Фиксирует имена пакетов, которые модель стабильно выдаёт в нескольких независимых запросах.
  3. Выбирает наиболее повторяемые (43%-порог) — это предсказуемые мишени.
  4. Регистрирует выбранные имена в PyPI/npm с вредоносным post-install скриптом: кража токенов, установка обратного шелла, exfiltration секретов из окружения.
  5. Ждёт. Следующий разработчик или AI-агент, задавший похожий вопрос, получает тот же ответ и выполняет установку.
  6. Вредонос срабатывает при pip install или npm install — часто до того, как код вообще попал в PR.

Стоимость атаки для злоумышленника: регистрация аккаунта в реестре бесплатна, загрузка пакета бесплатна, промпты стоят копейки. Риск для атакующего практически нулевой [13].

Что показывают цифры

По совокупности источников картина складывается следующая:

  • 19,7% — средняя доля галлюцинированных пакетов среди всех моделей (USENIX Security 2025, 576 000 сэмплов) [2].
  • 21,7% — у открытых моделей (CodeLlama, WizardCoder, DeepSeek) [2].
  • 5,2% — у коммерческих моделей (GPT-4, Claude) [2].
  • 34% — доля галлюцинаций в рекомендациях AI coding agents по данным Endor Labs [1].
  • 44–49% — доля AI-импортированных версий зависимостей с известными уязвимостями [1].
  • 80% — доля AI-рекомендованных зависимостей, несущих хоть какой-то риск [1].
  • GPT-4 Turbo и DeepSeek способны самостоятельно обнаружить только что сгенерированную галлюцинацию с точностью ~75% — самодетекция есть, но не решает проблему [5].

Эшелонированная защита: что проверять и где

Защита от slopsquatting и package hallucination строится в несколько слоёв. Ни один слой не достаточен сам по себе.

Слой 1: верификация перед установкой

Базовое правило: любое имя пакета, предложенное AI, требует ручной проверки до выполнения команды установки.

  • Убедиться, что пакет существует в реестре: pip index versions <name> или поиск на pypi.org/npmjs.com.
  • Проверить дату первой публикации: пакеты, зарегистрированные недавно под правдоподобным именем, — красный флаг.
  • Проверить количество скачиваний и историю версий. Ноль скачиваний у пакета с «популярным» именем — повод насторожиться.
  • Проверить владельца: аккаунты без истории, без других пакетов — сигнал.
  • Для Python: pip install --dry-run покажет, что будет установлено.

Слой 2: изоляция сборочной среды

AI-агенты не должны выполнять pip install или npm install напрямую в боевом окружении разработчика.

  • Запускать установки зависимостей в эфемерных контейнерах или виртуальных машинах.
  • Использовать частный прокси-реестр (Artifactory, Nexus, Cloudsmith) как единственный источник пакетов: публичные реестры проходят через него после проверки [14].
  • Включить верификацию cryptographic hash для каждой зависимости.
  • Использовать allowlist: разрешённые пакеты и версии определены заранее; всё остальное требует явного одобрения.

Слой 3: gate в CI/CD до merge

SCA-инструменты (OWASP dep-check, Snyk, Socket, Safety CLI) должны запускаться на каждый PR с изменениями в requirements.txt, package.json, Cargo.toml и аналогичных файлах.

Что проверять автоматически:

  1. Новые зависимости: существуют ли в реестре? Не являются ли недавно зарегистрированными с нулевой историей?
  2. Обновлённые версии: нет ли CVE с известными эксплойтами?
  3. Lock-файлы: совпадают ли хэши с ожидаемыми?
  4. Транзитивные зависимости: не появились ли новые транзитивные зависимости с флагами?
  5. SBOM: обновлён ли Software Bill of Materials для данного релиза?

Слой 4: обнаружение подозрительных пакетов по поведению

Post-install скрипты — главный вектор немедленного выполнения вредоноса при установке. Что стоит проверять:

  • Наличие postinstall-скриптов в package.json (npm).
  • Наличие setup.py с network-вызовами или file-системными операциями вне обычного scope.
  • Обращения к внешним хостам при установке — это аномалия для легитимного пакета.

Слой 5: культура и промпт-дисциплина

Технические контроли не работают без дисциплины на уровне команды.

  • Тренировать разработчиков: «Код, сгенерированный AI, — это непроверенный сторонний код».
  • Добавлять в системные промпты AI-агентов явное требование: «Перед рекомендацией пакета проверяй его существование в официальном реестре».
  • Вести approved packages list — список одобренных зависимостей для типовых задач команды.
  • Никогда не использовать --accept-all режим в agentic workflows без промежуточного gate.

Ошибки, которые приводят к компрометации

Типовые сценарии, которые регулярно встречаются в реальных инцидентах и анализах:

  • «Код работает локально, значит зависимости в порядке» — PyPI lookup не означает, что пакет легитимен. Злоумышленник мог зарегистрировать его раньше.
  • «Мы используем только известные пакеты» — скомпрометированный @ctrl/tinycolor имел 2 миллиона еженедельных загрузок до инцидента в сентябре 2025 года [12].
  • «AI не будет рекомендовать несуществующий пакет — он же проверяет» — большинство AI coding tools не верифицируют пакеты в реальном времени [8].
  • «SCA-инструмент не нашёл CVE, значит пакет безопасен» — gallucinированный пакет не будет иметь CVE по определению: он слишком новый или несуществующий до атаки.
  • «Это транзитивная зависимость, мы её не выбирали» — транзитивные зависимости несут те же риски; AI-агент может добавить их без явного упоминания.

Тренды и куда движется угроза

Несколько направлений, которые формируют ландшафт угроз на 2025–2026 годы:

Автономные агенты как вектор масштабирования. По мере роста автономности coding agents — Claude Code, Devin, Cursor в agentic-режиме — увеличивается количество установок, выполненных без человека в петле. OWASP в декабре 2025 года выпустил первую формальную таксономию рисков автономных AI-агентов (Top 10 for Agentic Applications 2026) [15].

MCP как новая attack surface. MCP-серверы соединяют AI-агентов с внешними инструментами. Среди 10 663 проанализированных MCP-репозиториев 75% созданы одиночными разработчиками без enterprise-grade защиты [1]. Компрометация одного популярного MCP-сервера может масштабировать атаку на тысячи проектов.

Промышленные кампании в реестрах. Sonatype зафиксировала в 2025 году 833% рост событий data corruption и рост числа бэкдоров с persistence [16]. Атаки перестали быть точечными.

Самодетекция как mitigation. Исследование USENIX 2025 показало, что GPT-4 Turbo и DeepSeek способны обнаружить собственную галлюцинацию с ~75% точностью при дополнительном промпте [5]. Это направление перспективно, но не достаточно само по себе — и не реализовано по умолчанию ни в одном инструменте.

Практический чек-лист для команды

Перед merge любого PR с зависимостями:

  • [ ] Все новые пакеты существуют в реестре?
  • [ ] Дата первой публикации пакета не «вчера»?
  • [ ] У пакета есть история версий и разумное количество загрузок?
  • [ ] SCA прошёл без критических CVE?
  • [ ] Lock-файл обновлён и хэши верифицированы?
  • [ ] Транзитивные зависимости проверены?
  • [ ] Нет post-install скриптов с сетевыми вызовами или подозрительными операциями?
  • [ ] SBOM обновлён?
  • [ ] Изменение прошло ревью (а не принято через «Accept All»)?

Перед релизом:

  • [ ] Нет свежедобавленных зависимостей с нулевой историей?
  • [ ] Нет зависимостей, добавленных AI-агентом без явного одобрения человека?
  • [ ] Артефакт сборки соответствует ожидаемому составу зависимостей?

Как HighVibe помогает в этом контексте

Описанные угрозы концентрируются именно на этапе между генерацией кода и слиянием в main. Именно здесь работает HighVibe — слой контроля до merge и релиза.

Когда AI-агент добавляет новую зависимость в PR — явно в requirements.txt или неявно через scaffolded код — это изменение попадает в зону анализа: что именно добавлено, откуда, что это меняет в контексте релиза. Вместо длинного security-отчёта команда получает конкретный ответ: можно ли безопасно принять именно это изменение сейчас. Если имя пакета выглядит подозрительно, если зависимость появилась из ниоткуда, если в контексте релиза это блокирующий риск — сигнал приходит до того, как код уходит в продакшн.

HighVibe не заменяет SCA, SAST или SBOM-инструменты, а дополняет их: это дополнительный слой контроля на самом важном рубеже — перед тем, как изменение становится частью релиза.

Заключение

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

Четыре вывода, которые стоит унести из этой статьи:

  1. Относитесь к AI-сгенерированному коду как к непроверенному стороннему коду. Те же контроли, что применяются к open source — ревью, SCA, верификация — должны применяться к любому коду, который написал AI-агент.
  2. Проверяйте имя пакета до установки, а не после. Post-install скрипт может сработать уже при pip install — задолго до того, как SCA-инструмент увидит уязвимость.
  3. Не доверяйте «Accept All» в agentic-режиме. Автономный агент, устанавливающий зависимости без gate, — это эффективный, но неуправляемый разработчик с admin-доступом.
  4. Контроль нужен именно перед merge и релизом — это точка, где изменение ещё можно остановить без последствий для пользователей.

Источники

[1] Endor Labs — "State of Dependency Management 2025: Security in the AI-Code Era" — https://www.endorlabs.com/lp/state-of-dependency-management-2025

[2] Spracklen J. et al. — "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs" — USENIX Security 2025 — https://arxiv.org/abs/2406.10279

[3] Wikipedia — "Slopsquatting" — https://en.wikipedia.org/wiki/Slopsquatting

[4] Sonatype — "2026 State of the Software Supply Chain" — https://www.sonatype.com/state-of-the-software-supply-chain/2026/open-source-malware

[5] Socket — "The Rise of Slopsquatting: How AI Hallucinations Are Fueling a New Class of Supply Chain Attacks" — https://socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks

[6] MITRE ATT&CK — "T1195.001: Compromise Software Dependencies and Development Tools" — https://attack.mitre.org/techniques/T1195/001/

[7] Aikido Security — "Slopsquatting: The AI Package Hallucination Attack Already Happening" — https://www.aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks

[8] Trend Micro — "Slopsquatting: When AI Agents Hallucinate Malicious Packages" — https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/slopsquatting-when-ai-agents-hallucinate-malicious-packages

[9] Aqua Security — "What Is a Dependency Confusion Attack?" — https://www.aquasec.com/cloud-native-academy/supply-chain-security/dependency-confusion/

[10] Kaspersky — "Risks, emerging when developing or using open-source software" — https://www.kaspersky.com/blog/open-source-vulnerabilities-in-ai-era/55543/

[11] Knostic — "AI Coding Agent Security: Threat Models and Protection Strategies" — https://www.knostic.ai/blog/ai-coding-agent-security

[12] Simon Roses Femerling — "The Dependency Trap: Supply Chain Risks in AI-Generated Code (Part 4)" — https://simonroses.com/2026/05/the-dependency-trap-supply-chain-risks-in-ai-generated-code-part-4/

[13] Mend.io — "The Hallucinated Package Attack: Slopsquatting Explained" — https://www.mend.io/blog/the-hallucinated-package-attack-slopsquatting/

[14] Cloudsmith — "Typosquatting & Slopsquatting: Detecting and Defending Against Malicious Packages" — https://cloudsmith.com/blog/slopsquatting-and-typosquatting-how-to-detect-ai-hallucinated-malicious-packages

[15] Microsoft Open Source — "Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents" — https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/

[16] Sonatype — "Open Source Malware Index Q4 2025: Automation Overwhelms Ecosystems" — https://www.sonatype.com/blog/open-source-malware-index-q4-2025-automation-overwhelms-ecosystems

[17] Dark Reading — "AI Code Tools Widely Hallucinate Packages" — https://www.darkreading.com/application-security/ai-code-tools-widely-hallucinate-packages

[18] Snyk — "Slopsquatting: New AI Hallucination Threats & Mitigation Strategies" — https://snyk.io/articles/slopsquatting-mitigation-strategies/

Нужен такой же контроль в ваших изменениях и релизах?

Покажем пример такого замечания на вашем сценарии и соберём пилотный контур без лишней суеты.

Запросить пилот Все статьи
Дальше по теме

Ещё материалы

Все статьи
24 июня 2026 18 мин

Политика использования ИИ в команде разработки: как не опоздать, когда всё уже идёт

Если разработчики уже пишут код с ИИ ассистентами, политика нужна сегодня — а не после первого инцидента TL;DR Более 84% разработчиков уже используют или планируют использовать ИИ инструменты 1 , и большинство делают эт…

Открыть материал
23 июня 2026 16 мин

Регистрация и онбординг пользователей: где появляются первые уязвимости

Форма регистрации выглядит просто. За ней скрывается один из наиболее атакуемых периметров приложения. TL;DR Форма регистрации и онбординг флоу — это первая поверхность атаки, которую видит злоумышленник. Большинство уя…

Открыть материал
23 июня 2026 15 мин

Бизнес-логика и мошенничество в продукте: что проверять до запуска

Ваш продукт работает правильно. Но это не значит, что он работает безопасно. TL;DR Уязвимости бизнес логики — это не сломанный код, а сломанные правила: приложение делает именно то, что написано, но не то, что задумывал…

Открыть материал