Entender a los equipos de desarrollo

Implementar cualquier programa interfuncional requiere empatía. La colaboración entre los equipos de seguridad y desarrollo suele fallar porque sus perspectivas y objetivos son muy diferentes. Aunque ambos equipos pueden buscar el mismo resultado —aplicaciones seguras—, sus flujos de trabajo preferidos y las formas de medir el éxito pueden ser muy distintos. Por suerte, la empatía puede impulsar la alineación.

Para lograr una adopción sólida y natural, es importante crear una cultura de colaboración en la que tus equipos de seguridad y desarrollo hablen el mismo idioma y trabajen en conjunto para alcanzar objetivos comunes. El equipo de seguridad ya no está ahí para auditar y agregar trabajo a los equipos de ingeniería. Está ahí para apoyar y permitir que los ingenieros encuentren y resuelvan los problemas de seguridad lo antes posible, con rapidez y eficacia. Los equipos de ingeniería deben ver a los equipos de seguridad como el grupo que los ayuda a lograrlo, y deben pedir ayuda cuando no sea así.

Al implementar un programa moderno de seguridad de aplicaciones (AppSec), es fundamental que quienes interactúan con los equipos de desarrollo y los apoyan comprendan claramente los problemas, las fricciones y las frustraciones que enfrentan actualmente los desarrolladores. Solo cuando los comprendan podrán ver cómo integrar la seguridad en el proceso de desarrollo. Analicemos en más detalle qué aspectos conviene evaluar y tener en cuenta antes de iniciar nuevas colaboraciones. Estas son algunas preguntas que puedes hacerte antes de comenzar la implementación.

«[La seguridad] debe basarse en una asociación. Una razón fundamental por la que ocurren muchas de nuestras fallas de seguridad es que tratamos de imponerles cosas a los grupos a los que queremos ayudar a tener éxito, en lugar de colaborar realmente con ellos. Mi función es ayudar a nuestros equipos de ingeniería en Mandiant a producir código de calidad, seguro y funcional con rapidez. Como empresa, necesitamos avanzar rápido; colaborar es la forma de producir cosas que resuelvan las necesidades del negocio y de seguridad».

Tim Crothers, vicepresidente sénior y director de seguridad de Mandiant

¿Cuánto comprendes y empatizas con tus equipos de desarrollo?

Es fundamental entender cómo trabajan tus equipos de desarrollo y cómo toman decisiones. Si comprendes su enfoque general y su nivel de madurez en el desarrollo, podrás establecer expectativas realistas sobre lo que quieres que hagan, determinar cómo y dónde pueden cambiar realmente, y ver cuál es la mejor manera de apoyarlos y empoderarlos. Sin esto, no podrás entender su punto de vista, lo que generará fricciones y reducirá las probabilidades de éxito. Además, recuerda que las respuestas a los siguientes temas probablemente varíen entre los equipos de una misma unidad de negocio o incluso de un mismo departamento. No hagas suposiciones sobre los equipos de desarrollo y ten en cuenta que probablemente tengan culturas y enfoques distintos.

¿Qué disposición tienen para el cambio?

A algunos equipos de desarrollo les atrae la tecnología más reciente —a veces demasiado— y están dispuestos a probar nuevas herramientas, tecnologías, bibliotecas, modelos de programación, etc., solo para mantenerse al día o descubrir si podría ser una mejor solución. Otros equipos solo hacen este tipo de cambios cuando hay un problema existente o cuando tienen la certeza de que el cambio resolverá un problema que afecta actualmente a su aplicación. Y hay equipos que, por defecto, evitan los cambios y siguen la filosofía de «si no está roto, no lo arregles».

Reconocer el comportamiento y la mentalidad de tus equipos de desarrollo respecto a su disposición para cambiar te ayudará a determinar cómo colaborar mejor con ellos para encontrar un objetivo común para tu programa AppSec. Por ejemplo, si antes se resistieron a hacer pruebas mediante pull requests de Git, no des por sentado que agregar pruebas de seguridad a sus pull requests será diferente de otros intentos.

