Модуль 5.2: Сканування образів за допомогою Trivy

Складність: [СЕРЕДНЯ] — критично важлива навичка для CKS

Час на проходження: 45 хвилин

Передумови: Модуль 5.1 (Безпека образів), основи Docker та маніфести Kubernetes

Що ви зможете зробити

Після завершення цього модуля ви зможете:

Сканувати локальні образи, образи з віддалених реєстрів, кластери Kubernetes, маніфести Kubernetes та чарти Helm за допомогою Trivy, використовуючи перевірені прапорці CLI.
Інтерпретувати знахідки про вразливості, читаючи ідентифікатори CVE, докази на рівні пакетів, виправлені версії, діапазони серйозності CVSS v3.1, джерела оцінок серйозності від вендорів та контекст експлуатації.
Інтегрувати Trivy у GitHub Actions та GitLab CI з бар’єрами за кодом виходу, виводом у форматі SARIF чи JSON, оновленням бази даних з урахуванням кешу та закріпленими (pinned) посиланнями на дії.
Сортувати хибнопозитивні спрацювання та прийнятий ризик через .trivyignore, .trivyignore.yaml, VEX, політики Rego та задокументований перегляд списку дозволів замість мовчазного приховування.

Чому цей модуль важливий

Гіпотетичний сценарій: команда постачає внутрішній API з Dockerfile, який не змінювався місяцями. Код застосунку чистий, тести проходять, а тег образу є незмінним, проте наступного ранку проти базового шару Debian, який успадкував образ, з’являється критичне попередження щодо OpenSSL. Образ тепер ризикованіший, ніж учора, хоча жоден розробник не змінив жодного рядка коду, тому що ризик образу — це рухоме співвідношення між запакованим програмним забезпеченням, базами даних попереджень, експозицією під час виконання та тим, наскільки швидко команда перезбирає образи з виправлених баз.

Trivy популярний у роботі з ланцюгом постачання Kubernetes, оскільки він дає один практичний інструмент для кількох релевантних для іспиту поглядів на цю проблему. Він може сканувати образ контейнера до того, як той потрапить у реєстр, сканувати завантажений образ за посиланням, перевіряти образи робочих навантажень кластера, що працює, та об’єкти Kubernetes, а також оцінювати маніфести Kubernetes чи чарти Helm на наявність проблем конфігурації. Навичка CKS — це не запам’ятовування однієї команди. Справжня навичка полягає в тому, щоб знати, які докази використав сканер, які рівні серйозності повинні блокувати конвеєр, які результати потребують людського контексту, а яких ризиків сканування образів не бачить взагалі.

Сканування також є частиною врядування. Контрольний список безпеки Kubernetes рекомендує сканувати образи перед розгортанням, зазвичай у CI/CD, щоб отримати інформацію про вразливості, як-от оцінки CVSS. NIST SP 800-190 робить схоже операційне зауваження щодо контейнерів: управління вразливостями, специфічне для контейнерів, повинно враховувати як вразливості програмного забезпечення в образі, так і налаштування безпечної конфігурації, тому що традиційні сканери хостів можуть не помітити робочий процес із незмінними образами. Тому чистий звіт Trivy не є сертифікатом безпеки, а корисною контрольною точкою в ширшому процесі збирання, допуску, виконання та перезбирання.

На іспиті CKS один реалістичний сценарій містить маніфест Pod, що використовує my-api:latest, тому що колега швидко розгорнув термінове виправлення й оновив лише поле образу в маніфесті. Правильна відповідь — визначити та просканувати дайджест, який насправді працює (kubectl + ім’я образу плюс SHA), а не перезапускати сканування проти latest, а потім перевірити, чи досі не розв’язана CVE, оскільки базовий образ у деплойменті залишався на відомому вразливому тегу, тоді як кандидат на патч посилається на новіший псевдонім образу від вендора. Ця відмінність — це різниця між проходженням лабораторної роботи та розумінням того, як дрейф дайджестів створює невидиму експозицію.

Як Trivy завантажує дані про вразливості

Бінарний файл Trivy — це лише рушій сканера. Корисна для дій інформація надходить через бази даних, які Trivy завантажує, кешує та оновлює під час запуску сканувань. Основна база даних вразливостей — це trivy-db, база даних Java — trivy-java-db, а набір перевірок — trivy-checks для сканування неправильних конфігурацій. У Trivy v0.70.0 довідка CLI показує типові репозиторії бази даних вразливостей: спочатку mirror.gcr.io/aquasec/trivy-db:2, а потім ghcr.io/aquasecurity/trivy-db:2, з еквівалентними типовими значеннями для бази даних Java. Ця деталь має значення в обмежених середовищах, тому що доступ до бази даних може бути різницею між змістовним скануванням та застарілими доказами.

Trivy найкраще розуміти як уніфікований локальний збирач доказів, а не лише як команду пошуку CVE контейнерів. Той самий CLI може перевіряти шари образу, бази даних пакетів, файли блокувань (lock files), залежності застосунків, YAML Kubernetes, вивід Helm, секрети, ліцензії, SBOM та живі ресурси Kubernetes. Така широта корисна на іспиті CKS, тому що завдання може казати «проскануй цей образ» в одній задачі та «знайди небезпечні налаштування в цьому маніфесті» в наступній задачі, не змінюючи інструментів. Небезпека полягає в тому, щоб трактувати кожну команду Trivy як той самий тип сканування. trivy image відповідає на питання, які пакети та файли існують в артефакті; trivy config відповідає, чи порушує оголошена інфраструктура політику; trivy k8s відповідає, що кластер наразі відкриває через API Kubernetes та інвентар робочих навантажень.

Офлайн-модель бази даних — одна з причин, чому Trivy підходить для робочих процесів іспиту та CI. Після завантаження бази даних сканер може працювати повторювано, не звертаючись до віддаленого SaaS-сервісу за кожною знахідкою, що допомагає, коли віртуальна машина іспиту має обмежений мережевий доступ або раннер збирання ізольований від інтернету. Компромісом є свіжість. Кешована база даних робить сканування швидшими та детермінованішими, але вона може пропустити попередження, опубліковані після прогріву кешу. Запуск з оновленням через мережу бачить новіші дані попереджень, але він може зазнати невдачі, тому що дзеркало реєстру, проксі або обмеження частоти запитів недоступні. Хороші конвеєри розділяють ці питання, прогріваючи базу даних у запланованому завданні, скануючи з відомим кешем у коротких завданнях pull request та записуючи час оновлення бази даних поруч із дайджестом артефакту.

Trivy також надає архітектуру плагінів, що має операційне значення навіть тоді, коли іспит вимагає лише вбудованих команд. Плагінами керують через підкоманди trivy plugin, а trivy plugin list — це швидка перевірка інвентарю розширень, встановлених у поточному середовищі. Плагін може додати обробку виводу або поведінку інтеграції, але це також код, який виконується в межах довіри сканера. У захищеному конвеєрі встановлення плагінів має бути версійованим, переглянутим та кешованим, як і будь-яка інша залежність збирання, замість того, щоб завантажуватися динамічно всередині кожного завдання сканування.

trivy plugin list
trivy plugin install github.com/aquasecurity/trivy-plugin-referrer
trivy plugin list

Шлях даних від першоджерел навмисно широкий. Репозиторій vuln-list від Aqua відстежує NVD, GitHub Advisory Database, GitLab Advisory Database, Debian Security Tracker, Ubuntu CVE Tracker, Alpine secdb, Amazon Linux Security Center, Red Hat OVAL та Security Data, SUSE CVRF, Oracle Linux OVAL, AlmaLinux, Rocky Linux, Arch Linux, Photon OS та інші стрічки вендорів. Посібник з вразливостей Trivy також документує джерела мовних екосистем, такі як GitHub Advisory Database для Composer, pip, RubyGems, npm, Maven, Go, NuGet та Pub, а також стрічки вендорів ОС та офіційну стрічку CVE Kubernetes для компонентів Kubernetes. Тому результат — це збіг пакета з попередженням, а не незалежний доказ експлуатації.

