[24/07/2020] DevSecOps es un cambio de cultura en la industria del software que tiene como objetivo introducir la seguridad en los ciclos de rápida liberación, que son típicos del desarrollo e implementación de aplicaciones modernas -también conocido como el movimiento DevOps. La adopción de esta mentalidad de cambio a la izquierda requiere que las organizaciones salven la brecha que suele existir entre los equipos de desarrollo y seguridad, hasta el punto de que muchos de los procesos de seguridad están automatizados y son manejados por el propio equipo de desarrollo.
¿En qué se diferencia DevSecOps del desarrollo de software tradicional?
Tradicionalmente, los principales desarrolladores de software solían lanzar nuevas versiones de sus aplicaciones cada pocos meses, o incluso años. Esto proporcionaba el tiempo suficiente para que el código pasara por el control de calidad y las pruebas de seguridad, procesos que eran realizados por equipos especializados separados, ya sea internos o contratados externamente.
Sin embargo, en los últimos diez años se ha observado el aumento de las nubes públicas, los contenedores y el modelo de microservicio en el que las aplicaciones monolíticas se descomponen en partes más pequeñas que funcionan de manera independiente. Este desglose también ha tenido un impacto directo en la forma en que se desarrolla el software, lo que ha dado lugar a versiones sucesivas y prácticas de desarrollo ágiles, en las que las nuevas características y el código se introducen continuamente en la producción a un ritmo rápido. Muchos de estos procesos han sido automatizados con el uso de nuevas tecnologías y herramientas, lo que permite a las empresas innovar más rápidamente y mantenerse por delante de la competencia.
El avance de la nube, los contenedores y los microservicios también ha dado lugar a la aparición de lo que la industria llama la cultura DevOps, en la que los desarrolladores pueden ahora suministrar y ampliar la infraestructura que necesitan, sin esperar a que un equipo de infraestructura independiente lo haga por ellos. Todos los principales proveedores de nubes ofrecen ahora APIs y herramientas de configuración que permiten tratar la configuración de la infraestructura como código utilizando plantillas de despliegue.
Si bien la cultura DevOps aportó mucha innovación al desarrollo de software, a menudo la seguridad no pudo mantenerse al día con la nueva velocidad a la que se producía y liberaba el código. DevSecOps es el intento de corregir eso, e integrar plenamente las pruebas de seguridad en los conductos de integración continua (CI) y de entrega continua (CD), pero también de acumular los conocimientos y aptitudes necesarios en el equipo de desarrollo para que los resultados de las pruebas y la corrección también puedan hacerse internamente.
Tres cosas clave hacen un verdadero entorno de DevSecOps:
- Las pruebas de seguridad son realizadas por el equipo de desarrollo.
- Los problemas encontrados durante esas pruebas son manejados por el equipo de desarrollo.
- La solución de esos problemas permanece dentro del equipo de desarrollo.
"La última va a llevar algún tiempo, pero creo que es cuando la seguridad de la aplicación se convierte realmente en DevSecOps y no hay necesidad de un equipo separado", señala Chris Wysopal, cofundador y jefe de tecnología de la empresa de pruebas de seguridad de aplicaciones Veracode.
Lograr una verdadera integración de la seguridad y el desarrollo
Según Wysopal, la razón por la que es difícil dar el último paso, es porque los desarrolladores deben desarrollar las habilidades necesarias para arreglar los errores relacionados con la seguridad sin guía externa y eso lleva tiempo. Muchos equipos llegan a ello incorporando un llamado campeón de seguridad en sus equipos de desarrollo. Se trata de alguien con experiencia en seguridad de aplicaciones y que ha recibido una formación más avanzada en este campo que la mayoría del equipo, aunque la formación de todo el equipo en prácticas de programación segura también debería formar parte del proceso. Esta persona puede revisar las correcciones de seguridad para asegurarse de que son correctas.
Esto no significa que el campeón de la seguridad no pueda salir del equipo para pedir una opinión experta, por ejemplo, al proveedor de pruebas de seguridad de aplicaciones de la empresa, que podría estar ofreciendo servicios de consultoría a los clientes. Esto sería en casos especiales, no la norma. Esto es diferente a tener equipos de desarrollo y seguridad separados, y tener uno o más miembros del equipo de seguridad integrados en los equipos de desarrollo.
Según Brian Fox, CTO de la empresa de automatización de DevOps y de gobierno de código abierto Sonatype, la integración entre el desarrollo y la seguridad debe ocurrir también a nivel de gestión. "Cuando la misión de la seguridad no está totalmente alineada con estar completamente integrada en el desarrollo, de arriba a abajo, no creo que se termine con lo correcto", anota Fox. "Termina con estos enfrentamientos a nivel de gestión a veces donde los objetivos son diferentes, aunque la gente trabaje en el mismo equipo. Es similar al juego paralelo con niños pequeños: Tiene dos niños pequeños que juegan uno al lado del otro y no se pelean, pero eso no significa que realmente jueguen juntos. Creo que es un elemento de eso que ocurre en muchas organizaciones".
Esto ha sucedido antes con QA (control de calidad, por sus siglas en inglés), donde solía haber un gerente de QA y un gerente de ingeniería y trabajaban juntos, pero siempre había un poco de tribalismo, indica Fox. "Tan pronto como eso desapareció y el control de calidad se convirtió en parte de las cosas que la gente del equipo de desarrollo estaba haciendo, se dejó de ver la mentalidad 'de nosotros contra ellos', y no estamos allí todavía con la seguridad. Creo que es un área donde muchas compañías luchan".
Las pruebas y herramientas de DevSecOps
Las empresas tecnológicas del Silicon Valley lideraron la adopción de DevSecOps desde el principio, pero las herramientas de prueba de seguridad disponibles en ese momento no eran fáciles de desarrollar. Los desarrolladores quieren herramientas de línea de comandos que puedan automatizarse, que les permitan ajustar fácilmente diversas configuraciones y cuya salida pueda importarse fácilmente a los rastreadores de errores; mientras que los escáneres de seguridad tradicionales se diseñan teniendo en cuenta los equipos de seguridad y los CISOs, cuyos objetivos son la gobernanza, el cumplimiento de las políticas de seguridad y la gestión de riesgos.
Poco a poco empezaron a surgir nuevas herramientas creadas por los desarrolladores para los desarrolladores, e integradas en los entornos de desarrollo y en los flujos de trabajo de la CI/CD. Algunas eran de código abierto, otras eran modelos de negocio de arranque construidos en torno a ellas; pero, aunque resolvían las necesidades de los desarrolladores, ya no respondían realmente a las necesidades de los CISOs.
Si se utilizan muchas herramientas de código abierto diferentes, el equipo de desarrollo podría sentir que están cubriendo lo que creen que necesitan cubrir. Desde una perspectiva de gobierno, es difícil para el equipo de seguridad asignar todas estas diferentes herramientas fragmentadas a las políticas de la empresa, sostiene Wysopal.
En los últimos dos años, los proveedores tradicionales de aplicaciones seguridad de han cambiado sus productos para abordar ambos casos de uso: Para proporcionar tanto los análisis como los informes que necesitan los CISOs, y también tener la flexibilidad y la facilidad de uso que esperan los desarrolladores. Algunos proveedores de servicios basados en la nube dirigidos a los desarrolladores, como GitHub, han empezado a añadir pruebas de seguridad directamente a sus servicios. Cuando no está disponible como una característica nativa, suele estar disponible en el mercado del servicio como una integración de un proveedor tercero.
"A lo largo de toda mi carrera he observado un patrón que se repite", comenta Fox. "Hay un péndulo que parece oscilar de un lado a otro entre la gente que quiere un proveedor y un conjunto de herramientas que lo abarque todo, y la gente que está montando las mejores cadenas de herramientas. Yo diría que en los últimos dos años hemos visto que las cosas se mueven dramáticamente hacia el conjunto único que lo abarca todo".
Fox advierte que esta consolidación se revertirá en algún momento, cuando llegue la próxima tecnología disruptiva, y las organizaciones necesitan estar preparadas para eso. El problema con las suites es que pueden sobresalir en una o más cosas que la organización necesita, pero luego incluyen otras características que se utilizan porque vienen gratis con el paquete, no porque sean la mejor solución para esos respectivos problemas que está disponible ahí fuera. Con el tiempo, esto puede llevar a la formación de grupos de desarrolladores dentro de la organización que comenzarán a probar y a utilizar otras herramientas que se adapten mejor a sus necesidades, que las que ofrece el paquete aprobado por la empresa.
Desde el punto de vista de la gobernanza, tener equipos no gestionados es malo, pero las empresas deben ser conscientes de que, dentro de uno o dos años, ocurrirá inevitablemente y, a pesar de los intentos de restringir el uso de las herramientas, siempre habrá algunos desarrolladores que harán lo suyo, indica Fox. "Los primeros en adoptar la nube a veces eran equipos individuales dentro de organizaciones mucho más grandes que se rebelaban contra el tiempo que tardaban en conseguir las máquinas".
"Si uno acepta y comprende que eso va a suceder y piensa en ello, entonces puede ser un poco más flexible para reconocer que, oye, este nuevo equipo podría estar realmente al borde de alguna innovación realmente disruptiva, que podría ser con lo que queremos reemplazar esta [funcionalidad de la suite]", indica Fox.
Adopción de DevSecOps
Según Wysopal, cada vez más empresas están integrando escaneos de seguridad automatizados como parte de los pipelines de CI/CD, pero los resultados podrían no ser inmediatamente aparentes debido a lo que él llama la "deuda de seguridad", que es el número de vulnerabilidades que llegan a la producción porque los desarrolladores han decidido no arreglarlas.
Esto puede suceder por varias razones, entre ellas no poder arreglarlas inmediatamente, no tener previsto arreglarlas nunca porque hay otras mitigaciones en marcha, o no arreglarlas porque tienen una menor gravedad. En su informe sobre el estado de la seguridad del software en el 2019, que se basa en los datos recogidos en los escaneos realizados en 85 mil aplicaciones en el curso de un año, Veracode revela que el tiempo medio de reparación de las vulnerabilidades encontradas en las aplicaciones es de 171 días, en comparación con el tiempo medio de 59 días de hace una década, cuando salió el primer informe. Sin embargo, esto está sesgado por la deuda de seguridad acumulada y el tiempo medio de corrección se ha mantenido más o menos igual.
Cuando se correlacionan los resultados del escaneo con la frecuencia de los escaneos para una cierta aplicación -el aumento de la frecuencia sugiere la integración del escaneo automatizado en los flujos de trabajo de CI/CD-, los datos muestran que las aplicaciones escaneadas diariamente tienen una media de tiempo para arreglar de 19 días en comparación con 68 días para las aplicaciones que se escanean mensualmente. Esto sugiere que el escaneo más frecuente hace más probable que las vulnerabilidades se reparen más rápidamente.
"Al igual que con la deuda financiera, escapar de la deuda de seguridad requiere necesariamente cambiar los hábitos para pagar los saldos", concluye la empresa en el informe. "La integración del desarrollo de software y las operaciones de TI (DevOps) y la integración de la seguridad en esos procesos (a menudo llamados DevSecOps) en los últimos años ha cambiado ciertamente los hábitos".
Otro beneficio de un verdadero cambio de cultura hacia DevSecOps debería ser que el número de vulnerabilidades graves que existen en el código también debería disminuir. Los datos de Veracode muestran que el porcentaje de aplicaciones sin vulnerabilidades ha disminuido en general en comparación con hace 10 años, lo que sugiere que la situación ha empeorado; pero el porcentaje de aplicaciones sin fallas de alta gravedad ha aumentado en realidad del 66% al 80%.
"Veo tantas organizaciones que siguen luchando con este modelo", indica Fox. "Se están moviendo hacia este entorno de desarrollo continuo, y tienen infraestructura y CI y están usando contenedores. Luego tienen un equipo de seguridad de aplicaciones que llega más tarde ejecutando escaneos, produciendo informes -a veces literalmente informes impresos en papel físico- y llevándolos al desarrollo, en lugar de aprovechar las herramientas que potenciarían el desarrollo para evitar esos errores por adelantado. La mayoría de las organizaciones que veo todavía caen en esta mentalidad de nosotros contra ellos, de desarrollo contra seguridad".
Dicho esto, incluso con DevSecOps, algunas tareas todavía tendrán que ser realizadas por profesionales de la seguridad, y las pruebas manuales todavía tienen su papel. Por ejemplo, es difícil encontrar fallas lógicas o de diseño usando escaneos completamente automatizados.
"Lo que estamos empezando a ver es que las pruebas manuales no son algo que se haga una vez al año, o dos veces al año", señala Wysopal. "Está siendo más iterativo. Se está haciendo más como parte de ese proceso de DevOps donde tal vez hay un sprint de dos semanas, donde están haciendo una nueva característica que tiene un impacto en la seguridad, como una pequeña cantidad de pruebas manuales que están sucediendo solo para esa característica. Eso puede ser hecho a veces por el campeón de seguridad, si entienden lo suficiente acerca de las pruebas manuales y eso cumpliría el objetivo del equipo de desarrollo haciéndolo ellos mismos".
Lucian Constantin, CSO (EE.UU.)