Una distinción importante al estimar la madurez y la capacidad de adaptación de tus equipos de desarrollo es la adopción tecnológica frente a la adopción de procesos. Es común que las empresas menos maduras o en una etapa inicial se enfoquen más en adoptar tecnologías que en estandarizar procesos. Por ejemplo, las startups necesitan lanzar productos rápidamente para llegar primero al mercado, por lo que la maduración de procesos y estándares pierde prioridad. Será bastante difícil lograr que una empresa en esa etapa implemente prácticas de seguridad que funcionen como una barrera.

¿Qué tan bien definidos están los equipos o los proyectos?

Una diferencia importante entre la perspectiva de seguridad y la de los desarrolladores es la propiedad de los activos. Desde la perspectiva del equipo de seguridad, los equipos de ingeniería son responsables de varios activos, algunos más críticos que otros. Desde la perspectiva de los desarrolladores, cada equipo se enfoca en ciertos proyectos o servicios de los que es responsable, proyectos que otros equipos poseen y a los que contribuyen, y proyectos a los que muchos equipos contribuyen y de los que dependen, pero que no pertenecen a ningún equipo específico.

Teniendo esto en cuenta, pedirle a un equipo de desarrollo que se haga responsable de la seguridad de su código y sus proyectos tendrá distintos resultados según quién sea responsable de cada proyecto. Cuanto más claramente delimitada esté el área, más probable será que el equipo de desarrollo asuma la responsabilidad de la seguridad de ese proyecto.

Además, la antigüedad del equipo también puede influir en cómo implementas el programa. Lo ideal es incorporar estándares y procesos desde el inicio para un equipo nuevo. Pero una opción más probable es aprovechar los cambios naturales. Por ejemplo, si un equipo atraviesa un cambio importante ajeno a tu programa (un nuevo gerente, una reestructuración del equipo, etc.), será más probable que adopte estándares de desarrollo adicionales como parte de la definición de su forma de trabajar.

¿Cuál es la capacidad actual de tu equipo?

Como la mayoría de los equipos, los desarrolladores no están esperando sin hacer nada a que llegue el trabajo. Priorizan lo más importante que deben hacer después, sabiendo perfectamente que no pueden completar todo lo que tienen en su lista de tareas, que no deja de crecer. Simplemente agregar más tareas a la carga de trabajo ya desbordada de un desarrollador o un equipo no es constructivo ni brinda apoyo. Esto se agrava cuando los equipos tienen recursos insuficientes y hacen lo posible por avanzar sprint tras sprint mientras intentan mantenerse a flote.

«Sabemos que tienen muchas otras responsabilidades. Deben crear funcionalidades y productos. También deben ocuparse del rendimiento y la confiabilidad. Queremos que participar en seguridad sea lo más fácil posible».

Jason Chan, vicepresidente de Seguridad en Netflix

¿Qué variedad de capacidades tienen los equipos en toda la organización?

La razón para dedicar tiempo a comprender la dinámica de tus equipos de desarrollo es que todos son diferentes. Es muy común que un pequeño número de equipos pioneros adopte primero nuevas tecnologías y procesos, y que los demás los sigan con el tiempo. La adopción mayoritaria suele empezar lentamente, pero luego se acelera cuando hay suficientes automatizaciones y prácticas recomendadas para facilitar la adopción de otros equipos. Por supuesto, exigir que la barrera sea mucho más baja para lograr una adopción amplia significa que muchos equipos tardarán mucho más en adoptar los cambios, si es que lo hacen. Antes de impulsar la adopción entre los desarrolladores, necesitas saber cuántos equipos necesitarán una barrera más baja y cuáles pueden participar en un programa piloto para crear las automatizaciones y prácticas.

Un ejemplo de la variedad de capacidades de los equipos se observa en su tendencia a agregar integraciones y en su disposición a recibir comentarios. Por lo general, los equipos maduros quieren recibir comentarios lo antes posible, ya sea en su IDE, en las automatizaciones de sus procesos de compilación locales o en sus repositorios de Git. Los equipos menos maduros quizá solo quieran automatizar en el proceso de CI, lo que significa que recibirán comentarios tarde, normalmente justo antes de implementar en producción. Es poco probable que incluir a ambos tipos de equipos en el mismo grupo de implementaciones tenga éxito y, probablemente, abrumará a los equipos menos maduros.

