Сканирование Docker-образов с Anchore (inline scan)

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

• Архитектура Anchore

• Запуск inline-скрипта

• Результаты скана

• Генерация файлов отчёта

• Сканирование сохранённых архивов образов

• Указание Dockerfile для анализа

• Использование кастомных политик

• Заключение

Введение

Anchore Engine — это open-source инструмент для сканирования безопасности Docker-образов. Отчёт Anchore помогает выявить устаревшие версии пакетов, известные уязвимости и потенциальные проблемы конфигурации, спрятанные в зависимостях или Dockerfile.

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

Архитектура Anchore

Традиционно Anchore требовал отдельного развертывания Anchore Engine, работающего независимо от процесса сборки образов. Отдельный CLI позволял регистрировать образы, запускать анализ и опрашивать результаты.

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

Кроме классического режима, Anchore предлагает inline-сканирование. Inline-скрипт даёт команду «всё в одном»: скачивание нужных контейнеров, поднятие временных сервисов и вывод результатов прямо в терминал. В этой статье мы сфокусируемся на inline-режиме и практиках его использования.

Запуск inline-скрипта

Inline-сканирование реализовано через Bash-скрипт, размещённый на серверах Anchore. Скачайте скрипт и сделайте его исполняемым:

curl -s https://ci-tools.anchore.io/inline_scan-latest -o anchore.sh

chmod +x anchore.sh

Запустите сканирование целевого образа:

./anchore.sh -r alpine:latest

Первый запуск может занять заметное время: скрипт скачает Docker-образ Anchore Engine, поднимет временный экземпляр Anchore, настроит PostgreSQL и локальный Docker-реестр (если требуется), затем будет ждать, пока Engine полностью стартует.

После старта Engine таргетный образ будет выкачан и проанализирован. В терминале появится текстовый отчёт с результатами. По окончании скрипт убирает временные контейнеры и останавливает локальный Anchore Engine.

Важно: inline-скрипт отлично подходит для быстрой диагностики и локальной проверки, но не заменяет полнофункциональное развертывание для постоянного использования в CI/CD.

Детали процесса сканирования

Что именно делает скрипт и Engine при анализе образа:

• Скачивает и распаковывает образ для детального изучения слоёв;
• Составляет список установленных пакетов и версии;
• Сопоставляет пакеты с базами уязвимостей (CVE, NVD и другие фиды, если они настроены);
• Анализирует Dockerfile (если он передан) на предмет антипаттернов: использование root, небезопасные пути, сегменты с секретами;
• Применяет политики (стандартные и кастомные) и формирует итоговое решение: пропуск, предупреждение или отказ.

Результаты скана

Результаты содержат метаданные образа, затем таблицу найденных проблем. Anchore сравнивает образ с текущими политиками. Набор по умолчанию ищет известные уязвимости в пакетах и возможные проблемы Dockerfile.

В файле результата есть строка Status, расположенная над таблицей уязвимостей. Если статус — pass, образ соответствует базовым требованиям и готов к использованию в продакшене. Статус fail означает, что нужно просмотреть найденные проблемы и исправить их по возможности.

Каждая уязвимость помечена уровнем серьёзности от LOW до CRITICAL. Уязвимости, содержащие CVE-идентификатор, включают ссылку на страницу MITRE или другой источник, где можно посмотреть подробности.

Генерация файлов отчёта

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

./anchore.sh -r alpine:latest

Отчёты будут записаны в директорию anchore-reports в рабочем каталоге. Каждый скан генерирует набор JSON-файлов для различных разделов: уязвимости, пакеты ОС, требования политик и т.д.

JSON-файлы содержат расширенную информацию: CVSS-оценки, точные версии пакетов, метки поставщиков и указания на наличие фикс-патчей. Эти данные полезны для автоматизированных рабочих процессов (например, для трекинга инцидентов или создания тасков на исправление).

Сканирование сохранённых архивов образов

Anchore может анализировать как образы в реестрах, так и каталоги с сохранёнными архивами Docker образов. Экспортируйте образы с помощью docker save, поместите их в директорию и запустите скрипт с флагом -v:

docker save my-image:latest -o docker-images/my-image

./anchore -v docker-images

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

Указание Dockerfile для анализа

Inline-скрипт принимает аргумент -d, позволяющий указать путь к локальному Dockerfile. Anchore сравнит собранный образ и Dockerfile, что помогает выявлять дефекты на этапе сборки, которые не видны при анализе только бинарных слоёв.

./anchore.sh my-image:latest -d /dockerfiles/my-image

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

Использование кастомных политик

Anchore расширяем через наборы политик. Политики состоят из «gates» (врат), «triggers» и «actions» (действий). Они позволяют строить правила, которые проверяют образы в соответствии с вашими внутренними требованиями безопасности.

Каждый gate возвращает одно из действий: «go» — пропуск, «warn» — предупреждение, «stop» — блокировка дальнейшей обработки образа. Политики упакованы в «bundles», которые связывают наборы правил с реестрами и образами.

Добавить пакет политики в скан можно через флаг -b:

./anchore.sh -b policy-bundle.json

Ниже приведён упрощённый пример bundle-политики, которая выдаёт предупреждение, если Dockerfile не был передан в анализ (рекомендуется передавать Dockerfile для полного покрытия):

{

"action": "WARN",

"comment": "No Dockerfile given!",

"gate": "dockerfile",

"params": [],

"trigger": "no_dockerfile_provided"

}

Эта политика относится к gate dockerfile, где Anchore проверяет соответствие Dockerfile лучшим практикам. Триггер no_dockerfile_provided срабатывает, если скан инициирован без указания Dockerfile, и в результате генерируется предупреждение.

