Невидимый груз: как AI приносит уязвимые зависимости — transitive deps, hallucinated packages и dependency confusion

Почему смотреть только на верхний пакет уже недостаточно — и что делать, если AI предложил библиотеку с сомнительной историей или несуществующий пакет

Введение: скорость без карты

Команда ускорилась. Copilot, Cursor, Claude — разработчики генерируют в несколько раз больше кода, чем год назад. Но вместе с кодом в проект незаметно приезжают зависимости. Иногда — от библиотек с незакрытыми CVE. Иногда — от пакетов, которые AI «придумал». Иногда — от имён, которые злоумышленник уже успел занять в публичном реестре.

По данным Veracode, AI-генерированный код содержит в 2,74 раза больше уязвимостей, чем написанный человеком [3]. Apiiro фиксирует, что к июню 2025 года объём новых security-находок в AI-коде вырос в 10 раз по сравнению с декабрём 2024 [3]. И ключевая причина — не только сам код, но и то, что он тянет за собой.

Эта статья — для CTO, Tech Lead и AppSec-специалистов, которые уже используют AI-ассистентов и хотят понять, где именно проходит граница между «работает» и «безопасно».

Часть 1. Транзитивные зависимости: то, чего вы не выбирали

Что такое транзитивные зависимости

Когда разработчик добавляет import fastapi или require('express'), в проект попадает не один пакет. У каждого пакета есть собственные зависимости, у тех — свои, и так до 4–6 уровней вглубь.

Среднестатистическое приложение имеет около 128 прямых зависимостей, каждая из которых тянет ещё 4+ своих [2]. Итого — потенциально более 1500 точек риска в рамках одного проекта [2]. При этом 77–97% кода в современных приложениях — это открытый исходный код, большая часть которого разработчик не выбирал напрямую [2].

Главная проблема транзитивных зависимостей — невидимость. Разработчик видит fastapi в requirements.txt, но не видит starlette, anyio, httpx и ещё десяток библиотек, которые приезжают вместе с ней.

80% уязвимостей приходит именно из транзитивных зависимостей [2]. Если команда смотрит только на верхний список пакетов — она видит меньшую часть реальной поверхности атаки.

Как AI усугубляет проблему

AI-ассистент предлагает готовый код с импортами. Разработчик копирует, запускает pip install или npm install — и в проект попадает не только то, что явно написано в импорте, но и весь транзитивный граф.

AI не анализирует дерево зависимостей и не предупреждает о CVE-4 уровня вложенности. Он решает задачу «написать рабочий код», а не «минимизировать attack surface».

По данным Snyk, 59% разработчиков беспокоятся о новых уязвимостях, которые приносят AI-инструменты, — при этом 58% признают, что доверяют AI-выводу без дополнительной проверки [4].

Кейс: XZ Utils и OpenSSH

В марте 2024 года исследователь Andres Freund заметил аномальный расход CPU при SSH-логинах на Debian. Причиной оказался CVE-2024-3094 (CVSS 10.0) — бэкдор в xz-utils, библиотеке сжатия, которую используют почти все дистрибутивы Linux [30].

Но xz-utils и OpenSSH — не прямые зависимости. Цепочка выглядела иначе: некоторые дистрибутивы патчат OpenSSH, чтобы он поддерживал уведомления systemd через sd_notify. Для этого OpenSSH подгружает libsystemd, которая в свою очередь загружает liblzma — и именно там оказался бэкдор [31].

Атакующий (предположительно, актор уровня nation-state) три года методично набирал авторитет в сообществе XZ, строил доверие, получил права мейнтейнера — и спрятал вредоносный код в бинарных тестовых файлах, невидимых при обычном code review репозитория [35].

Этот инцидент обнажил два факта, важных для любой команды:

1. Код review верхнего репозитория не защищает от атак на транзитивные зависимости.
2. SCA-инструменты, которые сканируют только первый уровень, пропускают то, что «несут» зависимости зависимостей. Именно это показал XZ [2].

Часть 2. Hallucinated packages: пакеты, которых не существует

Как AI галлюцинирует зависимости