Конвеєр бази даних — це не проста копія NVD. Корисний результат сканера потребує ідентифікатора попередження, ураженого пакета чи екосистеми, діапазонів вразливих версій та достатнього контексту джерела, щоб зіставити це попередження з тим, що Trivy знайшов в образі чи файловій системі. Процес збирання бази даних Aqua пакує записи першоджерел в артефакти бази даних, що розповсюджуються через OCI, а метадані trivy-db використовують 24-годинний інтервал оновлення як звичайну межу свіжості. На практиці CVE може з’явитися через NVD, попередження вендора ОС, GHSA, попередження мовної екосистеми або дослідження Aqua, щойно з’являється придатне для дій зіставлення пакетів. Коли ці джерела не збігаються, Trivy може все одно показати знахідку, але джерело серйозності та поля виправленої версії стають частиною доказів, які ви маєте читати.

Середовища з повітряним зазором (air-gapped) зазвичай дзеркалять артефакти бази даних OCI, а не очікують, що кожен раннер дотягнеться до публічних реєстрів Aqua. Платформенна команда може скопіювати trivy-db, trivy-java-db та trivy-checks у внутрішній реєстр, а потім спрямувати сканування на це дзеркало за допомогою --db-repository, --java-db-repository та --checks-bundle-repository там, де це потрібно. Завдання дзеркалювання є контрольованим компонентом, повернутим до інтернету; кластер або раннер CI споживає лише схвалений внутрішній артефакт. Цей дизайн також дає аудиторам стабільну відповідь на питання «яку базу даних попереджень використало це сканування», тому що дайджест дзеркала та позначку часу оновлення можна записати разом зі звітом сканування.

Image layers or filesystem
        |
        v
Package discovery
  OS packages, lock files, JARs, binaries, language dependencies
        |
        v
Trivy DBs
  trivy-db, trivy-java-db, trivy-checks
        |
        v
Advisory sources
  NVD, GHSA, OS vendors, language ecosystems, Kubernetes CVE feed
        |
        v
Report
  vulnerability ID, package, installed version, fixed version, severity

Свіжість бази даних створює важливу іспитову та виробничу звичку: читайте час сканування та розумійте, чи була оновлена база даних. trivy image --download-db-only прогріває базу даних вразливостей без сканування, тоді як --skip-db-update використовує кешовану базу даних і уникає мережевого завантаження. Це корисно в CI з повітряним зазором або коли завдання оновлення кешу основної гілки щодня оновлює базу даних, але це ризиковано, якщо кожне завдання пропускає оновлення назавжди. Кешоване сканування може бути повторюваним і все одно пропустити нещодавно опубліковане попередження.

Налаштування кешу та паралелізму — це засоби контролю продуктивності, а не виправдання для приховування знахідок. --cache-dir дозволяє раннеру зберігати дані бази даних та кешу сканування між завданнями, а спільний кеш може прибрати більшу частину витрат із повторюваних сканувань pull request. --parallel контролює одночасність сканера, де нижчі значення допомагають раннерам з обмеженою пам’яттю, а вищі значення допомагають більшим раннерам швидше обробляти шари. CI-патерн із високим сигналом — прогріти базу даних один раз, просканувати кілька образів із прогрітого кешу та тримати ключ кешу прив’язаним до версії Trivy плюс метаданих бази даних. Якщо завдання сліпо видаляє кеш щоразу, воно витрачає час на завантаження тих самих доказів; якщо воно ніколи не оновлює кеш, воно дає відполірований звіт зі старими фактами.

Типове сканування образу Trivy також вмикає сканування секретів, що може зробити перші сканування повільнішими та може здивувати команди, які очікують лише виводу про CVE. Для перевірок вразливостей лише образу в тісному циклі CI --scanners vuln звужує роботу до вразливостей; для ширшої перевірки ланцюга постачання тримайте сканування секретів та перевірки неправильних конфігурацій в окремих завданнях з окремими відповідальними. Змішування всіх перевірок безпеки в один бар’єр часто дає незрозумілі збої, тоді як їх розділення тримає код виходу прив’язаним до рішення, яке ви насправді хочете автоматизувати.

Читання серйозності та CVSS без надмірної реакції

CVSS v3.1 — це стандартизований спосіб повідомляти характеристики вразливостей, але це не повне рішення щодо розгортання. FIRST визначає якісні діапазони серйозності так: Low від 0.1 до 3.9, Medium від 4.0 до 6.9, High від 7.0 до 8.9 та Critical від 9.0 до 10.0, з рядком вектора, що пояснює метрики, які дали оцінку. Trivy повідомляє про серйозність як LOW, MEDIUM, HIGH та CRITICAL, а довідка v0.70.0 підтверджує --severity HIGH,CRITICAL як синтаксис фільтра.

Рядок вектора — це те, де CVSS стає корисним для сортування. AV — це вектор атаки, тому AV:N означає досяжність через мережу, тоді як AV:L означає, що потрібен локальний доступ. AC — це складність атаки, PR — необхідні привілеї, UI — взаємодія з користувачем, S — чи перетинає експлуатація межу області безпеки, а C, I та A описують вплив на конфіденційність, цілісність та доступність. Перевірений приклад з NVD — це запис про компрометацію екосистеми Trivy, який містить вектор CVSS v3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H та базову оцінку High. Читайте це як: досяжний через мережу, низька складність, потрібні певні привілеї, без взаємодії з користувачем, незмінна область та високий вплив на конфіденційність, цілісність і доступність. Це пояснює, чому подія була операційно серйозною, навіть якщо оцінка v3.1 є High, а не Critical.

Нюанс полягає у виборі джерела. Trivy може використовувати специфічні для вендора оцінки серйозності, тому що вендори ОС переносять виправлення (backport) та оцінюють пакети в контексті свого дистрибутива. Оцінка NVD може описувати програмне забезпечення першоджерела загальним чином, тоді як Debian, Red Hat, Ubuntu чи Alpine можуть оцінювати пакет інакше на основі параметрів компіляції, перенесень або уражених шляхів коду. Trivy надає --vuln-severity-source, коли вам потрібен пріоритет джерела, але безпечніше типове рішення для тих, хто навчається, — читати SeveritySource у виводі JSON та порівнювати його з родиною пакетів, перш ніж перевизначати логіку сканера.

CVSS та можливість експлуатації розходяться, тому що CVSS описує властиві характеристики вразливості, а не те, чи використовують зловмисники цю ваду проти вашого розгортання сьогодні. Каталог відомих експлуатованих вразливостей (KEV) від CISA — це сигнал того, що спостерігалася реальна експлуатація і що ураженим організаціям потрібно термінове втручання. EPSS — це ймовірнісний сигнал щодо ймовірності експлуатації в дикій природі. Критична знахідка без досяжного шляху коду, без відкритого інтерфейсу, із сильною ізоляцією та без телеметрії експлойтів може мати нижчий безпосередній пріоритет, ніж знахідка High у CISA KEV, що сидить у публічному раннері збирання. Жоден із сигналів не замінює інженерного судження, але обидва допомагають уникнути поширеної помилки сортування лише за найбільшим числом у таблиці сканера.

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

