Seguridad de contenedores durante todo el SDLC

Los contenedores se están convirtiendo cada vez más en la unidad estándar del software. La imagen de contenedor, definida técnicamente en la especificación de imágenes OCI, es un componente clave de las herramientas modernas, desde Docker hasta Kubernetes y plataformas como AWS Fargate y Google Cloud Run. ¿Qué implica esto para la seguridad de las aplicaciones?

Dónde usamos imágenes de contenedor

Uno de los aspectos interesantes de las imágenes de contenedor es que abarcan el ciclo de vida del desarrollo de software (SDLC).

• Los desarrolladores crean imágenes de forma local, que ofrecen una manera práctica de distribuir software fácilmente (a veces, demasiado fácilmente).

• Las imágenes también se crean como parte de los pipelines de integración continua y entrega continua. Es posible adjuntar metadatos sobre la aplicación a la imagen para mejorar la administración de activos.

• Las imágenes se cargan en registros, tanto públicos como privados, desde donde se pueden compartir para su implementación.

• Por último, las imágenes se implementan en clústeres, desde desarrollo y pruebas hasta producción, cada vez más administrados por Kubernetes o herramientas similares.

Cada una de estas etapas ofrece la oportunidad de analizar la imagen en busca de vulnerabilidades de seguridad. Pero ¿cuál es el mejor momento para hacerlo?

¿Dónde debemos analizar nuestras imágenes?

Cuando se trata de proteger nuestras imágenes de contenedor, es fácil pensar que debemos analizarlas en un solo punto del SDLC. Por ejemplo, si solo tienes imágenes seguras en tu registro, estás protegido, ¿verdad? La realidad es más interesante y, por lo general, implica ciertas concesiones.

Cuanto más cerca de producción realices el análisis, más confianza tendrás en que comprendes los riesgos de las aplicaciones en ejecución. A menos que seas un proveedor de software que crea herramientas para que otras personas las usen, probablemente te interese principalmente proteger las aplicaciones que ejecutas en producción ahora mismo. Analizar al final del ciclo también es útil cuando se divulga una nueva vulnerabilidad en una dependencia que usas. Así puedes evaluar rápidamente qué aplicaciones de producción están afectadas y actuar con la urgencia adecuada.

Sin embargo, analizar solo al final del SSDLC probablemente implique ciclos de retroalimentación lentos para los desarrolladores. El desarrollador que decidió usar o modificar una imagen siguió trabajando sobre ella y ahora se ocupa de otras tareas. Por eso, hacer los cambios necesarios para cerrar la brecha de seguridad resulta disruptivo y costoso. Recuerda que el objetivo no es solo saber qué vulnerabilidades podrías tener (lo cual es importante), sino corregirlas. El análisis local ofrece el ciclo de retroalimentación más rápido, pero depende de que cada desarrollador se acuerde de analizar cada vez, algo que difícilmente sea exhaustivo o realista.

Antes de concluir que el pipeline es, por lo tanto, el lugar correcto para realizar el análisis, también vale la pena considerar el costo de implementación. Es posible que tengas uno o dos registros de contenedores centralizados, lo que te permite evaluar todas las imágenes que creas, pero probablemente tengas muchos más pipelines de integración continua. Según tu nivel de automatización y quién esté a cargo de las distintas herramientas de tu organización, quizá te resulte más práctico comenzar en un lugar o en otro.

También cabe destacar que contamos con distintos niveles de contexto en las diferentes etapas del SDLC. Analizar de forma local o en CI probablemente signifique que tenemos acceso tanto al código fuente como a la información del control de versiones. Esto podría facilitar la detección de ciertos tipos de problemas; por ejemplo, los que se deben al compilador utilizado o a confirmaciones sin firmar de un actor malicioso. También ayuda a entender cómo se incorporó una biblioteca. Sin embargo, analizar en producción significa que sabemos exactamente qué imágenes se usan y dónde, así como la manera en que están configuradas, lo que podría ayudarnos a priorizar los problemas que hemos detectado.

Conclusión

La realidad es que analizar en un solo lugar puede satisfacer las necesidades de una función (ya sea desarrollo, operaciones o seguridad), pero probablemente no cumpla por completo el objetivo general del negocio: encontrar y corregir vulnerabilidades lo más rápido posible. A modo de resumen:

Análisis de vulnerabilidades en distintas etapas del SDLC

La opción por la que comiences depende de las características de tu organización. Sin embargo, el objetivo ideal es analizar exhaustivamente las aplicaciones basadas en contenedores durante todo el SDLC. Depender de un único punto de control es demasiado simplista y probablemente genere fricciones entre los equipos de desarrollo, operaciones y seguridad, o afecte la rapidez con la que implementas aplicaciones.