Языковые модели не имеют доступа к реестрам пакетов в момент генерации. Они предсказывают «правдоподобный» следующий токен — и иногда генерируют имена библиотек, которые звучат реально, но не существуют.

Исследователи из Техасского университета в Сан-Антонио, Технологического университета Вирджинии и Университета Оклахомы протестировали 16 популярных LLM на двух наборах задач для Python и JavaScript. Результат: около 20% сгенерированного кода содержало ссылки на несуществующие пакеты [12]. При повторном использовании того же промпта 43% галлюцинированных имён воспроизводились снова и снова, что создаёт предсказуемый паттерн для атакующих [16].

Структура галлюцинаций закономерна [19]:

• 51% — чистые выдумки;
• 38% — слияния реальных пакетов (например, express-mongoose вместо отдельных express и mongoose);
• 13% — опечатки и вариации.

Slopsquatting: атака на галлюцинации

Термин slopsquatting ввёл Seth Larson, его распространил Andrew Nesbitt [13]. Схема проста:

1. Атакующий запрашивает у LLM генерацию кода с определённым контекстом.
2. Получает галлюцинированное имя пакета — например, aws-helper-sdk или securehashlib.
3. Регистрирует этот пакет в npm или PyPI с вредоносной нагрузкой.
4. Следующий разработчик, получивший от AI тот же совет, устанавливает «настоящий» пакет с таким именем — и получает малварь.

Первый публичный эксперимент провёл исследователь Bar Lanyado в марте 2024 года: он заметил, что ChatGPT регулярно рекомендует несуществующий пакет huggingface-cli (правильный — pip install -U "huggingface_hub[cli]"). Lanyado зарегистрировал пустой пакет с этим именем на PyPI. За три месяца тот набрал более 30 000 загрузок — Alibaba успела вставить галлюцинированную команду установки прямо в README одного из своих публичных репозиториев [11].

В 2024 году диапазон частоты галлюцинаций у разных моделей составлял 5–38% [15]. При этом в 2023 году 20–35% галлюцинированных имён уже были конвертированы атакующими в реальные вредоносные загрузки [15].

Snyk назвал slopsquatting одной из главных emerging-угроз в supply chain 2024–2025 годов [12].

Deprecated и сомнительные библиотеки

Помимо несуществующих пакетов, AI регулярно предлагает устаревшие библиотеки из своих обучающих данных. Модель обучена на коде двух-трёхлетней давности; за это время пакет мог быть заброшен, форкнут или оказаться под одним мейнтейнером без активной поддержки.

AI не знает, когда пакет получил последний коммит. Он не знает, закрыты ли в нём свежие CVE. Он не знает, доверяет ли сообщество этому мейнтейнеру сегодня.

Часть 3. Dependency confusion: когда приватное имя становится оружием

Механика атаки

Dependency confusion — атака, которую впервые публично продемонстрировал Алекс Бирсан в 2021 году против Apple, Microsoft и PayPal. Механика следующая [20]:

Компании часто используют внутренние пакеты с именами вроде internal-auth-service, которые хранятся в приватном реестре. Когда npm install или pip install запускается без явного указания источника, менеджер пакетов проверяет не только приватный, но и публичный реестр — и часто отдаёт предпочтение тому пакету, у которого выше версия.

Атакующий узнаёт имя внутреннего пакета (через package.json, requirements.txt, error messages или CI-логи), регистрирует его на PyPI или npm с более высоким номером версии и вредоносным кодом. При следующей установке CI-системы подтягивают «обновлённую публичную версию» вместо корректной приватной.

По оценкам Orca Security, 49% организаций имеют хотя бы один актив, уязвимый к dependency confusion-атаке [25].

Как AI amplifies этот вектор

AI-ассистент, генерируя код для конкретного проекта, может предложить имя пакета, которое звучит как внутренний инструмент или использует паттерны, характерные для приватных реестров команды. Если разработчик принял этот код без проверки, риск confusion-атаки возрастает: вместо проверки фактического источника устанавливается то, что лежит в публичном реестре под этим именем.