Знахідка Medium може бути неприйнятною, коли вона лежить на чутливому шляху даних або межі ланцюга постачання. Вада парсера з оцінкою medium в образі, що обробляє ненадійні завантаження, вада обробки секретів з оцінкою medium в образі помічника CI або проблема пакета з оцінкою medium у контролері допуску можуть нести більший операційний ризик, ніж критична вада в неактивному пакеті. Саме тому зрілі бар’єри поєднують серйозність із наявністю виправленої версії, сигналами експлойтів, експозицією активу, досяжністю пакета та роллю робочого навантаження. Іспит CKS часто винагороджує таке міркування, тому що сліпе видалення кожної знахідки повільніше за визначення тих кількох знахідок, які насправді блокують розгортання.

Два реальні CVE показують, чому ідентифікатори потрібно перевіряти, а не вигадувати. NVD перелічує CVE-2021-44228 (Log4Shell, канонічний опис у DevSecOps) з CVSS v3.1 10.0 Critical. NVD перелічує CVE-2024-3094 (бекдор xz-utils, канонічний у ланцюзі постачання KCSA) з CVSS v3.1 10.0 від Red Hat CNA. У 2026 році NVD також перелічує CVE-2026-33634 для компрометації ланцюга постачання екосистеми Trivy, з CVSS v3.1 8.8 High та посиланнями на попередження вендора Aqua. Ці приклади корисні саме тому, що ідентифікатори CVE, уражені продукти та оцінки можна перевірити в NVD, а не скопіювати з таблиці сканера.

# Human-readable triage view.
trivy image --severity HIGH,CRITICAL nginx:1.27

# Machine-readable evidence for review or dashboards.
trivy image --format json --output trivy-nginx.json nginx:1.27

# Narrow to fixed high-impact vulnerabilities for a fast rebuild gate.
trivy image --ignore-unfixed --severity HIGH,CRITICAL nginx:1.27

Зупиніться та спрогнозуйте: за вектором AV:N/AC:L/PR:L на образі пакетного завдання без мережевого вихідного трафіку, вразливий пакет присутній, але демон, що його використовує, ніколи не запускається, а простір імен блокує підвищення привілеїв — чи заблокували б ви розгортання лише через критичну серйозність, чи спершу вам потрібно більше доказів? Сильна відповідь називає те, що ще потрібно перевірити: підтвердити серйозність із SeveritySource та NVD, а не довіряти одному рядку сканера, довести, що ланцюг атаки недосяжний у цьому робочому навантаженні, та вирішити, чи виправдовують компенсаційні засоби контролю обмежений у часі виняток замість негайного перезбирання.

Бар’єр серйозності має бути нудним, передбачуваним та задокументованим. Поширена політика — провалювати нові образи на виправлених критичних вразливостях, попереджати про знахідки High та вимагати тікет або обмежений у часі виняток для будь-якого прийнятого ризику. Інша поширена політика провалює і на High, і на Critical лише для сервісів, доступних з інтернету, або для виробничих просторів імен, тоді як внутрішні пакетні завдання отримують коротше вікно попередження замість негайного блокування. Правильна відповідь залежить від експозиції активу, наявності виправлення, бізнес-критичності, зрілості експлойта та того, чи насправді досяжний вразливий пакет.

Сканування образів, реєстрів, кластерів, маніфестів та чартів Helm

Почніть з образу, який насправді запуститься. Trivy може сканувати образ з локального рушія контейнерів, віддаленого реєстру або архіву tar, а прапорець --image-src дозволяє надати пріоритет джерелам, таким як Docker, containerd, Podman та віддалені реєстри. Прапорець --input сканує збережений архів tar, що корисно, коли система збирання експортує артефакт образу перед завантаженням. Відповідь CKS має показати правильну ціль: сканування Dockerfile або репозиторію корисне, але це не те саме, що сканування фінальних шарів образу після збирання.

# Scan a remote registry image by reference.
trivy image registry.k8s.io/pause:3.10

# Scan a locally built image tag if your container engine has it.
trivy image my-api:dev

# Scan an exported image archive.
docker save my-api:dev -o my-api-dev.tar
trivy image --input my-api-dev.tar

# Use registry credentials without placing the password in shell history.
printf '%s\n' "$REGISTRY_PASSWORD" | trivy image \
  --username "$REGISTRY_USER" \
  --password-stdin \
  registry.example.com/team/my-api:1.2.3

Сканування реєстрів — це те, де автентифікація та дисципліна тегів стають частиною безпеки. Сканер, що завантажує latest, може не перевірити той самий дайджест, який пізніше розгорне допуск, а сканер, що використовує широкі облікові дані реєстру, може стати цінним секретом CI. Надавайте перевагу незмінним дайджестам або тегам релізів, автентифікуйтеся за допомогою токена лише для читання, обмеженого репозиторієм, який сканується, та публікуйте результат сканування поруч із артефактом, який він описує. Корисний запис — це «дайджест X було просканувано з версією бази даних Y у час Z», а не «конвеєр колись просканував ім’я, яке тепер може вказувати на інше».

Розширені опції сканування слід вибирати, виходячи з питання про робоче навантаження, на яке ви намагаєтеся відповісти. --scanners vuln — це швидкий бар’єр CVE для виробничого образу. --scanners vuln,secret — це розумна перевірка для розробника на шарах образу, які можуть випадково містити облікові дані. --scanners vuln,misconfig,secret,license ширший і корисний для реліз-кандидата, тому що він питає про вразливі пакети, оголошену конфігурацію, витоки секретів та знахідки щодо ліцензій за один запуск. Ім’я сканера для знахідок конфігурації — це misconfig у поточній довідці Trivy, навіть якщо підкоманда для сканування маніфестів — це trivy config. Ця відмінність має значення в скриптах, тому що неправильне ім’я сканера перетворює рішення щодо політики на команду, що зазнає невдачі, замість корисного звіту.

--skip-dirs та --skip-files — це гострі інструменти. Вони доречні, коли контекст збирання містить згенеровані тестові фікстури, вендорні зразкові архіви або змонтовані каталоги кешу, що не є частиною придатного для розгортання артефакту. Вони небезпечні, коли використовуються для приглушення «галасливих» каталогів без доведення відсутності цих файлів у production. Надмірне пропускання нівелює сканування, тому що сканер може міркувати лише про файли, які йому дозволено перевіряти. Рецензент має бути здатний прочитати кожен патерн пропускання та зрозуміти, чи прибирає він нерозгорнуті тестові дані, кеш інструмента або реальну частину образу.

--ignore-policy переносить логіку винятків із плоского файлу ігнорування до Rego, що корисно, коли рішення щодо списку дозволів залежить від таких полів, як тип знахідки, ім’я пакета, шлях або статус. Trivy оцінює пакет Rego з ім’ям trivy із правилом ignore проти кожної знахідки. Консервативна політика ігнорує лише вузькі випадки, які ваша команда може пояснити, наприклад класифікацію ліцензії для шляху файлу, що ніколи не постачається, або вразливість у пакеті, що існує лише в задокументованому шляху, доступному лише під час збирання. Політика має лежати в репозиторії, проходити рев’ю коду та експортуватися разом із доказами сканування, тому що вона є частиною рішення щодо безпеки.

Для VEX використовуйте поточний робочий процес Trivy керування репозиторіями VEX за допомогою команд trivy vex repo та передавання джерел VEX за допомогою --vex, наприклад --vex repo для тверджень, підкріплених репозиторієм. Мета — нести інформацію про можливість експлуатації як машиночитні докази замість того, щоб ховати її в коментарі до тікета. Твердження VEX може казати, що продукт не уражений, виправлений, досліджується або уражений у конкретному контексті. У сортуванні це питання про підмножину, що активно експлуатується: які збіги пакетів представляють реальну експозицію продукту, а які збіги пакетів присутні, але заблоковані досяжністю, конфігурацією збирання або засобами контролю під час виконання.

# Broad release-candidate scan across vulnerability, config, secret, and license signals.
trivy image --scanners vuln,misconfig,secret,license registry.example.com/team/api:1.2.3

