Anchore Engine: где даёт сбой проверка Docker-образов
Сборка одна, а базовый образ тянется из чужого реестра: уязвимости в образах попадают в рабочий контур не из вашего кода, а из слоя, который вы не собирали и никогда не обновляли. Проверка при этом держится на ручном просмотре манифеста перед релизом — и заканчивается ровно там, где начинается спешка.
Ломается это на масштабе. Плавающий тег указывает на разные образы в разные дни, кэш закрепляет старый слой, зависимости ставятся по файлу фиксации версий месячной давности. Патч в базовом слое давно вышел, пересборки не было — и уязвимость осталась в проде, хотя формально состав сервиса не менялся.
Anchore Engine закрывает именно эту дыру: сканирование docker-образов идёт по контрольной сумме, а не по тегу, а сам образ разбирается на слои с инвентаризацией пакетов системного менеджера и языковых зависимостей. Контроль базовых слоёв держится на политике: порог по критичности, белые и чёрные списки пакетов, запрет на выпуск сборки, не прошедшей проверку в текущей редакции.
Разница видна не в отчёте, а в точке перед выкаткой. Проверка до записи в реестр останавливает сборку; проверка после — оставляет артефакт в реестре и превращает разбор в ручную работу дежурного. Ниже разбираем, как это закрывается на практике и что именно ломается чаще всего.
Что даёт сканирование образов в конвейере сборки
Проверка образов даёт эффект, только когда встроена в конвейер сборки: отчёт по образу, который собрали вручную раз в месяц, не влияет на то, что уходит в продакшн. Мы ставим Anchore Engine на этап сборки и привязываем его вердикт к правилам допуска — тогда безопасность контейнеров перестаёт быть отдельной задачей и становится условием выпуска релизов. Ниже — чек-лист результатов, по которым видно, что проверка работает, а не создаёт видимость.
- Покрытие сборок. Раньше проверяли выборочно, по запросу или перед крупным релизом; теперь вердикт получает каждый образ до публикации в реестре. Образ без заключения просто не попадает дальше.
- Время на ручную проверку. Разбор отчёта занимает минуты вместо часов ручного просмотра списка пакетов и манифестов. Замечание приходит тому, кто собирает образ, а не тому, кто потом дежурит ночью.
- Проверка зависимостей по слоям. Видно конкретный пакет и его версию, из-за которых сборка не проходит. Правка обычно сводится к одной строке в описании сборки, а не к пересборке сервиса целиком.
- Исчезающий класс отказов. Правило допуска блокирует публикацию образа с критичным уровнем уязвимости — сценарий «в продакшн уехало то, что никто не смотрел» закрывается на этапе сборки.
- Исключения под контролем. Вместо молчаливого согласия — запись с причиной и сроком пересмотра. Реестр исключений со временем сокращается, потому что каждое видно на общей панели.
- Тренд вместо разового среза. По релизам видно, растёт ли число уязвимостей и что именно его тянет: стареющий базовый образ или конкретная библиотека. Это уже основание для плановой замены, а не для аврала.
Порог срабатывания и список исключений настраиваем под сервис: для внутреннего инструмента и для публичного API уровни допуска различаются.
Режимы сканирования образов и их ограничения
Anchore Engine не включают одним переключателем — сначала выбирают точку, где принимается решение о судьбе образа. Один и тот же движок даёт разный результат в зависимости от глубины разбора слоёв, момента запуска и порога, при котором выпуск останавливается.
Режимы и их пределы
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Полный разбор слоёв | Аудит выпуска, разбор инцидента, подготовка к внешней проверке | Самый медленный: на крупных образах идёт минутами и требует свежей базы уязвимостей |
| Быстрая проверка на входе в реестр | Отсечь заведомо проблемный образ до выката | Поверхностная: разбирает манифест и базовые слои, собственные слои почти не видит |
| Проверка по расписанию | Найти новые уязвимости в образах, которые уже лежат в реестре | Между запусками образ считается чистым, к выпуску не привязана |
| Сканирование по триггеру выпуска | Гейт в конвейере перед выкатом в среду | Нужны пороги и права на реестр; слишком жёсткий порог останавливает выпуски |
Без пороговых правил любой режим даёт отчёт, но не решение. Порог определяет, что считать блокирующим: уровень критичности и наличие исправленной версии пакета. Исключения выносят в правила с датой пересмотра — иначе они превращаются в постоянный обход проверки.
Порядок внедрения: от аудита реестра до передачи регламентов
Сканирование образов даёт эффект только когда встроено в контур поставки: реестр подключён, пороги зафиксированы, а вердикт проверки останавливает выкладку уязвимой сборки. Поэтому начинаем с инвентаризации — без неё правила либо пропускают критичное, либо блокируют всё подряд.
- Аудит реестра образов. Собираем перечень репозиториев и активных тегов, отмечаем архивные и дубли. На выходе — карта парка с приоритетом: что проверяем на каждой публикации, что разово.
- Схема подключения к реестру. Разворачиваем Anchore Engine рядом с реестром, выдаём учётную запись только на чтение и настраиваем забор образа по событию публикации тега — новая сборка сразу встаёт в очередь на проверку.
- Правила и пороги. Разделяем находки по критичности и типу: уязвимости в исполняемом слое, устаревшие пакеты, секреты внутри слоёв. Порог блокировки подбираем так, чтобы он ловил реальный риск, но не срабатывал на каждой зависимости.
- Исключения. Для находок, которые нельзя закрыть быстро, фиксируем адресное исключение со сроком и владельцем вместо общего пропуска правила.
- Обкатка на живых сборках. Прогоняем проверку на текущих ветках без блокировок, сверяем вердикты с ручным разбором, убираем ложные срабатывания.
- Блокирующий режим. Проверка встаёт воротами перед выкладкой: образ с критичной находкой не уходит в продуктивный контур, откат остаётся на предыдущий проверенный тег.
- Передача регламента проверок. Отдаём матрицу порогов, порядок разбора находок, правила исключений и инструкцию по обновлению базы уязвимостей.
Артефакты внедрения: конфигурации, схемы и регламенты
Внедрение заканчивается не отчётом, а работающим контуром на вашей стороне. Anchore Engine разворачивается в вашей инфраструктуре, поэтому настройки, правила и инструкции остаются у вашей команды — чтобы поменять порог блокировки или подключить новый реестр, не нужно обращаться к нам.
- Файлы конфигурации — параметры сканера, источники баз уязвимостей, расписание обхода образов, глубина и срок хранения результатов.
- Схема интеграции — цепочка «реестр → сборка → сканирование → допуск к выкату» с точками отказа и описанием поведения, когда сканер недоступен.
- Политики блокировки — какие классы уязвимостей останавливают выпуск, что уходит в исключения, с каким сроком пересмотра и кто их снимает.
- Регламент реагирования — уровни критичности, сроки реакции дежурной смены, порядок эскалации, шаблон записи об инциденте.
- Инструкции по эксплуатации — обновление баз уязвимостей, ротация доступов к реестру, проверка работоспособности, разбор типовых отказов.
- Отчёт по базовой линии — какие образы уже нарушают политику на момент сдачи и какой объём работы предстоит закрыть.
- Матрица ролей и доступов — кто меняет политику, кто только читает отчёты и как эти действия логируются.
Всё передаётся в версионируемом виде: правки политик проходят через тот же процесс проверки, что и код, а история изменений остаётся восстанавливаемой.
Кейс: убрали уязвимые образы из продакшена
Заказчик — продуктовый контур из нескольких десятков сервисов, релизы каждую неделю. Сборка образов была отлажена, а вот проверка состава — нет: манифест базового слоя и зависимости не анализировались, поэтому уязвимый пакет мог дойти до рабочего контура и жить там месяцами. Находили такое обычно не мы, а внешний сканер периметра или разбор инцидента, когда исправлять уже поздно и дорого.
Мы встроили сканирование в сборку: Anchore Engine разбирает образ послойно и показывает, в каком пакете и на каком слое пришла уязвимость. Политика останавливает сборку при критичных находках, для которых есть исправление; остальное уходит в отчёт с приоритетом и назначенным сроком. Обновление баз уязвимостей идёт по расписанию, поэтому вердикт по образу не устаревает.
Метрики до и после
До: проверку не проходил ни один образ, девять из десяти критичных находок обнаруживались уже в рабочем контуре, среднее время от появления уязвимости до исправления — около недели. После: через сканирование проходит каждый образ, восемь из десяти критичных находок гасятся до публикации в реестре, реакция на новую уязвимость в используемом пакете — часы, а не дни.
Для цикла выпуска это дало предсказуемость: внеплановые выпуски только по безопасности сократились втрое, откатов из-за уязвимого слоя не было ни одного. Команда перестала тратить время на разбор того, что должно было отсекаться на сборке.
Чем Anchore Engine отличается от сканеров в реестрах
Встроенный сканер реестра проверяет образ в момент отправки и не пускает его дальше по списку известных уязвимостей. Отдельной инфраструктуры это не требует, порог срабатывания задаёт провайдер. Дальше начинаются ограничения: свои правила допуска задать нельзя, отчёта по составу пакетов нет, а история находок исчезает вместе с перезаписанным тегом.
Anchore Engine — отдельный сервис: разбирает образ на слои, собирает список пакетов и версий операционной системы и оценивает его по правилам, которые пишет ваша команда. Проверка идёт не только при отправке, но и по расписанию — новая запись в базе уязвимостей переводит уже выпущенный образ в статус «есть находки» без пересборки.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Встроенный сканер реестра | Один реестр, одна команда, нужен только запрет на входе | Правила заданы провайдером, нет истории находок и отчёта по составу |
| Открытые сканеры, запускаемые вручную | Разовый аудит перед выпуском или проверка чужого образа | Нет состояния между запусками, результат не воспроизводится |
| Anchore Engine в вашем контуре | Несколько реестров, свои правила допуска, регулярная перепроверка уже выпущенных образов | Нужны хранилище базы уязвимостей и обслуживание сервиса |
Разница не в количестве найденного. Встроенная проверка отвечает на вопрос «пускать ли образ прямо сейчас», отдельный сканер ведёт инвентарь: видно, какие пакеты внутри, кто подтвердил исключение и что изменилось после обновления базы.
Технические вопросы о сканировании образов
Вопросы у команд почти всегда одни и те же: заработает ли Anchore Engine в закрытом контуре, не удлинит ли проверка сборку, как жить с шумом срабатываний и что делать с уже запущенными контейнерами. Ниже — как каждое из этих мест закрывается в конфигурации.
Закрытый контур без выхода наружу — сканирование заработает?
Да. База уязвимостей заезжает внутрь пакетом изменений через внутреннее зеркало: источник обновляется на периметре, а в контур уходит только готовый набор данных. Образы и сведения о пакетах наружу не передаются.
Проверка удлинит сборку?
Только если оставить её в критическом пути. Скан запускается параллельно сборке следующего образа или сразу после публикации тега — на отдельном узле. Конвейер не ждёт вердикта: отчёт приходит асинхронно, длительность сборки не меняется.
Ложные срабатывания заблокируют выпуск?
Блокировка срабатывает только на выбранном уровне критичности. Остальное закрывается правилами исключений: конкретный идентификатор уязвимости, версия пакета, срок действия записи и обязательная отметка в журнале. Тихого отключения проверок не получается.
Что делать с уже развёрнутыми образами?
Пересобирать весь парк сразу не нужно. Сначала инвентаризация работающих тегов, затем плановое пересканирование по расписанию и сортировка находок по достижимости во время работы. В релиз попадает то, что действительно используется.
Обсудим задачу сканирования ваших образов
Чтобы вернуться с оценкой работ, а не с общими словами, нам нужны вводные по вашему контуру. Сканирование образов через Anchore Engine настраивается под конкретную инфраструктуру: одна и та же политика на разных сборочных контурах даёт разный объём находок и разное время сборки. Поэтому сначала собираем картину, а уже потом предлагаем план внедрения и подбор режима.
- Реестр и доступы: какой реестр используется, сколько репозиториев и тегов активно, какие права на чтение образов можно выдать.
- Сборочный контур: где и чем собираются образы, есть ли отдельные ветки под релизы и как часто выходят новые версии.
- Базовые слои: публичные базовые образы или внутренние, есть ли требования к их происхождению.
- Требования безопасности: какие классы уязвимостей критичны, нужен ли контроль лицензий и секретов в слоях, кто утверждает исключения.
- Порог отказа: какой уровень находок блокирует выпуск, а какой только попадает в журнал для разбора.
- Интеграции: куда складывать отчёты и как уведомлять команды — почта, задачи, чат, панель.
- Зона ответственности: что закрываем мы, а что остаётся на вашей стороне при эксплуатации.
Опишите задачу в удобном формате — вернёмся с оценкой работ, планом внедрения и подбором режима проверок под ваш контур.
