Компрометація Trivy: що перевірити в Docker і GitHub Actions за 30 хвилин

Коротко: це не кейс про «ще одну CVE». У Trivy тимчасово скомпрометували довірені канали доставки: реліз, Docker-образи та GitHub Actions refs. Якщо ви в цей період тягнули latest, 0.69.4, 0.69.5, 0.69.6, старі теги trivy-action або setup-trivy без надійного pinning, правильна базова позиція одна: вважати доступні секрети потенційно засвіченими, перейти на safe versions і прибрати mutable refs із пайплайнів сьогодні, а не «коли буде час».

Чому цей інцидент важливіший за звичайний security advisory

Звичайна вразливість — це часто історія про оновлення коду до патча. Тут проблема інша: шкідливий код потрапив у те, що команди звикли вважати «надійним за замовчуванням» — релізи, образи та GitHub Actions-теги.

Людською мовою це означає таке:

• ви могли не зробити жодної «дивної» дії;
• pipeline міг виглядати абсолютно нормальним;
• але під час запуску міг витягнути шкідливий артефакт і віддати назовні токени, SSH-ключі, cloud credentials або Docker config.

Тому реакція тут має бути як на incident response, а не як на звичайне «оновимо залежність на вихідних».

Хто реально під ризиком

1) Команди, які запускали Trivy як контейнер або binary

За офіційними джерелами, під ризиком були:

• trivy v0.69.4;
• Docker Hub образи aquasec/trivy:0.69.5, 0.69.6 і latest у вікні компрометації;
• інсталяції, які тягнули скомпрометовані артефакти через звичні канали доставки.

Менший ризик або відсутність впливу:

• v0.69.3 або раніше;
• образи, зафіксовані за digest;
• збірка з source;
• офіційний Homebrew-шлях, який будує з source.

2) Команди, які використовували GitHub Actions

Під підозрою:

• aquasecurity/trivy-action на старих тегах до 0.35.0 / v0.35.0;
• aquasecurity/setup-trivy без безпечного pinning на конкретний SHA;
• workflow, які покладались на рухомі теги або кеші self-hosted runner’ів.

Практичний висновок простий: якщо ви не можете швидко і доказово довести, що використовували лише безпечний immutable ref, поводьтесь так, ніби pipeline був потенційно скомпрометований.

30-хвилинний playbook без паніки

Крок 1. Знайдіть усі точки використання Trivy

Спочатку не оновлюйте навмання — зробіть коротку інвентаризацію.

rg -n "aquasec/trivy|ghcr.io/aquasecurity/trivy|aquasecurity/trivy-action|aquasecurity/setup-trivy" .

Що шукаємо:

• Dockerfiles;
• reusable workflows;
• шаблонні CI репозиторії;
• self-hosted runner bootstrap-скрипти;
• внутрішні action wrappers.

Особлива увага до таких шаблонів:

• :latest
• :0.69.4
• :0.69.5
• :0.69.6
• uses: aquasecurity/trivy-action@0.x
• uses: aquasecurity/setup-trivy@v0.2.x без full SHA.

Крок 2. Негайно замініть refs на safe versions

Мінімально безпечна матриця зараз така:

Компонент	Що вважати safe прямо зараз
Trivy binary/image	v0.69.3 або перевірений v0.69.2; для образів краще pin by digest
trivy-action	v0.35.0 / 0.35.0
setup-trivy	v0.2.6, бажано ще й pinned на full SHA

Головний урок не лише в цифрах версій. Якщо security-інструмент у критичному пайплайні живе на mutable tag, то це вже операційний ризик, навіть коли сьогодні все «зелене».

Крок 3. Якщо скомпрометований артефакт міг виконатися — ротуй секрети

Не витрачайте перші години на суперечки «а точно витекло чи ні». Якщо pipeline мав доступ до секретів і міг запустити уражений компонент, безпечний шлях такий:

1. відкликати / перевипустити GitHub PAT, App tokens, CI service tokens;
2. ротувати cloud creds (AWS/GCP/Azure);
3. перевипустити registry credentials;
4. замінити SSH keys, якщо вони були доступні runner’у;
5. оновити Kubernetes tokens, .env secrets, database credentials — за пріоритетом доступу.

Сенс простий: наслідки ротації — це контрольований дискомфорт. Наслідки неротованого секрету — це вже можливий інцидент через день або тиждень.

