Атаки на цепочки поставок ПО: как они работают и как защититься

Когда вредоносный код внедряют в процесс разработки или распространения программных продуктов, происходит атака через цепочку поставок. Компании становятся жертвами из-за опенсорсных библиотек либо своих же партнёров и подрядчиков. Компрометация остаётся незамеченной, пока вирус не начнёт работать.

 

 

 

 

 

 

1. 1. Введение
2. 2. Почему атаки на цепочки поставок стали массовыми
3. 3. Как происходят атаки на цепочку поставок
4. 4. Типы атак на цепочку поставок
   
   1. 4.1. Компрометация репозиториев и исходного кода
   2. 4.2. Вредоносные пакеты: NPM, PyPI, RubyGems
   3. 4.3. Заражённые CI/CD
   4. 4.4. Контейнеры и образы
   5. 4.5. Инструменты разработки, SDK и плагины
   6. 4.6. Черви в опенсорсных экосистемах
   7. 4.7. Атаки через поставщиков управляемых услуг
   8. 4.8. Компрометация механизмов обновлений ПО
   9. 4.9. Атаки через инструментарий искусственного интеллекта
5. 5. Последствия атаки на цепочку поставок
6. 6. Как понять, что поставщик уже скомпрометирован
7. 7. Как защититься от атак на цепочки поставок
8. 8. Выводы

Введение

Код редко пишут с нуля, обычно используются фреймворки, открытые библиотеки и чужие наработки. Чем больше внешнего кода в проекте, тем выше риск впустить вредонос вместе с обновлением или программной зависимостью. Поэтому злоумышленники всё чаще атакуют не саму компанию, а тех, кому она доверяет: разработчиков библиотек, подрядчиков, облачные сервисы, провайдеров управляемых услуг и опенсорс‑проекты.

По данным из Verizon DBIR 2026, доля утечек с участием третьих сторон выросла до 48 %, увеличившись на 60 % по сравнению с прошлым годом.

Атаки затрагивают и программное обеспечение, и оборудование. В ПО злоумышленники подменяют библиотеки, внедряют вредоносный код в программные зависимости или используют уязвимые компоненты с открытым исходным кодом. В аппаратных атаках подменяют прошивки или микрочипы, чтобы перехватывать данные или получать удалённый доступ. Атаки Supply Chain (через цепочки поставок) называют определяющим вектором угроз 2026 года. Они угрожают экосистеме целиком, а не отдельной организации. Ниже о том, как атакуют через поставщиков ПО.

Почему атаки на цепочки поставок стали массовыми

Масштаб проблемы растёт из‑за того, как сегодня устроена разработка. По данным Linux Foundation, 96 % кодовых баз содержат опенсорс‑компоненты, а доля внешнего кода в корпоративных приложениях достигает 70–90 %.

По данным из отчёта OSSRA 2026 «Open Source Security and Risk Analysis», среднее приложение включает в себя 1 180 открытых пакетов, и около 64 % из них — транзитивные зависимости. Только за один год медианное число файлов с открытым кодом в типовом проекте выросло с 5 386 до 16 082 — почти в три раза.

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

 

Рисунок 1. Рост числа опенсорсных компонентов и файлов в типичном приложении (источник: OSSRA)

 

Автоматизация обновлений сократила окно атаки до минимума. Около 60 % команд обновляют зависимости каждую неделю. Пакет, который появился в реестре утром, может оказаться в продакшене уже днём. Мало кто сознательно выдерживает паузу перед установкой обновлений, большинство ставят всё автоматически.

Облачная разработка и контейнеризация добавили новые точки входа. GitHub Actions, CI/CD‑раннеры, публичные реестры контейнеров, SaaS‑инструменты — всё это стало частью цепочки поставок. По данным IBM X‑Force, число крупных инцидентов в цепочках поставок выросло почти в 4 раза за 5 лет.

