Seguridad continua en DevSecOps

¿Qué es el monitoreo continuo de seguridad?

El monitoreo continuo de seguridad es la evolución natural de la seguridad. El desarrollo de software moderno avanza hacia un modelo de continuidad total, desde la integración hasta la entrega o implementación. Los enfoques tradicionales de seguridad se centran en probar las versiones de software después de su puesta en producción, pero esto genera cuellos de botella en el desarrollo y puede hacer que las vulnerabilidades lleguen a producción. La seguridad continua, en cambio, integra la seguridad en el proceso de desarrollo, lo que reduce los riesgos y elimina los cuellos de botella para acelerar las entregas.

¿Qué beneficios ofrece la seguridad continua?

El desarrollo de software moderno se caracteriza por arquitecturas y capas de infraestructura complejas. Enfoques como las aplicaciones nativas de la nube, los microservicios y la contenerización permiten a los desarrolladores probar y entregar código con mayor rapidez. Las versiones suelen ser pequeñas y rápidas. Los entornos pueden implementar cambios en producción varias veces al día.

La seguridad de DevOps requiere un nuevo enfoque para hacer frente a este rápido aumento en la velocidad de cambio del software. Los métodos de seguridad heredados probaban el software al final del ciclo de desarrollo o una vez que llegaba a producción. A menudo, equipos externos se encargaban de las pruebas, lo que generaba fricciones entre desarrolladores y profesionales de seguridad.

Además, los enfoques de seguridad heredados no están bien adaptados a las arquitecturas y la infraestructura de software modernas. La infraestructura en la nube puede ponerse en marcha en minutos. La arquitectura no está bien definida. Esto resulta atractivo para los desarrolladores modernos, pero amplía la superficie de ataque y hace que sea más difícil protegerla. Los enfoques de seguridad heredados no están bien preparados para probar estos entornos.

La seguridad continua es una extensión natural de las prácticas de DevOps que integra la seguridad en el pipeline de CI/CD. Está estrechamente relacionada con el concepto de DevSecOps y el enfoque de desplazar la seguridad hacia la izquierda. Los equipos de desarrollo asumen la propiedad y la responsabilidad de la seguridad del código para detectar y corregir problemas lo antes posible en el proceso de desarrollo. En definitiva, la seguridad continua acelera la entrega de funciones y automatiza los requisitos de seguridad, lo que mejora la gobernanza y la seguridad.

¿Cómo se integra la seguridad continua en los pipelines de CI/CD?

La seguridad continua aplica políticas y pruebas directamente en el pipeline de CI/CD para proteger la infraestructura y las aplicaciones en cada etapa del ciclo de vida de desarrollo de software:

Modelado de amenazas

Lo ideal es que el modelado de amenazas tenga lugar en las primeras etapas del SDLC. Allí, los desarrolladores modelan los cambios que se producirían al ejecutar el código, pero sin ejecutarlo realmente. Esto permite obtener comentarios casi instantáneos y ofrece la oportunidad de probar las implicaciones de seguridad del código.

El modelado de amenazas puede volverse complejo rápidamente. Un enfoque como STRIDE incluye un análisis independiente para cada uno de los tipos de ataque más comunes:

• Suplantación de identidad

• Manipulación

• Repudio

• Divulgación de información

• Denegación de servicio

• Elevación de privilegios

Metodologías como STRIDE ayudan a evaluar qué estás creando, qué podría salir mal, cómo podrías mitigar esos riesgos y cómo evaluar tu proceso de mitigación de amenazas.

El modelado de amenazas también requiere planificación para que se integre bien con la cultura de DevSecOps. Tradicionalmente, implicaba numerosas reuniones iniciales entre desarrolladores y expertos en seguridad. La seguridad continua aplica un enfoque de desplazar hacia la izquierda al modelado de amenazas, adelantándolo en el proceso de desarrollo, y también aplica el enfoque de «extender hacia la derecha» con herramientas de modelado de terceros para detectar y mitigar amenazas automáticamente en etapas posteriores del pipeline.

Revisión del código y del diseño

Una vez escrito el código, es hora de revisarlo para asegurarse de que haga lo que debe y detectar vulnerabilidades o problemas de seguridad. Este proceso debe incluir la limpieza y validación de todas las entradas mediante una biblioteca confiable, la aplicación de una autenticación segura, el análisis de vulnerabilidades en las dependencias de software y muchas otras verificaciones de seguridad.

Consulta esta guía rápida de revisión de código que creamos para conocer más prácticas recomendadas.

Pruebas

Una vez que se haya validado la seguridad y el diseño del código, es hora de probarlo. En esta etapa, los desarrolladores crean un entorno aislado que puede ponerse en producción y prueban el código en esas condiciones. Esto incluye pruebas automatizadas de llamadas de red, validación de entradas, autorización, registros y control de acceso. ¿La aplicación registra correctamente las métricas de seguridad? ¿El acceso está limitado al grupo adecuado de personas?

Las pruebas continuas de seguridad de este tipo permiten obtener comentarios rápidamente. También pueden incluir el aprovisionamiento y las pruebas de recursos de infraestructura. Por ejemplo, en un entorno de prueba implementado en AWS, se puede usar una herramienta llamada Managed Config Rules para garantizar que los recursos en la nube cumplan con las prácticas recomendadas de configuración de seguridad.

Producción

La producción es el final del recorrido del código, pero no de la seguridad. Los recursos pueden modificarse, agregarse o eliminarse, por lo que las aplicaciones en producción requieren pruebas continuas para verificar el cumplimiento de las normas de la organización, la industria o el gobierno. La seguridad en producción puede incluir la aplicación automatizada de parches, la administración de la configuración y la actualización automática de dependencias.