# Skip only known non-shipped fixtures or caches, and document the reason in review.
trivy fs --scanners vuln,secret --skip-dirs test/fixtures/vendor-cache .
trivy image --skip-files usr/share/doc/example/sample-key.pem my-api:dev

# Use reviewed Rego policy and VEX evidence for narrow, auditable suppressions.
trivy image --ignore-policy policy/trivy-ignore.rego my-api:dev
trivy image --vex repo my-api:dev

Сканування кластера Kubernetes відповідає на інше питання: що працює зараз? Trivy v0.70.0 надає trivy k8s з опціями, такими як --include-namespaces, --exclude-namespaces, --report summary, --report all, --skip-images та --kubeconfig. Це цінно, тому що виробничі кластери можуть містити старі ReplicaSet, CronJob, ініціалізаційні контейнери, sidecar-контейнери, впроваджені після CI, та образи, розгорнуті вручну, що ніколи не проходили через очікуваний конвеєр. Воно також операційно чутливіше, тому що сканування кластера може створювати завдання збирача вузлів (node collector), якщо не налаштовано інакше.

# Scan the current kubeconfig context and summarize findings.
trivy k8s --report summary

# Limit the scan to one namespace for a focused production review.
trivy k8s --include-namespaces payments --report summary

# Include all report details when exporting evidence for later analysis.
trivy k8s --include-namespaces payments --report all \
  --format json --output trivy-payments-k8s.json

# Scan Kubernetes objects without pulling workload images.
trivy k8s --skip-images --report summary

trivy k8s не є заміною для посканувань образів у CI. Команда кластера працює на основі виявлення через API Kubernetes та інвентарю робочих навантажень, тому вона може знаходити образи, що насправді працюють, об’єкти, що порушують перевірки Kubernetes, та дрейф між оголошеними конвеєрами та живим станом. Сканування на рівні образу краще для детермінованого бар’єра збирання, тому що воно сканує артефакт перед розгортанням і може провалити саме той конвеєр, що його створив. Використовуйте обидва, коли це можливо: сканування конвеєра не дає відомо поганим артефактам потрапити в реєстр, а сканування кластера ловить застарілі розгортання, ручні зміни, впроваджені sidecar-контейнери та робочі навантаження, що з’явилися до того, як бар’єр почав існувати.

Сканування на рівні всього кластера та обмежене простором імен мають різні наслідки для RBAC. Сканування всього кластера потребує дозволу перелічувати багато типів ресурсів у різних просторах імен і може потребувати доступу до ресурсів на рівні кластера, тому його має запускати навмисно обмежений сервісний акаунт, а не людський токен адміністратора, скопійований у CI. Сканування, обмежене простором імен, безпечніше для команди застосунку, тому що воно обмежує виявлення межею команди, але воно може пропустити об’єкти політик рівня кластера, конфігурацію допуску, CRD та робочі навантаження поза простором імен, що все одно впливають на застосунок. Для практики CKS припускайте, що дозволи сервісного акаунта є частиною відповіді: доведіть, що ви можете перелічити, скануйте лише запитаний обсяг та уникайте запиту cluster-admin, коли завдання просить лише один простір імен.

Зупиніться та спрогнозуйте: іспитове завдання дає вам обмежену простором імен Role, що може перелічувати Pod-и та Деплойменти в payments, але нічого на рівні кластера. Чи може ця ідентичність успішно запустити trivy k8s --include-namespaces payments --report summary, та які об’єкти кластера сканування може пропустити, навіть коли воно успішне? Корисна звичка — зіставити потреби виявлення сканера з дієсловами (verbs) RBAC, перш ніж припускати, що команда побачить усю картину ризику.

Користувацькі ресурси (custom resources) та ресурси на рівні кластера відрізняються від Pod-ів, тому що вони можуть описувати контролери, політики або поведінку допуску, а не виконувані контейнери. Специфікація Pod відкриває імена образів, контекст безпеки, томи, сервісний акаунт та налаштування виконання. Екземпляр CRD може представляти правило контролера Ingress, абстракцію мережевої політики, видавця сертифікатів або специфічний для платформи об’єкт розгортання, що пізніше непрямо створює Pod-и. Ресурси на рівні кластера, такі як ClusterRole та CRD, також впливають на кілька просторів імен, тому неправильна конфігурація там може створити широку експозицію, навіть коли кожен Pod у поточному просторі імен виглядає прийнятно. Звіт сканера має відокремлювати вразливі образи робочих навантажень від небезпечної конфігурації кластера, тому що відповідальний за усунення часто інший.

KubeBench, KubeHunter та KubeAudit відповідають на суміжні питання. KubeBench перевіряє, чи відповідають компоненти кластера CIS Kubernetes Benchmark, тому він найсильніший для доказів посилення безпеки площини управління та вузлів. KubeHunter ближчий до тестування на проникнення та шукає зовнішньо спостережувані шляхи атак Kubernetes, тому його ризикованіше запускати проти production без авторизації. KubeAudit перевіряє ресурси Kubernetes на поширені засоби контролю робочих навантажень, такі як запуск не від імені root, файлові системи root лише для читання, capabilities та привілейовані налаштування. Trivy найбільше прямо перетинається з KubeAudit для перевірок маніфестів та об’єктів кластера, менше перетинається з фокусом KubeBench на бенчмарках та не має трактуватися як прихований інструмент тестування на проникнення.

Сканування маніфестів та Helm ловить ризики, які зіставлення CVE не може побачити. trivy config ./manifests сканує YAML Kubernetes, Dockerfile, Terraform, Helm та інші формати IaC на перевірки неправильних конфігурацій. Для Helm Trivy обчислює шаблони зі значеннями та прапорцями, такими як --helm-values, --helm-set, --helm-set-string, --helm-set-file та --helm-kube-version, у маніфести Kubernetes, а потім запускає перевірки Kubernetes над згенерованими маніфестами. Це правильна модель для CKS: образ може мати нуль відомих CVE і все одно працювати від імені root, монтувати сокет Docker, використовувати мережу хоста або розгортати привілейований контейнер.

# Scan raw Kubernetes YAML for misconfigurations.
trivy config ./manifests

# Render a Helm chart with production values before scanning.
trivy config --helm-values values-prod.yaml ./charts/my-api

# Scan a repository filesystem for vulnerabilities, secrets, and config issues.
trivy fs --scanners vuln,secret,misconfig .

Практичний робочий процес багаторівневий. Скануйте фінальний образ перед завантаженням, скануйте завантажений дайджест перед розгортанням, скануйте згенеровані маніфести перед застосуванням та періодично скануйте кластер, щоб знайти дрейф. Кожен рівень має інший режим збою: сканування перед завантаженням ловлять проблеми образів розробників, сканування реєстру прив’язують докази до придатного для розгортання артефакту, сканування маніфестів ловлять небезпечну конфігурацію Kubernetes, а сканування кластера розкривають те, що уникнуло конвеєра. Трактуйте ці рівні як взаємодоповнювані, а не просіть одну команду Trivy довести, що весь ланцюг постачання безпечний.

Гейтинг CI/CD за допомогою GitHub Actions та GitLab CI

У GitHub Actions офіційний README aquasecurity/trivy-action документує входи, такі як image-ref, scan-type, scan-ref, format, exit-code, ignore-unfixed, vuln-type та severity. Приклади в README дії можуть використовувати тег версії, але компрометація екосистеми Trivy в березні 2026 року — це вагома причина закріплювати (pin) чутливі до безпеки сторонні дії за повним SHA коміту та оновлювати цей SHA навмисно. SHA нижче — це ціль тегу v0.36.0, спостережена за допомогою git ls-remote під час цього оновлення модуля, а не змінний рядок v0.36.0. Реальна організація має оновлювати цей SHA через обслуговування залежностей та переглядати нотатки до релізу перед зміною робочого процесу.