Когда inline-сканирование подходит, а когда нет

Варианты, когда inline-скрипт хорош:

• Локальная проверка образа перед пушем в реестр;
• Быстрая диагностика на машине разработчика;
• Одиночные проверки в тестовой среде.

Когда лучше развернуть полноценный Anchore Engine:

• Центральное сканирование множества репозиториев и образов в CI/CD;
• Необходимость синхронизировать фиды уязвимостей и кэшировать результаты;
• Требования к постоянному хранению и аудитам отчётов;
• Нужна интеграция с внешними системами (ticketing, SIEM).

Противоположные примеры (когда inline не подойдёт):

• Требуется анализ сотен образов ежедневно и долгосрочное хранение метаданных;
• Необходима высокая доступность и отказоустойчивость сервиса сканирования;
• Политики компании требуют централизованного управления и аудита.

Альтернативные подходы и интеграция в конвейер

Если inline не подходит, рассмотрите следующие варианты:

• Полное развёртывание Anchore Engine в Kubernetes/VM и использование CLI/API для взаимодействия;
• Рассмотрите SaaS-решения для сканирования образов, если не хотите поддерживать инфрастуктуру;
• Комбинируйте: inline для локальной проверки, Engine для CI и хранения данных.

Интеграция в CI (микропроцесс):

1. Собрать образ в CI.
2. Запушить в приватный реестр (или сохранить в артефактах).
3. Запустить сканирование (CLI или вызов API Engine).
4. Парсить JSON-отчёты и по результатам создавать задачи на исправление или отклонять билды.

Мини-методология для принятия решений по уязвимостям

1. Классифицируйте уязвимость по уровню: LOW / MEDIUM / HIGH / CRITICAL.
2. Смотрите CVSS и контекст — затронет ли уязвимость рантайм приложения или только инструменты сборки.
3. Ищите доступность фиксов у поставщика (patch, upgrade).
4. Если фикса нет, оцените компенсирующие меры: ограничение сети, runtime-меры безопасности.
5. Документируйте решение и закройте задачу в системе отслеживания.

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

DevOps / CI:

• Автоматизировать запуск сканирования в пайплайне;
• Хранить JSON-отчёты и метаданные;
• Настроить оповещения по критическим находкам.

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

• Перед пушем запускать inline-скрипт локально;
• При возможности передавать Dockerfile в анализ;
• Исправлять небезопасные инструкции Dockerfile.

Специалист по безопасности:

• Создать и поддерживать набор кастомных политик;
• Настроить регулярное сканирование образов в продакшене;
• Интегрировать результаты в процессы управления уязвимостями.

Шаблон SOP: быстрый рабочий процесс сканирования (playbook)

1. Сборка образа: docker build -t my-app:ci-123 .
2. Локальная проверка: ./anchore.sh my-app:ci-123 -d ./Dockerfile.
3. Если pass — пуш в реестр: docker push my-app:ci-123.
4. В CI при пуше запускается централизованный сканер Anchore Engine.
5. Автоматический разбор JSON-отчёта и создание тикетов на HIGH/CRITICAL.
6. При исправлении — новая сборка и повторный цикл.

Галерея крайних случаев (edge cases)

• Образы с собственными приватными бинарными пакетами, недоступными в публичных фидах — Anchore не сможет сопоставить уязвимости без дополнительной информации.
• Многоуровневые multi-stage Dockerfile: некоторые пакеты могут отсутствовать в финальном образе, поэтому анализ Dockerfile важен для понимания контекста.
• Образы с горящей зависимостью, где фикса нет — требуется оценка риска и, возможно, замена библиотеки.
• Образы, собранные с использованием нестандартных менеджеров пакетов — потребуют дополнительной настройки парсеров или хуков.

Рекомендации по повышению надёжности сканирования

• Перед внедрением inline-скрипта в CI, протестируйте поведение в staging-окружении.
• Храните и версионируйте наборы кастомных политик.
• Настройте накопление и ротацию отчётов, чтобы иметь историю изменений.
• Синхронизируйте фиды уязвимостей и проверяйте их актуальность.

Безопасность и конфиденциальность

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

• Доступ к отчётам ограничен;
• Inline-скрипт и временные контейнеры запускаются в контролируемой среде;
• В конфигурациях CI не записываются секреты в логи отчётов.

Пример принятия решения: риск × усилие

• CRITICAL с доступным фикс-патчем: высокий приоритет, обновление и пересборка — низкое усилие.
• HIGH без фикса: средний/высокий приоритет, нужны смягчающие меры — среднее усилие.
• LOW/INFORMATIONAL: отложенные задачи, мониторинг — низкое усилие.

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

• Скриншоты и JSON-отчёты генерируются и сохраняются в anchore-reports.
• CI пайплайн отклоняет билд при наличии CRITICAL уязвимостей (по политике).
• Документация политик и процедуры исправления доступны команде.

Заключение

Anchore — мощный инструмент для проверки безопасности контейнерных образов. Inline-скрипт ускоряет локальную проверку и удобен для диагностики, в то время как полнофункциональное развёртывание Anchore Engine даёт преимущества для масштаба, хранения истории и интеграции с корпоративными процессами.

Краткие рекомендации:

• Используйте inline для быстрой локальной валидации.
• Для постоянных проверок и CI разверните Anchore Engine.
• Пишите и храните кастомные политики, чтобы соответствовать внутренним требованиям безопасности.

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

Ключевые выводы:

• Inline-скрипт — быстрый путь получить отчёт в терминале.
• Перед анализом образ должен быть доступен (в реестре или в виде архива).
• Передавайте Dockerfile для лучшего покрытия анализа.
• Для масштабных задач разворачивайте Anchore Engine и управляйте политиками централизованно.