Новые зависимости в проекте: как одна библиотека может создать риск для продукта

Одна строчка в package.json — и цепочка атак готова. Разбираем, почему зависимости стали главным вектором supply chain угроз, как работают транзитивные риски, slopsquatting и dependency confusion — и что проверять до merge

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

Представьте: разработчик добавляет небольшую утилиту — логгер, хелпер для HTTP-запросов, пару вспомогательных функций. Ревьюер смотрит на diff, видит знакомое имя пакета и ставит approve. CI проходит. Merge выполнен.

Через три дня выясняется, что в одной из транзитивных зависимостей этой утилиты живёт вредоносный код, который при установке тихо собирает переменные окружения и отправляет их на внешний сервер.

Это не гипотетический сценарий. Именно так работало большинство атак 2024–2025 годов — через зависимости, которые никто не читал до конца.

Статья для тех, кто принимает решение о merge, настраивает release gates и выстраивает AppSec-практики в команде: CTO, Tech Lead, AppSec-инженер, DevSecOps. Разберём, как устроены риски зависимостей, какие векторы атак сейчас наиболее активны, и что конкретно проверять до того, как новый пакет окажется в production.

Почему зависимости стали главным вектором атак

Масштаб проблемы

Современное приложение — это в первую очередь сборка из чужого кода. По данным Socket и Chainguard, 70–90% типичного кода составляют сторонние пакеты [7]. Среднестатистическое корпоративное приложение использует около 150 зависимостей, из которых 90% — косвенные (транзитивные) [1].

Именно транзитивные зависимости — главная слепая зона. Это пакеты, которые подтягивают зависимости вашего пакета, зависимости этих зависимостей и так далее. Разработчик видит в package.json или requirements.txt десяток строк. Реальное дерево зависимостей может насчитывать сотни узлов — каждый из которых вносит свою площадь атаки.

По данным Ivanti, к 2024 году 75% software supply chains сообщили об атаках [1]. Gartner предсказывал, что к 2025 году 45% организаций испытают supply chain атаку [8]. Реальность оказалась хуже прогноза: данные Cyble показывают, что с апреля 2025 года число инцидентов удвоилось и устойчиво держится выше 28 случаев в месяц [2].

Средние потери от supply chain инцидента, по данным IBM Cost of a Data Breach Report 2025, составляют 4,91 млн долларов глобально и 10,22 млн долларов в США [9].

Почему атаки через зависимости так эффективны

Ключевое преимущество для атакующего — масштаб при минимальных затратах. Один скомпрометированный пакет может добраться до миллионов проектов, которые никогда не слышали о его существовании. В сентябре 2025 года двухчасовое окно компрометации npm-пакетов debug и chalk затронуло пакеты с совокупными 2,6 млрд еженедельными загрузками [3].

Атакующий не пробивает периметр — он приходит через доверенный канал доставки кода. Разработчик запускает npm install или pip install, и вредоносный код выполняется автоматически через install-time скрипты. CI-пайплайн не сигнализирует: пакет пришёл из официального реестра, подписан корректными метаданными, имеет подходящий номер версии.

Три главных вектора: как именно зависимость становится угрозой

1. Компрометация легитимного пакета

Наиболее опасный сценарий — когда атакующий захватывает управление над существующим, популярным пакетом. Классический пример — инцидент с XZ Utils (CVE-2024-3094, CVSS 10.0).

Злоумышленник на протяжении нескольких лет выстраивал репутацию в open source проекте, добился прав мейнтейнера, а затем внедрил бэкдор в библиотеку liblzma — зависимость, которую использует OpenSSH daemon. Бэкдор позволял выполнять произвольный код на удалённой машине до фазы аутентификации, при наличии определённого приватного ключа [10].

Вредоносный код не был виден в истории коммитов: он присутствовал только в release-артефактах и build-скриптах. Те, кто проверял только репозиторий, ничего не замечали — уязвимость жила в самих собранных тарболлах [11].

Урок: проверить репозиторий недостаточно. Доверие к release-артефакту должно быть отдельным и доказуемым.

В сентябре 2025 года произошёл аналогичный по масштабу инцидент: атакующие скомпрометировали аккаунты мейнтейнеров и опубликовали вредоносные версии 18 популярных npm-пакетов, включая debug и chalk. Вредоносный код таргетировал криптовалютные кошельки и blockchain-транзакции [3].