name: image-security
on:
  pull_request:
  push:
    branches:
      - main

jobs:
  trivy:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      security-events: write
      packages: write
      id-token: write
    strategy:
      fail-fast: false
      matrix:
        include:
          - image: my-api
            context: services/api
            dockerfile: services/api/Dockerfile
          - image: my-worker
            context: services/worker
            dockerfile: services/worker/Dockerfile
    steps:
      - name: Checkout
        uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd  # v5.0.1

      - name: Build image
        run: |
          IMAGE="ghcr.io/${{ github.repository }}/${{ matrix.image }}:${{ github.sha }}"
          docker build \
            --file "${{ matrix.dockerfile }}" \
            --tag "$IMAGE" \
            "${{ matrix.context }}"

      - name: Scan image with Trivy
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25  # v0.36.0
        with:
          image-ref: ghcr.io/${{ github.repository }}/${{ matrix.image }}:${{ github.sha }}
          format: sarif
          output: trivy-${{ matrix.image }}.sarif
          exit-code: "1"
          ignore-unfixed: true
          vuln-type: os,library
          severity: CRITICAL,HIGH

      - name: Upload SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@458d36d7d4f47d0dd16ca424c1d3cda0060f1360  # v3
        with:
          sarif_file: trivy-${{ matrix.image }}.sarif

      - name: Log in to GitHub Container Registry
        if: github.event_name == 'push'
        run: echo "${{ github.token }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin

      - name: Push scanned image
        if: github.event_name == 'push'
        run: docker push "ghcr.io/${{ github.repository }}/${{ matrix.image }}:${{ github.sha }}"

      - name: Install cosign
        if: github.event_name == 'push'
        uses: sigstore/cosign-installer@d58896d6a1865668819e1d91763c7751a165e159  # v3.9.2

      - name: Sign pushed digest
        if: github.event_name == 'push'
        env:
          COSIGN_YES: "true"
        run: |
          IMAGE="ghcr.io/${{ github.repository }}/${{ matrix.image }}:${{ github.sha }}"
          DIGEST="$(docker inspect --format='{{index .RepoDigests 0}}' "$IMAGE")"
          cosign sign "$DIGEST"

Цей робочий процес навмисно суворий, але не чарівний. exit-code: "1" означає, що дія провалюється, коли знахідки збігаються з вибраними сканерами, рівнями серйозності та іншими фільтрами; це не означає, що кожен можливий ризик усунено. --exit-code 1 --severity HIGH,CRITICAL у CLI має те саме значення політики: команда повертає вибраний ненульовий код виходу лише тоді, коли знахідки High або Critical залишаються після фільтрації. ignore-unfixed: true зіставляється з фільтрацією невиправлених вразливостей Trivy та зменшує шум від знахідок, де дані джерела не мають виправленої версії пакета, але це також може приховати термінові проблеми, де правильною дією є зміна базового образу, видалення пакета або застосування пом’якшення від вендора. Використовуйте це, щоб уникнути блокування кожного збирання на невиправному беклозі, а не для уникнення сортування.

Порядок «сканувати, підписати та завантажити» заслуговує на точність. Намір щодо безпеки — «сканувати перед публікацією довіреного артефакту», але підписи cosign зазвичай прикріплюються до посилань реєстру та дайджестів. Практичний робочий процес — зібрати локальний тег, просканувати цей тег, завантажити лише після проходження бар’єра сканування, визначити завантажений дайджест, а потім підписати дайджест. Політика допуску може пізніше вимагати дійсний підпис на дайджесті, тоді як політика вразливостей записує докази SARIF чи JSON, що виправдали завантаження. Якщо робочий процес підписує до бар’єра сканера або завантажує до того, як стане відомий результат сканування, системи нижче за течією можуть спостерігати артефакт, який конвеєр пізніше відхиляє.

Зупиніться та спрогнозуйте: якщо ви переупорядкуєте кроки GitHub Actions так, щоб завантажувати до сканування Trivy, підписувати одразу після завантаження та лише потім провалювати завдання на критичних знахідках, що може спостерігати споживач реєстру протягом хвилин між завантаженням та збоєм? Відповідь має згадати вразливий або непереглянутий дайджест, що вже опублікований, підпис, що засвідчує неправильний момент у конвеєрі, та системи допуску, що можуть завантажити артефакт до завершення бар’єра.

Завантаження SARIF перетворює одноразовий журнал CI на аудиторський слід у вкладці Security на GitHub. Корисний потік сортування — завантажувати SARIF на кожному запуску, провалювати завдання лише на порозі політики, призначати відповідального за нові знахідки та закривати знахідки шляхом перезбирання або документування обмеженого в часі винятку. Зберігання має значення, тому що результати сканування описують момент у часі: дайджест образу, версію Trivy, метадані бази даних, SHA робочого процесу та точні налаштування бар’єра. Майбутній рецензент має бути здатний відповісти, чи було розгортання прийнято, тому що не було збігів знахідок, тому що знахідку було невиправлено та відфільтровано, чи тому що явна політика списку дозволів приховала її.

GitLab має два поширені патерни. Власна документація GitLab щодо сканування контейнерів каже, що аналізатор сканування контейнерів використовує Trivy та передає змінні середовища Trivy, тоді як документація Trivy також показує пряме завдання GitLab CI з використанням образу aquasec/trivy. Вбудований шаблон простіший для інтеграції з GitLab Security Dashboard; пряме завдання простіше для репозиторіїв з відкритим кодом або користувацьких звітів. В обох випадках тримайте завдання прив’язаним до дайджесту або тегу образу, створеного тим самим етапом конвеєра.

stages:
  - build
  - scan
  - publish

variables:
  IMAGE_REF: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

build_image:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  script:
    - docker build -t "$IMAGE_REF" .
    - docker save "$IMAGE_REF" -o image.tar
  artifacts:
    paths:
      - image.tar

trivy_image_scan:
  stage: scan
  image:
    name: docker.io/aquasec/trivy:0.70.0
    entrypoint: [""]
  services:
    - docker:27-dind
  variables:
    TRIVY_CACHE_DIR: "$CI_PROJECT_DIR/.trivy-cache"
  cache:
    key: "trivy-0.70.0"
    paths:
      - .trivy-cache/
  script:
    - docker load -i image.tar
    - trivy image --download-db-only
    - trivy image --format json --output "trivy-${CI_COMMIT_SHA}.json" "$IMAGE_REF"
    - trivy image --exit-code 1 --ignore-unfixed --severity HIGH,CRITICAL "$IMAGE_REF"
  artifacts:
    when: always
    expire_in: 30 days
    paths:
      - "trivy-${CI_COMMIT_SHA}.json"
      - image.tar

push_image:
  stage: publish
  image: docker:27
  services:
    - docker:27-dind
  needs:
    - job: trivy_image_scan
      artifacts: true
  script:
    - docker load -i image.tar
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
    - docker push "$IMAGE_REF"

Проєктуйте бар’єри навколо доменів збоїв. Глобальний бар’єр Critical може зупинити кожен сервіс в організації, коли широко вживаний базовий образ отримує нове попередження, тому зрілі команди відокремлюють «нововведене цією зміною» від «наявний беклог» і підтримують аварійний шлях для хибнопозитивних спрацювань або недоступних виправлень. Аварійний шлях має бути придатним для аудиту: хто схвалив виняток, який ідентифікатор CVE чи попередження він покриває, коли він закінчується та який компенсаційний засіб контролю чи план перезбирання існує. Бар’єр сканера без процесу винятків буде обійдено, коли він блокує реальну доставку, тоді як бар’єр сканера без політики коду виходу дає привабливі звіти, яких нікому не треба дотримуватися.

