El 23/05/2024 participamos del festival de conocimiento en TI mas grande de Colombia: DevOpsDays Medellín. Es un evento técnico internacional que aborda temas cruciales en el desarrollo de software y las operaciones de TI, explorando la relación entre ambos. En esta edición Lucas Mariani ,experto en DevSecOps y Captain en Crowdar, se presentó con una charla que proporcionó una comprensión práctica sobre cómo implementar con éxito DevSecOps en las organizaciones y fortalecer la seguridad en el desarrollo de software.
______________________________________________________________
Me presento soy Lucas Mariani, hace unos largos 20 años de trabajo en sistemas, soy un SysAdmin de pura cepa devenido en SRE, DevOps o el nombre de moda que le pongan hoy en la transformación cultural que tiene TI.
El disparador de lo que les quiero contar es algo que empezó a suceder estos tiempos de agilidad, que demanda que el software se entregue más rápido, que el delivery sea más continuo. Creo que con los años bien o mal aprendimos a segurizar la frontera, firewalls, cómo a controlar la invasión externa. Nos empezamos a dar cuenta que nuestro software que tenía calidad porque hacíamos test, que no tenía tanta seguridad. Entonces, un poco esta charla está orientada a hablar de seguridad y pruebas automatizadas en etapas tempranas del desarrollo, es decir, antes de tener un producto en producción.
Voy a hacer una confesión soy un un GitLab Lover, me parece uno de los mejores versionadores de código, una de las mejores herramientas para integrar un montón de soluciones dentro de una plataforma. Emplear a diario GitLab me hace leer mucho de su documentación, entender cómo funcionan las cosas y como soy un techie, leo el issue traker del repo para ver qué le falló a otra persona y que me puede fallar a mí. Sacaron algo que es hermoso para empezar a controlar la seguridad en nuestros desarrollos y se llama GitLab Security Dashboards. Si alguno no sabe de qué se trata, son unos componentes que podemos poner adentro de nuestro pipeline. Automágicamente detectan el lenguaje, automáticamente generan un pipeline y va a controlar un montón de steps de seguridad, a través del ciclo en el cual nuestro producto se deploya y se buildea. Lo interesante es que en cada step va a ir generando una reportería y nos va a entregar este dashboard hermoso, donde vamos a tener cada producto con sus vulnerabilidades, el nivel de seguridad que presenta, cuántas informations nos va a dar para cosas que podemos mejorar en el código. Es hermoso pero vale $100 usd por usuario. Si hacen la cuenta y por ejemplo tenemos 50 desarrolladores, multiplicamos por 100, muchas empresas no lo suelen querer pagar.
Otra de las cosas que les quiero contar sobre mi, es que soy un fan del open source, soy un evangelizador, estoy a favor de usar este tipo software libre. Mi desafío fue: ¿cómo poder tener un GitLab Security Dashboards con herramientas open source? Esta charla va a empezar a desarrollar esto. ¿Cómo podemos llegar a monitorear y tener control de la seguridad de nuestras aplicaciones en etapas tempranas? ¿Cómo detecto una vulnerabilidad, una librería que esta bugueada? Porque por lo general escaneamos el código en zona, pero eso nos dice cómo está nuestro producto y no cómo está la librería que hace un ucraniano y la mantienen tres observer con cuatro estrellas. Esto nos va a llevar un poquito a eso.
En este recorrido, lo que voy a ir comentando son las herramientas que fui encontrando. Algunas las usa GitLab, en lo que llama Auto DevOps, que es como su pipeline automágico. ¿Qué me pasa a mí con todo lo que sea “auto”? Me pone nervioso. No sé qué está pasando en lo auto. A algunos les pasará con Spring Boot que es muy genial, pero hay cosas que no entiendo por qué suceden y eso me ponen nervioso. Es por ello que lo que hice, mediante la documentación, experimento y error, fue desarmar ese Auto DevOps y entender qué está usando GitLab y cómo poder reimplementarlo en un pipeline que yo mismo gobierne. Hago una aclaración, esto también aplica para Bitbucket, GitHub, GiT, Jenkins o lo que se les ocurra, donde tengan un pipeline. Esto va a funcionar en cualquiera.
¿Cuál es el primer problema con el que me encuentro en la entrega de código en un repositorio? Los secretos. Hardcodeamos los secretos en el código, hacemos un commit sin skipear los archivos y tenemos la contraseña de la base de datos para que cualquiera que tenga acceso al repo la pueda ver. Quizás no se nos escapa una contraseña base de datos, pero se nos escapa un token, una PKI, un conjunto de secretos que no deberían estar ahí o que tienen que estar skipeados en el commit o fuera del contexto del versionado de código. Tenemos una herramienta como gitleaks, completamente open source, la cual puede ejecutar sobre nuestro repositorio, escanear todos los archivos y decirnos ( por un patrón de expresión regular) dónde hay un secreto, dónde hay una PKI. Inclusive detecta PKIs de AWS, access key, secret key. Lo interesante es que si hay algún patrón que nosotros tenemos, podemos agregarlos con una expresión regular, podemos hacer nuestra propia plantilla de detección de secretos. De esa forma lo que va a hacer es escanear y contarnos qué encontró cuando corrió la herramienta. Lo otro interesante es que gitleaks está pensado para trabajar en un repo de Git es que le puedo decir cuánto historial para atrás de commit quiero que me revise cada vez que ejecute, porque quizás en el último nadie subió un secreto pero hace tres commit alguien eliminó por error una una contraseña de base de datos. Gitleaks lo que nos va a dar es esa información y muy rápido. Obviamente si le hacemos ejecutar sobre el historial de un repo con 10000 commits va a ser más lento, pero en líneas generales es muy rápido y nos va a dar la información del archivo como el nombre, la línea donde está el secreto, de una manera muy fácil. Puede pasarnos que tengamos algunos falsos positivos pero se pueden excluir mediante alguna regla.
Repasando, el primer gran problema que tuve en los repos fueron los “secretos” y con gitleaks lo puedo mitigar. Ya tengo la primera parte del problema resuelto. GitLab usa gitleaks. No fue un descubrimiento, hay varias herramientas que hacen lo mismo. Probé git-secret y otras que había dando vuelta y la verdad es que esta me pareció la más interesante.
Dependency -Check de OWASP es, según mi punto de vista, la herramienta fundamental para entender cómo es la salud y la seguridad de nuestro código. Va a leer las dependencias de nuestro proyecto, ir a una base de datos a buscar esas dependencias y traer todos los CVE de vulnerabilidad, errores, problemas que pueda tener esa versión. Esa información es muy valiosa porque nos va a decir si tenemos una librería vulnerada, si es alta para una intrusión o que puedan hacer un túnel inverso ssh. Con estos datos vamos a poder actuar en consecuencia. Es una herramienta open source, es decir, que ya tenemos dos con la anterior.
Quizás conozcan Cloc, es una herramienta muy simple pero muy interesante para tener una visión rápida de cómo está nuestro repositorio. Por lo general, GitLab y GitHub tienen una lista que nos dice cuál es el porcentaje de línea de código que tenemos en nuestro repositorio. Bueno, Cloc hace algo similar. Es una línea de comando de Linux que cuenta líneas de código y nos va a generar un JSON con la información de qué porcentaje de línea de código tenemos, en qué lenguaje. De esta forma vamos a poder saber qué porcentaje de código CSS o JavaScript está mezclado dentro de un proyecto en, por ejemplo, .NET Core. Nos va a proveer de una estadística que también la va a dar GitLab Security Dashboards . Por lo que resulta una alternativa open source en la que podemos contar líneas de código y saber a qué lenguaje pertenece cada una.
Hay una tecnología que vino para quedarse, que son los contenedores. Detrás de esto vino Kubernetes, Docker y todo el mundo de contenedores. Por lo que hoy resulta importante escanear un contenedor. Más allá de que es autocontenido, lo hacemos lo más pequeño posible, le quitamos todas las dependencias que tengamos; existen librerías que están corriendo allí embebidas, para que lo puedan hacer parte de la pieza de software. Esas librerías tienen vulnerabilidades. Tenemos que saber si curl, SSL o cualquiera de las ellas, que están instaladas dentro del contenedor, tienen o no una vulnerabilidad. Es parte de ser seguros en etapas tempranas de desarrollo.
Hay muchas herramientas que hacen esto, por ejemplo Anchore. A mí, particularmente, la que más me gustó fue Trivy. Me parece simple, súper práctica, no tiene que tener varios contenedores, ejecuta autocontenida por línea de comando y sobretodo funciona en Linux. En cambio, Anchore hay que tener una base de datos y un montón de componentes. Lo podemos ejecutar embebido, pero no tiene la misma potencialidad. Esto, cuando se ejecuta, bajo una base más pequeña de datos, escanea el contenedor y nos arroja todas las vulnerabilidades. Ahí encontramos otro lugar para empezar a corregir nuestra salida de producción y tener contenedores sanos, que es lo más importante en el circuito.
Hasta acá, pasamos por la etapa de tener código fuente, le sacamos secretos, nos fijamos las dependencias, hicimos un test de integración, contamos las líneas de código, generamos una estadística de cómo está nuestro código, compilamos, creamos un contenedor, analizamos el contenedor. Vamos a desplegar en desarrollo, en test, en producción o donde corresponda.
OWASP ZAP crea un proxy. ¿Qué hace ese proxy? Básicamente opera de dos formas: en modo web y en modo API. Si tenemos este proxy corriendo, podemos atacar esa API recién desplegada entregándole una definición de OpenAPI: el famoso JSON del Swagger. Se lo pasamos al proxy, le decimos que es una API y esto lo que va a hacer es bombardearla para ver si tiene alguna vulnerabilidad de las top 10 más conocidas. De esta forma nos enterarnos más rápido si nuestro producto tiene un elefante con un tutú rosa saltando arriba. Entonces, permitimos una inyección de SQL, que se puedan hacer cross-site scripting.
Si tenemos una web, es más complejo porque en una API hay endpoints definidos. Como son microservicios, pensamos en cuatro o cinco endpoints, le pasamos el Swagger, los va a atacar y nos va a dar un reporte. Pero cuando tenemos una web, quizá no cuente con un sitemap, algunos vínculos pueden ser dinámicos, entonces, OWASP ZAP lo que hace es utiliza una técnica de spider, empieza a recorrer los hipervínculos y a recorrer URL a URL y atacarla. Como puede ser un proceso muy largo o muy corto, podemos limitar el tiempo. Tenemos que pensar que queremos correr esto en un pipeline. No podemos estar cuatro horas para que llegue a producción un producto o que el pipeline se ponga en verde después de cuatro horas. Entonces, vamos a limitar el tiempo en que atacamos ese frontend o ver si podemos usar sidemaps rotativos y atacar una parte y después otra. Con esto quiero decir que existen varias estrategias para hacerlo. Recorrimos todo y lo detectamos cuando era código fuente, cuando lo deployamos y lo empaquetamos, y ahora lo tomamos cuando ya está en runtime y lo volvimos a atacar. ¿Esto nos va a garantizar el 100% de la seguridad de nuestro software? Nunca, pero vamos a mitigar mucho la superficie de ataque, porque tenemos recorrido un gran camino en donde tratamos de achicar todo esto. Si yo corro este pipeline todos los días, no voy a ser más seguro. Voy a ser más seguro si tomo ese feedback y empiezo a corregir los errores que hay en el software. Este conjunto de herramientas nos va a dar ese feedback. Tenemos que materializarlo, priorizar nuestro sprint, empezar a segurizar.
Tengo el feedback, pero ¿quién lo va a usar? Es la pregunta que nos tenemos que hacer. ¿Cómo logramos que los desarrolladores tomen ese feedback y lo prioricen dentro de su backlog?
Entonces, ¿cómo hacemos para tener el GitLab Security Dashboard? Hay un producto open source, que es un pacman de reportes. No lo puedo definir de otra forma, es una máquina de absorber cualquier cosa que uno le arroje y empieza a generar información sobre el producto. Entonces, nuestro dashboard de seguridad va a ser DefectDojo en lugar de GitLab. Día a día va acumulando todas las corridas, nos muestra el histórico de ellas y nos va diciendo cuántas vulnerabilidades detectó en cada una y las podemos segmentar por tipo de detección: vulnerabilidad, leak de Git, problemas de Dependency- Check. Hay un problema de dependencia, sí, podemos segmentar todas las partes de los análisis y los tests. Y esto sí nos da una herramienta donde un equipo de desarrollo puede tomar un feedback real y entender cómo mejorar el producto y cómo planificarlo en un sprint.
¿Qué es lo primero que tenemos que atacar cuando queremos hacer una estrategia de mejorar nuestra calidad de código en etapas tempranas? Debemos atacar los critical y los high, de medium para abajo podemos tomarnos el tiempo de arreglarlos a futuro. Lo interesante es que sobre cada producto que tengamos en findings, vamos a poder ver todos los findings activos. Acá nos va a decir cuáles tuvo, podemos entrar a ver la descripción y cómo mitigarlo. Nos va a decir la descripción del problema que encontramos, la forma para mitigarlo y la planning. Tomamos los más graves, le hacemos el PoC strategy y lo mitigamos en un o dos sprints. No hace falte que mire en el pipeline, el stdout para saber cuál es la vulnerabilidad. Esto facilita eso. Si tuviéramos un área de seguridad informática que quisiera tomar ownership de esto, puede asignar un responsable de los issues, puede planificar cuándo se van a solucionar e ir controlando el vencimiento de esa solución. Si tienes que hacer algo con SLA, mucho más avanzado, la herramienta es más potente. Envía mail, te avisa que te excediste el tiempo en el que tenías que mitigar el error y demás. Pero básicamente nos da más información que el GitLab Security Dashboard. ¿Cuál es la única pega que tiene? Que tenemos que switchear de pestaña. Antes teníamos todo en GitLab, ahora tenemos que ir a DefectDojo. Pero la ventaja es que nos da la solución fácilmente, no hay que googlear, no hay que ir a Stack Overflow, o quizás sí porque nos guste y porque queremos ver si hay una solución alternativa a la que nos ofrece. Pero nos va a achicar mucho el scope de cómo resolver los problemas y los va a centralizar en un único lugar. Consume cualquier JSON, XML o cosa que le pasen. Si tiene criticidad, si tiene una categoría de severidad, la va a categorizar y se la va a mostrar. Y obviamente después ustedes elegirán si lo organizan, gestionan y los mitigan o si hay un área de seguridad que va a velar porque estas cosas sucedan.
Soy partidario de que los equipos se autogestionen y no tener un “policía” diciéndome que hay un bug. El camino que les mostré es cómo pude llegar a tener algo que anhelaba mucho y que nunca nadie me quiso pagar. Así que soy un cabeza dura, ¿no? Si no me compran el autito, me lo hago yo. Do It Yourself.
