En Pomelo consideramos a la seguridad de nuestras aplicaciones e infraestructura como uno de los pilares para entregar el mejor producto a nuestros clientes y evolucionar nuestras soluciones. Es por eso que en conjunto con iniciativas como la implementación de Zero Trust, tenemos como prioridad también incrementar la seguridad en el desarrollo de nuestros servicios. 

Particularmente, en el equipo de Platform Solutions buscamos que cada producto, servicio o aplicación desarrollado atraviese diversos controles durante todo su ciclo de vida. Llevamos adelante esta iniciativa con el objetivo de minimizar las posibilidades de generar una brecha de seguridad que afecte a la confidencialidad, integridad o disponibilidad de nuestra información, la de nuestros clientes y sus usuarios.

Entendemos que la implementación de un ciclo de vida de desarrollo seguro (SSDLC) es un todo y que una aplicación es más segura si se realizó el análisis necesario en cada una de sus etapas. No obstante, la idea de este post es hacer foco en todo aquello que transcurre desde que una idea ya fue aprobada por las partes y el equipo de desarrollo comienza a darle forma, hasta que el producto se implementa y comienza su etapa de mantenimiento. Y, en particular, vamos a profundizar en algunos detalles y desafíos que tuvimos en Pomelo al poner en práctica nuestro esquema de seguridad aplicativa. ¡Vamos!

Pero, ¿qué es un SSDLC y en qué se diferencia con un SDLC? 

SSDLC es una variante o extensión del tradicional SDLC, el cual se enfoca en la seguridad del software desde el inicio hasta la finalización del proceso de desarrollo. Al tener un enfoque mayor de seguridad, el SSDLC busca integrarla en etapas tempranas del proceso.

SSDLC en Pomelo: ¿Por qué implementar seguridad en el SDLC? 

Es sabido que la inclusión de vulnerabilidades (y bugs en general) se maximiza en las etapas tempranas del desarrollo. Esto quiere decir que si logramos reducir la aparición de problemas en estos momentos, vamos a ser mucho más eficientes y ahorrar dinero y horas de trabajo. Veamos este concepto en el siguiente gráfico:

Arquitectura de un SSDLC

Para comenzar, un SSDLC está conformado por herramientas, las cuales dividimos en dos grandes grupos: 

  • Las herramientas open-source, que nos brindan agilidad y la posibilidad de incluirlas en nuestro pipeline de forma rápida. Como contrapartida, el manejo de cada output y, dependiendo del caso, la confiabilidad en las detecciones y su visibilidad, suelen ser factores de mayor complejidad a tener en cuenta. 
  • Las herramientas de seguridad pagas, que además de ofrecer un marco conocido y aprobado por la industria, en general, cuentan con múltiples interacciones que hacen más eficiente su implementación.

Teniendo en cuenta esto, en Pomelo decidimos implementar un esquema híbrido donde combinamos el poder de herramientas de seguridad como Snyk, Sonarqube o Dependabot, con un paquete de herramientas open-source, como Gitleak o Trivy, en un producto interno llamado “security-orb”. Esta iniciativa permite maximizar nuestras posibilidades de detección y mejora en el pipeline de desarrollo. 

Una ventaja adicional de este enfoque combinado, es que dada su versatilidad, nos ayuda a construir un pipeline de desarrollo cada día más seguro, siguiendo el concepto de shift-left

¿Qué es shift-left? Un enfoque en el que se adelantan actividades y pruebas hacia las etapas iniciales del SDLC, en lugar de dejarlas para las etapas finales.

Si bien nuestra arquitectura está en constante evolución, les compartimos un snapshot:

Para enfocarnos en la seguridad del desarrollo local, nos apoyamos en un componente de la plataforma de Snyk, security IDE plugin, el cual analiza en tiempo real el código que está siendo desarrollado en busca de vulnerabilidades de cualquier tipo. Esto lo podemos ver en la transición (1) del diagrama.

Luego, una vez que ese código es subido a un pull-request en Github, se disparan dos flujos de seguridad: por un lado, el análisis de Snyk y Dependabot, y por otro, la ya antes mencionada security-orb. Es en esta etapa donde se encuentra la mayor cantidad de controles de seguridad, incluyendo pero no limitándose a controles de leak de secretos, escaneos de código estático, escaneos de librerías y licencias vulnerables, escaneo de uso de imágenes base hardenizadas, entre otros. Esto se puede apreciar en la transición (2) del diagrama.

¡Si bien estamos haciendo énfasis en los controles aplicativos, en esta etapa analizamos también otras aristas, mantenidas en conjunto con otros equipos de Infrasec!

Cuando uno de estos controles detecta un issue, dependiendo de las condiciones del mismo, esto hace fallar de forma restrictiva el job (es decir, no permite seguir adelante con el merge). Es importante tener los canales y automatizaciones necesarias para que, cuando esto suceda, pueda darse respuesta y apoyo rápido a los equipos de desarrollo. 

Visibilidad

Nada de esto sería útil si no lográramos un engagement con los equipos de desarrollo. Por eso, buscamos maximizar la visibilidad de cada detección al máximo, con el objetivo de que todos los equipos puedan actuar de forma rápida. 

Para otorgar este grado de visibilidad, nos apalancamos en nuestra herramienta de plataforma, “Rocket”, y en diversas herramientas de gestión que nos permiten notificar y mostrar toda métrica de seguridad necesaria a todos los equipos. Esto lo podemos ver en la transición (3). Todos los equipos pueden consultar detecciones y vulnerabilidades en Rocket, plataforma a través de la cual también son notificados cuando se encuentra un nuevo bug de seguridad.

¡Te dejamos un video donde contamos más sobre cómo implementamos nuestro SSDLC!

https://www.youtube.com/watch?v=0CnGt0VUxn0

Resumen final

La inclusión de la seguridad en las etapas iniciales del desarrollo y durante todo el ciclo de vida nos va a permitir ahorrar en costos y esfuerzo, a la vez que nos ayudará a crear un ecosistema cada vez más seguro para todos nuestros servicios, internos y externos. 

Para lograr una implementación eficiente, debemos dar siempre especial atención a dar la visibilidad necesaria a los equipos de desarrollo, generando el ambiente para que eso suceda de forma natural. Pero además, es importante buscar apoyo también en los managers de la compañía, con el fin de dar mayor impulso a las iniciativas.

Ofrece tus propios productos financieros
en cuestión de semanas

Utiliza nuestra tecnología para desarrollar, lanzar y escalar servicios financieros en América Latina, de forma ágil y segura.

Los comentarios están cerrados.