Матричне сканування — це CI-патерн, що не дає спільним репозиторіям ховати ризик за одним образом «щасливого шляху». Монорепозиторій може збирати образ API, образ фонового процесу, образ міграції та образ налагодження з різних Dockerfile. Якщо матриця сканує лише API, реліз все одно може завантажити вразливий образ процесу, що обробляє корисне навантаження черги, або образ міграції з широкими привілеями бази даних. Дайте кожному запису матриці чітке ім’я образу, контекст, Dockerfile, файл виводу сканування та відповідального. Коли один запис провалюється, команда має знати, чи перезбирати базовий образ, оновити залежність застосунку, чи видалити пакет з виробничого етапу.

Обробка хибнопозитивних спрацювань та прийнятого ризику

Обробка хибнопозитивних спрацювань починається з називання доказів, а не з приховування знахідки. Рядок вразливості Trivy зазвичай містить ідентифікатор вразливості, ім’я пакета, встановлену версію, виправлену версію, серйозність, основну URL-адресу та інформацію про джерело. Перш ніж приховати її, спитайте, чи походить пакет від виявленого вендора ОС, чи існує виправлена версія в репозиторії пакетів образу, чи досяжний вразливий код, та чи насправді працює образ у середовищі, що переглядається. Серйозність від вендора та перенесення пакетів (backports) — поширені причини видимої невідповідності між сканерами.

Trivy підтримує кілька механізмів приховування. Класичний файл .trivyignore приховує ідентифікатори знахідок для каталогу сканування, а --ignorefile вибирає нетиповий файл ігнорування. Новіший формат .trivyignore.yaml може нести структуровані записи ігнорування та метадані терміну дії, але документація щодо фільтрації Trivy зазначає, що явне використання --ignorefile ./.trivyignore.yaml є необхідним, поки функція все ще експериментальна. Для складніших випадків --ignore-policy оцінює політику Rego проти кожної знахідки, а VEX може стверджувати, що вразливість не може бути експлуатована в конкретному контексті продукту.

# Accept until 2026-06-30: package present in debug-only image, not deployed.
CVE-2023-48795

vulnerabilities:
  - id: CVE-2026-33634
    paths:
      - "ci/trivy-runner-image"
    statement: "Historical runner image retained only for forensic rebuilds."
    expired_at: "2026-06-30"

Наведені вище приклади ідентифікаторів — це реальні CVE, але причини приховування навмисно є лабораторними прикладами. У виробничому репозиторії ніколи не копіюйте запис ігнорування з посібника в живу політику. Перевірте CVE в NVD або попередженні вендора, доведіть, що уражений пакет присутній у просканованому артефакті, та напишіть причину, яку рецензент може перевірити. Корисний список дозволів закінчується; небезпечний список дозволів є постійним, широким та відірваним від відповідальності. Критичні знахідки ланцюга постачання, такі як CVE-2024-3094 (бекдор xz-utils, NVD CVSS v3.1 10.0 Critical), не повинні з’являтися у звичайному файлі ігнорування без відповідальності за реагування на інциденти на рівні керівництва, тому що приховування підтвердженого бекдору — це принципово інше рішення, ніж прийняття слабкості протоколу з оцінкою medium у невиробничому образі налагодження.

VEX краще, ніж голе ігнорування, коли вам потрібен машиночитний контекст можливості експлуатації між інструментами. Якщо бібліотека присутня, але вразлива функція недосяжна, твердження VEX може казати, що продукт не уражений, та пояснити обґрунтування. Це не прибирає CVE з історії, і це не означає, що кожен сканер автоматично прийме твердження. Воно дає командам безпеки, платформи та застосунку структурований спосіб відокремити «пакет присутній» від «ризик експлуатований тут» без втрати придатності до аудиту.

Порівняння Trivy з Grype, Clair, Snyk, Copa та Aqua Platform

Trivy та Grype — це обидва потужні сканери з відкритим кодом для образів контейнерів та файлових систем, і обидва можуть сканувати SBOM. Grype тісно поєднаний із Syft для генерації SBOM та наголошує на функціях пріоритизації ризику, таких як EPSS, KEV та підтримка OpenVEX. Trivy має ширшу комплексну поверхню для кластерів Kubernetes, маніфестів Kubernetes, чартів Helm, секретів, ліцензій, SBOM та перевірок неправильних конфігурацій з одного CLI. Для CKS Trivy — найзручніший для іспиту інструмент, тому що один бінарний файл покриває шляхи сканування образів та Kubernetes, які вам потрібно практикувати.

Порівняння інструментів має залишатися якісним, якщо у вас немає відтворюваного бенчмарку для ваших власних образів. Швидкість залежить від розміру образу, екосистеми пакетів, розкладки залежностей мови, мережевого доступу до баз даних, прогрітості кешу та формату виводу. Хибнопозитивні спрацювання залежать від зіставлення джерел, перенесень вендора, виявлення пакетів та того, чи оптимізує сканер точне чи всеохопне виявлення. Таблиця нижче — це практичний посібник з вибору, а не універсальне вимірювання. На іспиті вибір уже Trivy; у production корисне порівняння — це чи інтегрується інструмент з вашим реєстром, процесом SBOM, робочим процесом винятків та моделлю відповідальності за безпеку.

Інструмент	Швидкість	Свіжість БД	Поведінка з хибнопозитивами	Формати виводу SBOM
Trivy	Швидкий із прогрітою БД та кешем; широкі сканери додають час.	БД, що розповсюджуються через OCI, із щоденним інтервалом метаданих та широкими стрічками вендорів.	Схиляється до точного зіставлення пакетів, з опціями серйозності від вендора та приховування Rego/VEX.	JSON, CycloneDX, SPDX, SPDX JSON та таблично-орієнтовані звіти.
Grype	Швидкий для сканувань образів та SBOM, особливо в парі зі згенерованими Syft SBOM.	Стрічка вразливостей Anchore плюс дані екосистеми, із сильними робочими процесами «SBOM-перш-за-все».	Сильні функції пріоритизації ризику, такі як EPSS, KEV та контекст VEX; результати все одно залежать від доказів на рівні пакетів.	JSON, CycloneDX, робочі процеси SBOM на основі SPDX через парування із Syft.
Snyk Container	Залежить від хостингової інтеграції та робочого процесу реєстру; сильний UX для розробників.	Свіжість сервісу під керуванням вендора та комерційні дані пріоритизації.	Комерційні поради щодо виправлень та контекст політики зменшують навантаження сортування, але знахідки все одно потребують контексту робочого навантаження.	Підтримка SBOM залежить від плану продукту та шляху інтеграції.
Clair	Створений для індексування у стилі реєстру та сповіщень, а не для разових локальних сканувань.	Свіжість стрічки прив’язана до розгорнутого оновлювача та індексатора Clair.	Хороший для безперервної переоцінки індексованих образів; менш зручний для разових завдань CKS.	Переважно інтеграція API/звітів навколо індексованих маніфестів, а не локальний робочий процес авторства SBOM.

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

Snyk Container — це комерційний продукт безпеки для розробників, що сканує образи контейнерів та надає інтеграції для репозиторіїв, реєстрів, Kubernetes та порад щодо виправлень. Він часто привабливий, коли команди вже використовують Snyk для ризику залежностей з відкритим кодом і хочуть хостинговий робочий процес навколо пріоритизації та усунення. Проєкт Copacetic, що зазвичай викликається як copa, не є сканером у тому самому сенсі; він застосовує патчі до образів контейнерів, оновлюючи пакети ОС на основі результатів сканування вразливостей. Це робить Copa супутником з усунення, а не заміною для сканування, перезбирання та походження.