В сентябре 2025 года атака GhostAction затронула 327 GitHub-пользователей, 817 репозиториев и позволила утечь 3 325 секретам, включая PyPI, npm и DockerHub-токены [20].

Часть 4. Lock-файл: необходимый, но недостаточный

Что фиксирует lock-файл

package-lock.json, yarn.lock, poetry.lock, Cargo.lock, go.sum — каждый из этих файлов фиксирует точные версии пакетов на момент установки, включая транзитивные зависимости. Каждая запись содержит версию, URL источника и integrity hash (SHA) [42].

Если lock-файл закоммичен в репозиторий и CI использует npm ci или yarn install --frozen-lockfile, среда воспроизводима: в production попадает ровно то, что тестировалось [44].

Это фундамент — но не достаточная защита.

Чего lock-файл не делает

Lock-файл не проверяет, что пакет под зафиксированным именем и версией безопасен. Он только гарантирует воспроизводимость установки.

Если атакующий получил доступ к учётной записи мейнтейнера и опубликовал скомпрометированную версию до того, как вы создали lock-файл — именно эта версия попадёт в фиксацию. В сентябре 2025 года был скомпрометирован мейнтейнер и через его аккаунт опубликованы вредоносные обновления 18 популярных npm-библиотек, включая chalk и debug, с совокупными 2,6 млрд еженедельных загрузок — и за два часа доступности пакеты успели распространиться [22].

Кроме того, lock-файл не защищает от:

• lockfile injection через pull request (злоумышленник может подменить lock-файл в PR) [29];
• конфликта имён в приватном и публичном реестре (dependency confusion);
• установки пакета через npx — который вообще не создаёт lockfile [29].

Что проверять в lock-файле при code review

При анализе PR с изменёнными зависимостями важно проверять следующее:

1. Совпадает ли поле resolved с ожидаемым реестром (не появились ли неожиданные внешние источники).
2. Не изменился ли integrity hash для пакета, который не должен был обновляться.
3. Не появились ли новые транзитивные зависимости, которые не обосновываются изменениями в прямых.
4. Не изменился ли lock-файл без явного изменения package.json/requirements.txt — это красный флаг потенциального lockfile injection.

Часть 5. Как проверять то, что предложил AI

Шаг 1: Убедитесь, что пакет существует

Перед pip install или npm install проверьте существование пакета непосредственно в реестре: pypi.org, npmjs.com. Обратите внимание на дату создания, количество загрузок и историю публикаций.

Пакет, опубликованный неделю назад с несколькими сотнями загрузок и правдоподобным именем — потенциальный slopsquat.

Шаг 2: Проверьте репутацию через OpenSSF Scorecard

OpenSSF Scorecard — инструмент, который автоматически оценивает security-практики открытого проекта по 18+ параметрам: наличие code review, branch protection, автообновление зависимостей, наличие security policy, подписанные релизы и другие [58][59].

Запуск через CLI: scorecard --repo github.com/owner/repo

Результат — оценка 0–10 по каждой проверке. Проект с низким баллом по Maintained или Code Review — сигнал: зависимость держится на одном мейнтейнере или давно не обновляется.

CISA рекомендует Scorecard как один из инструментов оценки безопасности открытых проектов [67].

Шаг 3: SCA — проверьте весь граф, а не только верхний уровень

Software Composition Analysis (SCA) сканирует дерево зависимостей целиком, включая транзитивные, и сопоставляет каждый пакет с базами CVE (NVD, OSV, GitHub Advisory Database). Ключевое — инструмент должен поддерживать глубокое сканирование, а не только прямые зависимости.

Инструменты: npm audit, pip-audit, trivy, grype, Snyk, Dependabot.

Важно: SCA находит известные CVE, но не обнаруживает свежие вредоносные версии до появления advisory.

Шаг 4: Генерируйте и проверяйте SBOM

SBOM (Software Bill of Materials) — машиночитаемый инвентарь всех компонентов, включая транзитивные зависимости. Стандарты: SPDX (ISO/IEC 5962:2021) и CycloneDX.

