«Информзащита» об атаках supply-chain

Как  сообщила компания «Информзащита», по оценке ее специалистов, в первом полугодии 2026 г. доля атак через цепочки поставок ПО среди значимых облачных инцидентов выросла на 15 процентных пунктов – с 10 до 25%. За полгода их доля выросла в 2,5 раза, при этом абсолютное число значимых инцидентов, связанных с цепочками поставок, более чем удвоилось.

Как поясняют эксперты, рост связан с тем, что современная разработка опирается на большое число внешних компонентов и автоматизированных процессов, которым компания вынуждена доверять. Даже относительно небольшой корпоративный продукт зависит от внешних библиотек, пакетов, расширений среды разработки, систем сборки и репозиториев. Каждый такой компонент связан с учетными записями сопровождающих, токенами доступа и автоматизированными процессами публикации. Компрометация одного аккаунта сопровождающего, токена публикации или элемента CI/CD может дать злоумышленнику штатный канал доставки вредоносного кода в корпоративную сборку. Вредоносный пакет устанавливается штатным менеджером зависимостей, измененный компонент попадает в сборку, а похищенный токен используется в легитимном CI/CD-процессе. Для средств сетевого контроля установка пакета, обращение CI/CD к репозиторию или публикация артефакта часто выглядят как обычная работа команды разработки.

В первой половине 2026 г. подобные кампании затрагивали сразу несколько экосистем, включая npm, PyPI, Composer, расширения Visual Studio Code, плагины Jenkins и AUR. В одном из эпизодов компрометация единственной учетной записи разработчика позволила внедрить вредоносные изменения более чем в 140 пакетов. В других случаях атакующие получали контроль над аккаунтами сопровождающих и публиковали измененные версии сразу сотен компонентов..

Отдельную роль играет кража секретов разработчиков. Вредоносный пакет может использоваться как средство первоначального доступа, после чего атакующие извлекают персональные токены GitHub, ключи облачных платформ, учетные данные реестров пакетов или переменные окружения из систем сборки. Эти данные могут открыть доступ к следующему уровню инфраструктуры: приватным репозиториям, облачным ресурсам, контейнерным реестрам или системам сборки. В исследованных кампаниях украденные токены применялись повторно через несколько недель после первоначальной компрометации, причем часть такой активности, по оценкам исследователей, могла относиться уже к другим группам. В одном из эпизодов злоумышленники заявляли о доступе примерно к четырем тысячам частных репозиториев. Такой сценарий требует не только удалить вредоносный пакет, но и отозвать или заменить учетные данные, которые могли быть похищены во время его выполнения.

Структура атак через цепочки поставок в 2026 г. складывается из нескольких связанных сценариев. Первый строится вокруг компрометации открытого пакета или аккаунта его сопровождающего. Второй затрагивает CI/CD и позволяет менять сборки, кэши либо workflow без прямого доступа к конечному приложению. Еще один распространенный путь – через учетные данные разработчиков, когда первоначальное заражение используется для перехода в облачную инфраструктуру или внутренние репозитории. Отдельно развиваются атаки через плагины и расширения инструментов разработки. Такие инструменты особенно ценны для злоумышленника, если они имеют доступ к секретам, сборке или корпоративным сервисам. Расширение IDE работает внутри среды, где разработчик уже авторизован в корпоративных сервисах, а Jenkins-плагин или компонент сборочного конвейера может взаимодействовать с инфраструктурой от имени сервисной учетной записи. В результате граница между компрометацией поставщика и атакой на конечную компанию становится менее очевидной.

При оценке отраслевого распределения инцидентов, связанных с цепочками поставок, наиболее высока доля технологических компаний и разработчиков ПО – около 34% случаев. Финансовый сектор формирует еще 21%, интернет-ритейл и другие цифровые торговые площадки – 16%, промышленность – 14%, компании из сферы профессиональных и корпоративных услуг – около 9%. На остальные отрасли приходится порядка 6%. Такая структура связана прежде всего с интенсивностью использования сторонних компонентов.

Риск усиливается, когда управление зависимостями отделено от управления доступом и секретами. Команда может проверять уязвимости библиотек, но не отслеживать, кому разрешена их публикация и какие права имеет CI/CD после установки нового компонента. В другой организации защищен репозиторий исходного кода, однако сервисный токен сборочной системы имеет административные полномочия в облаке. Именно через такие связи атака выходит за пределы исходной точки: один похищенный секрет может дать доступ к следующему сервису, а затем – к другим учетным данным и системам.

Для снижения риска компаниям следует контролировать всю цепочку доверия от исходного кода и зависимостей до CI/CD и развертывания в продуктивной среде. Новые зависимости имеет смысл проверять до включения в сборку, а недавно опубликованные версии не устанавливать автоматически без дополнительной верификации. Для критичных проектов оправдан период задержки перед использованием новой версии пакета, поскольку часть вредоносных публикаций удаляется вскоре после обнаружения. Доступ CI/CD следует ограничивать минимально необходимыми действиями, долгоживущие токены заменять короткоживущими учетными данными, а секреты разработчиков регулярно проверять на утечки и аномальное применение. Отдельного контроля требуют изменения владельцев пакетов, публикация новых версий, отключение защиты веток и действия сервисных аккаунтов за пределами обычного профиля.

Практический приоритет – ограничить последствия компрометации одного элемента цепочки. Организация должна исходить из того, что популярная зависимость, аккаунт сопровождающего или токен разработчика могут быть скомпрометированы, и заранее ограничивать их возможности.