Aqua Security також має комерційну платформу навколо хмарно-нативної безпеки, тоді як Trivy залишається сканером з відкритим кодом, що підтримується Aqua. Практична відмінність — це підтримка та покриття життєвого циклу. Trivy з відкритим кодом — це екосистема CLI та бібліотек для сканування цілей та продукування результатів. Комерційна пропозиція Aqua додає корпоративні платформенні можливості, такі як централізоване управління, покриття під час виконання та хмари, робочі процеси політик, звітність та комерційну підтримку. Використання Trivy не вимагає купівлі Aqua, а купівля Aqua не усуває потреби розуміти, що означає результат Trivy.

Чи знали ви?

База даних Trivy — це не лише NVD. vuln-list від Aqua містить NVD, GHSA, попередження GitLab, стрічки вендорів ОС та дані мовних екосистем, тоді як trivy-db пакує ці дані для використання сканером.
Компрометація екосистеми Trivy в березні 2026 року має власний запис у NVD. NVD перелічує CVE-2026-33634 для шкідливого коду, що уражає пов’язані з Trivy шляхи розповсюдження, а попередження Aqua описує скомпрометовані релізи та force-push теги дій.
--severity HIGH,CRITICAL та --exit-code 1 — це перевірені прапорці Trivy v0.70.0. Довідка команди image також підтверджує --input, --ignore-unfixed, --download-db-only, --skip-db-update та --ignorefile.
Сканування чарту Helm обчислює шаблони перед перевірками. Документація щодо покриття Helm у Trivy каже, що він обчислює змінні та функції Helm у маніфести Kubernetes, а потім застосовує перевірки Kubernetes до згенерованого артефакту.

Типові помилки

Помилка	Чому це трапляється	Як це виправити
Сприйняття чистого сканування образу як гарантії безпеки	Сканування CVE бачить відомі збіги пакетів, а не кожен шлях виконання, секрет, політику чи компрометацію ланцюга постачання.	Поєднуйте сканування образів зі скануванням маніфестів, політикою допуску, засобами контролю під час виконання, ритмом перезбирання та відстеженням артефактів на основі дайджестів.
Сканування `latest` замість розгорнутого дайджесту	Теги зручні, а приклади часто їх використовують.	Збирайте, завантажуйте, розгортайте та записуйте незмінні дайджести образів або теги релізів, прив’язані до конкретного запуску конвеєра.
Блокування кожного розгортання на всіх знахідках High	Команди копіюють суворий бар’єр без політики винятків чи беклогу.	Провалюйте на виправлених Critical або контекстно-специфічних знахідках High, відстежуйте наявний беклог окремо та вимагайте обмежених у часі схвалень для винятків.
Приховування CVE без відповідальності чи терміну дії	`.trivyignore` легко редагувати та важко переглядати пізніше.	Включайте CVE, уражений пакет, обґрунтування, того, хто схвалив, дату закінчення та подальший тікет у робочому процесі списку дозволів.
Запуск зі застарілими базами даних назавжди	Завдання CI з повітряним зазором або кешем часто встановлюють `--skip-db-update` і забувають про завдання оновлення.	Використовуйте запланований процес `--download-db-only` або дзеркалювання та записуйте свіжість бази даних у докази сканування.
Плутання сканування маніфестів зі скануванням образів	Обидві команди в одному інструменті, тому команди припускають, що вони відповідають на те саме питання.	Використовуйте `trivy image` для фінальних шарів образу, `trivy config` для YAML та Helm, а `trivy k8s` для поточного стану кластера.
Закріплення тегу GitHub Action після інциденту компрометації тегу	Теги версій легко читати та легко оновлювати інструментам.	Закріплюйте чутливі до безпеки сторонні дії за повними SHA коміту та оновлюйте їх через переглянуті зміни обслуговування залежностей.
Запуск сканувань без коду виходу, що провалюється	Звіт виглядає серйозно в журналах CI, але завдання завжди успішне.	Додайте `--exit-code 1` або вхід дії `exit-code: "1"` до бар’єра політики, а потім публікуйте JSON чи SARIF для сортування.

Тест

Конвеєр запускає trivy image --exit-code 1 --severity CRITICAL my-api:latest і проходить. Які два важливі ризики все одно можуть залишитися?

Відповідь
Тег образу може не бути незмінним артефактом, що насправді розгорнеться, а сканування блокує лише знахідки Critical, видимі поточній базі даних та конфігурації сканера Trivy. Знахідки High, неправильно сконфігуровані маніфести Kubernetes, витоки секретів, непідписані образи, експозиція під час виконання, застарілі бази даних та вразливі залежності без актуальних збігів CVE все одно можуть залишитися. Сильніший робочий процес сканує дайджест образу, записує свіжість бази даних, сканує згенеровані маніфести та застосовує політику під час допуску чи розгортання.
Чому Trivy, NVD та вендор ОС можуть не збігатися щодо серйозності для одного й того ж CVE?

Відповідь
NVD часто оцінює вразливість першоджерела загально, тоді як вендор ОС може враховувати параметри збирання пакета, перенесені патчі, вимкнені шляхи коду або специфічну для дистрибутива експозицію. Trivy може надавати перевагу джерелам серйозності від вендора для пакетів ОС та надає вибір джерела через `--vuln-severity-source`. Правильна реакція — читати джерело серйозності та родину пакетів, а не припускати, що найбільше число завжди є найкращим операційним пріоритетом.
Ваш робочий процес GitHub Actions використовує aquasecurity/trivy-action@v0.36.0. Чому рецензент безпеки може попросити повний SHA коміту замість цього?

Відповідь
Тег версії є змінним у Git і може бути force-push, якщо обліковий запис мейнтейнера або процес релізу скомпрометовано. Попередження Aqua за березень 2026 року щодо компрометації екосистеми Trivy описало force-push теги `trivy-action`, що робить закріплення за SHA практичним засобом контролю для чутливих до безпеки дій. Закріплення за SHA не усуває весь ризик ланцюга постачання, але робить переглянуте посилання на дію незмінним, доки репозиторій навмисно його не оновить.
Коли слід використовувати trivy config --helm-values values-prod.yaml ./charts/my-api замість trivy image my-api:1.2.3?

Відповідь
Використовуйте команду Helm, коли питання стосується згенерованої конфігурації Kubernetes, наприклад чи створює чарт привілейовані Pod-и, небезпечні монтування хоста, відсутні ліміти ресурсів чи інші неправильні конфігурації. Використовуйте команду image, коли питання стосується пакетів, залежностей, секретів, ліцензій чи вразливостей шарів образу у зібраному артефакті. Повний реліз-конвеєр зазвичай запускає обидві, тому що вони перевіряють різні поверхні безпеки.
Результат Trivy показує критичну CVE в пакеті, але стовпець виправленої версії порожній. Чи завжди конвеєр має провалюватися?

Відповідь
Не завжди. Порожня виправлена версія означає, що сканер не знає про доступне оновлення пакета для цього попередження у виявленому джерелі, тому негайне перезбирання може не прибрати знахідку. Команді все одно потрібне сортування: змінити базовий образ, видалити пакет, застосувати пом'якшення від вендора, додати обмежений у часі виняток або заблокувати, якщо експозиція достатньо серйозна. `--ignore-unfixed` може зменшити невиправний шум, але це має поєднуватися з процесом управління вразливостями для випадків з високим впливом.
Яка різниця між .trivyignore та твердженням VEX у зрілому робочому процесі управління вразливостями?

