Типично ли для образа докера иметь более 900 уязвимостей при сканировании изображения?

Question

Я проверил образ докера ruby ​​debian через сканирование контейнера gitlab, и он вернулся со списком из более чем 900 CVE с большим чанком, датированным 2016 и 2017 годами. Это свежая версия официального образа докера ruby. Все CVE перечислены как исходящие из образа debian 9. Это типичный результат сканирования контейнеров, могу ли я что-то сделать с этим? Я бы подумал, что образы Debian будут обновляться и защищаться.

Точное изображение было извлечено ruby:2.5.1 из dockerhub

Answer 1

По моему опыту, это на самом деле типично, и я видел две причины, по которым это происходит.

Во-первых, особенно для языковых переводчиков, которые могут иметь расширения на С, иногда предварительно упакованное изображение содержитполный набор инструментов для сборки CЭто включает заголовки ядра Linux.Поскольку у вас есть заголовки ядра Linux, вы отключите громкие сигналы тревоги от сканера безопасности, если у вас устаревшее ядро, даже если сам Docker не запускает ядро.

Вторым являетсянемного страшнееЕсли вы посмотрите на https://hub.docker.com/_/ruby, то увидите, что сейчас есть изображение MRI 2.5.5, а не изображение 2.5.1, перечисленное там.Общая практика заключается в создании одной версии образа для каждого вспомогательного выпуска, но после выхода нового выпуска исправления прекратите публикацию обновлений для более старых выпусков исправлений.То есть у вашего образа 2.5.1, вероятно, есть некоторые проблемы с безопасностью, и никогда не будет более нового официального образа, который их исправит.

Лучшее решение, которое я нашел, - это создать свой собственный язык.базовый образ интерпретатора, начиная с дистрибутива Linux по вашему выбору, и периодически перестраивайте его самостоятельно.Тогда это под вашим контролем, и вы обязательно будете иметь обновления безопасности, когда будете делать релизы.

Answer 2

Точное извлеченное изображение было ruby:2.5.1 из dockerhub

Как упоминает Дэвид, вы перестанете видеть сборки для одного патча, когда выйдет следующий патч.За кулисами, если вы сконфигурируете docker hub для выполнения ваших сборок за вас, вы увидите, что docker зависит от тегов на вашем репозитории github, и когда вы помечаете свой код, сборка запускается из этого.Вы можете узнать больше об их автоматизированных сборках здесь .Поэтому, если вы не откажетесь от старого тега, он не будет обновляться автоматически.В этом случае тег 2.5.1 последний раз выдвигался 6 месяцев назад, и было несколько выпусков 2.5.x, которые заменили его.

Вы можете клонировать ruby ​​repo и выполнитьваши собственные сборки основаны на этом по вашему собственному расписанию.Вытягивая свежие базовые изображения, вы обновите свое изображение.

Вы также можете использовать рубиновое изображение на альпийской основе, которое будет иметь гораздо меньшее базовое изображение.Уменьшенный размер означает, что меньше предварительно установленных приложений, которые потенциально могут быть уязвимы.Однако это связано с некоторыми проблемами с удобством использования, такими как musl вместо libc, и некоторые другие предустановленные приложения могут оказаться полезными.

Самый простой ответ - не использовать конкретную версию патча, когда у вас есть semverна основе номеров версий.Таким образом, вместо ruby:2.5.1 вы можете получить ruby:2.5, и когда выйдет 2.5.2, он обновит тег 2.5 для вашего следующего запуска.Есть даже простой ruby:2 образ, который автоматически обновит вас до текущей версии 2.6, не вызывая серьезных изменений из версии 3.x всякий раз, когда это произойдет.

Наконец, если вам нравится установка на основе Debian поверхАльпийская версия, вы все еще можете переключиться на свернутую версию Debian с тонкими изображениями.В этом случае ruby:2.5-slim будет меньше, но при этом сохраняются обновления с самой последней версией 2.5.