Наша организация требует, чтобы мы исправляли все уязвимости высокого и критического уровня в наших Docker-образах перед их развертыванием в продакшен. В настоящее время наша сборка Discourse, основанная на discourse/base:2.0.20251008-0017-web-only, содержит несколько таких уязвимостей, которые мы пытаемся устранить, если это возможно. Ниже приведен список уязвимостей, которые нам необходимо исправить.
Можете ли вы дать какие-либо рекомендации относительно того, вызовет ли бездумное обновление любых из этих компонентов до версий, в которых исправлены соответствующие уязвимости, какие-либо проблемы? Если да, как мы можем определить, что обновление вызывает проблему?
Также я заметил, что существует множество уязвимостей, связанных с golang. Использует ли Discourse golang каким-либо образом во время выполнения, или мы можем полностью удалить его из итогового образа? То же самое касается и python.
Думаю, можно просто попробовать и посмотреть, что получится. У целой группы людей есть постоянная работа по управлению безопасностью и версиями библиотек.
Но подождите. Если вы смотрите на базовый образ Docker (хотя, возможно, вы имеете в виду образ, который вы собрали сами; я не совсем уверен), то, на мой взгляд, ваша задача невыполнима, поскольку многое из этого управляется в исходном коде Discourse. Например, этот коммит обновляет Rack до версии 2.2.20. Версия в базовом образе Docker не имеет значения. Скорее всего, вам стоит собрать свой образ с помощью launcher, а затем посмотреть, какие версии компонентов у вас есть. После этого вы можете добавить немного YAML-конфигурации, чтобы, например, удалить go и python.
Кроме того, существует множество проблем безопасности, которые становятся актуальными только при наличии других пользователей в системе, поэтому наличие их в вашем контейнере Docker на самом деле не имеет значения, и для команды Discourse это вряд ли будет приоритетом.
Наш текущий процесс сборки начинается с базового образа Discourse, упомянутого в предыдущем сообщении, затем выполняется скрипт — это лишь этап инициализации (bootstrap) из поддерживаемого процесса установки (скрипт запуска), но без шагов, требующих активного подключения к Redis/БД.
Таким образом, этап инициализации, как я полагаю, устанавливает все зависимости Ruby и npm для Discourse. Версии, которые появляются в списке уязвимостей, в основном относятся к зависимостям самого приложения Discourse.
Я также провёл небольшое расследование и выяснил, что зависимости Go, на которые указываются, относятся к npm-пакету esbuild, который собран с использованием Go. Версия Go, используемая этим пакетом, содержит уязвимость в стандартной библиотеке, что и приводит к её отметке. Поэтому, думаю, решение этой проблемы потребует перекомпиляции этой библиотеки, и я не уверен, стоит ли прилагать для этого усилия.
Остальные уязвимости — это либо прямые зависимости Ruby/npm, либо транзитивные зависимости Discourse. Мой вопрос касался в основном обновления версий этих зависимостей непосредственно перед их установкой. Я понимаю, что разработчикам Discourse может быть сложно работать над исправлением этих проблем. Я просто хотел понять, существует ли способ проверить, вызовет ли «обновление» какие-либо проблемы, поскольку, возможно, некоторые зависимости создают проблемы только в определённых путях выполнения кода.