Тихий абордаж: как атаки на цепочки поставок уводят «корабли» под чужой флаг

Гибридная угроза

История с GhostAction показала, насколько уязвимой может быть среда разработчиков при комбинированном использовании облачных сервисов, менеджеров пакетов и автоматизированных конвейеров CI/CD. Дело закончилось тем, что около 330 пользователей на GitHub в 817 репозиториях оказались затронуты масштабной кампанией GhostAction. Злоумышленники похитили более 3,3 тыс. секретов, в том числе учётные данные PyPI, npm, Docker Hub и Amazon Web Services. Для этого они внедряли вредоносные рабочие процессы, замаскированные под Github Actions Security, извлекали данные и отправляли их через HTTP POST на удалённый сервер. В интерфейсе GitHub такое имя выглядит как обычная задача безопасности, поэтому разработчик мог принять её за легитимную проверку.

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

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

Такие атаки являются «сложным на бумаге», а на деле простым в реализации вектором нападения на организации, говорит инженер группы расследований инцидентов центра исследования киберугроз Solar 4RAYS ГК «Солар» Денис Чернов. «Кажется, что „скомпрометировать компанию А для компрометации компании Б“ сложнее, чем действовать напрямую, но это не так. Как показала практика последних лет, подрядчики редко задумываются о собственной безопасности. К тому же подрядчиками больших компаний зачастую могут являться маленькие организации на несколько десятков человек, где в целом может отсутствовать штат ИБ, а сотрудники работают с личных незащищённых компьютеров», — отметил эксперт.

Этот метод одновременно подходит для массовых и точечных атак, рассказал архитектор web-разработки UserGate Олег Пименов. «Массовые кампании монетизируются быстро: инфостилеры, майнеры, бэкдоры в популярных пакетах, компрометации аккаунтов в экосистемах. Точечные — когда нужен гарантированный вход в конкретную компанию или отрасль через „усилитель“ в цепочке: вендор, MSP, IdP, облачный сервис, EDR или интеграция с широкими правами», — отметил эксперт.

Аналитик угроз GSOC компании «Газинформсервис» Владислав Шелепов также говорит, что метод стал гибридным. Массовый характер атак проявляется в использовании автоматизации для засорения реестров тысячами вредоносных пакетов, рассчитанных на случайную установку через опечатки в названиях или автоматические менеджеры зависимостей. Точечные атаки нацелены на конкретных разработчиков или инструменты, чтобы через них атаковать заранее выбранные организации.

В России Supply Chain чаще используется для таргетированных атак, рассказал Сергей Авраменко. Атакующие специально изучают стек технологий конкретных отраслей и пытаются скомпрометировать специфичные для них зависимости. Также сохраняется риск закладок, нацеленных на широкое поражение российской инфраструктуры без выбора конкретной цели — просто по признаку IP-адреса или системной локали.

Кого ломают больше всех

На первом месте среди векторов Supply Chain атак, по мнению Дениса Чернова, находятся подрядчики. Почти треть всех кибератак хакеры совершают именно через них, следует из данных центра исследования киберугроз Solar 4RAYS. На втором месте эксперт отметил open source: «Бездумное использование бесплатно распространяемого ПО без его проверки может стать большой ошибкой. Особенно это касается непопулярных и новых проектов, которые вовсе могут оказаться вредоносными».

В то же время руководитель отдела реагирования на инциденты компании «Бастион» Семён Рогачёв с точки зрения массовости и вероятности реализации вектора атаки называет open-source-зависимости однозначным лидером. «Почти в любой современной организации так или иначе производится разработка ПО, и крайне маловероятно, что она используется без различных open-source-компонентов. При этом компании часто не ведут учет зависимостей и библиотек, используемых в их разработках. В такой ситуации, в случае компрометации open-source-библиотеки, организация может даже не знать, что она находится под угрозой», — рассказал эксперт.

На практике самый высокий риск там, где есть доступы и автоматическое распространение, считает Олег Пименов. Самые уязвимые векторы для атак — это CI/CD и секреты, SaaS/IdP и интеграции, репозитории артефактов / механизмы обновлений, а также open-source-зависимости, включая транзитивные.