Відповідь
Запис `.trivyignore` приховує ідентифікатор знахідки для контексту сканування, зазвичай з обмеженою структурою, якщо команда не додає конвенцій рев'ю. Твердження VEX — це машиночитна інформація про можливість експлуатації, що пояснює, чи продукт уражений, не уражений, виправлений або досліджується для вразливості. VEX краще для крос-інструментальної придатності до аудиту, тоді як `.trivyignore` залишається корисним для локальних, ретельно переглянутих винятків.
Чому сканування кластера за допомогою trivy k8s доповнює сканування образів у CI, а не замінює його?

Відповідь
Сканування образів у CI перевіряє артефакт перед розгортанням, але кластери можуть дрейфувати через ручні розгортання, старі ReplicaSet, ініціалізаційні контейнери, впроваджені sidecar-контейнери, заплановані Job та образи, що передують поточному бар'єру. `trivy k8s` перевіряє те, що працює чи сконфігуровано через Kubernetes, що ловить прогалини в інвентарі під час виконання. Воно має бути ретельно обмежене прапорцями простору імен та звіту, щоб сканування було корисним без перевантаження операцій кластера.
Сканування знаходить CVE-2024-3094 (NVD CVSS v3.1 10.0 Critical, бекдор xz-utils) в образі, схваленому для офлайн-простору імен пакетних завдань без вихідного трафіку. Яка правильна послідовність сортування перед зміною бар’єрів?

Відповідь
Спершу перевірте серйозність із авторитетних джерел — прочитайте `SeveritySource` у виводі JSON та підтвердьте запис NVD — перш ніж трактувати знахідку як щось менше за Critical. Потім класифікуйте досяжність: чи насправді виконується уражений пакет у контейнері, та чи розривають компенсаційні засоби контролю (без вихідного трафіку, файлова система root лише для читання, виконання не від root, політика допуску) ланцюг атаки? Критичний бекдор в офлайн-просторі імен пакетних завдань все одно потребує набагато сильнішого обґрунтування, ніж знахідка Medium: відповідальності за реагування на інциденти на рівні керівництва, задокументованого плану перезбирання чи міграції базового образу з коротким терміном дії та явних доказів компенсаційних засобів контролю. Лише після цього перегляду слід розглядати обмежений у часі виняток у `.trivyignore.yaml` чи VEX, ніколи мовчазне приховування у плоскому файлі. Узгоджуйте бар'єр із ризиком простору імен, але не знижуйте критичні знахідки ланцюга постачання без перевіреної серйозності та відповідальності.

Практична вправа

Ця вправа призначена для одноразової робочої станції та лабораторного кластера Kubernetes. Ви проскануєте образ, експортуєте докази, проскануєте маніфести та чарти Helm, запустите обмежене простором імен сканування кластера, налаштуєте бар’єр у стилі CI та потренуєтеся писати запис списку дозволів із достатнім контекстом для рев’ю. Команди використовують лише прапорці, перевірені проти довідки Trivy v0.70.0 або названого раніше коміту офіційного README Trivy Action.

У першому сценарії сканування образу в стилі іспиту завдання дає вам посилання на образ та просить знайти вразливості High та Critical у JSON. Почніть із визначення точного імені образу або дайджесту в завданні, запустіть trivy image --format json --output findings.json --severity HIGH,CRITICAL IMAGE та перевірте ім’я пакета, встановлену версію, виправлену версію та джерело серйозності, перш ніж щось редагувати. Якщо образ зібрано з бази Debian або Ubuntu, а завдання явно просить усунення на рівні пакетів, виправте Dockerfile за допомогою apt-get update && apt-get upgrade -y у відповідному виробничому етапі, очистіть списки пакетів, перезберіть образ та перескануйте перезібраний артефакт. У production оновлення базового образу часто чистіше за широкий рядок upgrade, але іспит може винагородити демонстрацію циклу перезбирання: сканувати, визначити виправлені пакети, оновити Dockerfile, перезібрати та довести, що набір знахідок змінився.

У другому сценарії маніфесту в стилі іспиту завдання дає вам файл YAML Kubernetes та просить знахідки неправильних конфігурацій плюс виправлену версію. Запустіть trivy config manifest.yaml або проскануйте каталог, що його містить, якщо кілька файлів спільно використовують мітки та сервісні акаунти. Потім виправте поля, релевантні для безпеки, безпосередньо: встановіть runAsNonRoot, уникайте привілейованих контейнерів, відкиньте непотрібні capabilities Linux, встановіть allowPrivilegeEscalation: false, додайте профіль seccomp, видаліть небезпечні шляхи хоста та переконайтеся, що сервісний акаунт відповідає дозволам робочого навантаження. Ключове — зберегти намір застосунку, водночас зменшуючи неправильну конфігурацію. Хороша відповідь містить як вивід сканера, так і виправлений маніфест, який рецензент може застосувати, не вгадуючи, який засіб контролю змінився.

У третьому сценарії конвеєра завдання просить вас провалити збирання Jenkins, GitHub Actions або GitLab CI на критичних знахідках. Мінімально прийнятний бар’єр — це не «запустити Trivy та надрукувати таблицю»; це команда, чий код виходу змінює результат завдання, коли збіги знахідок залишаються. Для етапу Jenkins на основі оболонки це може бути trivy image --exit-code 1 --ignore-unfixed --severity CRITICAL "$IMAGE_REF", після чого архівується вивід JSON. Для GitHub Actions або GitLab CI використовуйте ту саму семантику через входи дій або прямі команди CLI, а потім зберігайте SARIF чи JSON як артефакт. Бар’єр сканера має стояти після збирання образу та перед тим, як образ трактуватиметься як придатний до релізу.

Коли сканування повертає понад сто CVE, а таймер цокає, використовуйте трипрохідну стратегію. По-перше, визначте артефакт та докази: дайджест образу, свіжість бази даних, формат виводу та фільтри сканера. По-друге, пріоритизуйте лише знахідки, що збігаються із запитаним порогом, мають виправлені версії, уражають пакети у виробничому етапі або несуть сигнали експлойтів, такі як KEV. По-третє, усуньте ті кілька знахідок, що можуть швидко змінити результат, зазвичай оновленням базового образу, оновленням пакетів у фінальному етапі або видаленням непотрібних пакетів. Не витрачайте двадцять хвилин на читання кожного рядка Low та Medium, коли завдання просить вивід High та Critical, і не ігноруйте знахідку Medium, що лежить на межі ланцюга постачання чи шляху даних, лише тому, що таблиця сортує її нижче за більші числа.

Критерії успіху

Ви можете пояснити, яку базу даних Trivy було використано та чи оновлювало її сканування, чи використало кеш.
Ви просканували образ за іменем та архів образу за допомогою перевіреного прапорця --input.
Ви створили принаймні один файл доказів JSON чи SARIF, придатний для артефактів CI.
Ви просканували YAML Kubernetes або вивід Helm окремо від пакетів образу.
Ви запустили обмежене простором імен сканування trivy k8s та можете пояснити, який стан кластера воно спостерігає.
Ви написали виняток, що містить ідентифікатор CVE, контекст пакета, відповідального, причину та термін дії.
Ви можете пояснити, чому закріплені за SHA GitHub Actions зменшують, але не усувають ризик ланцюга постачання CI.

Перевірка засвоєння

Сканування образів за допомогою Trivy — це не вправа на запам’ятовування однієї команди. Навичка CKS полягає в тому, щоб знати, який артефакт сканувати, яка база даних та джерело серйозності дали докази, які знахідки повинні провалювати конвеєр та яких ризиків сканування не може побачити без перевірок маніфестів, інвентарю кластера та дисципліни розгортання на основі дайджестів.

Джерела

Наступний модуль

Модуль 5.3: Статичний аналіз за допомогою kubesec та OPA — Скануйте маніфести Kubernetes та забезпечуйте дотримання політики ланцюга постачання до того, як ризиковані об’єкти потраплять на API-сервер.