Veamos algunas de las prácticas recomendadas para crear un programa de seguridad continua eficaz.

¿Cuáles son las prácticas recomendadas para un proceso de seguridad continua?

La seguridad continua requiere planificación

No basta con delegar los objetivos de seguridad al equipo de DevOps y esperar que aplique y haga cumplir los procedimientos. Los equipos de desarrollo no deberían cargar solos con las integraciones. Los equipos de seguridad deben enfocarse en aplicar la seguridad continua con una interrupción mínima, desde la etapa de planificación. Los equipos de seguridad y DevOps deben colaborar desde el principio para incorporar funciones y auditorías, y seguir trabajando juntos durante todo el proceso.

La planificación comienza con el modelado de amenazas durante la conceptualización inicial de un sistema, una aplicación o una historia de usuario. Las pruebas de seguridad de aplicaciones deben ejecutarse automáticamente cuando se realizan cambios en el código y después de la integración. Cualquier posible problema debe señalarse para su revisión y los resultados deben entregarse a los desarrolladores en sus herramientas de desarrollo habituales.

El proceso debe automatizarse tanto como sea posible. Por ejemplo, la implementación debe depender de las métricas de seguridad y de la seguridad en tiempo de ejecución.

La infraestructura requiere atención especial

La flexibilidad de la infraestructura en la nube implica que se deben establecer y aplicar políticas. Estas pueden incluir deshabilitar servicios innecesarios, cerrar puertos que no se usan, hacer cumplir los permisos y asegurarse de que no haya herramientas de desarrollo instaladas en producción.

El código debe compilarse en sistemas operativos seguros con versiones actualizadas de las aplicaciones. También se deben aplicar controles de seguridad relacionados con el tamaño de los clústeres, los permisos para la infraestructura compartida y los socios de infraestructura o plataforma.

Realiza pruebas periódicas (pruebas de penetración, programas de recompensas por errores)

Las pruebas son fundamentales. Garantizan que el código sea funcional y seguro antes de su lanzamiento. También pueden automatizarse para evitar las demoras asociadas con la verificación manual. Las pruebas pueden revelar vectores de ataque, identificar posibles vulnerabilidades de seguridad y clasificarlas según su alcance potencial.

Este nivel de pruebas también debe aplicarse a la infraestructura, las redes y cualquier otro elemento representado como código. El objetivo es analizar todos los componentes de una aplicación para garantizar que se implemente la seguridad adecuada en toda la pila tecnológica.

Usa herramientas que promuevan la seguridad sin interrumpir el trabajo de los desarrolladores

Las herramientas modernas facilitan que los desarrolladores mejoren la seguridad directamente en el pipeline de CI/CD. Las herramientas de pruebas estáticas de seguridad de aplicaciones (SAST) pueden usarse durante la creación del software para encontrar problemas y vulnerabilidades en el código actualizado. Por ejemplo, las herramientas SAST pueden detectar si una entrada del usuario podría activar una función relacionada con la base de datos y generar una vulnerabilidad de seguridad (lo que se conoce como vulnerabilidad de inyección SQL).

Tradicionalmente, las herramientas SAST se usaban como un proceso de CI independiente, pero las herramientas SAST modernas pueden utilizarse mientras se crea el código fuente para ofrecer comentarios rápidos y prácticos a los desarrolladores. Estas herramientas tienen una baja tasa de falsos positivos y también ofrecen información sobre cómo corregir los problemas. Priorizan a los desarrolladores y se integran en el IDE, la CLI y otras herramientas que ya usan.

Las herramientas de análisis de composición de software (SCA) son otra tecnología valiosa para la seguridad continua. Permiten a los desarrolladores revisar los cambios en el código fuente para detectar vulnerabilidades relacionadas con las dependencias antes de fusionarlos.

Los motores de políticas y las herramientas similares a los linters son otros dos tipos de herramientas que se pueden ejecutar cada vez que un desarrollador entrega código. Las herramientas de administración de secretos, como Vault, también ayudan a proteger el código en la infraestructura en la nube y las aplicaciones.

Herramientas de Snyk para la seguridad continua

Hay muchas herramientas para encontrar y corregir vulnerabilidades durante el ciclo de vida de desarrollo. Snyk se distingue por su enfoque centrado en los desarrolladores y su plataforma de seguridad líder en su categoría.

Por ejemplo, mantener las dependencias actualizadas representa un obstáculo para los desarrolladores. ¿Cómo sabes cuándo se necesita una actualización? ¿Será útil? ¿Introducirá errores o impedirá la compilación? Las actualizaciones continuas de dependencias, más frecuentes y pequeñas, facilitan la gestión del problema. Los desarrolladores pueden usar herramientas para aprobar y fusionar actualizaciones automáticamente cuando se superan las pruebas, lo que finalmente permite implementar más rápido y automatizar por completo el proceso desde el pull request hasta producción.

Las dependencias de código abierto son motivo de especial preocupación. Snyk Open Source prueba automáticamente el código a través del pipeline de CI/CD para detectar y corregir vulnerabilidades antes de que lleguen a producción. Una vez que el código está en producción, Snyk monitorea nuevas vulnerabilidades mediante una base de datos propia.

En definitiva, los análisis de código son un requisito clave para la seguridad continua. Si no analizas el código, ¿qué vulnerabilidades o errores podrían pasar inadvertidos?