Владислав Шелепов отметил, что эксперты компании чаще всего наблюдают атаки на среды разработки и CI/CD-системы — именно там сосредоточены ключи, токены и механизмы подписи кода. На втором месте — транзитивные зависимости в open source, особенно в экосистемах с высокой скоростью обновления, таких как npm и PyPI. Также эксперт выделил стремительно растущий сектор ИИ/МО: модели и датасеты, распространяемые через публичные пространства, часто ведут себя как исполняемый код, но при этом подвергаются гораздо менее строгой проверке безопасности, создавая новые «слепые зоны». SaaS-провайдеры и подрядчики остаются классическим слабым звеном из-за каскадного эффекта: один взломанный поставщик услуг открывает доступ к десяткам его клиентов, добавил Владислав Шелепов.

Сергей Авраменко выделил два вектора, которые критически влияют на ландшафт угроз:

• Технический (компоненты и среда исполнения) — безусловным лидером остаются open-source-компоненты. Причем они каскадно компрометируют всю производственную цепочку. Например, сборочные сервера часто имеют избыточные привилегии. Если вредоносный код выполняется на этапе npm install или сборки, он может украсть секреты доступа к продуктивной среде или ключи подписи кода.
• Организационный (связность инфраструктур) — существенная асимметрия уровня зрелости ИБ в головном отделении организации и её дочерних структурах или подрядчиках. Внешний периметр и внутренние сервисы последних обычно являются «слабым звеном», определяющим уровень безопасности всей организации.

«Каждое из звеньев этой цепи может быть уязвимым к данного типа атакам. Но за что-то отвечает сам разработчик (например, за зависимости в коде или CI/CD-конвейер), а за что-то — поставщик или провайдер», — считает руководитель центра практик безопасной разработки Innostage Михаил Черкашин.

На практике в 2025 году злоумышленники сделали основной упор на эксплуатацию доверия в экосистемах ПО, используя несколько основных методов взлома:

• Компрометация зависимостей (Compromised dependencies) — внедрение вредоносного кода в популярные библиотеки разработки.
• Атака на CI/CD-пайплайны (CI/CD pipeline breaches) — проникновение в системы непрерывной интеграции и развёртывания.
• Typosquatting и Dependency confusion — создание фейковых пакетов и репозиториев с именами, схожими с легитимными ресурсами.
• Компрометация инструментов разработки — взлом сторонних инструментов, используемых в разработке.

Драйверы роста Supply Chain Attack

Supply Chain атак становится всё больше. По РФ точная статистика отсутствует, однако зарубежная указывает на рост более чем на 50% подобных нападений за 2025 год, рассказал Семён Рогачёв. «Есть два основных драйвера роста — при разработке ПО всё активнее используются различные open-source-решения, а атакующие, в свою очередь, всё активнее пытаются скомпрометировать создателей общедоступного софта и создавать вредоносные пакеты программ», — объяснил эксперт.

Движущей силой Supply Chain можно назвать повышение защищённости целевых организаций от прямых атак, рассказал Денис Чернов. Сейчас не так просто пробиться через все механизмы защиты, выстроенные вокруг организаций с большим бюджетом на ИБ. В свою очередь, Supply Chain позволяет атакующим появиться там, где их не ждали. Также явным драйвером стало развитие удалённой работы — зачастую подрядчики не просто занимаются outsource-задачами, а имеют прямой доступ внутрь инфраструктуры.

По мнению Олега Пименова, за последнее время Supply Chain атаки заметно «повзрослели»: фокус сместился от точечного отравления пакетов к компрометации идентичности и контура поставки — CI/CD, токены, интеграции, подпись и распространение артефактов. В числе факторов роста, по его оценкам, — масштабная автоматизация разработки и эксплуатации (DevOps/SaaS) при высокой сложности транзитивных зависимостей и избытке секретов/доступов в пайплайнах.