При этом цепочки подрядчиков стали очень сложными. У компаний десятки внешних исполнителей (MSP, интеграторы, DevOps‑подрядчики, облачные провайдеры), и каждый из них так или иначе подключён к репозиториям, пайплайнам, инфраструктуре или данным. Достаточно взломать одного поставщика, чтобы получить доступ сразу к нескольким клиентам. По данным Yandex Cloud, 54 % атак в 2025 году проходили через легитимные учётные данные. Часто это старые доступы подрядчиков, которые никто не отозвал.

Угроза растёт быстрее, чем инструменты защиты. Аналитики «Информзащиты» отмечают, что за последние два года количество вредоносных программ в экосистемах с открытым кодом увеличилось почти в 12 раз, причём основной всплеск пришёлся на начало 2026 года. Атаки на цепочки поставок выросли на 110 % за год и уже составляют до трети всех инцидентов.

Современная разработка стала быстрой, распределённой и зависимой от огромного числа внешних компонентов. Это ускорило бизнес, но одновременно создало идеальные условия для атак через цепочки поставок. Злоумышленникам больше не нужно ломать компанию напрямую, достаточно взломать одного поставщика, одну библиотеку или один CI/CD‑раннер.

Как происходят атаки на цепочку поставок

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

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

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

Когда точка найдена, атакующий встраивает код. Он подменяет обновление, добавляет бэкдор в исполняемый файл или меняет библиотеку. Всё выглядит как обычная часть продукта.

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

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

По данным из отчёта Verizon DBIR 2025, инциденты в цепочке поставок обходятся компаниям в среднем в 4,91 млн долларов, а их обнаружение занимает до 267 дней.

Типы атак на цепочку поставок

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

Компрометация репозиториев и исходного кода

Злоумышленник получает доступ к учётной записи мейнтейнера на GitHub, GitLab или Bitbucket. После этого он публикует вредоносные версии, меняет код в основной ветке или внедряет бэкдор в подмодуль. Проекты с автоматическими обновлениями подтягивают заражённый код без предупреждений. Всё выглядит как обычный релиз от доверенного автора.

Одна из самых масштабных атак 2025 года произошла через проект Nx — инструмент, который загружают более 5,5 млн раз в неделю. Атакующие взломали GitHub Actions разработчика и опубликовали подложную версию пакета в реестре NPM. При установке активировался скрипт, который крал токены GitHub и NPM, SSH‑ключи, файлы окружения и криптокошельки. Пострадали более 2180 учётных записей GitHub и 7200 репозиториев.

В декабре 2024 года через фишинговый NPM‑пакет украли учётные данные разработчика @solana/web3.js. От имени мейнтейнера вышли версии 2.0.9–2.0.11 со скрытым кодом, который перехватывал приватные ключи криптокошельков. Эти версии провисели в реестре несколько часов, но их успели скачать сотни проектов.

Ещё один метод — реподжекинг (repo jacking). Когда владелец GitHub‑аккаунта переименовывает профиль или удаляет репозиторий, старый URL остаётся свободным. Злоумышленник может занять его, создать репозиторий с тем же названием и разместить там подложный код. Все проекты, которые ссылались на старый URL, начнут подтягивать уже его версию.

Реподжекинг можно выявить, проверив изменение идентификатора репозитория. Для этого есть библиотека PyGithub на Python.

 

Рисунок 2. Пример, как обнаружить реподжекинг (источник: GitHub)

 

Вредоносные пакеты: NPM, PyPI, RubyGems

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

С каждым годом вредоносных пакетов становится всё больше. В 2025 году компания Sonatype выявила более 454 600 новых вредоносных пакетов, а общее число известных вредоносных пакетов во всех экосистемах превысило 1,23 млн.

Количество обнаружений вредоносных опенсорс-пакетов выросло на 73 % по сравнению с 2024 годом, причём почти 90 % пришлось на NPM.

 

Рисунок 3. Рост вредоносных пакетов (источник: ReversingLabs)

 

Согласно отчёту «Лаборатории Касперского», к концу 2025 года в опенсорс-проектах найдено почти 19 500 вредоносных пакетов, что на 37 % больше, чем годом ранее.