SBOM даёт возможность моментально ответить на вопрос «какие наши продукты используют этот пакет?» — как это было актуально в дни Log4Shell. IBM отмечает, что к 2025 году 60% организаций, работающих с критической инфраструктурой, планировали ввести SBOM как обязательный элемент [51].

Генерация SBOM на каждый билд: syft, cdxgen, cyclonedx-bom. Интеграция в CI гарантирует актуальный снапшот после каждого merge.

Шаг 5: Защитите приватные пакеты от confusion-атаки

Для npm: используйте scoped-имена (@yourorg/internal-service) и в .npmrc явно привяжите ваш скоуп к приватному реестру [29].

Для pip: укажите --index-url явно и используйте --extra-index-url с осторожностью — этот флаг может разрешить подмену из публичного реестра.

Зарезервируйте имена внутренних пакетов в публичных реестрах (даже как пустышки), чтобы атакующий не смог занять имя [20].

Шаг 6: Не удаляйте и не пересоздавайте lock-файл без обоснования

Если AI предлагает «удалить lock-файл и переустановить зависимости» — это нужно остановить и обосновать. Пересоздание lock-файла открывает окно для подтягивания новых версий, среди которых могут оказаться скомпрометированные.

В CI всегда используйте npm ci, а не npm install — первая команда строго следует lock-файлу и падает при расхождениях [42].

Часть 6. Что делать, если AI предложил библиотеку с сомнительной историей

Красные флаги: когда стоит остановиться

1. Пакет создан менее месяца назад — особенно если имя звучит как слияние двух известных библиотек.
2. Один мейнтейнер, нет активности в issues за последние 6+ месяцев.
3. Нет security policy (SECURITY.md).
4. OpenSSF Scorecard ниже 4/10 по параметрам Maintained и Code Review.
5. Changelog отсутствует или содержит подозрительные изменения в бинарных или тестовых файлах (именно так был спрятан бэкдор в XZ [31]).
6. Package.json или setup.py содержат post-install скрипты без очевидного назначения.
7. Имя пакета не совпадает с тем, что вы ожидали установить (pypi.org показывает другого владельца).

Decision framework: принять или отклонить

Принять и использовать можно, если:

• пакет существует в реестре, опубликован до 2023 года, имеет стабильное количество загрузок;
• OpenSSF Scorecard 6+;
• SCA не выявил критических CVE;
• у пакета более одного активного мейнтейнера;
• в lock-файле integrity hash воспроизводим.

Использовать с осторожностью (additional review):

• пакет существует, но молодой или малопопулярный;
• один мейнтейнер, но активный и с историей;
• есть non-critical CVE, которые команда принимает осознанно.

Отклонить или заменить:

• пакет не существует в реестре — это галлюцинация;
• имя подозрительно похоже на другой популярный пакет;
• SCA выявил critical/high CVE без патча;
• пакет в публичном реестре появился недавно и совпадает с именем вашего приватного пакета.

Часть 7. Ошибки, которые команды совершают чаще всего

Ошибка 1: Смотреть только на прямые зависимости npm audit в режиме по умолчанию часто ограничивается поверхностным анализом. Нужно явно включать глубокое сканирование и использовать инструменты уровня SCA, а не только встроенный аудит пакетного менеджера.

Ошибка 2: Игнорировать lock-файл или пересоздавать его без проверки Если lock-файл не коммитится в репозиторий или регулярно пересоздаётся командой npm install вместо npm ci — детерминизм сборки теряется.

Ошибка 3: Устанавливать пакет через npx без проверки npx some-tool скачивает и запускает пакет без lockfile и без hash-верификации. Это допустимо для разовых задач в изолированном окружении, но не в CI/CD-контексте [29].

Ошибка 4: Не проверять, что пакет существует, перед установкой AI может галлюцинировать правдоподобные имена — и разработчик может обнаружить, что устанавливает не тот пакет, только когда код не работает. Или — не обнаружить вовсе, если пакет-slopsquat ведёт себя нормально.

