De algo estamos seguros y es que ambas culturas comparten el mismo objetivo, donde su principal propósito es: “Encontrar las vulnerabilidades e informarlas lo mas pronto posible”, y sí, estamos hablando de seguridad informática. Allí es donde radica la necesidad de adoptar las mejores prácticas en el proceso de desarrollo, pruebas, despliegues y monitoreo de nuestras aplicaciones de software, mas aún con enfoques orientados a la seguridad en toda su dimensión.

Actualmente, la mayoría de las Pymes y grandes compañías se están iniciando en las prácticas DevOps, como lo indica el mas reciente Informe llamado “ACCELERATE State of DevOps” de Google en colaboración con DORA (DevOps Research &Assesment), donde allí se relata el crecimiento exponencial en América Del Norte con un 50% y en América Latina pasando del 1% en 2018 a tener 2% en el 2019 y creciendo en el uso de DevOps.

Ahora en profundidad ¿Qué es DevSecOps o SecDevOps? Pues mis queridos lectores, realmente pregonan un mismo mensaje, pero se construye y se implementan de maneras diferentes, con sus particularidades, beneficios y contras.


DevSecOps

Como su siglas lo indican, se realiza el desarrollo, se válida la seguridad y por último se realiza la operación de desplegar, todo esto con un toque de automatización. Realmente, a muy alto nivel es correcto deducir esto, pero ampliemos un poco más en el detalle de sus actividades y del como podemos llegar a dicha implementación.

Para implementar seguridad informática luego del desarrollo y de manera automática se requiere tener una serie de herramientas y estrategias que nos permitan identificar el análisis de código tanto estática como dinámicamente, allí es donde toman fuerza los analizadores de código (raxisSonarqubeFortifyKiuwanCruciblealojados en servidores web dedicados para la compañía donde se tendrán reglas definidas como estándar para ser cumplidas por todos los actores en el desarrollo de software, incluyendo testers con enfoque de automatización. Todo este análisis de carácter automático.

Interiorizando esto, cada que un analista activo en el desarrollo de software promueva su código hacia los repositorios centralizados en las herramientas de gestión de versiones y artefactos, este código será leído por los analizadores de código en mención y lo que harán es evaluar según sus reglas definidas las buenas prácticas que se quieran adoptar y a su vez arrojar un dictamen que nos permita identificar que tan correcto está nuestro desarrollo a nivel modular.

Algo muy importante es saber si el código que se quiere promover es seguro según su construcción, o si definitivamente de manera automática “Rompemos el Build” para que los hallazgos sean solucionados antes de fusionar sus cambios en ambientes Pre-Productivos o en lenguaje GIT antes de hacer merge con una rama principal. Esto se condiciona con estrategias como PullRequest o MergeRequest con validaciones atadas a los resultados, según las herramientas utilizadas.

También debemos analizar, luego de desplegada la aplicación en momento de ejecución ¿Cómo es su seguridad? Teniendo en cuenta la integración de otros módulos en la aplicación como lo son BD, API’s, logs, entre otros. Allí empezamos a hablar sobre análisis dinámico de seguridad.

Este análisis dinámico por lo regular se hace de manera manual por los diferentes equipos de pruebas o proveedores de seguridad que se encargan de dictaminar según flujos y técnicas del Pentesting la veracidad de la aplicación y su mínimo de vulnerabilidades más críticas. Para estas técnicas también existen módulos automáticos que nos permitirán analizar rápidamente nuestra aplicación sobre ataques básicos conocidos. Una de esas aplicaciones es OWASP ZAP, que nos permite analizar rápida y automáticamente la seguridad de una aplicación Web, su desventaja es que solo está disponible para aplicaciones Web.

Otra manera de validar la seguridad de una aplicación de manera automática, es con Hacking Continuo, lo cual para esto tendríamos un historial de vulnerabilidades conocidas halladas y automatizadas, y cada que se requiera desplegar la aplicación se analice si alguna de estas vulnerabilidades que estamos validando se encuentra en la aplicación. En caso positivo de vulnerabilidades abiertas encontradas, fallaría el release, despliegue o Pipeline.

Lo anterior conlleva a un riesgo, y es que si no somos exhaustivos probando la aplicación a nivel de seguridad, no encontraremos las suficientes vulnerabilidades para automatizarlasy validarlas en cada despliegue, por lo que es importante darle prioridad a los desatraces y análisis de vulnerabilidades de toda la aplicación, y que como máximo el código que sea desplegado hoy, esté analizado en una semana por seguridad, esto lo da la Integración Continua, las buenas practicas de Feature Flags y los merges de funcionalidades pequeñas o particionadas, para así tener mucha más cadencia en dichos análisis.


SecDevOps

Ahora la pregunta que surge es: ¿Podré analizar mas seguridad sabiendo que DevSecOps ya está abarcando gran parte de esta práctica? y la respuesta es SÍ, aquí es donde nace SecDevOps, y lo que se busca es encontrar mucho mas rápido las posibles inmersiones de vulnerabilidades y código “spagueti” en el código, a continuación los detalles.

¿De pronto habrán escuchado de los Linters? En este caso, nuestra principal arma para combatir las vulnerabilidades en el código son los Linters (SonarlintSonarqubeESLint y muchos mas), herramientas que están alojadas en los IDE de trabajo para el diseño y desarrollo de software, y su principal objetivo es indicarnos en que momento de la construcción de código voy a inyectar una vulnerabilidad o mala práctica.

Estos linters también se pueden modificar, y agregarles reglas adicionales a las que vienen por default, esto para hacer mas completo el análisis, antes de subir el código en repositorios remotos o centralizados. También, estos Linters ayudan a romper el build cuando se está compilando en el mismo IDE o en Local, y se hace con el fin de alertar mucho antes de realizar el commit a la rama destino.

Otra de las prácticas y no menos importante para análisis de seguridad antes de desplegar el código son los Pre-Hooks. Lo que se hace es que antes de subir los cambios al repositorio centralizado remoto, los cambios son evaluados en un Pre-Commit y se válida que afectaciones posibles pueda tener según las reglas definidas, y en caso de no conllevar todo lo requerido para el éxito, simplemente no permite realizar el commit y posterior merge.

En la aplicación e implementación de SecDevOps también se intervienen procesos luego de los merge, y en momento de ejecución.


Conclusiones:

A la pregunta que nos planteamos en el titulo de este blog: ¿Son lo mismo las prácticas DevSecOps y SecDevOps? Podemos concluir que no son lo mismo, a pesar de sus similitudes, en DevSecOps no estamos orientados en analizar el código exhaustivamente desde la maquina donde surge el código, en cambio en SecDevOps nos enfocamos en garantizar que lo que estás construyendo en tu maquina sea confiable y no se despliegue deuda técnica y vulnerabilidades que luego tendrás que corregir para poder re-desplegar dichos cambios.

Como recomendación, para aplicaciones que gestionen información de clientes, financiera y gubernamental trabajar con SecDevOps, es la estrategia mas exhaustiva, pero con menos margen de error.

En T-EVOLVERS nos encargamos de transformar la cultura al interior de los equipos y orientar los esfuerzos en actividades de valor, enfocados en automatizar las implicaciones de la desrobotización humana …