Trivy: сканирование контейнеров и CI

Кратко: Trivy — лёгкий сканер уязвимостей для образов контейнеров, пакетов ОС и зависимостей языка. В этой статье показано, как установить Trivy, запускать сканы локально и в CI, уменьшать шум в отчётах, работать в клиент‑серверном режиме и внедрить Trivy в процесс разработки.

Логотип Trivy

Быстрые ссылки

Installing Trivy
First Run
Reducing the Noise
Filtering Vulnerabilities
Using Trivy In CI
Server Mode
Summary

Введение

Скан Trivy проверяет базовый образ из Dockerfile и ищет незакрытые уязвимости, которые контейнеры унаследуют. Trivy также анализирует пакеты ОС и зависимости исходного кода, установленные через популярные менеджеры пакетов.

Trivy поддерживает три типа сканирования: образ контейнера, Git‑репозиторий и директорию файловой системы. В этой статье мы сосредоточимся на сканировании образов контейнеров. Документация Trivy содержит дополнительные детали по анализу исходного кода и окружения.

Важно: Trivy — инструмент для обнаружения и приоритизации рисков. Он помогает находить потенциальные проблемы, но не заменяет комплексной политики управления уязвимостями.

Установка Trivy

Trivy доступен в репозиториях большинства популярных дистрибутивов Linux. Для некоторых дистрибутивов потребуется добавить репозиторий разработчика — ссылка есть в официальной документации.

Если нужна конкретная версия, можно скачать бинарник с релизов проекта на GitHub. Также есть автоматический скрипт установки, который подберёт подходящий бинарник для вашей ОС.

Альтернативный вариант — запускать Trivy как контейнер вместо установки на хосте:

docker run --rm -v trivy-cache:/root/.cache/ -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:latest

Эта команда монтирует каталог trivy-cache в путь к кешу контейнера Trivy. Такое кеширование повышает производительность, позволяя хранить данные между запусками вне контейнера.

Также сокет Docker хоста монтируется в контейнер — это позволяет Trivy сканировать образы и контейнеры на хосте.

Первый запуск

Движок Trivy поддерживает локальные и удалённые образы. Он работает с Docker, Podman, экспортированными архивами образов (docker save) и образами в регистрах, таких как Docker Hub или GitHub Container Registry.

Запустите базовое сканирование команды trivy image, указав тег образа:

trivy image my-image:latest

При первом запуске Trivy скачает базу данных уязвимостей. Эта база будет кешироваться и переиспользоваться в следующих запусках.

Пример отчёта Trivy в терминале

Результаты сканирования выводятся прямо в терминал. Сводка вверху показывает ОС контейнера и распределение уязвимостей по уровням серьёзности. Таблица содержит полный список проблем: библиотеку, описание и идентификатор CVE, если он доступен.

Уменьшение шума в отчётах

Trivy умеет гибко настраивать вывод с помощью флагов. По умолчанию он показывает все найденные уязвимости, включая те, которые ещё не исправлены в исходном проекте. Это может создавать «шум» в отчёте.

Чтобы исключить незакрытые проблемы, используйте флаг --ignore-unfixed. Это скрывает уязвимости, для которых пока нет фикса.

trivy image --ignore-unfixed my-image:latest

Иногда уязвимость осознанно принимается командой (accepted risk). В этом случае можно добавить файл .trivyignore в рабочую директорию и перечислить CVE‑идентификаторы по одному на строку. Trivy автоматически найдёт файл и исключит перечисленные CVE из отчёта.

# .trivyignore
# Эта проблема не релевантна для нашего окружения
CVE-2021-1234

Рекомендуется добавлять комментарий рядом с каждой исключённой записью — это помогает другим участникам понять причину принятия риска.

Фильтрация уязвимостей

Можно ограничить объём отчёта по типу уязвимости и по уровню серьёзности.