Вредоносные пакеты могут быть опасны по-разному:

1. Тайпсквоттинг (typosquatting) — злоумышленник создаёт пакет с именем, отличающимся от популярного одной буквой, например, lod4sh вместо lodash. Разработчик ошибается при установке, и вредоносный код попадает в проект.
2. Подмена внутренней зависимости (dependency confusion) — публикуется пакет с тем же именем, что и внутренняя библиотека компании. Менеджер зависимостей, настроенный на самую свежую версию, подтягивает публичный пакет вместо локального.
3. Postinstall‑скрипты — некоторые пакеты запускают команды сразу после установки. Через эти команды воруют SSH-ключи, токены, переменные окружения, настройки CI/CD, облачные секреты.
4. Slopsquatting — это эволюция тайпсквоттинга, адаптированная к ИИ-ассистентам. Если при классическом тайпсквоттинге атакующий рассчитывает на опечатку разработчика, то здесь он полагается на галлюцинацию ИИ. Модели иногда выдумывают названия пакетов. Атакующие регистрируют эти галлюцинации в npm или PyPI и ждут, когда разработчик установит их по совету ИИ.

В апреле 2026 года вредоносные версии PyPI‑пакета Lightning содержали скрытую директорию, которая при запуске скачивала JavaScript‑сборщик учётных данных и запускала его. Сам пакет работал как обычно, поэтому заражение долго оставалось незамеченным.

В мае 2026 года группа TrapDoor устроила перекрёстную атаку сразу на NPM, PyPI и Crates.io. В NPM использовали postinstall‑хуки, на PyPI — код, запускающийся при импорте, в Crates — вредоносный файл сборки build.rs. Целью были разработчики блокчейн‑проектов и ИИ‑сервисов. Злоумышленники подменяли конфигурации ИИ‑ассистентов, внедряя скрытые команды с символами нулевой ширины. Ассистенты сами начинали красть данные.

Заражённые CI/CD

Сборочный конвейер — удобная точка для внедрения вредоносного кода. Атакующий проникает в пайплайн через украденный токен, уязвимый раннер или открытые переменные окружения и подменяет артефакты или добавляет бэкдор на этапе сборки.

В марте 2026 года атакующие получили доступ к учётной записи мейнтейнера Trivy — популярного сканера уязвимостей, который используют более чем в 10 000 CI/CD‑пайплайнов. Они принудительно обновили 76 из 77 тегов в репозитории GitHub Actions «aquasecurity/trivy-action» и заменили все 7 тегов в «aquasecurity/setup-trivy». В обновления встроили код, который крал учётные данные.

Затем атакующие загрузили в Docker Hub заражённые образы Trivy версий 0.69.5 и 0.69.6 и перезаписали тег «latest». По данным Docker, вредный код извлекал из памяти CI/CD‑процессов секреты, SSH‑ключи, токены облачных провайдеров и настройки Docker.

В мае группа Megalodon получила доступ к тысячам GitHub‑репозиториев. За шесть часов они изменили 5 561 проект, используя поддельные аккаунты «build-bot», «auto-ci» и «ci-bot». В GitHub Actions добавлялись воркфлоу‑файлы со скриптами в Base64, которые крали секреты CI/CD, SSH‑ключи и облачные токены.

Контейнеры и образы

Публичные реестры контейнеров вроде Docker Hub — удобный канал для доставки вредоносного кода в продакшен. Образы маскируются под популярные сервисы, а бинарники подменяются под теми же именами, что и легитимные утилиты.

По данным ActiveState, 82 % компаний за последний год столкнулись хотя бы с одним инцидентом, связанным с контейнерами. 87 % образов в продакшене содержат высокие или критические уязвимости, годом ранее таких было 75 %.

 

Рисунок 4. Доля компаний, столкнувшихся с утечкой данных (источник: ActiveState)

 

Исследователи Flare обнаружили, что только за ноябрь 2025 года в Docker Hub загрузили 10 456 контейнеров, содержащих один или несколько секретов. Утечки затронули 101 компанию. Почти половина образов содержала пять и более критических секретов. 42 % всех утёкших данных — токены доступа к ИИ‑моделям OpenAI, Gemini, Groq, Anthropic и Hugging Face.

