Checkmarx предупредила клиентов о вредоносной версии своего плагина Jenkins Application Security Testing. Поддельный пакет попал в Jenkins Marketplace и мог украсть учётные данные из сред разработки, поэтому риск касается команд, которые собирают и выкатывают приложения через автоматические конвейеры.

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

Что случилось с плагином Checkmarx AST

По данным BleepingComputer, Checkmarx сообщила, что в Jenkins Marketplace опубликовали изменённую версию её плагина Jenkins AST. Этот плагин подключает проверку безопасности приложений к автоматическим сборкам: код проходит сканирование прямо в конвейере разработки.

Jenkins — одна из самых популярных систем CI/CD (Continuous Integration/Continuous Deployment — непрерывная интеграция и доставка). Её используют для сборки, тестирования, анализа кода, упаковки приложений и доставки обновлений на серверы.

Вредоносная версия получила номер 2026.5.09 и появилась в репозитории repo.jenkins-ci.org 9 мая 2026 года. Checkmarx указала, что выпуск прошёл вне её обычного релизного процесса: у пакета не было git-тега и отдельного релиза в GitHub, а номер не совпадал с принятой схемой дат.

Откуда взялись украденные доступы

Ответственность за атаку заявила группа TeamPCP. По версии Checkmarx, злоумышленники использовали учётные данные, украденные ранее во время атаки на цепочку поставки Trivy в марте.

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

Это уже третий эпизод в серии атак на цепочку поставки, с которыми Checkmarx столкнулась с конца марта. Ранее атакующие, используя украденные учётные данные, публиковали изменённые версии инструментов для разработчиков в GitHub, Docker и VSCode. В конце апреля компания также подтверждала утечку данных из приватного репозитория GitHub после публикации материалов группой LAPSUS$.

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

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

В случае с Jenkins риск особенно высок. Система сборки часто хранит токены к репозиториям, ключи контейнерных реестров, пароли к тестовым и рабочим стендам, учётные записи облачных сервисов. Если инфостилер (от англ. information stealer — похититель данных) получает доступ к такой среде, ущерб быстро выходит за пределы одного плагина.

Похожую проблему SAFENET21 уже разбирал на примере утечек секретов в локальных ИИ-инструментах: уязвимость Ollama грозит утечкой ключей API и переписок. Логика та же: токен или ключ часто открывает больше дверей, чем один украденный пароль.

Что советует Checkmarx

Checkmarx рекомендовала пользователям убедиться, что они используют версию 2.0.13-829.vc72453fa_1c16 от 17 декабря 2025 года или более старую версию плагина. Вредоносную сборку 2026.5.09 нужно считать небезопасной.

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

Checkmarx также заявила, что её репозитории GitHub отделены от рабочей среды клиентов и не хранят клиентские данные. Для защитников компания подготовила индикаторы компрометации — список вредоносных артефактов, по которым можно искать следы атаки в собственных системах.

Что проверить в своей инфраструктуре

Если компания использует Jenkins, проверка не должна ограничиваться одним плагином. Сначала стоит понять, какие сборочные узлы могли скачать подозрительную версию, какие задания запускались после обновления и какие секреты были доступны этим заданиям.

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

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

О роли автоматической проверки кода мы писали в материале OpenAI запустила Daybreak: ИИ будет искать уязвимости в коде. Но этот инцидент показывает: даже хороший сканер не заменяет контроль за тем, откуда пришёл сам инструмент.

Практический вывод: что сделать прямо сейчас

  • Проверьте, установлен ли в Jenkins плагин Checkmarx AST версии 2026.5.09.
  • Если версия совпадает, отключите плагин и перейдите на 2.0.13-829.vc72453fa_1c16 от 17 декабря 2025 года или более раннюю доверенную сборку.
  • Смените токены, пароли и ключи, к которым могли получить доступ задания Jenkins.
  • Проверьте журналы сборок, сетевые соединения и действия сервисных аккаунтов после 9 мая 2026 года.
  • Найдите признаки бокового перемещения: новые ключи, неизвестные задания, странные вебхуки, изменения в репозиториях и контейнерных образах.
  • Введите правило: плагины для CI/CD обновляются только после проверки релиза, подписи, тега и источника публикации.
Поделиться: