Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASAПо оценке специалистов компании «Информзащита», в первом полугодии 2026 г. доля атак через цепочки поставок ПО среди...
21 Августа 2026 10:31 21 Авг 2026 10:31 |
По оценке специалистов компании «Информзащита», в первом полугодии 2026 г. доля атак через цепочки поставок ПО среди значимых облачных инцидентов выросла на 15 процентных пунктов – с 10% до 25%. За полгода доля выросла в 2,5 раза, при этом абсолютное число значимых инцидентов, связанных с цепочками поставок, более чем удвоилось. Об этом CNews сообщили представители компании «Информзащита».
Рост связан с тем, что современная разработка опирается на большое число внешних компонентов и автоматизированных процессов, которым компания вынуждена доверять. Даже относительно небольшой корпоративный продукт зависит от внешних библиотек, пакетов, расширений среды разработки, систем сборки и репозиториев. Каждый такой компонент связан с учетными записями сопровождающих, токенами доступа и автоматизированными процессами публикации. Компрометация одного аккаунта сопровождающего, токена публикации или элемента 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 следует ограничивать минимально необходимыми действиями, долгоживущие токены заменять короткоживущими учетными данными, а секреты разработчиков регулярно проверять на утечки и аномальное применение. Отдельного контроля требуют изменения владельцев пакетов, публикация новых версий, отключение защиты веток и действия сервисных аккаунтов за пределами обычного профиля.
Практический приоритет – ограничить последствия компрометации одного элемента цепочки. Организация должна исходить из того, что популярная зависимость, аккаунт сопровождающего или токен разработчика могут быть скомпрометированы, и заранее ограничивать их возможности. Чем меньше полномочий получает такой компонент после попадания внутрь процесса разработки, тем ниже вероятность того, что одна вредоносная публикация даст атакующему доступ сразу к репозиториям, облачным ресурсам и корпоративным данным.