Минимальный контейнерный образ может быть меньше, но не обязательно безопаснее: 19 октября The New Stack обратил внимание на пробел, который остаётся за пределами привычной дискуссии о distroless-подходе. Безопасность distroless-образов упирается не только в отсутствие shell, пакетного менеджера и лишних библиотек в рантайме, но и в происхождение каждого слоя. Для российских DevOps-команд это практичный сигнал: уменьшение образа само по себе не заменяет контроль цепочки поставки.
Как сообщает The New Stack, следующим шагом в эволюции OCI-образов могут стать контейнеры, собранные «снизу вверх» — от проверяемых минимальных компонентов, а не от уже готового базового образа, которому команда вынуждена доверять целиком. Издание называет это ответом на ограничение distroless-образов: они сокращают доступную атакующему поверхность в продакшене, однако не объясняют автоматически, откуда появились включённые в образ файлы, как они собирались и что именно попало внутрь на промежуточных этапах.
Distroless давно стал понятной реакцией на тяжёлые универсальные базовые образы. Если приложению не нужен интерактивный shell, менеджер пакетов и набор привычных утилит Linux, нет большого смысла доставлять их в production-контейнере. Меньше компонентов — меньше пакетов для обновления, меньше известных уязвимостей в отчёте сканера и меньше инструментов, которыми сможет воспользоваться злоумышленник после компрометации процесса. Эта логика здравая, но она легко превращается в удобную метрику: образ стал компактнее, значит задача безопасности будто бы решена.
Именно здесь появляется неприятный нюанс. Сканер может показать немного CVE, потому что в образе почти нет пакетов, которые он умеет распознавать. Но это не равнозначно доказательству, что приложение собрано из доверенных исходников и зависимостей. В финальном слое могут оказаться скомпилированный бинарник, сертификаты, конфигурация, сторонние библиотеки или артефакты сборки; их минимальный набор ещё нужно уметь проследить. «Пустой» образ без понятной истории происхождения — не нулевая поверхность атаки, а скорее более тихий отчёт о ней.
Подход bottom-up переносит фокус с состава финального контейнера на процесс его создания. Вопрос звучит уже не «какой базовый образ взять?», а «из каких исходных, проверяемых и воспроизводимых частей получен каждый элемент образа?». Для OCI это особенно важно: формат удобен именно тем, что образ состоит из слоёв, которые можно переносить между средами и реестрами. Та же модульность требует дисциплины: команде нужны ясные правила для зависимостей, сборочных окружений, подписей артефактов и проверки того, что опубликованный образ соответствует тому, что прошло CI/CD.
Для разработчика это означает дополнительную работу не в момент деплоя, а раньше — в пайплайне. Полезно отделить сборочную среду от рантайма, фиксировать версии зависимостей, хранить сведения о составе артефакта и не считать результаты сканирования единственным критерием допуска в реестр. Для платформенной команды — определить, какие базовые компоненты разрешены, кто их обновляет и как подтверждается их происхождение. Для бизнеса это менее эффектная, но важная часть управления риском: инцидент часто начинается не с того, что в контейнере оказался bash, а с того, что никто не может быстро установить источник уязвимого или подменённого компонента.
Безопасность distroless-образов поэтому стоит оценивать в двух плоскостях. Первая — эксплуатационная: достаточно ли в контейнере лишних утилит, библиотек и сервисов, которые можно атаковать или использовать после проникновения. Вторая — производственная: можно ли воспроизвести сборку, проверить зависимости и доказать состав доставленного образа. Distroless уверенно помогает с первой задачей. Вторая требует процессов, инструментов и ответственности, которые не появляются вместе с новым тегом в Dockerfile.
У российского рынка есть ещё и прикладной повод смотреть на эту тему внимательнее: локальные реестры, собственные форки, изолированные контуры и зеркала зависимостей добавляют точки, где теряется прозрачность происхождения артефактов. В таких условиях слепо доверять «официальному» минимальному образу не всегда возможно, а пересборка из контролируемых компонентов становится не академическим упражнением, а способом быстрее проходить аудит и расследовать инциденты.
Главный вопрос теперь не в том, вытеснят ли bottom-up-контейнеры distroless-образы. Вероятнее, они станут следующим уровнем той же практики: минимальный рантайм останется полезным, но безопасность distroless-образов будут измерять не размером образа и числом CVE в одной панели, а проверяемостью пути от исходного кода до запущенного в кластере артефакта.