Проверка Docker-образов на уязвимости с помощью Trivy и Copacetic

Безопасность Docker-образов — важная часть DevSecOps и процесса разработки контейнеризированных приложений. Устаревшие системные пакеты, библиотеки и зависимости могут содержать уязвимости, которые повышают риск компрометации приложения и инфраструктуры.

Для автоматического поиска уязвимостей можно использовать Trivy — инструмент анализа безопасности контейнеров, файловых систем и зависимостей. А для автоматического исправления части найденных уязвимостей подходит Copacetic (Copa), который позволяет обновлять системные пакеты непосредственно в существующем образе.

В этой статье рассмотрим, как установить Trivy в Debian, проверить Docker-образ на известные уязвимости, сохранить результаты сканирования в JSON и создать исправленный образ с помощью Copacetic.

Содержание

• Установка Trivy в Debian
• Проверка Docker-образа на уязвимости
• Сохранение результатов сканирования в JSON
• Установка Go, runc, BuildKit и Copacetic
• Автоматическое исправление уязвимостей Docker-образа
• Повторное сканирование и проверка исправленного образа

1. Установка Trivy в Debian

Trivy можно установить несколькими способами: через пакетный репозиторий, с помощью готового бинарного файла, Bash-скрипта, Nix или Docker. В этом примере воспользуемся официальным репозиторием Trivy для Debian.

Сначала установим необходимые пакеты:

apt updateapt install -y wget apt-transport-https gnupg lsb-release ca-certificates

Добавим ключ репозитория и подключим источник пакетов:

wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key \  | gpg --dearmor \  -o /usr/share/keyrings/trivy.gpg

echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" \  > /etc/apt/sources.list.d/trivy.list

Обновим список пакетов и установим Trivy:

apt updateapt install -y trivy

Проверим, что установка прошла успешно:

trivy --version

После установки можно приступать к сканированию Docker-образов.

2. Проверка Docker-образа на уязвимости

Для демонстрации используем образ NGINX с версией 1.21.6. Это устаревшая версия, поэтому она подходит для примера анализа известных уязвимостей. Фактические результаты сканирования будут зависеть от состава образа и актуальности базы уязвимостей Trivy.

Сначала загрузим образ из Microsoft Container Registry:

docker pull mcr.microsoft.com/oss/nginx/nginx:1.21.6

Теперь выполним сканирование системных пакетов:

trivy image \  --vuln-type os \  --ignore-unfixed \  mcr.microsoft.com/oss/nginx/nginx:1.21.6

Здесь используются следующие параметры:

• image — проверка контейнерного образа.
• --vuln-type os — поиск уязвимостей в пакетах операционной системы.
• --ignore-unfixed — исключение из отчёта уязвимостей, для которых Trivy не обнаружил доступного исправления.

В результате Trivy выведет список обнаруженных уязвимостей, их идентификаторы CVE, затронутые пакеты, установленные и исправленные версии, а также уровни критичности, если эти сведения доступны.

При анализе отчёта в первую очередь стоит обратить внимание на уязвимости уровня CRITICAL и HIGH, а также на наличие исправленных версий затронутых пакетов.

3. Сохранение отчёта Trivy в JSON

Для автоматизации проверок в CI/CD удобно сохранять результаты сканирования в JSON. Такой отчёт можно использовать для последующего анализа, формирования отчётности и передачи данных в другие инструменты.

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

trivy image \  --vuln-type os \  --ignore-unfixed \  --format json \  --output nginx.1.21.6.json \  mcr.microsoft.com/oss/nginx/nginx:1.21.6

После выполнения команды появится файл nginx.1.21.6.json с результатами проверки.

JSON-отчёт удобно использовать в автоматизированных сценариях: например, для запуска дополнительных проверок, анализа уязвимостей и передачи отчётов в системы управления безопасностью.

Важно учитывать, что параметр --ignore-unfixed исключает из отчёта уязвимости без известного исправления. Если требуется полный аудит, выполните дополнительное сканирование без этого параметра.

Trivy подходит не только для проверки Docker-образов. Инструмент также умеет анализировать исходный код, файловые системы, конфигурации и файлы блокировки зависимостей, включая Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock и Cargo.lock.

4. Автоматическое исправление уязвимостей Docker-образа с помощью Copacetic

Trivy помогает обнаруживать уязвимости, но сам по себе не предназначен для непосредственного обновления системных пакетов внутри образа. Для этой задачи можно использовать Copacetic (Copa) — инструмент, который применяет исправления на основе отчёта сканера и создаёт новый контейнерный образ.

В отличие от ручного изменения Dockerfile, такой подход позволяет исправлять некоторые уязвимости в уже собранном образе без полной пересборки приложения. При этом Copacetic не заменяет полноценный процесс обновления базового образа и повторного тестирования приложения.

Для установки Copacetic в рассматриваемом сценарии понадобятся:

• Go — для сборки Copa из исходного кода;
• runc — среда выполнения контейнеров;
• BuildKit — инфраструктура сборки образов;
• Copacetic — инструмент применения исправлений.

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

4.1. Установка Go

Загрузим архив Go для Linux AMD64:

wget https://go.dev/dl/go1.19.5.linux-amd64.tar.gz

Распакуем его в /usr/local:

tar -C /usr/local -xzf go1.19.5.linux-amd64.tar.gz

Добавим исполняемый файл Go в PATH через символическую ссылку:

ln -s /usr/local/go/bin/go /usr/bin/go

Проверим версию:

go version

Для нового развёртывания рекомендуется использовать поддерживаемую версию Go, совместимую с выбранной версией Copacetic.

4.2. Установка runc

Установим необходимые инструменты для сборки:

apt install -y \  make git gcc build-essential pkgconf libtool \  libsystemd-dev libprotobuf-c-dev libcap-dev \  libseccomp-dev libyajl-dev libgcrypt20-dev \  go-md2man autoconf python3 automake

Получим исходный код runc:

git clone https://github.com/opencontainers/runccd runc

Соберём и установим программу:

makemake install

Для воспроизводимой установки в производственной среде желательно выбирать конкретный стабильный релиз или фиксированный тег, а не собирать произвольное состояние основной ветки репозитория.

4.3. Установка BuildKit

Загрузим архив BuildKit версии 0.11.0 для Linux AMD64:

wget https://github.com/moby/buildkit/releases/download/v0.11.0/buildkit-v0.11.0.linux-amd64.tar.gz

Распакуем файлы в каталог /usr:

tar -C /usr -xzf buildkit-v0.11.0.linux-amd64.tar.gz

Убедимся, что исполняемые файлы BuildKit доступны в системе. Для дальнейшей работы потребуется демон buildkitd.

4.4. Установка Copacetic

Клонируем репозиторий Copacetic:

git clone https://github.com/project-copacetic/copaceticcd copacetic

Соберём проект:

make

Если сборка завершилась успешно и бинарный файл создан по ожидаемому пути, установим его:

install -m 0755 dist/linux_amd64/release/copa /usr/local/bin/copa

Проверим доступность CLI:

copa --help

Пути к артефактам сборки могут различаться в зависимости от версии Copacetic и конфигурации сборки. При необходимости используйте инструкции из официального репозитория проекта.

5. Исправление уязвимостей Docker-образа

После установки необходимых инструментов можно перейти к созданию исправленного образа.

Сначала запустим BuildKit. В тестовом окружении демон можно запустить в фоновом режиме:

buildkitd &

В рабочей среде предпочтительнее использовать предусмотренный для вашей системы способ управления службой и проверить, что BuildKit действительно запущен и доступен.

Теперь передадим Copacetic исходный образ, отчёт Trivy и тег нового образа:

copa patch \  -i mcr.microsoft.com/oss/nginx/nginx:1.21.6 \  -r nginx.1.21.6.json \  -t 1.21.6-patched

В этой команде:

• -i — исходный Docker-образ;
• -r — JSON-отчёт Trivy;
• -t — тег, который будет использоваться для исправленного образа.

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

Исходный образ при этом не перезаписывается: исправленный вариант получает отдельный тег. Однако успешное выполнение команды не гарантирует устранения всех уязвимостей. Результат зависит от доступности обновлений, совместимости пакетов и возможностей выбранного базового образа.

6. Проверка исправленного Docker-образа

После завершения обработки посмотрим список образов:

docker images

Проверим историю нового образа:

docker history mcr.microsoft.com/oss/nginx/nginx:1.21.6-patched

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

docker run -d \  --rm \  --name nginx-test \  -p 8080:80 \  mcr.microsoft.com/oss/nginx/nginx:1.21.6-patched

Проверим доступность NGINX:

curl -I http://localhost:8080

Если контейнер запустился, дополнительно проверьте журналы, конфигурацию, сетевую доступность и работоспособность приложения. При необходимости остановите контейнер:

docker stop nginx-test

Запуск контейнера и получение HTTP-ответа подтверждают только базовую работоспособность. Они не доказывают, что все уязвимости устранены или что приложение полностью совместимо с обновлёнными пакетами.

7. Повторное сканирование после исправления

Чтобы оценить результат работы Copacetic, повторно просканируем новый образ:

trivy image \  --vuln-type os \  --ignore-unfixed \  mcr.microsoft.com/oss/nginx/nginx:1.21.6-patched

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

Если часть уязвимостей осталась, необходимо выяснить причину: для некоторых CVE может отсутствовать исправление, пакет может не поддерживаться или уязвимость может находиться в другом компоненте образа.

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

8. Практические рекомендации по безопасности Docker-образов

Чтобы встроить сканирование в процесс разработки и эксплуатации, рекомендуется придерживаться нескольких правил:

1. Используйте поддерживаемые базовые образы. Устаревшие версии ОС и приложений могут содержать множество известных уязвимостей.
2. Регулярно запускайте Trivy. Проверяйте образы перед публикацией в registry и после обновления зависимостей.
3. Автоматизируйте проверки в CI/CD. Настройте правила, определяющие, при каких уровнях критичности публикация образа должна блокироваться.
4. Исправляйте уязвимости на уровне Dockerfile и базового образа. Copacetic может помочь быстро обновить пакеты, но исправления желательно закреплять в процессе сборки, чтобы они не терялись при следующем выпуске.
5. Повторно сканируйте исправленные образы. Не считайте патчинг успешным только на основании завершения команды.
6. Тестируйте приложения после обновления пакетов. Обновления безопасности могут влиять на совместимость и поведение приложения.
7. Фиксируйте версии инструментов и образов. Это повышает воспроизводимость сборок и упрощает аудит.

Заключение

Trivy и Copacetic позволяют организовать практический процесс обнаружения и исправления части уязвимостей в Docker-образах. Trivy выполняет сканирование и формирует отчёт, а Copacetic использует полученные данные для обновления доступных системных пакетов и создания нового образа.

Такой подход полезен при работе с контейнерной инфраструктурой, в DevOps-процессах и при автоматизации проверок безопасности в CI/CD.

При этом патчинг готового образа не заменяет обновление Dockerfile, переход на поддерживаемую базовую версию и полноценное тестирование. Оптимальная стратегия — сочетать регулярное сканирование, своевременную пересборку образов, автоматизированное исправление уязвимостей и повторную проверку безопасности перед развёртыванием.