Продолжим разбирать интересные атаки на цепочку поставок последних месяцев. И если в прошлый раз у нас был кейс про вредоносную зависимость, которая приезжала транзитивно, то здесь история еще прикольнее. Потому что злоумышленники умудрились ударить по популярному опенсорсному инструменту SCA. Давайте еще раз. Не по какому-то пакету, который разрабы использовали в своем ПО, а по целому инструменту, который должен искать уязвимости в пакетах и зависимостях... Взлом Trivy, дамы и господа 😉
Если смотреть на механику атаки, то получим показательный пример третьего сценария, потому что удар пришелся не столько по коду, сколько по инфраструктуре сборки, релизов и доставки. Все началось еще в конце февраля 2026, когда злоумышленники смогли вытащить учетные данные из CI-окружения Trivy. А уже 19 марта этот доступ превратился в полноценную атаку. Дальше злоумышленники не стали атаковать в лоб, а воспользовались тем, что разработчики и пайплайны уже доверяют официальным релизам и GitHub Actions. В марте был опубликован вредоносный релиз Trivy v0.69.4, помимо чего были переписаны теги у trivy-action и setup-trivy. Сама подмена шла сразу по нескольким каналам доставки (через бинарник, через action и через setup-цепочку)
Как обычно и бывает с атаками на цепочку поставок, для жертв все выглядело штатно. Пайплайн запускал знакомый action или ставил знакомый бинарник, Trivy потом даже мог отработать как обычно и показать результаты сканирования. Но перед этим выполнялся вредоносный код. Socket описывает это как компрометацию entrypoint.sh, в котором сначала происходила кража секретов, а уже потом запускалась фактическая логика сканера. Скрипт искал на машине процессы GitHub Actions раннера, включая Runner.Worker, Runner.Listener, runsvc и run.sh, а затем читал их переменные окружения через /proc/<pid>/environ. Ему были интересны значения, похожие на env, ssh и другие потенциально чувствительные переменные. Если значение указывало на файл, скрипт пытался прочитать и сам файл. После этого собранные данные шифровались (AES-256-CBC и RSA-4096) и уходили наружу
Тревогу подняли довольно быстро. Одним из первых на вредоносный Trivy v0.69.4 обратил внимание исследователь Paul McCarty (почти битлз, но не битлз), после чего к расследованию подключились Aqua, Socket, Wiz, CrowdStrike, SANS и другие эксперты. Исследователи заметили аномалии в релизах и тегах (старые версии начали ссылаться на новые коммиты)
В итоге уже 20 марта злоумышленники начали использовать украденные токены для новой волны заражений в npm. Так появился CanisterWorm (вредонос, который через postinstall ставил Python-бэкдор, закреплялся через systemd --user и пытался превращать украденные npm-токены в следующий этап распространения). То есть Trivy в этой истории оказался не финальной целью, а точкой входа. Сначала компрометировали инструмент и собрали секреты из пайплайнов, потом эти секреты использовали для публикации вредоносных пакетов дальше по цепочке 💀
Как от такого нужно защищаться (и можно ли)?
Во-первых, здесь все также работает совет, который я уже давал в посте про axios: не жить на плавающих версиях. В истории с Trivy это относится не только к пакетам, но и к GitHub Actions. Aqua прямо рекомендовала использовать trivy-action не по тегам, а по полному commit SHA, потому что тег можно переписать. То же самое с образами (лучше ссылаться на контейнер по digest, а не по тегу вроде latest)
Во-вторых, все, что мы обсуждали в контексте воспроизводимой установки и фиксации зависимостей, здесь тоже абсолютно в тему. Просто уровень применения шире. Нужно фиксировать и версии пакетов в lockfile, и версии экшенов, setup-скриптов, контейнерных образов и вообще всего, что участвует в пайплайне
В-третьих, нужно снижать объем секретов, доступных раннеру
Ну и последнее. Такие атаки подталкивают нас к мысли, что одной только проверки состава зависимостей уже мало. Важно еще и ограничивать поведение того, что мы запускаем 🧠
#информационная_безопасность