В апреле 2026 года злоумышленники получили доступ к учётной записи издателя Checkmarx и загрузили вредоносные образы в официальный репозиторий «checkmarx/kics» на Docker Hub. Они перезаписали существующие теги, включая «latest», «v2.1.20» и «alpine», и добавили два новых. В модифицированном бинарнике KICS был встроен код, который собирал результаты сканирования, шифровал их и отправлял на сервер. Атаку заметили через 30 минут, но за это время тысячи пользователей успели скачать заражённые образы.

Группировка TeamTNT публиковала вредоносные образы из‑под своих аккаунтов, включая alpineos с более чем 150 тысячами загрузок. Внутри были руткиты, майнеры Monero и инструменты для выхода из контейнера. Уязвимость в XZ Utils (CVE‑2024‑3094, CVSS 10.0) до сих пор присутствует в десятках образов на Docker Hub. Некоторые из них используются как базовые слои, распространяя заражение дальше.

Разработчики сами нередко выкладывают секреты. По данным Flare, только четверть удаляет их в течение 48 часов. В остальных случаях ключи остаются активными.

 

Рисунок 5. Схема использования раскрытых секретов (источник: Flare)

 

Инструменты разработки, SDK и плагины

Плагины для редакторов кода, сторонние наборы средств разработки (Software Development Kit, SDK) и расширения для сред работают с теми же правами, что и сам разработчик. Одно вредоносное дополнение способно собрать токены, ключи облачных провайдеров или исходный код у всех, кто его установил. Разработчики доверяют плагинам как части интегрированной среды разработки (Integrated Development Environment, IDE), и этим пользуются атакующие.

В 2025 году число вредоносных расширений выросло в четыре раза. Исследователи обнаружили почти 57 тысяч опасных пакетов, на 58 % больше, чем годом ранее.

Даже легитимные расширения бывают уязвимы. В феврале 2026 года OX Security нашли критические ошибки в четырёх популярных дополнениях для Visual Studio Code:

• Live Server (более 72 млн установок) — уязвимость CVE-2025-65717, удалённая кража локальных файлов разработчика;
• Code Runner (37 млн установок) — CVE-2025-65715, удалённое выполнение кода;
• Markdown Preview Enhanced (8,5 млн установок) — CVE-2025-65716, запуск вредоносного JavaScript;
• Microsoft Live Preview (более 11 млн установок) — XSS‑уязвимость (межсайтовый скриптинг) позволяет злоумышленнику внедрить вредоносный код на веб‑страницу, который выполнится в браузере жертвы, исправлена в сентябре 2025 года в версии 0.4.16.

Эти расширения суммарно установили более 128 млн раз, а часть уязвимостей оставалась открытой месяцами. Ранее в магазине VS Code уже находили тысячи вредоносных расширений с миллионами установок. Только в майских патчах Microsoft исправила 120 уязвимостей.

Отдельная волна атак пришлась на поддельных ИИ‑ассистентов. В январе 2026 года в официальном маркетплейсе VS Code нашли два расширения — «ChatGPT - 中文版» и ChatMoss (CodeMoss). Они набрали 1,5 млн установок и выглядели как обычные помощники, но в фоне работал вредоносный модуль MaliciousCorgi, который:

• отправлял любые открытые файлы (в Base64) на сервер;
• по команде мог запросить до 50 файлов из рабочей области;
• передавал данные аналитическим SDK Zhuge.io, GrowingIO, TalkingData и Baidu Analytics, помогая мошенникам понять ценность проектов.

 

Рисунок 6. Расширения для VS Code, кампания MaliciousCorgi (источник: KOI Security)

 

