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

Компания рекомендовала пользователям проверить установленную версию и не полагаться на неизвестные сборки. Инцидент важен не только для разработчиков: атаки на цепочку поставки ПО всё чаще бьют по сервисам, которыми затем пользуются обычные люди.

Что известно о подмене плагина

Checkmarx сообщила, что пользователям Jenkins AST Plugin нужно убедиться в установке версии 2.0.13-829.vc72453fa_1c16, опубликованной 17 декабря 2025 года, или более ранней версии. Позднее компания выпустила версию 2.0.13-848.v76e89de8a_053 на GitHub и в Jenkins Marketplace.

Как именно изменённая версия попала в каталог Jenkins, Checkmarx не раскрыла. Это ключевой вопрос: если злоумышленники получили доступ к публикации плагина, они могли использовать доверие разработчиков к официальному каналу распространения.

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

TeamPCP снова атакует Checkmarx

По данным The Hacker News, за атакой стоит группа TeamPCP. Это не первый эпизод: за несколько недель до инцидента с Jenkins злоумышленников связали с компрометацией Docker-образа KICS, двух расширений VS Code и рабочего процесса GitHub Actions (workflow — автоматизированный сценарий).

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

С марта 2026 года TeamPCP связывают с серией взломов, построенных на доверии к инструментам разработки. Схема проста: атакующие не ломают каждого пользователя отдельно, а заражают компонент, который многие команды ставят добровольно.

Почему цепочка поставки ПО так уязвима

Цепочка поставки ПО (software supply chain — путь кода от разработчика до конечного продукта) держится на доверии. Команды подключают плагины, пакеты, расширения и готовые образы, чтобы быстрее выпускать обновления. Но каждый новый компонент расширяет поверхность атаки.

Особенно опасны инструменты для CI/CD (continuous integration and continuous delivery — непрерывная интеграция и доставка). Они работают с исходным кодом, ключами API, токенами облачных сервисов и данными для публикации релизов. Если такой инструмент подменили, злоумышленник может получить не один пароль, а доступ к целой инфраструктуре.

Похожий риск возникает и в проектах с искусственным интеллектом: утечка ключей API быстро превращается в финансовые потери и раскрытие переписок. Мы разбирали такой сценарий в материале про уязвимость Ollama и утечку ключей API.

Что насторожило исследователей

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

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

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

Почему это касается не только администраторов Jenkins

Обычный пользователь редко ставит Jenkins-плагины. Но он пользуется приложениями, сайтами и сервисами, которые собирают через такие инструменты. Если атакующие проникли в процесс сборки, заражённый код может попасть дальше — в обновление, клиентское приложение или внутренний сервис компании.

Разработчики тоже часто действуют на автомате. Человек ищет справку по sql distinct on, ставит удобное расширение для редактора или копирует пакет из инструкции — и не всегда проверяет автора, историю релизов и права доступа. С бытовыми запросами вроде discord web version логика та же: риск возникает не в запросе, а в сомнительной утилите, которую предлагают скачать под видом удобного помощника.

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

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

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

  • Если вы используете Checkmarx Jenkins AST Plugin, проверьте версию. Ориентируйтесь на рекомендации Checkmarx и официальные каналы Jenkins Marketplace и GitHub.
  • Удалите неизвестные или промежуточные сборки плагина. Не оставляйте компонент «до выяснения», если он имеет доступ к проектам и секретам.
  • Смените токены, ключи API и пароли, которые могли быть доступны Jenkins. Ротацию лучше провести даже без явных признаков кражи.
  • Просмотрите журналы Jenkins, GitHub, npm и облачных сервисов за период вокруг установки или обновления плагина.
  • Ограничьте права плагинов: сборочный сервер не должен иметь доступ ко всем репозиториям и всем средам сразу.
  • Включите многофакторную защиту для аккаунтов разработчиков и администраторов.
  • Закрепляйте версии критичных зависимостей и проверяйте контрольные суммы там, где это возможно.
  • Для личных устройств держитесь того же правила: расширения, плагины и утилиты ставьте только из проверенных каталогов и от известных авторов.
Поделиться: