Атаки через цепочки поставок ПО удвоились: один взломанной учетки хватает для компрометации сотен пакетов

По данным компании «Информзащита», за первое полугодие 2026 года доля атак через цепочки поставок программного обеспечения среди значимых облачных инцидентов выросла на 15 процентных пунктов — с 10% до 25%. Абсолютное количество таких инцидентов более чем удвоилось. Основная причина роста — сложность современной разработки: даже небольшие корпоративные продукты зависят от множества внешних библиотек, пакетов и автоматизированных процессов сборки.

Злоумышленники используют легитимные каналы доставки кода. Если компрометируется аккаунт разработчика или токен доступа к системе непрерывной интеграции (CI/CD), вредоносный код попадает в сборку штатным менеджером зависимостей. Для систем сетевого контроля такая установка выглядит как обычная работа команды, что затрудняет обнаружение атаки.

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

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

Механика проникновения и кража секретов

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

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

Сценарии атак 2026 года делятся на несколько типов:

• Компрометация открытого пакета: Взлом аккаунта сопровождающего (мэйнтейнера) или самого пакета.
• Атаки на CI/CD: Изменение сборок, кэшей или workflow без прямого доступа к конечному приложению.
• Кража учетных данных разработчика: Использование зараженного инструмента для перехода в облачную инфраструктуру клиента.
• Злоупотребление плагинами: Эксплуатация расширений IDE или сборочных систем, имеющих доступ к корпоративным сервисам от имени сервисной учетной записи.

Отраслевые риски и меры защиты

Наиболее уязвимыми оказались технологические компании и разработчики ПО — на них приходится около 34% случаев инцидентов. Финансовый сектор занимает вторую строчку (21%), за ним следуют интернет-ритейл (16%) и промышленность (14%). Высокая доля атак в этих отраслях связана с интенсивным использованием сторонних компонентов, автоматизированных сборок и интеграций.

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

Для снижения рисков компаниям необходимо контролировать всю цепочку доверия:

• Проверять новые зависимости до включения в сборку.
• Вводить период задержки перед установкой недавно опубликованных версий пакетов, так как вредоносные публикации часто удаляются вскоре после обнаружения.
• Ограничивать права CI/CD-систем минимально необходимыми действиями.
• Заменять долгоживущие токены короткоживущими учетными данными.
• Регулярно проверять секреты разработчиков на утечки и аномальное использование.

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