Mejorando la seguridad en una cultura agile con Gitlab

Autores: José Manuel Aliaga y Maria Rosina Garagorry (Equipo de Seguridad Cencommerce)

Introducción

La seguridad de las aplicaciones no es sólo una preocupación para los usuarios finales, sino también para las empresas que las desarrollan. A medida que la tecnología y la adopción de internet se han expandido, los riesgos de ciberseguridad han aumentado de manera exponencial. De hecho, los ciberataques ahora se consideran una de las principales amenazas a nivel mundial, según el Foro Económico Mundial (World Economic Forum). En Cencommerce, entendemos la importancia de la seguridad en el desarrollo de software y nos comprometemos a ofrecer soluciones seguras y confiables para nuestros clientes. En Latam tenemos:

Para crear y entregar aplicaciones lo más seguras posibles, es necesario contemplar la seguridad en todos los procesos del desarrollo. En este sentido, la cultura DevOps ha dado paso a una nueva práctica: DevSecOps. A pesar de que algunos desarrolladores pueden experimentar cierta resistencia ante la integración de medidas de seguridad en los procesos de desarrollo, es importante destacar que una estrategia de DevSecOps no solo asegura la protección de los usuarios finales, sino que también optimiza el tiempo de desarrollo. Con Gitlab Ultimate, es posible lograr una gestión del código segura y ágil, lo que garantiza aplicaciones más confiables para nuestros clientes.

La herramienta: Gitlab Ultimate

Anteriormente en Cencommerce usábamos un conjunto de herramientas diversas, tales como: Archerysec, Sonarqube, Trivy, DefectDojo, entre otras. Estas herramientas tenían sus despliegues correspondientes en un cluster de kubernetes y el equipo de DevSecOps se encargaba de mantener esas herramientas. Estas entregaban reportes a los equipos de desarrollo sobre la seguridad de sus productos.

Por ejemplo, los equipos podían ir a las URLs de las distintas herramientas para ver qué resultados tenía el análisis de su código. Para cada herramienta, existía una URL y una interfaz distinta. Además, en la práctica el equipo de DevSecOps funcionaba como un equipo de soporte de las herramientas: se dedicaba sobre todo al mantenimiento de las mismas, antes que a implementar controles en el ciclo de desarrollo.

Si bien la generación de reportes es muy importante para tener visibilidad sobre lo que se está desplegando, es también de vital importancia el poder actuar en base a esos reportes. Esto lo logramos con otra capacidad de Gitlab: las políticas. Gitlab Ultimate nos permitió centralizar las herramientas en una sola interfaz que fuera fácilmente adaptable a los pipelines ya existentes en Gitlab y, más recientemente, a actuar de manera automática en base a lo que descubren los jobs de seguridad.

En marzo de 2022, presentamos el nuevo esquema de los jobs de seguridad. Este no requería que los desarrolladores modificaran el código en cuestión, lo que hicimos fue informar de esta nueva implementación y nuestro plan a futuro: bloquear errores críticos en merge requests que van hacia producción. Desde entonces, en los merge requests, los jobs de seguridad cargan los findings que encuentran. Algo similiar al esquema anterior, pero todo centralizado en la interfaz de Gitlab.

Cómo inyectar los jobs de seguridad

Para agregar los jobs de seguridad tenemos que modificar el archivo `.gitlab-ci.yml` y agregarle las referencias a los templates de Gitlab: SAST, DAST, escáner de dependencias, detección de secretos, scanner de contenedores y análisis de código.

Dentro de Cencommerce, manejamos plantillas de despliegue estándar. El equipo de DevSecOps mantiene un archivo de referencia que es utilizado por las otras plantillas (por ejemplo, el archivo de despliegue a k8s hace referencia al documento que inyecta los jobs de seguridad) con los jobs que vamos introduciendo y mejorando. De esta manera descargamos en gitlab el mantenimiento de las herramientas.

Además de las configuraciones por defecto, tenemos la posibilidad de aplicar ciertas personalizaciones a cada uno de los jobs (por medio de variables). Por ejemplo: si no especificamos nada, estos jobs corren en una etapa llamada `test`, dado que muchos de los equipos usan esa misma etapa para hacer sus pruebas. Estaríamos inyectando en sus etapas propias jobs de seguridad, que, si bien no causarían mayores problemas, sí causarían desconcierto en los equipos. Para evitar eso, declaramos en cada uno de los jobs, una etapa particular: `sast`

