Атаки на цепочку поставки – одна из самых устойчивых угроз для разработки программного обеспечения. По итогам OWASP Top Ten, в 2025 году проблемы с цепочкой поставки заняли третью позицию в рейтинге наиболее критических рисков безопасности веб-приложений. В случае с атаками в open source злоумышленники эксплуатируют доверие к публичным репозиториям, человеческий фактор и сложность зависимостей, внедряя вредоносный код в тысячи проектов одновременно. Последствия варьируются от единичной кражи секретов до компрометации целых экосистем с глобальными экономическими потерями. Только за 2025 год они оцениваются в $60 млрд и прогнозируются на уровне $138 млрд в ближайшие годы.
Меня зовут Артем Максимов, я отвечаю за продуктовую экспертизу в платформе безопасной разработки CodeScoring. Наша команда агрегирует и дополняет данные из более чем 20 баз уязвимых и вредоносных зависимостей, а также более 10 лет анализирует исходный код открытых компонентов. Опираясь на эту накопленную экспертизу, непрерывный мониторинг экосистем и реальные инциденты последних лет, в этой статье я решил разобрать основные векторы атак на 2026 год, рассмотреть, как атаки эволюционируют с участием ИИ и предложить практические меры защиты.
Материал будет особенно полезен senior-разработчикам, техлидам и DevSecOps-инженерам, которые ежедневно работают с open source зависимостями и отвечают за процессы сборки и доставки кода. Он поможет им лучше понимать реальные векторы атак на цепочку поставки, принимать более взвешенные решения при выборе и обновлении компонентов и выстроить практическую защиту без излишней бюрократии.
Сторонний код – это ваш код
По нашим оценкам, в типичном проекте примерно 80% кода составляют заимствованные компоненты. Данные из других исследований подтверждают эту картину. Например, недавний отчёт Synopsys показал, что 96% коммерческих проектов опираются на open source компоненты и 77% кода в этих проектах пришло из открытых источников.
Тем временем, мировой open source не собирается останавливаться. По нашим данным, сейчас он включает в себя более 250 млн проектов, около 11 млн пакетов и порядка 195 млн их версий. Вместе с этим растёт и количество угроз. За прошлый год мы зарегистрировали 456 тысяч вредоносных версий пакетов – это десятикратный рост по сравнению с 2024 годом. Продолжают расти и другие классы рисков – например, в начале лета прошлого года были зафиксированы 28 npm-пакетов с protestware-скриптами, ориентированными на российских пользователей и разработчиков.
Помимо этого любая open source экосистема содержит огромное количество legacy-кода. В отчете Census III от The Linux Foundation, в рамках которого формируется список наиболее широко используемых библиотек с открытым исходным кодом, в качестве примера приводится npm-пакет request. Он по-прежнему фигурирует в списке наиболее распространенных прямых и транзитивных зависимостей, хотя был объявлен устаревшим еще в 2019 году. Даже его мейнтейнер отметил, что «подходы, лежащие в основе request, безнадежно устарели». При этом, по нашим данным, в репозитории PyPI примерно 0,7% всех пакетов имеют статус yanked («изъят») — то есть они были удалены мейнтейнерами проекта.
Таким образом, нужно заботиться о своих зависимостях, чтобы избежать скрытых рисков, которые могут привести к серьезным инцидентам, и обеспечить безопасность всего проекта на протяжении его жизненного цикла. Основные направления здесь – это композиционный анализ, который позволяет детально изучить состав используемых компонентов, выявляя уязвимости и лицензионные конфликты, и защита цепочки поставки, о которой мы как раз сегодня и поговорим.
Таксономия атак: три основных семейства
Атака на цепочку поставки – это попытка внедрить вредоносный компонент в ваш контур разработки, что может привести к компрометации данных, систем или целых инфраструктур. Мы классифицируем три основных вида атак по точке входа и механизму внедрения вредоносной функциональности.
1. Вредоносный пакет
В этом сценарии злоумышленник создаёт пакет, который несёт некоторую полезную функцию, и размещает его в публичном репозитории. Одним из самых популярных и резонансных примеров в последние месяцы можно назвать Shai-Hulud 2.0, который стал причиной слива более 400 000 секретов, что привело к значительным убыткам для множества компаний.
Как не дать вредоносу пробраться в репозиторий?
Контроль над зависимостями начинается с базовых, но критически важных практик. Фиксация версий компонентов, включая транзитивные, позволяет избежать автоматических обновлений до потенциально опасных релизов. Перед ручным обновлением стоит проверить новую версию на наличие нежелательного поведения, изменений в лицензировании и соответствие внутренним политикам безопасности.
Не менее значимым шагом является ограничение поведения зависимостей во время установки. Запрет исполнения install-скриптов снижает риск немедленного выполнения вредоносного кода – одной из самых распространённых техник атак на цепочку поставки. В сочетании с изоляцией сборки и использованием песочниц это позволяет локализовать потенциальную угрозу и предотвратить её распространение на основную инфраструктуру, даже если вредоносный компонент всё же оказался в проекте.
Дополнительный уровень защиты даёт анализ компонентов ещё на входе в контур разработки. Проверка скачиваемых зависимостей (OSA) помогает выявлять заведомо вредоносные пакеты до их попадания в репозиторий, а композиционный анализ (SCA) и ведение SBOM формируют полную и прозрачную картину состава проекта. Это не только упрощает поиск вредоносных зависимостей, но и делает риски управляемыми.
2. Путаница в названиях (name squatting)
Часто злоумышленники создают пакеты с именами, похожими на легитимные, рассчитывая на невнимательность или незнание разработчика. На первый взгляд кажется, что достаточно включить проверку на наличие пакета в пакетном индексе и о проблеме можно забыть. Но на практике существует целый «зоопарк» векторов, ориентированных на человеческую невнимательность, которые нужно держать в голове:
1. Combosquatting: Атакующий создает пакет с легитимным названием, но добавляет к нему популярный в сообществе суффикс: -dev, -rc и так далее.
2. Изменение последовательности слов в имени пакета: Например, в экосистеме Python существует вполне легитимный пакет python-dateutil. Он упрощает работу с датами и временем. Злоумышленник может выпустить пакет dateutil-python, и разработчик, который в спешке не помнит точное название, установит зловред.
3. Манипуляции с разделителями: Иногда к имени пакета добавляют разделители. Например, пакет pyyaml может превратиться в py-yaml, а fsspec в fs-spec.
4. Typosquatting: В эту категорию попадает широкий набор всевозможных модификаций имен, но все они рассчитаны на то, что разработчик допустит опечатку в имени пакета. Реальный пример: в экосистеме Jest [фреймворк для тестирования JavaScript] есть два легитимных пакета fetch-mock-jest и jest-fetch-mock. Но в прошлом году в сети обнаружили поддельный пакет с почти идентичным названием — jest-fet-mock.
5. Similarity attack: Эта атака напоминает typosquatting, но здесь авторы вредоносов подбирают имена пакетов по звучанию. Например, в Python есть популярный пакет certifi, оканчивающийся на «i», а злоумышленник может создать пакет certify с «y» на конце. Или взять библиотеку NumPy, добавить в конец «ai» и получить NumPai.
6. Dependency confusion: В этом случае злоумышленник публикует пакет с именем, которое имеет внутренний корпоративный пакет, а инструмент сборки в процессе разрешения зависимостей загружает его из публичного репозитория вместо внутреннего пакета.
7. Brandjacking: Вредоносный пакет включает в свое название имя крупной уважаемой компании или популярного open source-проекта, чтобы вызвать доверие. Например, в октябре исследователи из Koi Security обнаружили вредонос PhantomRaven, который, помимо прочего, прятался в пакете с названием airbnb-base-hf. Он похищал npm-токены, учетки GitHub и CI/CD-секреты у разработчиков по всему миру. Здесь интересен сам механизм распространения: атакующий использовал технику Remote Dynamic Dependencies (RDD) — вредоносный код подгружался не с npm, а с внешнего ресурса во время установки.
8. Манипуляции с пространством имён (namespace omission). Если разработчик меняет имя аккаунта или организации и прежнее имя освобождается, злоумышленник может зарегистрировать его и опубликовать под ним вредоносный пакет, маскируясь под оригинального автора. Кроме того, атакующие клонируют легитимные проекты, внедряют в них вредоносный код, публикуют копии под ранее использовавшимися именами и распространяют их через форки и внешние площадки.
9. Галлюцинации систем ИИ (slopsquatting). Сегодня многие разработчики используют ИИ-агентов в IDE – например, просят подсказать библиотеку или показать пример кода. Но LLM «галлюцинируют» и рекомендуют несуществующие библиотеки в 20% случаях, либо воспроизводят ряд вышеописанных рисков, в основе которых лежит мимикрия проблемных решений под легитимные. Этим пользуются злоумышленники: они создают вредоносный пакет и ожидают, что кто-то установит его, доверившись исключительно подсказке модели. Ситуацию усугубляет тот факт, что галлюцинации являются воспроизводимыми, что облегчает процесс наименования вредоносных компонентов для злоумышленников.
Как бороться с путаницей в зависимостях?
Все вышеперечисленные методы для борьбы с вредоносными пакетами применимы и здесь. К ним также добавляется фиксация названий пакетов для предотвращения случайных установок и ошибок в именах, запрет на скачивание неизвестных компонентов из публичных источников, чтобы минимизировать риски от непроверенных репозиториев, и превентивный сквоттинг в публичных индексах пакетов. Хотя последний подход мы считаем сомнительным из-за этических и практических вопросов, но в некоторых случаях может быть оправдан как мера предосторожности для защиты от потенциальных подмен.
3. Подрыв легитимного пакета
Ранее безопасные компоненты могут быть скомпрометированы несколькими способами – например, через внедрение вредоносной функциональности через исходный код. Чтобы добиться этого, злоумышленник становится мейнтейнером известного проекта, входя в доверие к автору или просто выкупая у него домен. Например, есть старый проект Polyfill, который автоматически добавляет недостающие функции в старых браузерах. В феврале 2024 года домен polyfill.io купила компания Funnull, которую неоднократно обвиняли в участии в различных мошеннических схемах и связях с киберпреступностью. Летом того же года домен cdn.polyfill.io начал распространять библиотеку polyfill.js с вредоносным кодом, перенаправляющим пользователя на мошеннические сайты.
Другой известный пример – атака на XZ Utils. В 2021 году в проекте появился новый участник под именем Цзя Тан – человек с наработанной репутацией. В конце 2022 года с подачи сообщества мейнтейнер передал Тану права. А тот, вместо дальнейшего развития проекта, провел комплексную атаку на цепочку поставки: постепенно внедрял бэкдор в библиотеку, контролирующую ключевые функции компрессии и распаковки, чтобы обеспечить удаленное выполнение кода на серверах, использующих скомпрометированную версию XZ. Кстати, обнаружили проблему практически случайно. Один разработчик поставил свежую версию пакета и заметил, что SSH-подключения слишком сильно нагружали процессор. Он был достаточно въедливым, чтобы начать во всем разбираться, и в итоге нашел «закладку».
Также внедрение может происходить на этапе сборки легитимного пакета – через запуск как мейнтейнер или участник, или взлом системы сборки, что позволяет внести изменения прямо в процесс создания релиза. Кроме того, злоумышленники могут распространять вредоносную версию легитимного пакета, маскируя ее под официальную. Предположим, что разработчик десять лет назад опубликовал пакет и больше его не поддерживает, а аккаунт привязан к почтовому адресу на «протухшем» домене – в этом случае злоумышленник находит такой адрес, регистрирует его заново, восстанавливает доступ к почте и выкладывает новую версию пакета – уже с сюрпризом в виде вредоносного кода. Сюда же относится подделка метаданных пакета, чтобы обмануть системы проверки, а также MITM-атаки для перехвата трафика во время скачивания, и перехват администратора или всей цепочки поставки пакета, что дает полный контроль над распространением.
Как не стать жертвой взломанного пакета?
К вышеперечисленным практикам здесь стоит добавить аудит используемых пакетов для проверки их целостности, истории изменений и признаков компрометации, что помогает своевременно выявлять подобные аномалии.
Вместо вывода
Атаки на цепочку поставки давно перестали быть экзотикой и превратились в повседневный риск для любой команды, использующей сторонний код. Универсальной «серебряной пули» здесь не существует, но базовые практики и рекомендации по-прежнему дают наибольший эффект.
Полезным упражнением становится хотя бы однократная сборка проекта исключительно из исходных кодов, без доверия к заранее собранным артефактам. Такой подход позволяет лучше понять реальную цепочку формирования бинарей, выявить скрытые зависимости и обнаружить неочевидные точки риска.
Отдельного внимания заслуживает объём стороннего кода. Чем меньше внешних компонентов используется в проекте, тем меньше поверхность атаки и тем проще контролировать происходящее. Это не означает отказ от open source, но требует осознанного выбора зависимостей и регулярного пересмотра их необходимости.
Чтобы внедрение практик проходило легче – стоит ознакомиться с современными инициативами и методическими фреймворками защиты цепочки поставки – такими как SLSA. Они помогают структурировать подход к безопасности, выстроить воспроизводимые процессы и перейти к системной работе с рисками вместо реагирования на уже произошедшие инциденты. В условиях постоянно эволюционирующих атак именно такой подход становится ключевым фактором устойчивости разработки.
