Cómo aplicar la metodología de prueba shift left con la integración continua

La metodología de prueba shift left es un enfoque que lleva las pruebas a una etapa anterior del ciclo de vida del desarrollo de software (como lo indica su nombre en inglés, a la izquierda). Si las pruebas de seguridad se realizan cuando el código está listo para la etapa de producción, puede ser difícil volver atrás y corregir problemas y, por lo general, es demasiado tarde para solucionarlos rápidamente. Esto puede dar lugar a demoras en las entregas, a problemas de seguridad y a silos entre los equipos de seguridad y el resto de los equipos de DevOps.

A medida que las organizaciones intentan pasar a una estructura más DevSecOps, será fundamental incorporar las pruebas de seguridad al ciclo de vida del desarrollo. Para lograrlo, se deben integrar las pruebas de seguridad en los pipelines de implementación para que el código se pruebe de manera continua, no solo en lo que respecta a otras confirmaciones en el repositorio compartido, sino también para garantizar la seguridad.

La integración continua (CI) es un proceso que mejora la calidad del código a través de pipelines de implementación. La seguridad se puede integrar en estos pipelines más temprano en el proceso, lo que ayuda a las organizaciones a aplicar la metodología de prueba shift left.

Integrar la seguridad en los pipelines de integración continua

Las pruebas estáticas de seguridad de las aplicaciones (SAST) permiten automatizar la seguridad a través de la integración continua. SAST analiza el código fuente y permite a los desarrolladores solucionar problemas antes en el ciclo de vida de desarrollo del software.

En la CI/CD de GitLab, el pipeline de implementación verifica el informe SAST y compara las vulnerabilidades entre las ramas de origen y de destino. Estos hallazgos aparecen en la solicitud de fusión.

Las pruebas dinámicas de seguridad de las aplicaciones (DAST) suelen funcionar en conjunto con SAST. Mientras que SAST analiza el código fuente, DAST analiza los errores en tiempo de ejecución en las aplicaciones ejecutadas. Una vez que se implementa una aplicación, se expone a nuevas formas de riesgos de seguridad, como secuencias de comandos en sitios cruzados o fallas de autenticación rotas.

Al igual que con SAST, GitLab verifica el informe DAST y compara las vulnerabilidades entre las ramas de origen y de destino y muestra los resultados, pero la comparación utiliza solo el último pipeline ejecutado para la confirmación base de la rama de destino.

Otros tipos de pruebas de seguridad incluyen pruebas de seguridad de aplicaciones interactivas (IAST) y protección de seguridad de aplicaciones en tiempo de ejecución (RASP). IAST funciona colocando un agente dentro de una aplicación y RASP se trata más bien de una herramienta de seguridad que se coloca dentro de una aplicación que puede responder a ataques en vivo.

Reducir la complejidad de la cadena de herramientas

Además de requerir mucho tiempo de mantenimiento, una cadena de herramientas compleja puede exponer un sistema a riesgos de seguridad. Muchos equipos de DevSecOps utilizan complementos, scripts o integraciones personalizadas codificadas para reunir sus herramientas. Dado que algunos de estos procesos deben hacerse manualmente, estas cadenas de herramientas están sujetas a errores humanos. Además, contar con más herramientas equivale a contar con más autenticación, más permisos, requisitos de seguridad y menos visibilidad del ciclo de vida de desarrollo del software. Estas capas de abstracción hacen que sea más difícil no solo identificar los problemas, sino también resolverlos.

Un sistema complejo incorpora múltiples puntos de falla. Si las organizaciones desean pasar a la metodología de prueba shift left, reducir parte de esta complejidad facilita la incorporación de la seguridad y el cumplimiento en el ciclo de vida del desarrollo. Una cadena de herramientas compleja o un entorno de complementos también pueden provocar que haya pipelines frágiles que necesitan atención adicional.

Reforzar la seguridad sus sistemas de integración continua

Reforzar la seguridad es el proceso de asegurar un sistema reduciendo su superficie de vulnerabilidad. De manera similar a la reducción de la complejidad de la cadena de herramientas para reducir las fuentes de riesgo, las listas de verificación de refuerzo de la seguridad permiten a una organización examinar sus sistemas internos a fin de garantizar que están siguiendo las prácticas de seguridad recomendadas.

Una recomendación es reforzar los sistemas que alojan los repositorios de código fuente y de artefactos de compilación, los servidores de CI y de entrega continua (CD), y los sistemas que alojan las herramientas de gestión de la configuración, creación, implementación y lanzamiento. Asegúrese de que su equipo sepa distinguir lo que se hace in situ frente a lo que está en la nube y comprenda cómo esto afecta los flujos de trabajo.

Reforzar la seguridad de su sistema de integración continua, además de incorporar análisis de seguridad en sus pipelines de implementación, puede facilitar que los equipos pasen a la metodología de prueba shift left.  Los equipos de DevOps maduros implementan naturalmente pruebas de seguridad en su proceso de integración continua y adoptan el enfoque shift left. En lugar de tratar la seguridad como algo secundario, estos equipos de DevSecOps la tienen presente en todo momento.