Ошибка 5: Принимать PR с изменёнными зависимостями без проверки lock-файла Изменение в requirements.txt на одну строчку может принести несколько новых транзитивных пакетов. Если reviewer смотрит только на верхний файл — транзитивный граф остаётся вне поля зрения.

Ошибка 6: Использовать внутренние имена пакетов, не зарезервированные в публичном реестре Имена приватных пакетов утекают через package.json, CI-логи и error messages. Если они не зарезервированы — любой может занять это имя в npm или PyPI [20].

Часть 8. Как выстроить контроль в команде

Минимальный жизнеспособный процесс (MVP)

1. Коммитить lock-файл в репозиторий. Всегда.
2. В CI использовать npm ci / yarn install --frozen-lockfile / pip install --require-hashes.
3. Запускать npm audit / pip-audit на каждом PR.
4. Проверять новые пакеты через OpenSSF Scorecard перед добавлением.
5. Использовать scoped-имена для приватных пакетов.

Продвинутый уровень

1. SCA с поддержкой транзитивных зависимостей (Snyk, Grype, Trivy) интегрирована в CI-пайплайн.
2. SBOM генерируется автоматически на каждый билд и хранится как артефакт релиза.
3. Dependabot или Renovate настроены для автоматических PR при появлении патчей безопасности.
4. Политика реестров: разрешены только верифицированные источники. В npm — --registry явно указан, в pip — --index-url прибит.
5. Pre-install hooks (через npq или аналоги) проверяют пакет до установки [29].
6. Имена всех внутренних пакетов зарезервированы в публичных реестрах.

Где нужен gate, а не просто предупреждение

Некоторые события требуют остановки merge или release, а не просто уведомления:

• новый пакет в PR с нулевой историей в реестре;
• critical/high CVE в транзитивной зависимости без доступного патча;
• изменение lock-файла без соответствующего изменения манифеста;
• пакет с именем, совпадающим с внутренним, из публичного реестра.

Именно здесь HighVibe работает как дополнительный слой контроля: он анализирует конкретное изменение в PR — включая новые и изменённые зависимости, lock-файл и контекст релиза — и сигнализирует, когда изменение несёт риск, который стоит остановить до merge, а не разбирать уже после. Цель не заменить SCA или CI-проверки, а дать команде короткий и понятный ответ: «это изменение безопасно принимать прямо сейчас?»

Подробнее о подходе: https://highvibe.dev/

Будущее: регуляторика и тренды

Атаки на software supply chain выросли на 567% год к году по данным Google Cloud за 2025 год [2]. Среднее время компрометации через supply chain — около 12 минут [2]. При этом уровень обнаружения таких атак — около 3% [2].

Регуляторы реагируют:

• Указ президента США 14028 (2021) требует SBOM для федерального ПО.
• EU Cyber Resilience Act вступает в силу к декабрю 2027 года и требует supply chain security assurances для продуктов, продающихся на территории ЕС [31].
• NIS2 в ЕС начал применяться с октября 2024 года [22].

Тренд очевиден: требования к прозрачности цепочки зависимостей будут ужесточаться. Команды, выстраивающие SBOM и SCA сейчас, получают конкурентное преимущество — не только в безопасности, но и в соответствии регуляторным требованиям.

Заключение: «работает» ≠ «безопасно»

AI-ассистенты стали стандартным инструментом разработки. Они ускоряют написание кода — но также ускоряют появление зависимостей, которые никто не выбирал сознательно и никто не проверял. Транзитивный граф, галлюцинированные имена, confusion-атаки — всё это атакует в слепой зоне, которую не покрывает ни один беглый взгляд на package.json.

Что делать дальше:

1. Аудит текущего состояния: прогоните SCA с поддержкой транзитивных зависимостей по вашим репозиториям.
2. Настройте SBOM-генерацию в CI — хотя бы для продовых компонентов.
3. Проверьте, зарезервированы ли имена ваших внутренних пакетов.
4. Добавьте в чеклист code review проверку lock-файла при изменении зависимостей.
5. Настройте gate для критических изменений в supply chain — не уведомление, а блокировку merge.

Скорость не отменяет ответственности за то, что едет вместе с кодом.

Источники