Кампания GlassWorm (октябрь 2025 — март 2026) добавила в каталог OpenVSX 72 вредоносных расширения. Они маскировались под линтеры, форматировщики и ИИ‑помощников. Вредоносный код добавляли через обновления после того, как расширение набирало аудиторию. Плагины крали учётные данные GitHub, NPM, OpenVSX, а также файлы ~/.aws и ~/.ssh. В марте 2026 года нашли ещё 20 неактивных расширений, которые должны были активироваться позже через обновления.

Черви в опенсорсных экосистемах

Самораспространяющиеся скрипты атакуют цепочку доверия между разработчиками. Они автоматически создают форки, генерируют запросы на включение кода (pull request) с заражённым кодом и распространяются дальше, если хотя бы один мейнтейнер принимает изменения.

Первый такой червь Shai‑Hulud появился в сентябре 2025 года и быстро стал одной из самых серьёзных угроз для опенсорсных экосистем. Червь охотится за машинными идентификаторами — токенами доступа, которые используются в CI/CD для автоматизации, а не за паролями людей. Он заражает машины, ворует эти токены и через них распространяется на другие проекты. К концу 2025 года червь поразил более 30 000 репозиториев и похитил сотни GitHub‑токенов.

 

Рисунок 7. Схема атаки Shai-Hulud (источник: Palo Alto)

 

Червь Mini Shai‑Hulud (четвёртое поколение, активен с сентября 2025 года) крадёт GitHub‑токены из CI/CD‑окружения. Затем получает права на публикацию пакетов, модифицирует исходный код, увеличивает версию и публикует вредоносные обновления. Новый заражённый проект снова крадёт токены — цикл повторяется бесконечно.

На пике активности в мае 2026 года Mini Shai‑Hulud поразил 314 пакетов за 22 минуты. Среди них был «size-sensor», который скачивали 4,2 млн раз в месяц. Это значит, что разработчики по всему миру, включая Россию, автоматически подтянули вредоносный код в свои проекты.

Атаки через поставщиков управляемых услуг

Взлом одного поставщика управляемых услуг (Managed Service Provider, MSP) открывает злоумышленникам доступ ко всем его клиентам. Подрядчики управляют десятками и сотнями чужих сетей через единые платформы для удалённого мониторинга (Remote Monitoring and Management, RMM), облачные консоли и системы резервного копирования.

MSP обычно обладают правами доменных администраторов, доступом к серверам, рабочим станциям, резервным копиям и инструментам массового развёртывания. Фактически подрядчик может делать в сети клиента всё то же, что и штатный ИТ‑отдел. Эти же учётные данные используются для работы со всеми клиентами, что делает MSP удобной точкой входа.

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

По данным ConnectWise, доля MSP, пострадавших от атак на цепочку поставок, выросла с 35 % в 2023 году до 78 % в 2025‑м. Чаще всего злоумышленники используют украденные или давно не меняемые пароли.

В январе 2025 года атакующие провели фишинговую кампанию против администратора MSP. Специалист техподдержки получил письмо, которое выглядело как обычное уведомление от RMM-платформы ScreenConnect. Ссылка вела на поддельную страницу входа, созданную с помощью Evilginx — фреймворка, который перехватывает логин, пароль и одноразовый MFA‑код.

После ввода данных злоумышленники получили сессию суперадминистратора. Им стали доступны все клиентские среды: серверы, рабочие станции, резервные копии и инструменты автоматизации. Этого хватило, чтобы развернуть вымогатель Qilin сразу у всех клиентов без необходимости взламывать каждую компанию по отдельности.

 

Рисунок 8. Фишинговое электронное письмо, полученное администратором (источник: Sophos)

 

Атака на Kaseya, хоть она и произошла ещё в 2021 году, остаётся одним из самых показательных примеров компрометации MSP. Группировка REvil использовала уязвимость в ПО Kaseya, которое применяют тысячи MSP. Атака затронула 60 поставщиков услуг и более 1500 компаний по всему миру.

Компрометация механизмов обновлений ПО

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

В феврале 2026 года разработчики Notepad++ сообщили, что инфраструктуру обновлений взломали на уровне хостинг‑провайдера. С июня по декабрь 2025 года через процесс обновления распространялись вредоносные файлы, нацеленные на конкретных пользователей — от частных лиц до госструктур и финансовых организаций. Атака оставалась незамеченной почти полгода.

