Cómo escanear vulnerabilidades en imágenes Docker

Contenido del curso

Optimización Avanzada en Docker

Buenas Prácticas en Docker

Instalación y Configuración en Entornos Multiplataforma

Redes Avanzadas y Balanceo de Carga

Automatización de CI/CD

Orquestación

Develop

34
Dev containers en VS Code con Docker
09:54 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:45

Cómo escanear vulnerabilidades en imágenes Docker

Curso de Docker Avanzado

Clase 4 de 34

Clase 4 / 34

Recursos

Antes de publicar una imagen, necesitas escanear vulnerabilidades en imágenes Docker para detectar riesgos críticos. La buena noticia: no buscas cero vulnerabilidades, sino atacar las que sí pueden comprometer tu aplicación. Esta guía es para quienes despliegan contenedores y quieren un proceso de seguridad real, no perfeccionista.

En Microsoft lo repiten constante: si tienes que elegir entre velocidad y seguridad, la seguridad gana. Y en el mundo de los contenedores, eso se traduce en un paso concreto antes del push: analizar la imagen, leer el reporte y decidir qué mitigar.

¿Cómo se construye y analiza una imagen Docker para detectar CVEs?

El flujo arranca con la construcción de la imagen desde el Dockerfile y termina en el panel de análisis de Docker Desktop, donde puedes ver paquetes y CVEs asociados [02:00].

Los pasos son directos:

Ubícate en la carpeta donde está tu Dockerfile.
Ejecuta docker build -t docker-scan . para compilar la imagen.
Abre Docker Desktop y refresca la lista de imágenes.
En los tres puntos de la imagen, elige la opción ver paquetes y CVEs.

Docker Desktop empieza el análisis automático y devuelve un listado de vulnerabilidades clasificadas por severidad. Aquí es donde se separa lo cosmético de lo realmente urgente.

¿Qué es un CVE en Docker? Es un identificador público de una vulnerabilidad conocida. Docker Scout cruza los paquetes de tu imagen contra esa base y te dice cuáles te afectan.

¿Por qué la imagen base genera vulnerabilidades aunque tu Dockerfile esté limpio?

Al revisar el reporte aparece un dato incómodo: la imagen base Debian 12 Slim trae por defecto 23 vulnerabilidades de bajo impacto, todas marcadas en amarillo [03:30]. Tu Dockerfile puede estar impecable y aun así heredas esa superficie de ataque.

Esto introduce una distinción clave: una cosa es la seguridad de tu código y otra muy distinta es la seguridad de la imagen base con la que partes. Tu imagen es tan segura como su capa más débil.

En la vista de Docker Scan puedes recorrer cada etapa del build. La mayoría aparecen en amarillo, pero en la etapa 13 surge una vulnerabilidad de alto impacto que sí merece atención inmediata [04:30].

¿Cómo identificar la regla específica que falla?

Al expandir la vulnerabilidad y abrir el enlace del escaneo, se abre Docker Scout, la herramienta por defecto de Docker para visualizar este tipo de problemas. Ahí encuentras:

El score de severidad. En el ejemplo aparece un 7.5, considerado alto.
El resumen de la vulnerabilidad y su comportamiento.
Los factores de mitigación, cuando existen.
Las versiones afectadas del runtime o paquete.

En el caso mostrado, la vulnerabilidad se relaciona con la omisión del envío de un certificado, lo que abre la puerta a una denegación de servicio. Microsoft no había identificado factores de mitigación oficiales y el problema solo aplicaba a versiones 6 u 8 de .NET.

¿Qué decisiones tomar cuando aparece una vulnerabilidad de alto impacto?

Detectar el problema es solo la mitad. La otra mitad es decidir cómo responder, y eso depende del contexto de tu proyecto.

Las rutas posibles son tres:

Cambiar la imagen base por una versión sin esa vulnerabilidad.
Modificar la etapa del Dockerfile que está exponiendo el riesgo, por ejemplo un puerto innecesario o un comando mal configurado.
Mantener la versión actual y compensar con una solución como agregar un certificado de seguridad.

En el ejemplo de .NET, podrías quedarte en la versión 8 agregando el certificado, retroceder a la versión 7 que no presenta el problema, o incluso volver a la 6 si tu proyecto lo permite. La elección depende de las políticas del equipo y del margen de maniobra que tengas con el runtime.

¿Necesito eliminar todas las vulnerabilidades de mi imagen Docker? No. La meta es priorizar las de alto impacto, como un score de 7.5 o superior, y aceptar de forma consciente las de bajo impacto cuando no hay mitigación viable.

La habilidad indispensable aquí es discernir si el problema vive en la imagen base o en tu Dockerfile. No es lo mismo cambiar una línea de configuración que migrar toda tu aplicación a otro runtime. Esa lectura técnica es lo que separa un escaneo decorativo de una estrategia real de seguridad en contenedores.

Cuéntame en los comentarios qué herramienta usas tú para escanear tus imágenes y cómo decides qué vulnerabilidades atacar primero.