Consejos para fortalecer tu estrategia de seguridad de imágenes de contenedor

En la primera parte de esta serie de blogs, analizamos las prácticas recomendadas de seguridad para las imágenes base que podrías estar usando. Pero ¿qué pasa con la seguridad de las imágenes de contenedor cuando les agregamos otros elementos? Quizás instalamos software adicional desde fuentes upstream y tenemos aplicaciones personalizadas propias que también podrían instalar sus propias dependencias. Estos elementos que agregamos están bajo nuestro control, así que debemos asumir la responsabilidad de corregir las vulnerabilidades que hemos introducido.

Crea una línea base

Al crear tus imágenes de contenedor, es buena idea analizar solo la imagen base antes de agregar modificaciones. De esta manera, estableces una línea base de seguridad para la imagen de contenedor y puedes ver fácilmente qué vulnerabilidades estaban en la imagen base y cuáles agregaste en las capas posteriores. Si creas imágenes con varias capas adicionales —quizás una capa de middleware personalizada además de tu aplicación—, también es recomendable establecer una línea base en cada uno de esos puntos y mantener esas imágenes por separado. Así podrás identificar claramente de dónde provienen las vulnerabilidades.

Establece prioridades

Probablemente no sea realista esperar una seguridad total en las imágenes de contenedor (es decir, que no tengan ninguna vulnerabilidad), excepto en el caso de aplicaciones muy simples. Como no contamos con recursos ilimitados para corregir todo, debemos priorizar y decidir qué vulnerabilidades corregir y cuáles podríamos aceptar.

Sin embargo, puede ser muy difícil tomar esas decisiones si trabajas con imágenes en las que el escáner detecta una gran cantidad de vulnerabilidades. El análisis de seguridad puede generar tanta información que abrume a quien la consulta, lo que puede llevar a ignorar o desactivar el análisis por completo.

Además, las vulnerabilidades no son un juego de suma cero. Una vulnerabilidad específica quizá solo represente un problema en circunstancias muy concretas, o en una arquitectura o plataforma determinadas. Sin leer los detalles de cada vulnerabilidad, ¿cómo podemos decidir cuáles representan un problema en nuestro entorno?

La priorización no es una ciencia exacta y puede basarse en diversos factores. La gravedad por sí sola no nos dice mucho más que el impacto potencial. La puntuación CVSS, que tiene en cuenta factores como la posibilidad de explotación y el impacto, nos da más contexto; pero también podemos usar información como el grado de madurez del código de explotación disponible y, sobre todo, si hay una corrección disponible. Probablemente sea obvio que conviene corregir primero las vulnerabilidades de gravedad alta que cuentan con un exploit y una corrección disponible. Las puntuaciones de priorización de Snyk tienen en cuenta todos estos factores al presentar las vulnerabilidades, para que los desarrolladores cuenten con información clara que les ayude a tomar decisiones.

Define una estrategia de seguridad para imágenes de contenedor

La seguridad casi siempre implica una serie de concesiones, en particular entre el esfuerzo y el riesgo. ¿Cuánto esfuerzo requiere corregir algo y qué riesgo representa en mi entorno específico? Al decidir cómo priorizar la corrección de vulnerabilidades de seguridad, definir una estrategia suele ser el primer paso. Un ejemplo muy sencillo podría ser:

• Ningún CVE de gravedad alta en producción

• Nada que tenga un exploit maduro

• Aplicar los parches disponibles

Si sigues estas pautas, probablemente reducirás drásticamente la cantidad total de vulnerabilidades en la mayoría de los casos.

Mitigación de riesgos: cada entorno es diferente

Aunque las puntuaciones te dan una idea de la gravedad, es evidente que hay elementos subjetivos. Por ejemplo, podrías decidir que una vulnerabilidad de gravedad alta que requiere acceso local a la shell representa un riesgo menor en tu entorno específico porque tienes otros controles para proteger ese acceso. Podrías usar contenedores distroless, que no incluyen una shell, y estos controles mitigarían el riesgo.

Comprende los límites de seguridad

En algunos entornos, podrías considerar que la red es confiable y que, por lo tanto, cualquier vulnerabilidad expuesta a esa red representa un problema menor. Este escenario es problemático en la mayoría de los entornos informáticos modernos, ya que la conectividad es tan compleja que resulta muy difícil establecer límites, salvo en entornos totalmente aislados de la red. Esto se vuelve especialmente problemático en entornos de nube. Además, no te protege frente a actores maliciosos internos, que pueden representar un riesgo considerable, sobre todo en organizaciones grandes. Por lo general, es más seguro considerar que ninguna de tus redes es confiable.

Conoce tus herramientas

Aquí es donde entra en juego entender las herramientas que usamos para detectar estos problemas. La mayoría de las herramientas de análisis de imágenes te permiten filtrar sus resultados para configurar qué información te interesa más. Esto es especialmente importante al integrar el análisis de seguridad en tus pipelines de entrega de software. No quieres que las compilaciones o implementaciones fallen continuamente por información irrelevante o por riesgos que decidiste mitigar de otras maneras. Snyk ofrece el indicador --fail-on flag para controlar el estado de salida del análisis de la CLI, de modo que la CLI solo indique un fallo en determinadas circunstancias. Por ejemplo:

1snyk container test purpledobie/mattj-goof --fail-on upgradable

Este comando solo terminará con un fallo si encuentra al menos una vulnerabilidad actualizable en la imagen, pero no si encuentra vulnerabilidades que no se pueden corregir o para las que no hay parches.

La Snyk CLI también ofrece resultados en formato JSON para aplicar filtros posteriormente. Con estos resultados, es posible crear filtros complejos usando herramientas como jq:

1snyk container test purpledobie/mattj-goof --json | jq '.vulnerabilities[] | select(.CVSSv3 | test("AV:N"))'

Este ejemplo muy sencillo solo mostrará las vulnerabilidades que se pueden explotar desde la red, ya que filtra la lista de vulnerabilidades según si el vector de ataque de la puntuación CVSS está configurado como Network. Al crear filtros como este, puedes implementar en tus análisis una toma de decisiones compleja basada en políticas.

Automatiza la corrección

Una vez que hayas definido tu estrategia y configurado tus herramientas, habilitar la automatización de las correcciones puede reducir la carga cognitiva de los desarrolladores (al requerir menos decisiones) y también los recursos necesarios. Los pull request automatizados para problemas que encajan claramente en la estrategia general y tienen correcciones disponibles facilitan que los equipos de desarrollo corrijan problemas de forma continua, y reservan los recursos manuales para casos límite más complejos.

Seguridad integral de imágenes de contenedor

Es posible que el análisis de contenedores no detecte elementos como los binarios que se agregan fuera de los paquetes durante el proceso de compilación. Por eso, el análisis de imágenes de contenedor no debería ser tu única protección. También es importante analizar tu base de código y tus Dockerfiles. Para las cargas de trabajo en producción, casi con certeza querrás adoptar el principio de defensa en profundidad e incluir otras comprobaciones de seguridad, como la detección de anomalías en tiempo de ejecución y el análisis de endpoints.

Mantén tus contenedores seguros

Hay muchos aspectos que considerar al abordar la seguridad de las imágenes de contenedor, pero esperamos que esta publicación te haya ayudado a aclarar algunos puntos de partida. Para comprobar qué tan seguras son tus imágenes de contenedor actuales, crea una cuenta gratuita de Snyk y ejecuta un análisis.