Крок 4. Перевірте кеші, mirror і локальні хвости

Навіть якщо upstream уже почистили, шкідливий артефакт може лишитися у вас:

• у Docker cache на runner’і;
• у приватному registry mirror;
• у prebuilt base images;
• у self-hosted runner workspace або tools cache.

Тобто недостатньо просто замінити тег у YAML. Треба ще прибрати шанс, що старий артефакт підхопиться повторно з кешу.

Крок 5. Перевірте ознаки потенційного витоку

Офіційна advisory окремо радить шукати сліди ексфільтрації. З практичних перевірок:

• перегляньте workflow runs за 19–20 березня 2026;
• перевірте, чи не з’являлися нетипові звернення до зовнішніх доменів;
• пошукайте сторонні публічні репозиторії на кшталт tpcp-docs, якщо у вас були GitHub токени з достатніми правами;
• звірте audit/security logs по незвичних create/push/release діях.

Навіть якщо прямих ознак немає, це не причина пропускати ротацію, якщо запуск підозрілого артефакту можливий.

Що перевірити окремо для Docker users

Якщо ви використовували Trivy як контейнер:

1. Перевірте, чи тягнули aquasec/trivy з Docker Hub у вікні компрометації.
2. Подивіться, чи не залишились образи 0.69.4, 0.69.5, 0.69.6 або latest на runner’ах і build-нодах.
3. Якщо у вас є registry mirror або локальний cache — очистіть/перевалідуйте саме його, а не лише upstream reference.
4. Для майбутнього: критичні scanner images фіксуйте за digest, а не тільки за тегом.

Це особливо важливо для self-hosted CI, де кеш часто живе довше, ніж усі про нього пам’ятають.

Що перевірити окремо для GitHub Actions users

Якщо ви використовували Trivy через Actions:

1. Перегляньте всі uses: refs на trivy-action і setup-trivy.
2. Приберіть старі теги й перейдіть на v0.35.0 / v0.2.6 або, ще краще, на full SHA.
3. Перевірте reusable workflows та центральні шаблони — часто саме вони тягнуть ризик у десятки репозиторіїв.
4. Якщо у вас self-hosted runners, очистіть tools cache і тимчасові робочі каталоги.
5. Перевірте, які secrets реально були доступні job під час скану.

Найнебезпечніша помилка тут — оновити один репозиторій і вирішити, що інцидент закрито. Якщо шаблон shared, перевіряти треба ланцюжок, а не одну точку.

Safe versions і безпечні посилання: що брати як базу

За офіційними джерелами:

• Trivy v0.69.3 — надійна reference-точка для rollback/forward fix;
• trivy-action v0.35.0 — офіційно позначений як safe;
• setup-trivy v0.2.6 — офіційно перевипущений safe release;
• якщо вже використовуєте GitHub Actions у критичному CI, робіть наступний крок одразу: pinning на full SHA, а не просто «безпечний тег».

Коротке правило на майбутнє:

• контейнери — digest;
• GitHub Actions — full SHA;
• security-інструменти — без latest.

Як не повторити цю історію через місяць

Мінімальна профілактика без оверінжинірингу:

• заборонити latest і неперевірені mutable tags у security-critical місцях;
• тримати список зовнішніх Actions/образів, які дозволено використовувати;
• для self-hosted runner’ів мати documented cleanup flow після security-інцидентів;
• мінімізувати набір секретів, доступних job сканування;
• відокремити «читання репозиторію» від «доступу до продакшн-секретів», де це можливо.

Це не робить supply-chain ризик нульовим, але сильно зменшує радіус ураження.

Висновок

Головна думка тут проста: якщо скомпрометували довірений scanner, треба лікувати не лише версію, а й саму звичку покладатися на рухомі refs. На практиці правильний порядок такий: швидко знайти всі місця використання, перейти на safe versions, ротувати потенційно доступні секрети, перевірити кеші й після цього зафіксувати нове правило — критичні зовнішні залежності лише через immutable refs.

Офіційні джерела:

• https://www.docker.com/blog/trivy-supply-chain-compromise-what-docker-hub-users-should-know/
• https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23
• https://github.com/aquasecurity/trivy/releases/tag/v0.69.3
• https://github.com/aquasecurity/trivy-action/releases/tag/v0.35.0
• https://github.com/aquasecurity/setup-trivy/releases/tag/v0.2.6