2. Dependency confusion и typosquatting

Dependency confusion — атака, при которой злоумышленник публикует в публичном реестре пакет с тем же именем, что у внутреннего приватного пакета организации. Пакетный менеджер по умолчанию часто выбирает более высокую версию — то есть вредоносный публичный пакет.

Typosquatting работает проще: злоумышленник регистрирует имя, максимально похожее на популярный пакет — с опечаткой, сменой регистра, добавлением дефиса. Разработчик, ошибившийся при наборе, получает вредоносный код.

По данным Sonatype, только за 2024 год было задокументировано 512 847 вредоносных пакетов — рост 156% год к году [12].

3. Slopsquatting: новый вектор эпохи AI-кодинга

В апреле 2025 года Seth Larson, Developer-in-Residence Python Software Foundation, ввёл термин slopsquatting — эволюция typosquatting, адаптированная под AI-ассистентов [4].

Механика простая: LLM при генерации кода галлюцинирует несуществующие имена пакетов. Атакующие регистрируют пакеты под этими именами с вредоносными payload. Разработчик принимает AI-рекомендацию, запускает install — и малварь уже на машине.

Исследование USENIX Security 2025 показало, что от 5% до 38% имён пакетов, которые предлагают ведущие LLM, — галлюцинации [13]. По данным из 2023–2024 годов, 20–35% галлюцинированных имён в Python и npm были конвертированы в реальные вредоносные загрузки [4].

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

Это прямое следствие «vibe-coding» паттерна: большинство AI-сгенерированного кода сейчас отправляется в production с меньшим peer review, чем прежде [4].

Что делает транзитивные зависимости особенно трудными для контроля

Глубина дерева зависимостей

Даже простой npm-пакет типа express тянет за собой десятки вложенных зависимостей. Каждый узел этого дерева — отдельная поверхность атаки, которую команда явно не проверяла и не добавляла в проект.

OWASP зафиксировал: подавляющее большинство уязвимостей живёт именно в транзитивных зависимостях, а не в прямых [5]. SCA-инструменты без полного обхода дерева дают ложное чувство защищённости.

Автоматическое выполнение при установке

PyPI-пакеты автоматически выполняют setup.py при установке через pip. Npm-пакеты — postinstall-скрипты. Это означает, что вредоносный код может выполниться просто при запуске npm install или pip install — до того, как разработчик увидел хоть одну строку кода библиотеки [14].

Lock-файлы: иллюзия стабильности

Lock-файлы (package-lock.json, yarn.lock, poetry.lock) фиксируют версии зависимостей — и это хорошо. Проблема в том, что они не защищают от ситуации, когда уже зафиксированная версия оказывается скомпрометирована. Если злоумышленник обновляет существующую версию пакета в реестре, не меняя номер — lock-файл не поможет.

Именно поэтому верификация целостности артефактов (хэши, подписи) критична отдельно от pin-версий.

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

XZ Utils / CVE-2024-3094 (2024)

Бэкдор в liblzma затронул OpenSSH на Linux-дистрибутивах Debian и Fedora. CVSS-оценка — 10.0. Немецкое Федеральное ведомство уголовной полиции (BKA) вручную связывалось с администраторами уязвимых систем. Уровень вмешательства указывал на близость к глобальному каскадному сбою Linux-инфраструктуры [15].

Главный урок: атакующий потратил годы на выстраивание доверия в open source сообществе. Репутация мейнтейнера — не гарантия безопасности кода.

npm Supply Chain: debug, chalk и 16 пакетов (сентябрь 2025)

В течение двух часов 18 популярных npm-пакетов с суммарными 2,6 млрд еженедельными загрузками были скомпрометированы. Вредоносный код таргетировал cryptocurrency кошельки. Это транзитивные зависимости — большинство проектов не добавляли debug или chalk напрямую, они приходили через другие пакеты [3].

Log4Shell / CVE-2021-44228

Уязвимость в Apache Log4j существовала с 2013 года — незамеченной восемь лет. CVSS — 10.0. По оценке Tenable, это «самая масштабная и критическая уязвимость десятилетия». Организации, у которых был SBOM, определяли свою экспозицию за часы. Те, у кого его не было, тратили недели [16].

