Первую неделю апреля я потратил на чтение трех разных отчетов об анализе угроз, которые, на первый взгляд, не имели ничего общего. Один из них был посвящен кампании, проводимой Северной Кореей, в рамках которой было опубликовано более 1700 вредоносных пакетов в пяти экосистемах с открытым исходным кодом. Другой подробно описывал операцию с вредоносным ПО, использующую скомпилированный на Zig бинарный файл для скрытного заражения каждой IDE на машине разработчика. Третий рассказывал о каскадном компрометации цепочки поставок, превратившей доверенный сканер уязвимостей в инструмент для сбора учетных данных.
Три разные группы злоумышленников. Три разных технических подхода. Один общий вывод: рабочие станции разработчиков теперь являются самой ценной целью для первоначального доступа в корпоративных средах.
Это не история о безопасности цепочки поставок, по крайней мере, не в том смысле, в котором большинство руководителей по безопасности понимают риск цепочки поставок. Это история о том, почему злоумышленники независимо друг от друга пришли к одному и тому же стратегическому расчету и что эта конвергенция должна нам сказать о том, куда неверно направлены наши оборонительные инвестиции.
Скрытый на виду паттерн
Кампания Contagious Interview, приписываемая северокорейским злоумышленникам, в начале апреля пересекла порог масштаба, когда исследователи Socket сообщили, что операция одновременно распространилась на npm, PyPI, Go Modules, crates.io и Packagist. Пакеты маскируются под легитимные инструменты для разработчиков. После установки они функционируют как загрузчики вредоносного ПО, которые крадут данные браузера, учетные данные криптокошельков и содержимое менеджеров паролей. Операция ведется с января 2025 года, но параллельное расширение на пять экосистем сигнализирует о фабричной модели нацеливания на разработчиков.
Отдельно кампания GlassWorm эволюционировала от вредоносных расширений IDE до чего-то более амбициозного. Исследователи Aikido Security обнаружили поддельное расширение WakaTime в OpenVSX, которое включало скомпилированный на Zig нативный бинарный файл вместе с JavaScript-кодом. Бинарный файл не работает в песочнице расширения. Он запускается с полным доступом к операционной системе, сканирует машину на наличие всех совместимых IDE и незаметно устанавливает дроппер второго уровня во все из них. Вредоносное ПО избегает выполнения в российских системах и использует инфраструктуру блокчейна Solana для командно-контрольной связи. Это не кража учетных данных по принципу «ударил и убежал». Это устойчивая, кроссплатформенная атака, рассчитанная на то, чтобы пережить удаление любого отдельного расширения.
Затем есть TeamPCP, которая осуществила каскадную компрометацию, начавшуюся с уязвимого сканера Aqua Security Trivy в середине марта и прошедшую через Checkmarx KICS, LiteLLM и Python SDK от Telnyx. Каждая компрометация предоставляла учетные данные, необходимые для достижения следующей цели. Вредоносное ПО работало внутри конвейеров сборки и на машинах разработчиков, похищая облачные токены, секреты CI/CD и учетные данные служебных учетных записей. Компрометация одного инструмента безопасности стала стартовой площадкой для четырех других.
Эти три кампании не имеют общей инфраструктуры, семейств вредоносного ПО или видимой координации. Именно поэтому их сближение имеет значение. Когда несвязанные злоумышленники независимо приходят к одной и той же стратегии нацеливания, они реагируют на один и тот же структурный стимул. В данном случае стимул прост: на машинах разработчиков хранятся ключи.
Экономика, движущая конвергенцию
Типичная рабочая станция разработчика содержит SSH-ключи, учетные данные облачного провайдера, токены реестра контейнеров, токены аутентификации Git и секреты конвейеров CI/CD. Многие разработчики имеют административный доступ к внутренним реестрам пакетов и инфраструктуре развертывания. Их машины часто находятся за пределами защищенного периметра, который команды безопасности выстраивают вокруг производственных систем.
С точки зрения злоумышленника, компрометация одного разработчика эквивалентна атаке на цепочку поставок без сложности компрометации вышестоящего реестра пакетов. Вам не нужно отравлять пакет, который используют тысячи организаций. Вам нужен всего один разработчик, имеющий права на запись в конвейер развертывания в продакшене. Соотношение доступа к затратам просто лучше, чем при прямой атаке на производственную инфраструктуру. Производственные системы имеют мониторинг, сетевую сегментацию и регламенты реагирования на инциденты, построенные вокруг них. Рабочие станции разработчиков, напротив, часто пользуются неявным доверием, поскольку люди, которые ими пользуются, пользуются неявным доверием.
Отчет Google Cloud Threat Horizons за первую половину 2026 года задокументировал именно этот паттерн: злоумышленники использовали троянизированное приложение для получения точки опоры на рабочей станции разработчика, а затем использовали аутентифицированные сеансы и доступные учетные данные для перехода к облачным ресурсам. В течение 72 часов они перешли от локальной среды разработчика к полному доступу к администрированию облака, злоупотребив доверием OpenID Connect между провайдером CI/CD и облачной платформой.
Анализ волны атак в марте 2026 года от Security Boulevard охарактеризовал эту динамику как «Экономику учетных данных разработчиков», утверждая, что эти кампании следует рассматривать не как изолированные инциденты, а как свидетельство черного рынка высокопривилегированных учетных данных разработчиков. Эта формулировка полезна, поскольку она объясняет, почему мы наблюдаем одновременные, но независимые кампании, нацеленные на одну и ту же среду. Рыночная цена доступа разработчика выросла, потому что возросла последующая ценность этого доступа.
Что это должно изменить для руководителей по безопасности
Большинство организаций рассматривают безопасность среды разработки как расширение защиты конечных точек. Разработчики получают тот же агент EDR, то же управление исправлениями и те же элементы управления доступом, что и все остальные сотрудники. Некоторые организации идут дальше и требуют подписи кода или многофакторной аутентификации для доступа к реестрам пакетов. Но немногие рассматривают рабочую станцию разработчика как отдельную поверхность атаки, требующую собственной архитектуры безопасности.
Конвергенция этих трех кампаний предполагает, что это различие давно назрело. Машины разработчиков — это не просто конечные точки. Это хранилища учетных данных, контроллеры конвейеров и доверенные якоря для всей цепочки доставки программного обеспечения. Защита их требует средств контроля, для которых традиционная защита конечных точек никогда не предназначалась.
Это начинается с видимости, которая остается самым фундаментальным пробелом. Большинство центров управления безопасностью имеют ограниченное представление о том, что происходит внутри экосистем расширений IDE, установок пакетных менеджеров или выполнения конвейеров CI/CD. Кампания GlassWorm использовала OpenVSX — реестр, который многие команды безопасности даже не отслеживают. TeamPCP скомпрометировала рабочие процессы GitHub Actions, которые выполняются с повышенными привилегиями, но часто ускользают от внимания, уделяемого производственным развертываниям. Если ваша команда безопасности не может сказать вам, какие расширения IDE установлены на вашем парке разработчиков, у вас есть слепое пятно, которое активно эксплуатируют три разные группы злоумышленников.
Это распространяется и на архитектурные решения о том, как предоставляются и изолируются среды разработки. Эфемерные среды разработки, привязанные к оборудованию учетные данные, ограниченный сетевой доступ из систем сборки и обязательный обзор кода для изменений в конвейерах CI/CD — не новые идеи. Но они по-прежнему редко встречаются на практике, потому что большинство организаций еще не признали, что среды разработки требуют таких же оборонительных инвестиций, как и производственная инфраструктура.
Самое неприятное следствие носит организационный характер. Безопасность среды разработки не вписывается должным образом в существующие структуры команд безопасности. Она находится на пересечении безопасности приложений, безопасности конечных точек, управления идентификацией и риска цепочки поставок. В большинстве организаций ни одна команда не владеет этим пересечением. Команды по безопасности приложений фокусируются на уязвимостях кода. Команды по конечным точкам фокусируются на обнаружении вредоносного ПО. Команды по идентификации фокусируются на управлении доступом. Никто не следит за расширением IDE, которое только что установило бинарный файл на Zig с полным доступом к операционной системе. Кампании марта и апреля 2026 года эксплуатируют этот пробел.
Три не связанные между собой группы злоумышленников посмотрели на современное предприятие и независимо пришли к выводу, что рабочая станция разработчика предлагает лучшую отдачу от инвестиций для первоначального доступа. Это не совпадение. Это ценовой сигнал, и цена определяется разрывом между ценностью учетных данных разработчиков и зрелостью средств контроля, защищающих их. Вопрос для руководителей по безопасности заключается в том, закроют ли они этот разрыв до того, как прибудет следующая волна кампаний, чтобы его использовать.
Эта статья публикуется в рамках сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Josh Taylor
