Один із найпопулярніших відкритих сканерів вразливостей Trivy, що активно використовується для перевірки контейнерів, Kubernetes-кластерів та репозиторіїв коду, став центром складної атаки на ланцюг постачання програмного забезпечення (supply chain-атаки). У проєкт було непомітно вбудовано інфостілер, який збирав секрети з CI/CD-пайплайнів і робочих станцій розробників.
Trivy як критична ланка ланцюга постачання ПЗ
Trivy, який розвиває компанія Aqua Security, має понад 33 200 зірок на GitHub і фактично став стандартом де-факто в екосистемі DevSecOps. Інструмент часто інтегрують у автоматизовані CI/CD-процеси, тому будь-яка його компрометація безпосередньо впливає на безпеку ланцюга постачання ПЗ десятків тисяч проєктів.
Зловмисники, використавши викрадені облікові дані, виконали force-push для 75 із 76 тегів у репозиторії aquasecurity/trivy-action і підмінили сім тегів setup-trivy. Підроблені теги почали вказувати на шкідливі коміти. Серед скомпрометованих виявилися версії @0.34.2, @0.33 та @0.18.0, тоді як незміненою залишилася лише @0.35.0. Троянізований реліз Trivy v0.69.4 був доступний близько трьох годин, а підмінені теги GitHub Actions — приблизно 12 годин.
Механіка атаки: підміна тегів GitHub Actions і троянізовані релізи
За спостереженнями дослідників Socket і Wiz, ключова особливість кампанії полягала в тому, що нападники не створювали нових релізів чи комітів. Вони перенаправили існуючі теги на шкідливі коміти й максимально точно скопіювали метадані: ім’я автора, email, мітки часу та тексти повідомлень з номерами pull request-ів. Це мінімізувало аномалії в історії репозиторію і знижувало ймовірність спрацювання моніторингу.
Паралельно було змінено скрипт entrypoint.sh у GitHub Actions і опубліковано троянізовані білди Trivy v0.69.4 через GitHub Releases, Docker Hub, GHCR та ECR. Поки шкідливі артефакти залишалися доступними, будь-який CI/CD-процес, що посилався на підмінені теги, автоматично завантажував і виконував шкідливий код, що робить цей інцидент показовим прикладом глибокої supply chain-атаки.
Інфостілер у Trivy: які дані викрадали
Троянізований код запускав легітимний сканер Trivy, щоб зберегти звичну поведінку, і паралельно — інфостілер. Мета шкідливого модуля — витягти максимально можливий обсяг конфіденційних даних з CI/CD-середовищ і робочих станцій.
Інфостілер збирав змінні оточення, аналізував файлову систему в пошуках SSH-ключів, конфігурацій AWS, GCP, Azure, kubeconfig-файлів, Docker-конфігів, .env-файлів, паролів до баз даних, токенів Slack і Discord, TLS-ключів, VPN-конфігурацій та даних криптогаманців. Окремо він аналізував пам’ять процесу GitHub Actions Runner.Worker у пошуку JSON-об’єктів із секретами.
Зібрана інформація шифрувалася і надсилалася POST-запитом на тайпосквот-домен scan.aquasecurtiy[.]org, схожий на легітимний домен Aqua Security. Якщо ексфільтрація не вдавалася, шкідливе ПО створювало в акаунті жертви публічний репозиторій tpcp-docs і вивантажувало дані туди — нетиповий, але ефективний запасний канал витоку.
На розробницьких машинах троянізований бінарник додатково встановлював Python-пейлоад (~/.config/systemd/user/sysmon.py) як systemd-сервіс, що регулярно звертався до віддаленого сервера по нові завантажувані модулі. Це забезпечувало стійку постексплуатаційну присутність у системі.
Ймовірні виконавці: TeamPCP та пов’язані кампанії
Експерти пов’язують інцидент із групуванням TeamPCP (також відомим як DeadCatx3, PCPcat, ShellForce). На це, зокрема, вказує коментар «TeamPCP Cloud stealer» в одному з Python-скриптів. За даними Socket, група спеціалізується на атаках на хмарну інфраструктуру, активно використовуючи некоректно сконфігуровані Docker API, Kubernetes-кластери, Ray dashboards і сервери Redis.
Компанія Aikido додатково пов’язує цю атаку з кампанією CanisterWorm — саморозповсюджувальним черв’яком, що компрометує npm-пакети, публікуючи шкідливі версії за допомогою викрадених npm-токенів. На тлі відомих інцидентів SolarWinds, Codecov та хвиль шкідливих npm-пакетів, атака на Trivy демонструє стабільний тренд: зловмисники все активніше зміщуються «вліво» — ближче до процесів розробки й збірки.
Коренева причина: злам розширення VS Code і повторна компрометація
Мейнтейнер Trivy Ітай Шакурі пов’язує поточний інцидент із попередньою атакою від 1 березня 2026 року, коли було скомпрометовано розширення Aqua Trivy для VS Code. Це дало нападникам доступ до облікових даних із правами запису до GitHub-акаунту Trivy. Після першого інциденту токени замінили, однак частина артефактів — API-ключі, сертифікати, паролі — залишилася у зловмисників, що дозволило їм повернутися та провести ще масштабнішу операцію.
Більше того, нападники видалили з репозиторію Trivy інформацію про березневу компрометацію, намагаючись приховати повну картину ланцюжка атак і ускладнити форензічний аналіз.
Ризики для організацій та рекомендовані кроки реагування
Кого може зачепити інцидент
Будь-які організації, які використовували скомпрометовані теги GitHub Actions чи троянізовані білди Trivy, мають виходити з припущення про повну компрометацію своїх секретів. Під загрозою — не лише змінні середовища в пайплайнах, а й усі пов’язані ресурси: хмарні акаунти, репозиторії коду, кластери Kubernetes, бази даних, черги повідомлень та внутрішні сервіси.
Практичні заходи захисту
Мейнтейнери Trivy рекомендуть всім потенційно постраждалим негайно ротувати всі секрети: хмарні облікові дані, SSH-ключі, API-токени, паролі до БД, OAuth-токени, ключі VPN і корпоративних месенджерів. Додатково доцільно:
- провести детальний аудит CI/CD-пайплайнів і логів GitHub Actions на предмет підозрілих запусків та нетипових мережевих з’єднань;
- по можливості замінити посилання на теги в GitHub Actions на зафіксовані хеші комітів (pinning версій);
- мінімізувати права GitHub-токенів за принципом найменших привілеїв та увімкнути обов’язкове 2FA/апаратні ключі для критичних акаунтів;
- запровадити регулярний secret scanning у репозиторіях і контроль цілісності релізів (підписані релізи та перевірка підписів);
- переглянути політики використання розширень IDE, плагінів і сторонніх інструментів, що мають доступ до облікових даних розробників.
Атака на Trivy показує, що навіть перевірені часом інструменти безпеки можуть стати слабкою ланкою, якщо процеси управління доступом, секретами та артефактами недостатньо зрілі. Компаніям варто розглядати засоби безпеки в CI/CD як компоненти підвищеного ризику: фіксувати версії за хешами, системно моніторити репозиторії на аномалії, регулярно навчати команди безпечним практикам розробки й не відкладати перевірку власного ланцюга постачання ПЗ до наступного інциденту.