[1] knostic.ai — How to Secure AI Coding Assistants and Protect Your Codebase — https://www.knostic.ai/blog/ai-coding-assistant-security

[2] pixee.ai — How to Secure the 77% of Code You Didn't Write — https://www.pixee.ai/blog/secure-77-percent-code-you-didnt-write

[3] softwareseni.com — AI-Generated Code Security Risks: Why Vulnerabilities Increase 2.74x — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[4] paelladoc.com — Securing AI code with Snyk: A practical guide — https://paelladoc.com/blog/securing-ai-code-with-snyk/

[5] veracode.com — AI-Generated Code Security Risks: What Developers Must Know — https://www.veracode.com/blog/ai-generated-code-security-risks/

[6] softwareseni.com — Security Risks in AI-Generated Code and How to Mitigate Them — https://www.softwareseni.com/security-risks-in-ai-generated-code-and-how-to-mitigate-them/

[7] cset.georgetown.edu — Cybersecurity Risks of AI-Generated Code (Issue Brief, Nov 2024) — https://cset.georgetown.edu/wp-content/uploads/CSET-Cybersecurity-Risks-of-AI-Generated-Code.pdf

[8] sqmagazine.co.uk — AI Coding Security Vulnerability Statistics 2026 — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[9] endorlabs.com — Demystifying Transitive Dependency Vulnerabilities — https://www.endorlabs.com/learn/demystifying-transitive-dependency-vulnerabilities-sca

[10] nirmalya.net — Slopsquatting (i.e., package hallucination) — https://www.nirmalya.net/posts/2025/05/slopsquatting-aka-package-hallucination/

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

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

[13] securityweek.com — AI Hallucinations Create a New Software Supply Chain Threat — https://www.securityweek.com/ai-hallucinations-create-a-new-software-supply-chain-threat/

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

[15] devops.com — AI-Generated Code Packages Can Lead to 'Slopsquatting' Threat — https://devops.com/ai-generated-code-packages-can-lead-to-slopsquatting-threat-2/

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

[17] blog.gitguardian.com — Dependency Confusion Attacks and Prevention — https://blog.gitguardian.com/dependency-confusion-attacks/

[18] orca.security — Dependency Confusion Supply Chain Attacks — https://orca.security/resources/blog/dependency-confusion-supply-chain-attacks/

[19] snyk.io — Detect and prevent dependency confusion attacks on npm — https://snyk.io/blog/detect-prevent-dependency-confusion-attacks-npm-supply-chain-security/

[20] github.com/lirantal — npm Security Best Practices — https://github.com/lirantal/npm-security-best-practices

[21] crowdstrike.com — CVE-2024-3094 and XZ Upstream Supply Chain Attack — https://www.crowdstrike.com/en-us/blog/cve-2024-3094-xz-upstream-supply-chain-attack/

[22] softwareseni.com — The XZ Utils Backdoor CVE-2024-3094 — https://www.softwareseni.com/the-xz-utils-backdoor-cve-2024-3094-and-the-multi-year-social-engineering-campaign-behind-it/

[23] blog.cyberdesserts.com — npm Security Risks 2026: Vulnerable Packages & Fixes — https://blog.cyberdesserts.com/npm-security-vulnerabilities/

[24] bernat.tech — Defense in Depth: A Practical Guide to Python Supply Chain Security — https://bernat.tech/posts/securing-python-supply-chain/

[25] aikido.dev — Software Supply Chain Security Vulnerabilities — https://www.aikido.dev/blog/software-supply-chain-security-vulnerabilities

[26] ibm.com — What Is a Software Bill of Materials (SBOM)? — https://www.ibm.com/think/topics/sbom

[27] openssf.org — OpenSSF Scorecard — https://openssf.org/projects/scorecard/

[28] scorecard.dev — OpenSSF Scorecard — https://scorecard.dev/

[29] cisa.gov — OpenSSF Scorecard (Tools) — https://www.cisa.gov/resources-tools/services/openssf-scorecard

[30] habr.com — Lock-файлы npm — https://habr.com/ru/companies/domclick/articles/513130/