В марте 2026 года злоумышленники получили доступ к NPM‑аккаунту мейнтейнера Axios, библиотеки с более чем 100 млн загрузок в неделю. Они опубликовали вредоносные версии 1.14.1 и 0.30.4. При установке срабатывал postinstall‑скрипт, который скачивал и запускал троян для Windows, macOS и Linux. Подробнее об атаке на Axios можно прочитать в новостях на Anti-Malware.ru.

Через месяц та же группировка атаковала четыре официальных пакета SAP: @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service и mbt. В них добавили preinstall‑скрипт, который крал учётные данные разработчиков, токены CI/CD, SSH‑ключи, данные облачных сервисов и криптокошельков. Заражённые версии находились в реестре всего 2–4 часа, но этого хватило, чтобы их успели установить.

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

Атаки на инструменты искусственного интеллекта — новое и быстро развивающееся направление. Разработчики подключают библиотеки для работы с большими языковыми моделями, ставят ИИ‑ассистентов в IDE, используют MCP‑серверы и вспомогательные SDK. Всё это становится новой поверхностью атаки.

Отдельно растёт давление на конвейеры разработки ИИ. В отчёте JFrog за 2026 год указано, что обнаружено 495 заражённых ИИ‑моделей и 969 вредных скиллов ИИ‑агентов — новый тип артефактов, который раньше почти не отслеживали. При этом 53 % компаний продолжают загружать модели из публичных реестров, где уже находили подложные экземпляры. JFrog называет это иллюзией контроля: компании уверены, что управляют рисками, но фактически оставляют критические дыры в цепочке поставок.

В мае 2026 года исследователи Adversa AI описали атаку SymJack. Атакующие создают репозиторий с подложным файлом‑ссылкой, замаскированным под видеофайл. Разработчик копирует его в папку с документацией — действие, которое ИИ‑агент показывает как безопасное. После копирования ссылка перезаписывает конфигурацию самого агента. При следующем запуске агент подключается к серверу злоумышленников и выполняет их код с правами пользователя без песочницы и дополнительных запросов.

Эта атака особенно опасна в CI/CD. Если агент работает в конвейере сборки, злоумышленники получают все секреты из одного подложного пулл-реквеста. SymJack работает против шести популярных ИИ‑агентов: Claude Code, Gemini CLI, Cursor, Copilot CLI, Grok Build и OpenAI Codex CLI. Это не ошибка конкретной реализации, а архитектурная проблема: агенты по умолчанию доверяют инструкциям и не проверяют, что именно им подсовывают.

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

 

Рисунок 9. Поведение Claude Code до и после исправления ошибки с символическими ссылками (источник: Adversa)

 

Последствия атаки на цепочку поставок

Одна уязвимая библиотека или расширение может затронуть тысячи проектов. Зависимости обновляются автоматически, поэтому вредоносный код распространяется сразу. По данным «Лаборатории Касперского», в 2025 году с атаками на цепочки поставок столкнулись 31 % компаний в мире и 35 % в России, но лишь 9 % считают этот риск критическим.

Какие последствия могут наступить?

1. Кража секретов. Вредоносные пакеты воруют токены CI/CD, SSH‑ключи и учётные данные облаков. С этими доступами злоумышленники входят в продакшен, скачивают исходники, меняют конфигурации или закладывают бэкдоры.
2. Финансовые потери — по данным ГК «Солар», средний ущерб от атаки Supply Chain в российском финсекторе составляет 3,6 млн рублей, без учёта простоя разработки и восстановления инфраструктуры.
3. Штрафы от регуляторов — с 30 мая 2025 года за утечку персональных данных действует штраф от 3 до 20 млн рублей, а за повторную — оборотный штраф до 3 % выручки. Даже если данные утекли через стороннюю библиотеку, ответственность несёт оператор.
4. Потеря контроля над инфраструктурой — компрометация CI/CD позволяет выполнить код в рабочей среде и получить ключи от продакшена. Дальше возможны утечки баз данных, шифрование, удалённый доступ или запуск майнеров.
5. Репутационные потери — инцидент снижает доверие клиентов и партнёров, даже если уязвимость пришла из открытого кода. Компании теряют заказы и время на восстановление.
6. Риски для промышленности и КИИ — российские промышленные предприятия активно используют опенсорс в АСУ ТП и IoT. «Солар» отмечает, что первом квартале 2026 года на промышленность пришлось 48,8 тысячи кибератак, на 14 % больше, чем годом ранее.