Сейчас наблюдаются сложные цепочки заражения, включающие дропперы, кражу учётных данных и установку бэкдоров, которые выполняются прямо в средах разработки, отмечает Владислав Шелепов. «Злоумышленники поняли, что атака на CI/CD-конвейеры, менеджеры пакетов и инструменты разработчиков даёт неограниченный доступ к конечным целям, делая процесс компрометации воспроизводимым и масштабируемым», — отметил Владислав Шелепов.

Михаил Черкашин дополнительно отметил проблему «индивидуализации» разработки — многие команды уверены, что они отвечают только за свой код, а то, что они включили в проект, в лучшем случае проверяют при помощи инструментов композиционного анализа ПО. «Для разработчиков средств защиты это уже очевидно, но поясню: весь код, который команда добавляет в итоговую сборку, должен быть проверен. Нет „не нашего“ кода. Вы в проект добавили библиотеку из открытого недоверенного репозитория — вам и отвечать за него и за все уязвимости в нём», — объяснил Михаил.

В последние два года происходит «демократизация» атак, рассказал Сергей Авраменко. Раньше Supply Chain атаки ассоциировались со сложными операциями прогосударственных хакеров. Сейчас порог входа снизился до минимума. «Мы собираем софт как конструктор LEGO, где 80–90% кода нам не принадлежит. Злоумышленники поняли: зачем ломать хорошо защищённый периметр корпорации, если можно отравить „кирпичик“, который разработчик сам принесёт внутрь?» — отметил эксперт.

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

Предотвратить или расследовать?

«При расследовании Supply Chain достаточно часто возникает ситуация, когда после определения факта вины подрядчика он отрицает свою причастность и отказывается проводить проверку в собственной инфраструктуре», — рассказал Денис Чернов. Без предварительной подготовки расследовать инцидент практически невозможно. «Это поиск иголки в стоге сена, который уже сгорел», — отметил Сергей Авраменко. Главные ошибки организаций — это игнорирование угрозы и иллюзия безопасности от лоскутной автоматизации. «Компании внедряют плагины для Nexus или Artifactory, настраивают SCA-сканеры в CI/CD и считают, что вопрос закрыт. Но эти инструменты работают изолированно и видят только срез „в моменте“, не обеспечивая трассируемости», — отметил эксперт.

Данные атаки не заметны сразу, чаще это многосоставные и продолжительные по времени целенаправленные действия, отметил Михаил Черкашин. «Поэтому их непросто распознать, если кто-то надеется выследить злоумышленника по цепочке и заблокировать его, пока он не дойдёт до цели. Процесс безопасной разработки и поставки ПО нужно выстраивать на системном уровне», — уверен эксперт.

Расследование обычно сложнее, чем профилактика, говорит Олег Пименов. «Следы распределены между вендорами, SaaS и внутренними системами, а точка подмены может быть „до сборки“. Системнее всего риск управляется там, где есть аудит, регуляторика и зрелая инженерная практика: финсектор, крупные облака и софт-вендоры, оборонка, критическая инфраструктура. Но у многих это всё ещё декларация, а не операционная модель», — рассказал он.

Как защищаться от Supply Chain атак

Минимальные меры защиты:

• Сегментирование сети: системы, к которым будет иметь доступ подрядчик, должны быть в отдельной подсети.
• Доступ в инфраструктуру только через VPN с двухфакторной аутентификацией, а учётные записи должны быть активированными только на периоды работ.
• Сеть, к которой имеет доступ подрядчик, должна быть покрыта мониторингом и антивирусным ПО.
• Практически любое стороннее ПО может стать источником Supply Chain атаки, и тут нужно уделять ресурсы мониторингу активности приложений в сети, чтобы как минимум иметь логи и быстро распознать источник атаки.

«Также я рекомендую категорически запретить прямой доступ сборочных агентов и production-контейнеров в интернет. Любая загрузка зависимостей должна идти только через проксирующий репозиторий (с функциями файрвола), а любой сетевой трафик приложения должен быть жёстко ограничен белыми списками. „Свободный интернет“ для серверов — это подарок атакующему», — отметил Сергей Авраменко.