Флаг --vuln-type принимает значение library или os.
- library — уязвимости зависимостей языков (например, npm, pip, gem).
- os — уязвимости пакетов операционной системы.
Фильтрация по серьёзности осуществляется через --severity, принимающий запятую‑разделённый список уровней, например:

trivy image --severity MEDIUM,HIGH,CRITICAL my-image:latest

После этого в выдаче не будет уязвимостей уровня LOW.

Настройка формата отчёта

По умолчанию Trivy выводит визуальную таблицу для человека. Для автоматизированных процессов удобно использовать JSON:

trivy image --format json my-image:latest > report.json

Поддерживаются шаблоны для кастомной генерации отчётов (например, xml и html). Пример генерации HTML с использованием встроенного шаблона:

trivy image --format template @contrib/html.tpl -o scan.html my-image:latest

Пример HTML отчёта Trivy

Графические отчёты удобнее читать и легче отправлять заинтересованным сторонам.

Внедрение Trivy в CI

Trivy подходит для интеграции в конвейеры сборки. По умолчанию код завершения равен 0, даже если уязвимости найдены. Чтобы сделать сборку падающей при обнаружении проблем, используйте флаг --exit-code.

trivy image --exit-code 1 my-image:latest

Шаблоны интеграции доступны для популярных CI: GitHub Actions, GitLab CI, Travis CI и CircleCI. Рассмотрите одну из двух стратегий при проверке образов в CI:

Сканирование финального образа после сборки.
Запуск Trivy внутри контейнера во время многоступенчатой сборки Docker и прекращение сборки при провале скана.

Для варианта с запуском внутри контейнера используйте режим filesystem, так как скан идёт по файловой системе контейнера:

COPY --from=aquasec/trivy:latest /usr/local/bin/trivy /usr/local/bin/trivy
RUN trivy filesystem --exit-code 1 --no-progress /

Запускайте Trivy ближе к концу Dockerfile, после установки зависимостей, и удаляйте бинарь trivy (rm /usr/local/bin/trivy) перед финальным слоем, чтобы не увеличивать итоговый образ.

Playbook: добавить Trivy в CI (короткий SOP)

Решите, где запускать — отдельно в шаге CI или внутри Dockerfile.
Добавьте скачивание/кеширование базы уязвимостей (кеширование повышает скорость).
Настройте флаги: --ignore-unfixed, --severity, --exit-code по политике безопасности.
Сохраните машинно‑читабельный отчёт (JSON) и отправьте в систему трекинга багов или визуализации.
Обновляйте базу и периодически пересматривайте .trivyignore.

Серверный режим

Trivy поддерживает клиент‑серверный режим: база уязвимостей хранится на сервере, и клиенты подключаются к нему. Это снижает трафик и централизует обновления базы.

Запустите сервер командой:

trivy server

По умолчанию сервер слушает на порту 4594. Чтобы изменить адрес/порт, укажите --listen, например --listen localhost:8080.

Сервер скачивает базу при старте и периодически обновляет её в фоне. Клиент подключается так:

trivy client --remote http://localhost:8080 image my-image:latest

Если требуется авторизация, задайте токен через флаг --token и на клиенте, и на сервере — сервер примет только тех клиентов, которые предоставят корректный токен.

Политики и критерии приёмки

Установите правила, когда найденная уязвимость требует исправления или исключения:

Критично: исправлять немедленно или откатить релиз.
Высокая: планировать исправление в ближайшем спринте.
Средняя: оценить влияние и приоритизировать.
Низкая: документировать и переосмыслить позже.

Критерии приёмки (пример):

Нет уязвимостей CRITICAL и HIGH в продакшн‑образах.
В сборочных образах допускаются LOW/UNKNOWN с явным комментарием в .trivyignore.

Роли и чек-листы

Разделим ответственность по ролям — быстрое руководство для команд.

Разработчик:

Запускать Trivy локально перед PR.
Добавлять обоснования в .trivyignore, если исключаете CVE.
Обновлять зависимости, если уязвимость релевантна.

