Инциденты вокруг Checkmarx и Bitwarden хорошо показывают неприятную особенность современных атак на цепочки поставок. Злоумышленники всё чаще целятся не просто в отдельные компании, а в инструменты, которым уже доверяют разработчики и команды безопасности.

В этом случае под удар попали именно security-компании. Это делает историю особенно чувствительной: продукты таких компаний часто имеют доступ к репозиториям, токенам, ключам и другой инфраструктуре, где ошибка быстро превращается в проблему для клиентов.

Что произошло

По данным Ars Technica, цепочка началась с атаки на Trivy — популярный сканер уязвимостей. Злоумышленники получили доступ к GitHub-аккаунту Trivy и использовали его для распространения вредоносного кода среди пользователей инструмента.

Одним из пострадавших оказался Checkmarx. Вредоносное ПО искало на заражённых машинах токены репозиториев, SSH-ключи и другие учётные данные. Через несколько дней уже GitHub-аккаунт Checkmarx начал распространять вредоносные версии для пользователей самой компании.

Checkmarx заявил, что сдержал атаку и восстановил легитимные приложения. Но 22 апреля появилась новая волна вредоносного кода. Это может говорить либо о неполной очистке после первой атаки, либо о новом взломе, детали которого источник не раскрывает.

Почему это стало каскадной проблемой

Ситуация не ограничилась одним эпизодом. Socket также сообщил о вредоносных публикациях в официальном Docker Hub-репозитории Checkmarx/kics примерно в тот же период. Позже Checkmarx рассказал ещё об одной части истории: группировка Lapsu$ выложила в даркнет часть приватных данных.

По информации источника, метка времени у опубликованных материалов — 30 марта. Это важно, потому что может указывать на сохранение доступа после обнаружения компрометации 23 марта. При этом Checkmarx не уточнил, какие именно данные были раскрыты.

Bitwarden тоже оказался связан с этой кампанией. Компания сообщила, что вредоносный пакет был короткое время доступен через npm-канал для @bitwarden/cli@2026.4.0 22 апреля 2026 года — примерно с 17:57 до 19:30.

Почему атакуют именно такие компании

Главный вывод здесь не в том, что пострадали две известные компании. Важнее другое: security-инструменты становятся одновременно целью и средством доставки атаки.

Атакующие используют инструменты безопасности и как цель, и как канал доставки атаки.

Эта мысль хорошо объясняет логику злоумышленников. Если скомпрометировать инструмент, которому доверяют разработчики, можно получить доступ не только к одной организации, но и к её клиентам, партнёрам или downstream-инфраструктуре.

По версии Socket, за исходной атакой стояла группа TeamPCP. Источник описывает её как access-broker-операцию, то есть группу, которая получает доступы и затем может передавать или продавать их другим злоумышленникам. В случае Checkmarx предполагается, что доступ мог быть передан Lapsu$, но детали этой связи в открытом виде раскрыты не полностью.

Что остаётся неясным

Пока неясно, какие именно данные Checkmarx могли попасть в утечку. Также источник не даёт полного технического разбора того, как именно злоумышленники удерживали доступ и какие внутренние меры защиты сработали или не сработали.

Но общий смысл уже понятен: одна компрометация в цепочке поставок может быстро перейти на другие компании и каналы распространения. Для рынка это напоминание, что даже инструменты безопасности требуют постоянной проверки, изоляции прав и внимательного контроля публикаций в GitHub, npm и Docker Hub.

Эта история выделяется тем, что атака затронула не обычные сервисы, а компании, которые сами занимаются защитой и безопасной разработкой. Видно, как одна компрометация может пройти по цепочке: от одного инструмента к другому аккаунту, затем к пользователям и, возможно, к партнёрам. Это усиливает тренд на более строгую проверку open-source-зависимостей, CI/CD-процессов и прав доступа. Неоднозначность в том, что часть деталей остаётся закрытой, а значит, полную картину последствий ещё рано считать завершённой.

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

Источник: arstechnica.com