Атака s1ngularity на Nx build system (август 2025)

Злоумышленники внедрили AI-управляемый малварь в Nx build system — популярный инструмент монорепозиториев. Было скомпрометировано более 2 180 GitHub-аккаунтов. Малварь таргетировал AWS-ключи, OpenAI-токены и encryption-ключи [17].

Как устроена защита: инструменты и практики

SCA: Software Composition Analysis

SCA — это автоматический анализ состава зависимостей. Инструмент сканирует манифесты (package.json, pom.xml, requirements.txt) и lock-файлы, строит полное дерево зависимостей, включая транзитивные, и сверяет каждый компонент с базами уязвимостей — NVD, MITRE CVE, GitHub Security Advisories.

Важный нюанс: хороший SCA сегодня — это не только матч с CVE-базами. Ключевая возможность — reachability analysis: определение того, является ли уязвимость реально достижимой в вашем коде, а не просто присутствующей в зависимости. По данным Aikido, это снижает шум на ~92% [18].

SCA не заменяет SAST — они решают разные задачи. SAST анализирует ваш код. SCA — сторонние компоненты. Оба нужны в пайплайне.

SBOM: Software Bill of Materials

SBOM — формализованный инвентарь всех компонентов продукта. Это не отчёт, запускаемый раз в квартал, — это живой документ, который обновляется при каждом релизе.

Ценность SBOM проявляется в момент инцидента: когда выходит CVE для популярной библиотеки, наличие SBOM позволяет за минуты определить, есть ли уязвимый компонент в вашем продукте. Без SBOM та же задача занимает дни.

CISA в 2025 году обновила минимальные требования к SBOM, добавив обязательные поля: Component Hash, License, Tool Name, Generation Context [19]. Для компаний, поставляющих ПО государственным заказчикам США, SBOM уже фактически обязателен по Executive Order 14028.

Форматы: CycloneDX (ориентирован на безопасность и DevSecOps), SPDX (широкий compliance, Linux Foundation).

Верификация целостности и provenance

Проверка хэшей артефактов, подписей пакетов, build provenance (например, через SLSA framework) — это то, чего не заменяет просто pinning версий. XZ Utils показал: злоумышленник может внедрить вредоносный код в release-артефакт, не меняя исходный код в репозитории.

OpenSSF Scorecard и sigstore дают инструменты для проверки того, как именно был собран пакет и можно ли ему доверять.

Что проверять до merge: операционный чек-лист

Уровень Pull Request (каждый PR с изменением зависимостей)

1. Какой именно пакет добавлен и зачем — есть ли обоснование в описании PR?
2. Известен ли мейнтейнер? Насколько активен репозиторий? Когда последний коммит?
3. Проверен ли пакет через SCA на известные CVE, включая транзитивные зависимости?
4. Не является ли имя пакета похожим на популярный (typosquatting-проверка)?
5. Если код был сгенерирован AI-ассистентом — верифицировано ли существование пакета в официальном реестре перед install?
6. Проверен ли lock-файл — не расходится ли хэш с ожидаемым?
7. Добавляет ли пакет install-time скрипты (postinstall, setup.py)? Если да — обязательна ручная проверка.
8. Соответствует ли лицензия пакета политике проекта?

Уровень Release Gate (перед каждым релизом)

1. SBOM обновлён и отражает актуальное состояние зависимостей?
2. Нет ли непропатченных критических CVE в дереве зависимостей?
3. Не появилось ли новых security advisories по компонентам в production за последние 24–72 часа?
4. Прошёл ли полный SCA-скан (включая транзитивные зависимости, не только прямые)?
5. Нет ли в зависимостях незафиксированных (unpinned) версий?

Постоянный мониторинг (background контроль)

1. Подключены ли GitHub Security Advisories или аналог для автоматических уведомлений?
2. Настроен ли Dependabot или аналог для автоматических PR с обновлениями зависимостей?
3. Есть ли процесс ротации: удаление неиспользуемых зависимостей?
4. Проводится ли аудит зависимостей при onboarding новых проектов и компонентов?

Типичные ошибки и как их не совершать

