En los últimos días he tenido la oportunidad de hablar con personas de diferentes ámbitos sobre temas de desarrollo y las métricas y objetivos asociados a ellos. Como parte de estas conversaciones, han surgido algunas reflexiones sobre la seguridad y su encaje en el proceso de desarrollo, que me parece interesante compartir.
Seguramente nos hayamos encontrado en situaciones en las que, cuando a los equipos de DevOps se les añade una componente de seguridad, no siempre es bien recibida. Desde el equipo de DevOps, es muy probable que vean al equipo de seguridad como el policía malo que no les deja hacer nada y que pone pegas para que el trabajo salga adelante con toda la agilidad que el equipo DevOps quisiera, por el otro lado, tendremos al equipo de seguridad que verá al equipo de DevOps como un grupo de programadores que generan código sin tener en cuenta las implicaciones de seguridad que puedan acarrear, simplemente intentando minimizar tiempos de despliegue y en muchas ocasiones obviando las más mínimas medidas de seguridad.
Históricamente el equipo de DevOps y el equipo de seguridad han tenido objetivos y métricas diferenciados, mientras los primeros ponían foco en hacer lanzamientos rápidos y eficientes, los segundos se centran en eliminar las vulnerabilidades de los desarrollos, con lo que en cada nuevo lanzamiento, al equipo de seguridad le surgían nuevas probabilidades de encontrar en el código nuevas fallas de seguridad y vulnerabilidades.
Pero la realidad es que están obligados a entenderse por el bien de la empresa; interesa disponer de nuevas soluciones que aporten valor a negocio en el menor tiempo posible, pero estas han de ser seguras y confiables. Como decía un anuncio de hace tiempo “la potencia sin control no sirve de nada”, por ejemplo, no nos vale tener una web que permita hacer pedidos con solo pensarlos, si no podemos asegurar la identidad del comprador y la fiabilidad de la transacción. Aquí es donde nace DevSecOps, y aunque en muchas organizaciones aún se le sigue denominando DevOps, en la realidad ya es normal incorporar en sus equipos personas dedicadas a velar por la seguridad durante el desarrollo de cada uno de los lanzamientos.
Las ventajas de que DevOps y las operaciones de seguridad se retroalimente mutuamente es realmente beneficioso para las empresas y lo mejor para que ambos equipos trabajen de manera conjunta es compartiendo un lenguaje común, unas métricas y objetivos compartidos, de manera que los éxitos de uno sean los éxitos de todos. Veamos algunos ejemplos.
Auditorías de seguridad superadas
Por el titular de este indicador, puede parecer indicar que solo aplica a los equipos de seguridad, pero nada más lejos. El hecho de no superar una auditoría impacta por igual a ambos equipos y mina la confianza de la organización en IT. Del mismo modo, las auditorías pasadas día a día tienen un impacto positivo en todo el equipo, que pueden sentirse orgullosos de sus logros.
Reducción de pruebas de seguridad fallidas
El hecho de que una versión no supere las pruebas de seguridad, puede ser visto por el equipo de DevOps como que se han realizado pruebas innecesarias o que el equipo de seguridad está poniendo más trabas de las esperadas al despliegue de esa versión, creando fricción entre ambos equipos. Es por esto que, si se fijan desde un principio las pautas de seguridad esperadas y se establece el objetivo común de reducción de pruebas de seguridad fallidas, es más probable que todos trabajen juntos para solucionar el problema. Además, este indicador tiene un impacto directo en el indicador visto anteriormente.
Reducción del total de tickets de seguridad abiertos
Este es un objetivo claro para el equipo de seguridad, sin embargo, para el equipo de DevOps no es tan ovio. Si pensamos que un problema de seguridad en la mayor parte de las ocasiones puede acarrear un retraso en la entrega del software, vemos una clara implicación para el equipo de DevOps. Si quisiéramos llevarlo al extremo, en el caso incidentes graves de seguridad, podría hacernos retroceder a versiones anteriores de los desarrollos, con lo que tendría un gran impacto en el equipo de DevOps.
Incorporando herramientas de seguridad a los pipelines de CI/CD, podemos ayudar a los equipos de seguridad en la búsqueda de vulnerabilidades mientras que los equipos de DevOps pueden aprovecharlas buscar solución a los problemas de seguridad encontrados.
Cuanto más a la izquierda desplacemos la revisión de seguridad, antes podremos solucionar los problemas. De aquí podríamos sacar una nueva métrica que se basara en el número de vulnerabilidades que se descubren antes de llegar a producción, métrica que sería beneficiosa para ambos equipos: seguridad por tener mayor control de las vulnerabilidades y no llegar a producción y DevOps por no tener que hacer retrabajos ni retrasar despliegues.
Reducción del tiempo de despliegue
Es una métrica típica de los equipos de DevOps que no suele ser muy tenida en cuenta en los de DevOps. Cuanto más rápido se pueda desplegar cada versión, mejor para el equipo de DevOps. En el caso del equipo de seguridad, podemos observarlo bajo la visión de que cuanto menor sea el tiempo entre despliegues, menor es el tiempo que se debe esperar para corregir un error, más rápidamente tendremos la solución en producción.
Reducción del tiempo de reparación
La vida no es perfecta, y el software tampoco. Por muchos controles que pongamos, acabarán llegando vulnerabilidades a producción. La resolución de estos errores de seguridad es una tarea que requiere de la colaboración de los dos equipos, el de seguridad toma la iniciativa de encontrar qué ha ido mal y DevOps se encarga de solucionar el problema. En este caso la naturaleza de esta métrica indica una responsabilidad compartida con lo que es un objetivo para compartir entre ambos equipos
Como vemos visto, ambos equipos pueden compartir objetivos y métricas de manera que a ambos les interese trabajar de la manera más estrecha posible para su beneficio y el de la empresa. Ambos equipos un solo equipo: DevSecOps, una simbiosis perfecta.
1 thought on “DevSecOps, una simbiosis perfecta.”