Una causa común de las diferencias en la adopción es la complejidad y antigüedad de los proyectos. Un servicio antiguo y complejo que se mantiene, en lugar de desarrollarse activamente, es un buen ejemplo de un proyecto que no sería adecuado, ya que cabe esperar más resistencia a los cambios en los procesos. Del mismo modo, si tu organización creció de manera inorgánica (por ejemplo, mediante adquisiciones), heredarás distintas tecnologías, canalizaciones y culturas, lo que reduce la coherencia en toda la organización y aumenta las probabilidades de que las suposiciones sobre los equipos sean incorrectas.

¿Cómo integran hoy las prácticas de seguridad tus equipos de desarrollo en su canalización?

Después de dedicar tiempo a evaluar los equipos de desarrollo de tu organización, es importante identificar qué prácticas de seguridad siguen actualmente y cómo lo hacen para establecer una base sobre la cual avanzar. Normalmente, al principio los equipos de desarrollo adoptan un enfoque muy poco intervencionista: quizá ejecutan pruebas periódicamente solo para obtener visibilidad y las integran en la canalización cuando es posible. Para empezar, probablemente no haya acciones que bloqueen el proceso ni barreras, lo que permite que el equipo de desarrollo siga haciendo lanzamientos a la velocidad a la que está acostumbrado.

Luego, toma nota de sus preferencias de integración. Por ejemplo, ¿hacen análisis o pruebas en CI o antes, en los pull requests? ¿Usan una integración lista para usar o crearon scripts y automatizaciones para adaptarla a su canalización o proyecto? ¿Hacen pruebas en los IDE o su enfoque es más reactivo? Es más probable que un equipo que prefiere las integraciones adopte una solución de seguridad integrada para desarrolladores.

«Desde mi perspectiva, lo fundamental es comprender las prácticas que prefieren nuestros equipos de ingeniería. ¿Cuáles son esos patrones que nos permitirán ser socios para implementar barreras de protección en lugar de controles? Queremos apoyar los resultados que buscan los equipos. Debemos asegurarnos de que las prácticas y los procesos adecuados sean los que ellos han definido. Normalmente, colaboramos en eso. Si lo simplificamos, lo constante es buscar brechas: en nuestros procesos y en nuestra [colaboración]».

Tim Crothers, vicepresidente sénior y director de seguridad de Mandiant

¿Cómo priorizan la seguridad durante los sprints?

Otro buen indicador de la etapa en la que se encuentra un equipo en su recorrido hacia la seguridad es si se enfoca más en el desarrollo futuro o en el backlog. A menudo, los backlogs pueden resultar abrumadores, con miles de problemas o vulnerabilidades, frente a una nueva funcionalidad que quizá solo introduzca unos pocos. También es importante entender cómo el equipo clasifica los problemas para determinar cuáles son importantes (o necesarios) de corregir, así como cuándo y cómo escalar. Si un equipo tiene OKR relacionados con su backlog y procesos para avanzar, es más probable que adopte herramientas que le ayuden a lograrlo más rápido.

¿Cómo incorporan las pruebas y correcciones de seguridad a sus sprints? ¿Exigen que el código pase una prueba de seguridad sin problemas para poder entregarlo o agregan tareas de seguridad a su backlog de deuda técnica y dedican un sprint cada pocos meses a corregir los problemas? Esto último suele ser común en equipos que aún no tienen mucha madurez, e incluso en algunos equipos de bajo rendimiento que no pueden completar el trabajo dentro de los sprints. En estos casos, también es común ver sprints dedicados a la escalabilidad, el rendimiento o la confiabilidad, que compiten por el tiempo con los sprints de seguridad.

Por último, ¿el equipo cuenta con documentación interna sobre cómo realizan las pruebas o con SLA para resolver sus problemas? Estas son buenas preguntas que no solo te ayudan a entender en qué situación se encuentra el equipo hoy, sino que también te indican cuál es el siguiente paso para facilitar las pruebas y ayudarlo a enfocarse en lo que realmente importa.