Ошибка 1: «Мы проверили прямые зависимости — этого достаточно». Нет. Большинство атак идут через транзитивные. Нужно полное дерево.

Ошибка 2: «Lock-файл зафиксирован — значит, нас не касается». Фиксация версии не гарантирует неизменность содержимого пакета в реестре. Нужна верификация хэшей.

Ошибка 3: «AI-ассистент предложил пакет — значит, он существует и безопасен». Slopsquatting эксплуатирует именно это допущение. Всегда верифицировать имя пакета в официальном реестре независимо от AI-рекомендации.

Ошибка 4: «Пакет популярный — он точно безопасен». Популярность делает пакет более привлекательной целью, а не менее рискованным выбором. Debug и chalk — топовые npm-пакеты — были скомпрометированы в 2025 году.

Ошибка 5: «SBOM — это для enterprise, нам пока не нужно». SBOM нужен именно тогда, когда что-то пошло не так. Отсутствие SBOM конвертирует часы реакции в дни — при уже произошедшем инциденте.

Ошибка 6: «SCA генерирует слишком много алертов — мы его отключили». Это симптом неверной конфигурации, а не проблема инструмента. Reachability analysis и фильтрация по severity решают проблему шума.

AI-кодинг и зависимости: специфические риски

AI-ассистенты изменили темп разработки — и изменили профиль рисков. Код генерируется быстро, новые зависимости появляются как побочный эффект автодополнения, pull request'ы становятся длиннее, а diff дочитывают реже.

Согласно Cloudsmith Artifact Management Report, большинство опрошенных разработчиков сказали, что значительная часть их кода AI-генерирована и отправляется в production с меньшим peer review, чем прежде [4].

Это создаёт три конкретных риска:

1. Hallucinated packages — LLM называет несуществующие пакеты, которые атакующий регистрирует с вредоносным кодом.
2. Outdated recommendations — AI обучался на коде с определённым cutoff. Он может рекомендовать устаревшую или уязвимую версию, не зная о CVE, опубликованных после cutoff.
3. Reduced review — быстрый код создаёт иллюзию завершённости. «Работает» не означает «безопасно для merge».

Ключевое правило для AI-кодинга: любой пакет, предложенный LLM, требует ручной верификации в официальном реестре перед install. Не «доверяй, но проверяй» — «проверяй всегда».

Будущее: куда движется threat landscape

По данным OpenSSF, в 2025–2026 годах ожидается дальнейший рост атак через open source зависимости — прежде всего из-за автоматизации атак с помощью GenAI и роста числа LLM-ориентированных векторов [20].

Уже зафиксированы самораспространяющиеся атаки: в сентябре 2025 года Palo Alto Networks задокументировали первый npm-червь Shai-Hulud, способный автономно распространяться по экосистеме [21].

CISA активно обновляет требования к SBOM; регуляторное давление будет только возрастать. Для российских команд, работающих с иностранными заказчиками или разрабатывающих продукты для международных рынков, SBOM из «best practice» превращается в обязательный компонент.

На горизонте — SBOM для AI-компонентов: обязательный учёт ML-моделей, их весов и датасетов как части supply chain. CISA уже указала на это направление в черновике 2025 года [19].

Заключение: зависимость — это не просто строка в файле

Каждая зависимость — это доверие. Доверие к мейнтейнеру, к реестру, к build-процессу, к тому, что код делает то, что написано в README. Это доверие можно и нужно делать измеримым и верифицируемым.

Ключевые выводы:

• Транзитивные зависимости — главная слепая зона; полный SCA обязателен, не только по манифесту
• Lock-файлы не заменяют верификацию целостности артефактов
• Slopsquatting — реальный вектор, а не академическая угроза; любой AI-предложенный пакет требует независимой проверки
• SBOM — это не бюрократия, а инструмент быстрого реагирования при инцидентах
• «Работает» не означает «безопасно для merge»; эти вещи нужно проверять отдельно

Слой контроля между кодом и production

Именно здесь нужен инструмент, который смотрит не на весь репозиторий разом, а на конкретное изменение: что именно приехало в этом PR, какие зависимости добавились или обновились, есть ли среди них новые транзитивные, нет ли подозрительных имён, совпадающих с паттернами slopsquatting или typosquatting.

