Docker scan detecta vulnerabilidades

La seguridad en imágenes de Docker no es negociable: antes de publicar, hay que escanear y priorizar vulnerabilidades. La consigna es clara y práctica: no necesitas cero vulnerabilidades, necesitas enfocarte en las que pueden afectarte más. Aquí verás cómo analizar tu imagen, interpretar hallazgos y decidir acciones concretas con herramientas como Docker Desktop y Scout.

¿Por qué escanear imágenes de Docker antes de publicar?

La prioridad es la seguridad, siempre. Incluso si trabajas con imágenes multietapa (multi-stages), debes verificar riesgos antes de compartir o desplegar. El objetivo no es la perfección, sino atender lo crítico. Escanear te revela vulnerabilidades derivadas tanto de tu configuración como de la imagen base, para que tomes decisiones informadas.

¿Cómo construir y analizar una imagen con Docker Desktop y Docker Scan?

Partiendo de un proyecto con su Dockerfile abierto en Visual Studio Code, el flujo es directo: construir la imagen y luego analizarla en Docker Desktop.

• Construir la imagen desde la terminal.
• Abrir Docker Desktop y refrescar para ver la imagen creada.
• Usar la opción Ver paquetes y CVS para iniciar el análisis automático.

Ejemplo de construcción:

docker build -t dockerscan .

¿Qué muestra el análisis de vulnerabilidades y la imagen base?

El escaneo revela un panorama útil para priorizar. En el ejemplo, aparecen 23 vulnerabilidades en amarillo (bajo impacto) asociadas a la imagen despliegue. Al revisar la imagen base oficial, Debian 12 Slim, se observa que ya trae esas 23 vulnerabilidades. Conclusión: aunque tu imagen parezca “segura”, la base puede no serlo.

Además, se detecta una vulnerabilidad de alto impacto en la etapa trece. Al expandir el detalle y abrir el enlace, Docker Desktop muestra Scout, que es la herramienta por defecto para visualizar el escaneo. Ahí se reporta un score 7.5 (alto), suficiente para entrar en tu plan de mitigación.

¿Cómo decidir entre cambiar imagen base o ajustar el Dockerfile?

La clave es discernir si el problema viene de la imagen base o de una instrucción del Dockerfile. Podría ser que expongas un puerto o ejecutes un comando no ideal para esa imagen. Esta habilidad de diagnóstico es indispensable.

• Leer el resumen del problema y la regla que falla.
• Confirmar si el origen es la base o una etapa específica.
• Evaluar impacto y esfuerzo de cambio.

En el caso descrito, la vulnerabilidad está relacionada con el envío u omisión de un certificado, lo que puede derivar en una denegación de servicio. En los “factores de mitigación”, Microsoft no identifica mitigaciones y señala que sucede en versiones seis u ocho.

Opciones contempladas:

• Mantener .NET 8 agregando un certificado de seguridad.
• Regresar a .NET 7, donde no aparece este problema.
• Volver a .NET 6 (menos recomendado por antigüedad), agregando el certificado.

La elección depende del escenario: políticas del proyecto, capacidad de cambio de versión o necesidad de estabilidad.

¿Qué acciones prácticas puedes tomar para mitigar?

• Cambiar la imagen base si el origen está fuera de tu control.
• Omitir o ajustar la etapa del Dockerfile que dispara el riesgo.
• Agregar el certificado de seguridad cuando aplique.
• Mantener o modificar la versión de .NET según políticas.
• Documentar un plan de acción por escenario: flexible, versión fija o mitigación puntual.

Si el escaneo con Scout marca alto impacto, actúa primero sobre eso. Luego atiende lo de bajo impacto según prioridad y contexto.

¿Tienes una estrategia efectiva para tu entorno y tus restricciones? Comparte tu enfoque y decisiones clave para enriquecer la discusión técnica.