Nuestra organización requiere que parcheemos todas las vulnerabilidades Altas/Críticas en nuestras imágenes de Docker antes de poder implementarlas en producción. Actualmente, nuestra compilación de Discourse, que se basa en discourse/base:2.0.20251008-0017-web-only, tiene algunas de ellas que estamos intentando parchear si es posible. A continuación, se muestra la lista de vulnerabilidades que necesitamos parchear.
¿Podrían darme alguna orientación sobre si actualizar alguna de estas ciegamente a versiones que hayan solucionado estas vulnerabilidades podría causar algún problema? Si es así, ¿cómo podemos averiguar si una actualización está causando un problema?
Además, noto que hay muchas vulnerabilidades relacionadas con golang. ¿Discourse utiliza golang de alguna manera durante el tiempo de ejecución, o podemos simplemente eliminarlo por completo de la imagen final? Lo mismo ocurre con python.
Creo que podrías intentarlo y ver qué pasa. Un montón de gente tiene un trabajo a tiempo completo gestionando la seguridad y las versiones de las bibliotecas.
Pero espera. Si estás mirando la imagen base de Docker (oh, tal vez te refieres a la imagen que construiste; no puedo decirlo con seguridad), entonces creo que tu trabajo es imposible, ya que gran parte de eso se gestiona en el código fuente de Discourse. Por ejemplo, este commit actualiza Rack a 2.2.20. La versión en la imagen base de Docker no importa. Probablemente quieras construir tu imagen con launcher y luego ver qué versiones de cosas tienes. Luego podrías añadir algo de yaml para eliminar go y python, por ejemplo.
Además, hay un montón de problemas de seguridad que solo son problemas cuando hay otros usuarios en el sistema, por lo que tenerlos en tu contenedor Docker realmente no importa, por lo que es poco probable que sea una prioridad para el equipo de Discourse.
Nuestro proceso de compilación actual comienza con la imagen base de Discourse mencionada en el mensaje anterior y luego ejecuta un script, que es solo el paso de arranque del proceso de instalación compatible (el script del lanzador), pero sin ejecutar los pasos que requieren una conexión activa a Redis/base de datos.
Por lo tanto, el paso de arranque, supongo, instala todas las dependencias de Ruby y las dependencias de npm de Discourse. Las versiones que aparecen en la lista de vulnerabilidades son, en su mayoría, dependencias de la propia aplicación de Discourse.
También investigué un poco y descubrí que las dependencias de Golang que etiqueta provienen de una dependencia de npm llamada esbuild, que se compila usando Golang. La versión de Go que utiliza tiene una vulnerabilidad en la biblioteca estándar, que está siendo etiquetada. Por lo tanto, creo que resolver esto requeriría una recompilación de esa biblioteca, por lo que no estoy seguro de si vale la pena el esfuerzo.
Pero las otras vulnerabilidades son dependencias directas de Ruby/npm o dependencias transitivas de Discourse. Mi pregunta era principalmente sobre la actualización de las versiones de esas, justo antes de instalarlas. Entiendo que sería difícil para los desarrolladores de Discourse trabajar en la solución de esas. Solo estaba tratando de entender si había una manera de verificar si la “actualización” causa un problema o no, ya que supuse que algunas dependencias podrían causar problemas solo en ciertas rutas de código.