DevOps / CI‑инженер:

Интегрировать Trivy в пайплайны.
Настроить кеширование и хранение отчётов (JSON).
Настроить сервер Trivy при большом числе агентов.

Информационная безопасность (InfoSec):

Определять уровни приоритета (SLA на исправление).
Проводить ревью .trivyignore и решения по принятию риска.
Проверять лицензии источников данных (см. раздел о лицензиях).

Безопасность и жёсткая настройка

Запускайте сервер Trivy за TLS и в доверенной сети.
Ограничьте доступ к API токенами и/или IP‑фильтрами.
Минимизируйте привилегии у процессов, которые используют кеш и артефакты Trivy.

Конфиденциальность и лицензирование

Trivy агрегирует списки уязвимостей из различных источников. Некоторые источники могут накладывать ограничения (например, некоммерческое использование). Перед внедрением в коммерческие пайплайны проверьте условия использования и соответствие вашей политике лицензирования.

Примеры типичных проблем и когда Trivy может не помочь

Когда Trivy эффективен:

Поиск известных CVE в пакетах ОС и языковых зависимостях.
Быстрая автоматическая проверка контейнеров в CI.

Ограничения Trivy:

Не обнаруживает логические уязвимости в приложении (например, баги авторизации).
Не заменяет динамическое тестирование (DAST) и аудит кода.
Зависит от полноты и своевременности внешних баз данных уязвимостей.

Методика приоритизации (мини‑методология)

Идентифицировать: CVE, пакет, версия.
Оценить влияние: эксплойтабельность и наличие эксплойта в природе.
Определить охват: затронет ли уязвимость ваше приложение/функцию.
Приоритизировать исправление: CRITICAL → HIGH → MEDIUM → LOW.
Документировать шаги (фикс/заплатка/исключение).

Решение для CI: пример GitHub Actions

Ниже — упрощённый пример настройки шага в GitHub Actions, который запускает Trivy и прерывает сборку при критических уязвимостях:

- name: Run Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: my-org/my-image:latest
    format: 'json'
    exit-code: '1'
    severity: 'CRITICAL,HIGH'

Визуализация принятия решения

flowchart TD
  A[Есть образ для проверки?] --> B{Запускать локально или в CI}
  B -->|Локально| C[trivy image my-image:latest]
  B -->|CI| D[Запуск Trivy в конвейере]
  D --> E{Найдены уязвимости?}
  C --> E
  E -->|Нет| F[Proceed]
  E -->|Да| G{Типы уязвимостей}
  G -->|CRITICAL/HIGH| H[Fail pipeline + уведомить Sec]
  G -->|MEDIUM/LOW| I[Создать тикет, приоритизировать]

Критерии приёмки

Отчёт CI не содержит CRITICAL или HIGH уязвимостей.
Для всех исключённых CVE есть комментарий в .trivyignore с причиной и датой.
Сервер Trivy обновляет базу не реже одного раза в 24 часа (рекомендация для активных проектов).

Сценарии тестирования и приёмки

Unit тест: запуск Trivy на тестовом образе без уязвимостей — exit code 0.
Интеграция CI: при наличии CRITICAL уязвимости шаг должен возвращать ненулевой код.
Ручной тест: проверка работы .trivyignore — указанный CVE не появляется в выводе.

Глоссарий (одно предложение на термин)

CVE: уникальный идентификатор для известной уязвимости.
Кеш Trivy: локальное хранилище базы уязвимостей и сопутствующих данных.
filesystem режим: сканирование содержимого файловой системы, полезно внутри контейнера.
client/server режим: архитектура, где база уязвимостей хранится централизованно на сервере.

Итог: Trivy — быстрый и гибкий инструмент для проверки образов контейнеров, который подходит как для локальной разработки, так и для автоматизации в CI. Внедрение Trivy требует продуманной политики приоритизации уязвимостей, процесса приёма риска и настроек безопасности для серверного режима.