“Shift-left”: Peligros y cómo evitarlos

Los desarrolladores de aplicaciones desempeñan un papel fundamental para asegurar que las empresas tengan éxito y se mantengan competitivas. Pero la filosofía de "shift-left" que ha llegado a dominar el pensamiento sobre DevOps (o más bien, DevSecOps) ha tenido el efecto de dejarles sobrecargados de trabajo, estresados y cansados de ser culpados por cada problema o vulnerabilidad que aparece tras el despliegue de las aplicaciones de las que dependen las organizaciones.

Especialmente ahora, cuando el talento de los desarrolladores es cada vez más difícil de encontrar, la rotación de empleados y la pérdida de productividad que resulta de desarrolladores quemados es terriblemente costosa. Afortunadamente, este es un problema que se puede solucionar.

¿Qué es shift-left?

En los tiempos antiguos, los desarrolladores programaban aplicaciones, y luego los ingenieros de QA verificaban las aplicaciones para funcionalidad y facilidad de uso, y después los equipos de seguridad las revisaban en busca de vulnerabilidades. Y solo después de que todo estuviera revisado, las aplicaciones se desplegarían para uso operativo.

Nadie tiene ese tipo de tiempo ya. ¡Necesitamos que esas aplicaciones funcionen ahora ahora ahora! La solución fue, y es, shift-left, que se refiere a mover QA y seguridad hacia la izquierda en el ciclo de vida del desarrollo de software (SDLC) (anteriormente) lineal. Desde ahora, QA y seguridad se tratarían durante el desarrollo inicial de la aplicación, o incluso en la fase de diseño.

Teoría frente a práctica

Una buena idea en principio. En principio, significaba que los ingenieros de QA, los expertos en seguridad y los desarrolladores trabajarían juntos a lo largo del SDLC, colaborando en tiempo real para acelerar dramáticamente el proceso y desplegar las aplicaciones más pronto.

En la práctica, sin embargo, este enfoque a menudo significa que los equipos de desarrollo son responsables de cosas que están fuera de su área de experiencia. Los problemas culturales hacen que sea más desafiante de lo esperado lograr ese nivel de colaboración, y en muchos casos se les han asignado a los desarrolladores las tareas de QA y seguridad además de su descripción de trabajo básica.

Por supuesto, no hay nada de malo en pedir a los desarrolladores que piensen seriamente en la seguridad desde el principio. Si pueden identificar una posible vulnerabilidad en la fase de diseño, entonces se puede solucionar fácilmente. Mientras que si solo sale a la luz después de que la aplicación ha sido codificada y compilada, entonces podría ser un proceso mucho más tedioso solucionarlo, especialmente si el código vulnerable también tiene dependencias codificadas.

Como explica Shannon McFarland en esta publicación del blog de Cisco, los beneficios proyectados de shift-left son significativos: 

1. Colaboración mejorada, ya que los equipos de QA, seguridad y desarrollo trabajan juntos y todos ellos mejoran su comprensión de todo el proceso SDLC
2. Costes reducidos gracias a la identificación y solución de problemas más temprano en el proceso, lo que significa más rápido y fácil
3. Aumento de la seguridad a medida que los desarrolladores aprenden a integrar la seguridad en el proceso de diseño
4. Calidad de software mejorada ya que es probable que menos problemas de calidad sobrevivan a la implementación operativa

Pero en lugar de estos beneficios, con demasiada frecuencia los resultados son:

1. Aumento de la carga de trabajo a medida que los desarrolladores asumen nuevas tareas para las que no están capacitados, sin reducción de su carga de trabajo existente.
2. El aprendizaje continuo como desarrolladores es necesario para dominar constantemente nuevas herramientas, procesos y tecnologías a medida que más cosas se adelantan en el ciclo de vida del desarrollo.
3. Agotamiento, ya que los desarrolladores se encuentran bajo una presión creciente para crear aplicaciones seguras y de alta calidad aún más rápido que antes
4. Dinámicas de equipo interrumpidas a medida que se difuminan los límites organizativos tradicionales.

De lineal a continuo

Como argumenta Melinda Marks en este artículo de TechTarget, parte del problema con shift-left es que se basa en una comprensión tradicional y lineal del SDLC. Pero los procesos de desarrollo en la nube de hoy están dominados por pipelines de integración continua/entrega continua (CI/CD).

Para simplificarlo demasiado, esto significa que nuevas funciones y características—nuevas ramas de una base de código en constante crecimiento—se desarrollan, implementan e integran continuamente en aplicaciones existentes. No hay un momento en que la aplicación esté terminada, sellada como "APROBADA" por los equipos de control de calidad y seguridad, e implementada para salir y hacer el bien en el mundo. Las aplicaciones críticas para el negocio siempre están en un estado continuo de evolución.

Esto hace que sea mucho más difícil señalar un punto a lo largo de un proceso lineal y decir “Ahora haremos QA aquí, en lugar de más tarde.” Y significa que los desarrolladores, ingenieros de QA y especialistas en seguridad están aplicando sus habilidades al mismo tiempo, en un bucle continuo de innovación y mejora.

Haciéndolo funcionar

Liderazgo, responsabilidades claramente definidas, una cultura libre de culpas y el compromiso de todas las partes interesadas son las claves para una estrategia exitosa de desplazamiento a la izquierda que obtiene los beneficios sin los inconvenientes del agotamiento de los desarrolladores y todos los costos que conlleva.

Esto requiere habilidades organizativas sólidas, como ser capaz de diseñar un proceso que delinee específicamente las responsabilidades de cada equipo, en lugar de simplemente decir que los desarrolladores tienen que hacer más pruebas de control de calidad y auditorías de seguridad. Y requiere muchas habilidades de liderazgo suave, como alentar a todas las partes interesadas a participar en análisis post mórtem sin culpas, enseñar a todos a tanto aceptar como dar críticas constructivas con gracia, y gestionar la integración y colaboración de equipos que tradicionalmente han operado en silos separados.