24 июня Novee Security выпустила исследование о паттерне уязвимостей Cordyceps, и это не та история, которую можно спокойно отложить в папку «ещё один баг в девтулзах». Речь про безопасность CI/CD: если сборка, релиз и связанные сервисы открывают путь неаутентифицированному или слабо контролируемому доступу, атакующему уже не нужно ломиться в прод напрямую. Для русскоязычных команд это плохая новость ровно потому, что CI/CD во многих компаниях до сих пор считают служебной зоной, а не полноценной частью внешней поверхности атаки.
Как пишет The New Stack, исследование Novee Security описывает не единичную ошибку, а более широкий flaw pattern, то есть повторяемый класс слабостей вокруг пайплайнов и developer-инфраструктуры. Главная мысль неприятно простая: если связка из сборочных процессов, автоматизации, интеграций и сервисных прав настроена небрежно, то атакующий может использовать эту цепочку как короткий маршрут к коду, артефактам и релизам. И это уже совсем другой масштаб риска. Ошибка в пользовательском интерфейсе бьёт по отдельному сервису. Проблема в CI/CD потенциально бьёт по всему, что проходит через пайплайн.
Собственно, название Cordyceps здесь звучит почти без иронии. Гриб-паразит, который перехватывает поведение носителя, неплохо описывает логику таких атак: компрометируется не обязательно финальная система, а среда, которая управляет тем, что и как в эту систему попадает. Если злоумышленник оказывается в точке, где создаются сборки, подтягиваются зависимости, подписываются артефакты или запускаются автоматические задания, он получает не просто доступ, а влияние на доверенную цепочку поставки. В результате вредоносное действие начинает выглядеть как штатная операция разработки. Для защитников это худший сценарий: система как будто работает правильно, только результат уже чужой.
Почему эта тема снова всплывает именно сейчас, тоже понятно. За последние годы индустрия привыкла обсуждать безопасность облака, контейнеров, зависимостей и секретов, но безопасность CI/CD часто оставалась где-то между DevOps, платформенной командой и безопасниками. Ответственность размазана, а доступов у пайплайнов много по определению: токены, учётки сервисов, права на репозитории, доступ к registries, возможность деплоя, иногда и доступ к инфраструктуре. Плюс почти везде есть внешние интеграции, webhook-механики, self-hosted runner’ы, сторонние action’ы и шаблоны, которые однажды настроили и больше не трогали. В такой архитектуре даже не обязательно искать экзотическую zero-day. Достаточно найти слабое звено в автоматизации, которую команда давно перестала воспринимать как критичный контур.
Для разработчиков и платформенных инженеров из этого следует довольно приземлённый вывод: пора перестать смотреть на пайплайн как на внутреннюю техничку, которая «просто собирает проект». CI/CD давно стал системой принятия решений. Он решает, какой код считается валидным, какие артефакты попадают в registry, какой образ идёт в staging и какой релиз уезжает в production. Если этот слой можно обмануть, подменить или заставить выполнить не тот сценарий, проблема не ограничивается одним job’ом в Jenkins, GitHub Actions, GitLab CI или другом инструменте. Под удар попадает сам механизм доверия внутри разработки. А значит, вопросы вроде минимизации прав, изоляции runner’ов, жёсткой валидации входящих событий, ревизии webhook’ов и контроля над сторонними компонентами должны обсуждаться не после инцидента, а до него.
Для бизнеса последствия ещё скучнее и оттого опаснее. Компрометация CI/CD редко выглядит как громкая авария с красными лампочками. Гораздо чаще это тихая подмена в доверенном процессе: собралось, протестировалось, задеплоилось, подписалось. А потом выясняется, что клиент или внутренняя среда получили артефакт, который формально прошёл через официальную цепочку. Именно поэтому атаки на software supply chain так болезненны: они ломают не только инфраструктуру, но и репутационную модель доверия. Команда может быстро восстановить сервер, но куда сложнее объяснить заказчику, почему вредоносный код пришёл к нему по вашему же штатному каналу поставки.
Показательно и то, что история с Cordyceps подаётся не как сенсация про один конкретный инструмент, а как ещё одно доказательство более неприятного тренда. Индустрия постепенно признаёт: внешняя поверхность атаки больше не заканчивается на веб-приложении, VPN и почте. В неё входят всё более «инженерные» зоны, где раньше полагались на внутренний периметр и здравый смысл. На практике это означает пересборку процессов: security review для пайплайнов, инвентаризацию интеграций, отдельную модель угроз для build- и release-среды, нормальное логирование действий автоматизации и понятного владельца для всей цепочки доставки. Не «у всех есть доступ, потому что так удобнее», а конкретного человека или команду, которая отвечает за этот контур как за production-систему.
Главный вопрос теперь не в том, появятся ли новые варианты таких атак, а в том, сколько компаний готовы признать безопасность CI/CD отдельной дисциплиной, а не приложением к DevOps. Пока пайплайны остаются серой зоной между разработкой и ИБ, уязвимости вроде Cordyceps будут работать не только как техническая находка исследователей, но и как тест на зрелость инженерной организации. Подробности исходной публикации можно посмотреть у .