La mentalidad DevSecOps: de la metodología lineal al "shifting left y shifting right"

En nuestro artículo DevOps al desnudo, hacemos referencia a los resultados de una encuesta que sugieren que el 88% de las empresas han adoptado un enfoque DevOps o planean llevarlo a cabo en los próximos años, mientras que solo el 19% afirman tener plena confianza en poder integrar la seguridad en esta filosofía. Estos datos subrayan el trabajo que debe realizarse en muchas organizaciones para incorporar y automatizar las mejores prácticas en seguridad en todo el ciclo de vida DevOps.

Las empresas están exponiéndose a un mayor riesgo en su deseo de ser ágiles. Introduciendo DevSecOps, esto es, integrando una mejora continua de la seguridad y testeo a lo largo de todo el ciclo de vida de desarrollo y operaciones, pueden reducirlo.

Replantearse la postura

Con la necesidad realizar despliegues con agilidad es fácil que las empresas caigan en una postura de alto riesgo en ciberseguridad, a menudo sin darse cuenta de ello. Gracias a regulaciones cada vez más estrictas y a sanciones más elevadas, muchas de las empresas se están viendo obligadas replantearse su política de seguridad.

El mayor inconveniente a la hora de introducir DevSecOps se encuentra en que los equipos DevOps habitualmente trabajan con plazos muy ajustados, siendo los sprints de tan solo dos semanas a menudo la norma. Cualquier alteración que demore el deadline cuesta dinero y reduce su agilidad. Todo ello impacta sobre la competitividad de la empresa y genera fricciones con los equipos de seguridad, que ya de por sí son a menudo percibidos como si fueran limitadores de velocidad en coches deportivos.

Mide dos veces, corta una

En inglés tienen el refrán "mide dos veces, corta una" (measure twice, cut once), popular en muchos oficios físicos como la carpintería, construcción o ingeniería, pero es particularmente relevante también para DevSecOps.
Como en todas las áreas de negocio, modernizar algo cuesta significativamente más que diseñarlo correctamente desde el principio. De hecho, Microsoft descubrió que es diez veces más caro adaptar la seguridad en una aplicación finalizada que incorporarla correctamente desde el inicio en el proceso de desarrollo.

No obstante, cortar antes de medir es lo que tradicionalmente ha sucedido con DevOps, donde la seguridad solo ha sido realmente considerada en el lado Ops del bucle infinito DevOps.

"Los tests de seguridad deben ser ágiles durante las diferentes etapas del ciclo DevOps"

En el obsoleto mundo de la metodología de desarrollo en cascada, el proceso es lineal: tras cada fase, el proyecto y la documentación pasan a la siguiente y, a menudo, a manos de otro equipo, hasta llegar a una fase en la que ya ningún cambio es posible. Solo entonces el equipo DevOps realiza algún test de seguridad. La mayoría de las veces, esperan hasta la fase de lanzamiento, pero para entonces ya es demasiado tarde: detectar un problema en ese punto conlleva un impacto enorme sobre la fecha de despliegue a producción.
Los únicos sectores que realizan tests de seguridad en una fase previa han sido históricamente el retail y los servicios financieros. En el caso de los servicios financieros, las autoridades regulatorias de algunos países incluso lo requieren para poder avanzar a la siguiente fase de desarrollo.

Shifting left y shifting right

La introducción de prácticas ágiles y la adopción de metodologías DevOps hacen habituales expresiones como "shift left", que hacen referencia a la implementación de tests para poner en duda ideas, es decir, a un desarrollo dirigido por tests, rompiendo la linealidad.
En el mundo DevSecOps es habitual oír la expresión "shifting left". Pero, en realidad, DevSecOps significa "shifting left" y "shifting right": las verificaciones deben ser implementadas en todas las etapas del ciclo DevOps, incluyendo tanto planificación, programación y preproducción, pero también producción o incluso desmantelamiento.
Para ello, los tests de seguridad deben ser ágiles y más estrechamente integrados con todo el proceso de desarrollo para asegurar que las vulnerabilidades no pasan desapercibidas durante las etapas del ciclo DevOps. En otras palabras, requiere una política de comprobación continua. Las buenas noticias son que los tests de seguridad continuos no solo ayudan a cumplir con los requisitos, sino que, además, son una manera más efectiva de testear, puesto que solo necesitas evaluar aquellas partes que han cambiado, no todo el código.

"Todo el mundo puede empezar a ser dueño de la seguridad de sus aplicaciones"

La agilidad no es excusa

Todo esto significa que es imperativo contar con una estrategia de tests de seguridad clara y bien definida a lo largo de todo el ciclo de desarrollo. La agilidad no debe ser, en ningún caso, motivo para que una empresa ponga la seguridad en segundo plano. Es más, en el clima actual, el cumplimiento es un reto al que se enfrentan prácticamente todas las empresas.
En ningún caso la seguridad debe ser tratada como simplemente marcar un check en la casilla correspondiente. Implementando una cultura de tests de seguridad continuos a lo largo del ciclo DevOps la empresa puede mejorar su postura de seguridad y reducir la deuda de seguridad asociada a la mala práctica de adaptar aplicaciones cuando es demasiado tarde.
Para lograrlo, uno de los principios a seguir es el de la estrecha colaboración entre los distintos equipos de la organización. Así como los equipos de desarrollo y operaciones fueron invitados (a veces forzados) a sentarse en la misma mesa, ahora es el momento de hacerlo para los equipos de seguridad. Esto requiere una puesta en común de qué hace cada uno y por qué. Esta es la manera de empezar a ser dueño de la seguridad de las aplicaciones de la misma manera que se es dueño de su calidad, desarrollo y operaciones.
Ideas clave:

  • Mayores regulaciones y sanciones fomentan que los equipos DevOps se replanteen su política de seguridad.
  • Es diez veces más caro adaptar la seguridad a una aplicación finalizada que no integrarla desde el principio.
  • DevSecOps significa "shifting left" y "shifting right", puesto que deben realizarse verificaciones a lo largo de las distintas etapas del ciclo DevOps.
  • Para integrar la seguridad en el proceso DevOps con éxito los equipos de seguridad y desarrollo deben trabajar conjuntamente y establecer responsabilidades conjuntas.