Para ver qué variables podemos activar o desactivar, podemos ver la documentación de cada herramienta (link)

Previniendo despliegues inseguros: Las políticas de los merge requests

Hasta ahora, hemos hablado de la inyección de jobs en los pipelines que generan un reporte para los equipos. En esencia, logramos algo similar a lo que teníamos en el esquema anterior (generación de reportes). La mejora que agregamos en noviembre de 2022 fue la inclusión de una política que bloqueara merge requests con vulnerabilidades críticas.

Para crear una política tenemos que tener un proyecto específico para eso, tal y como lo indica la documentación oficial. En un proyecto al que llamaremos principal vamos a Security and compliance > Policies > New policy y ahí gitlab nos presenta con dos tipos de políticas:

· scan execution policies: se asegura de que siempre se ejecuten los jobs de seguridad que especifiquemos

· scan result policies: evalúa en los merge requests el resultado de los jobs de seguridad

Después de completar las opciones en la WUI, gitlab creará OTRO proyecto, llamémoslo nuevo, con el nombre de nuestro proyecto principal más la leyenda ` — Security policy project`. Desde ahí, si queremos realizar modificaciones, podemos ir al proyecto nuevo y hacer las modificaciones manualmente, sin embargo recomendamos hacerlo a través de la WUI del proyecto principal.

En este caso, como se puede ver más adelante, en nuestro caso se creó una `scan_result_policy`. Esta necesita un nombre, descripción, saber si está habilitada o no y las reglas. La política sigue el siguiente esquema de evaluación:

En términos de la política de gitlab:

Desafíos en la implementación

Los principales desafíos en cuanto a la implementacion de esta solución, fue la socialización. Tuvimos que explicar y volver a explicar el funcionamiento de la política de los merge requests: el cuándo bloqueaba los merges, dónde acceder a los resultados del scanner para identificar, cómo leer los reportes y demás. Por otro lado, debimos aprender a cómo integrar estos jobs a los pipelines existentes, cómo leer y entender los resultados de los jobs de seguridad y filtrar qué vulnerabilidades podrían permitirse y cuáles no.

Como claves para superar estos desafíos, destacamos:

· Enfatizar la comunicación: para que los equipos de producto entiendan los pipelines y sepan identificar cuáles son los bloqueantes en cada caso particular

· Trabajar la responsabilidad compartida en seguridad: si bien el equipo de DevSecOps somos el equipo responsable de responder ante incidentes, todos los miembros de la organización son responsables de la seguridad en sus tareas. Esto es: no quemando contraseñas, apikeys u otros secretos, previniendo códigos que habiliten la inyección de SQLs, y demás.

Conclusión

Bajo el lema “no queremos bloquear, queremos sacar vulnerabilidades de producción”, nosotros como equipo de DevSecOps de Cencommerce hemos crecido mucho, tanto en número como en conocimiento. Así mismo, mantenemos una comunicación constante con nuestro TAM y los equipos de soporte de Gitlab, ya que hay situaciones en las que incluso el mismo Gitlab desconoce la causa de algunos problemas. Como equipo, nos hemos trazado diversos objetivos a futuro, entre ellos:

· Asegurar que los equipos de desarrollo incluyan análisis de seguridad (por medio de un compliance framework)

· Generar reportes de todo el grupo para identificar porcentajes de vulnerabilidades y trabajar en su reducción

Como equipo, utilizamos prácticas DevSecOps y Gitlab Ultimate para asegurar la seguridad del software en cada paso del proceso de desarrollo. Además, implementamos políticas en merge request para que cada cambio de código sea revisado y aprobado por al menos dos miembros del equipo antes de ser fusionado con la rama principal. Estas medidas, junto con las políticas de seguridad de Gitlab, han reducido significativamente las vulnerabilidades en producción.

En Cencommerce, cuidamos de la seguridad para que nuestros desarrolladores se enfoquen en lo que más les gusta: ¡desarrollar!