Почти 44 % инцидентов связаны с вредоносными программами, а доля признаков APT‑групп выросла до 38 %. Хакеры переходят от простых атак к длительным операциям, нацеленным на срыв цепочек поставок и парализацию производства. Чаще всего страдают энергетика и топливно-энергетический комплекс.

 

Рисунок 10. Динамика атак на промышленные предприятия (источник: «Солар»)

 

Как понять, что поставщик уже скомпрометирован

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

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

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

Нетипичные зависимости. В проект добавляются новые пакеты или меняются версии без объяснений. Особенно опасны зависимости, которые тянут за собой сетевые библиотеки, криптографию или инструменты удалённого доступа.

Новые сетевые соединения. Приложение начинает обращаться к незнакомым доменам, API или IP‑адресам. Это часто означает утечку токенов, сбор телеметрии или попытку установить канал управления.

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

Необычные действия подрядчиков. MSP или интегратор запрашивает расширенные права, подключается в нерабочее время, меняет конфигурации без согласования или выполняет массовые операции. Сервисный аккаунт, который обычно появляется раз в сутки, внезапно начинает работать ночью. Это может означать, что его уже перехватили.

Как защититься от атак на цепочки поставок

Защититься от атак на цепочку поставок можно только системно, точечно закрывать риски бесполезно. Ниже — практики, которые в комплексе уменьшают поверхность атаки и снижают риски.

Управляйте зависимостями и их источниками. Фиксируйте версии, используйте lock‑файлы, отключайте автообновления. Проверяйте историю коммитов, активность мейнтейнеров, смену владельца. Перехват репозитория — распространённый вектор атак.

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

Используйте внутренние реестры и зеркала. Храните проверенные зависимости в собственном хранилище компонентов. Внешние реестры используйте только как источник информации.

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

Контролируйте инструменты разработки и доступ подрядчиков. Внедрите корпоративный каталог плагинов, запретите установку непроверенных расширений. Выдавайте временные доступы, требуйте многофакторную аутентификацию.

Защитите каналы обновлений и ИИ‑инструменты. Проверяйте подписи обновлений, используйте собственные зеркала. Анализируйте SDK, MCP-серверы, API‑шлюзы — это новая и быстрорастущая поверхность атаки.

Внедряйте мониторинг аномалий. Отслеживайте неожиданные обновления зависимостей, скачки версий, появление новых пакетов, изменения в CI/CD.

Готовьте план реагирования. Заранее пропишите откат зависимостей, изоляцию пайплайнов, ротацию секретов, проверку артефактов и уведомление клиентов. В атаках на цепочку поставок время решает всё.

Выводы

Атаки на цепочки поставок стали серьёзной угрозой для российского бизнеса. Хакеры не атакуют компании напрямую, а воздействуют на их зависимости: библиотеки, инструменты разработки, системы CI/CD, контейнеры, подрядчиков и сервисы обновлений. Компрометация одного звена автоматически затрагивает десятки проектов, приводит к утечкам секретов, остановке разработки, финансовым потерям и репутационному ущербу.

Единственный рабочий подход — относиться к цепочке поставок как к критической инфраструктуре: проверять источники, фиксировать версии, контролировать плагины и образы, изолировать CI/CD, ограничивать доступ подрядчиков, использовать анализ состава ПО и готовить план реагирования. В цепочке поставок слабым звеном становится доверие, и именно его нужно держать под контролем.