Продолжим разбирать интересные атаки на цепочку поставок последних месяцев. И если в прош…

Продолжим разбирать интересные атаки на цепочку поставок последних месяцев. И если в прошлый раз у нас был кейс про вредоносную зависимость, которая приезжала транзитивно, то здесь история еще прикольнее. Потому что злоумышленники умудрились ударить по популярному опенсорсному инструменту SCA. Давайте еще раз. Не по какому-то пакету, который разрабы использовали в своем ПО, а по целому инструменту, который должен искать уязвимости в пакетах и зависимостях... Взлом Trivy (https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/), дамы и господа 😉

Если смотреть на механику атаки, то получим показательный пример третьего сценария (https://t.me/maxienergy_channel/386), потому что удар пришелся не столько по коду, сколько по инфраструктуре сборки, релизов и доставки. Все началось еще в конце февраля 2026, когда злоумышленники смогли вытащить учетные данные из CI-окружения Trivy. А уже 19 марта этот доступ превратился в полноценную атаку. Дальше злоумышленники не стали атаковать в лоб, а воспользовались тем, что разработчики и пайплайны уже доверяют официальным релизам и GitHub Actions. В марте был опубликован вредоносный релиз Trivy v0.69.4, помимо чего были переписаны теги у trivy-action и setup-trivy (https://github.com/aquasecurity/trivy/discussions/10425). Сама подмена шла сразу по нескольким каналам доставки (через бинарник, через 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 (https://www.linkedin.com/posts/mccartypaul_updated-march-20-2026-at-3pm-heads-up-activity-7440548548775038976-ruRt) (почти битлз, но не битлз), после чего к расследованию подключились Aqua, Socket (https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise), Wiz (https://www.wiz.io/blog/trivy-compromised-teampcp-supply-chain-attack), CrowdStrike (https://www.crowdstrike.com/en-us/blog/from-scanner-to-stealer-inside-the-trivy-action-supply-chain-compromise/), SANS и другие эксперты. Исследователи заметили аномалии в релизах и тегах (старые версии начали ссылаться на новые коммиты)

В итоге уже 20 марта (https://www.aikido.dev/blog/teampcp-deploys-worm-npm-trivy-compromise) злоумышленники начали использовать украденные токены для новой волны заражений в npm. Так появился CanisterWorm (вредонос, который через postinstall ставил Python-бэкдор, закреплялся через systemd --user и пытался превращать украденные npm-токены в следующий этап распространения). То есть Trivy в этой истории оказался не финальной целью, а точкой входа. Сначала компрометировали инструмент и собрали секреты из пайплайнов, потом эти секреты использовали для публикации вредоносных пакетов дальше по цепочке 💀

Как от такого нужно защищаться (и можно ли)?

Во-первых, здесь все также работает совет, который я уже давал в посте про axios (https://t.me/maxienergy_channel/387): не жить на плавающих версиях. В истории с Trivy это относится не только к пакетам, но и к GitHub Actions. Aqua прямо рекомендовала использовать trivy-action не по тегам, а по полному commit SHA, потому что тег можно переписать. То же самое с образами (лучше ссылаться на контейнер по digest, а не по тегу вроде latest)

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

В-третьих, нужно снижать объем секретов, доступных раннеру

Ну и последнее. Такие атаки подталкивают нас к мысли, что одной только проверки состава зависимостей уже мало. Важно еще и ограничивать поведение того, что мы запускаем 🧠