HighVibe работает как слой контроля до merge и release: анализирует изменения в конкретном PR — новые зависимости, обновления lock-файлов, изменения в конфигурации — и даёт команде короткий понятный ответ: что в этом изменении стоит остановить, что требует проверки, а что можно принять. Это не замена SCA, SAST или SBOM — это дополнительный gate, который работает в контексте конкретного diff, а не абстрактного скана всего кода.

Подробнее — на highvibe.dev.

Источники

[1] Ivanti — "Software Supply Chain Attack Risk on the Rise" — https://www.ivanti.com/blog/software-supply-chain-attack-risk (май 2025)

[2] Industrial Cyber — "Software supply chain attacks surge" — https://industrialcyber.co/reports/software-supply-chain-attacks-surge-as-ransomware-groups-escalate-and-industrial-sectors-face-more-exposure/ (ноябрь 2025)

[3] Upwind — "npm Supply Chain Attack: Massive Compromise of debug, chalk" — https://www.upwind.io/feed/npm-supply-chain-attack-massive-compromise-of-debug-chalk-and-16-other-packages (сентябрь 2025)

[4] Cloudsmith — "Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages" — https://cloudsmith.com/blog/slopsquatting-and-typosquatting-how-to-detect-ai-hallucinated-malicious-packages (ноябрь 2025)

[5] OWASP — "A03 Software Supply Chain Failures — OWASP Top 10:2025" — https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/

[6] Snyk — "Guide to Software Composition Analysis (SCA)" — https://snyk.io/articles/open-source-security/software-composition-analysis-sca/

[7] Socket.dev — "The Landscape of Malicious Open Source Packages: 2025 Mid-Year Threat Report" — https://socket.dev/blog/malicious-open-source-packages-2025-mid-year-threat-report (май 2025)

[8] ScienceDirect — "Software supply chain: A taxonomy of attacks, mitigations and risk assessment strategies" — https://www.sciencedirect.com/science/article/pii/S2214212625003606 (декабрь 2025)

[9] CyberDesserts — "Gartner's 2025 Supply Chain Attack Prediction Vs Reality" — https://blog.cyberdesserts.com/gartners-2025-supply-chain-prediction-a-retrospective-look-at-what-actually-happened/ (март 2026)

[10] Zscaler — "CVE-2024-3094 — Security Compromise in XZ Utils" — https://www.zscaler.com/blogs/security-research/cve-advisory-cve-2024-3094-security-compromise-xz-utils (апрель 2024)

[11] Penligent — "CVE-2024-3094 and the XZ Utils liblzma Backdoor" — https://www.penligent.ai/hackinglabs/cve-2024-3094-and-the-xz-utils-liblzma-backdoor-why-a-routine-update-almost-became-a-trust-crisis/ (март 2026)

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

[13] DevOps.com — "AI-Generated Code Packages Can Lead to Slopsquatting Threat" — https://devops.com/ai-generated-code-packages-can-lead-to-slopsquatting-threat-2/ (декабрь 2025)

[14] ACM — "Malicious Package Detection in NPM and PyPI using a Single Model" — https://dl.acm.org/doi/10.1145/3705304

[15] Purple Ops — "Supply-Chain Risk Monitoring for CVE-2024-3094" — https://www.purple-ops.io/resources-hottest-cves/cve-2024-3094-xz-utils-supply-chain/ (март 2026)

[16] NSF/IEEE — "Top 5 Benefits and Challenges of Adopting SBOMs" — https://par.nsf.gov/servlets/purl/10517392

[17] TechDemocracy — "Top 5 Software Supply Chain Attacks in 2025" — https://www.techdemocracy.com/resources/top-5-software-supply-chain-attacks-in-2025-266 (декабрь 2025)

[18] Aikido Security — "Software Composition Analysis (SCA)" — https://www.aikido.dev/code/open-source-dependency-scanning-sca

[19] CISA — "2025 Minimum Elements for a Software Bill of Materials (SBOM)" — https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom (август 2025)

[20] OpenSSF — "Predictions for Open Source Security in 2025: AI, State Actors, and Supply Chains" — https://openssf.org/blog/2025/01/23/predictions-for-open-source-security-in-2025-ai-state-actors-and-supply-chains/ (январь 2025)

[21] Simon Roses — "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/ (май 2026)