Коротко: це не кейс про «ще одну 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-теги.

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

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

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

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

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

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

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

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

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

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

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

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

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

Що шукаємо:

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

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

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

КомпонентЩо вважати safe прямо зараз
Trivy binary/imagev0.69.3 або перевірений v0.69.2; для образів краще pin by digest
trivy-actionv0.35.0 / 0.35.0
setup-trivyv0.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 уже почистили, шкідливий артефакт може лишитися у вас:

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

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

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

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

Що перевірити окремо для 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 і безпечні посилання: що брати як базу

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

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

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

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

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

Висновок

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

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