Éxito de un programa DevSecOps

Mejorar el desarrollo seguro es un proceso que lleva tiempo y comienza por tener visibilidad de los procesos y las prácticas de seguridad que cada equipo aplica hoy. Si no se aborda con empatía, puede percibirse como una reacción a las deficiencias del desarrollo. Cuando los demás sienten que se les culpa o juzga, es fácil que se pongan a la defensiva. Una excelente manera de evitarlo es pedirle al referente que complete una evaluación de los procesos y las prácticas de su equipo. Esto permite reflexionar sin generar una dinámica de «ellos contra nosotros». La evaluación incluye preguntas que identifican distintos comportamientos de seguridad, tipos de pruebas, procesos, etc., para que el equipo de desarrollo indique cuánto realiza actualmente en cada área. Es común que los equipos se enfoquen más en unas áreas que en otras, y eso es totalmente normal.

El siguiente paso es mejorar, y ahí es donde el equipo de seguridad puede ayudar y apoyar a los equipos de desarrollo. Un gran ejemplo de mejora liderada por desarrolladores fue preguntarles qué aspectos de la evaluación querían mejorar. Solo tenían que elegir un par de aspectos y comprometerse con una fecha para implementar un proceso de mejora. Por ejemplo, podrían querer incorporar preguntas de seguridad en una revisión de código o eliminar de su backlog todas las vulnerabilidades de gravedad alta con una puntuación CVSS de 9.5 o más. Sea cual sea el objetivo, es importante que los desarrolladores lo lideren y se hagan responsables de él. El asesor de seguridad está para ayudar al referente a lograrlo. Ya sea que necesite capacitación, asesoramiento, cambios en el pipeline, etc., el asesor puede ayudarle a implementar el cambio que el referente quiere impulsar.

Sin embargo, una premisa fundamental es que el éxito (y posiblemente un KPI formal) del asesor de seguridad depende del éxito del referente de seguridad. El asesor solo tiene éxito si el referente logra cumplir su objetivo o avanzar en su plan. Esta medida de éxito compartida sustenta el objetivo común de desarrollar software de forma segura, que ambos equipos buscan alcanzar en conjunto.

Otra actividad habitual que impulsa el programa de referentes de seguridad es la gestión de vulnerabilidades. Tener visibilidad de dónde existen vulnerabilidades puede ser muy útil, ya que permite identificar los puntos críticos de tus aplicaciones e implementaciones. Sin embargo, en proyectos e implementaciones grandes, la enorme cantidad de vulnerabilidades que un desarrollador puede encontrar en el backlog de su proyecto puede volverse abrumadora. Tanto los equipos de desarrollo como los de seguridad pueden clasificar, ignorar y priorizar las vulnerabilidades del backlog, así como las recién identificadas. Los equipos de desarrollo conocen mucho mejor que el equipo de seguridad los flujos, la arquitectura y el diseño de las aplicaciones. Del mismo modo, el equipo de seguridad conoce mejor las amenazas y los riesgos. Trabajar en conjunto y mantener canales de comunicación abiertos —por ejemplo, mediante la relación entre un referente y un asesor— facilita y agiliza mucho estas conversaciones y evaluaciones.

Cómo iniciar e implementar un programa de referentes de seguridad

Ante todo, recuerda que la claridad y la sencillez son muy importantes. Al comenzar, asegúrate de que haya suficiente información para que las personas comprendan qué es el programa de referentes de seguridad, cuáles son sus objetivos y cuál es el apoyo que recibe y su importancia para la empresa. Redáctala pensando en los desarrolladores y pídeles comentarios mientras la preparas.

La lección más importante sobre el tamaño inicial del programa es no intentar abarcar demasiado ni implementarlo demasiado rápido. Identifica y aprende las prácticas recomendadas específicas de tu organización y tus equipos que puedan servir para ampliar el programa. Al elegir los equipos que participarán en la fase inicial, considera cuáles de los equipos de tu organización tienen las siguientes características:

• Los servicios, las aplicaciones y los equipos más importantes para tu empresa y que presentan el mayor riesgo

• Los equipos con mayor madurez en sus prácticas de seguridad y desarrollo, capaces de adaptarse al cambio

• Los equipos con integrantes que ya tienen relaciones con el equipo de seguridad

• Los equipos con integrantes interesados en la seguridad y dispuestos a mejorar la postura y la higiene de seguridad de su equipo.

Empezar con unos pocos equipos reduce el riesgo de que la implementación fracase, ya que puedes dedicar a cada equipo todo el tiempo que necesite. Al identificar las necesidades de los equipos, también puedes considerar los problemas comunes entre ellos, si ya los conoces. Por ejemplo, si implementas el programa en tres equipos y todos quieren empezar a adoptar el modelado de amenazas, puedes compartir comentarios entre ellos y concentrar los esfuerzos en menos aspectos.

Elegir al asesor de seguridad adecuado puede ser igual de importante, ya que será el principal punto de contacto para los equipos de desarrollo. Elegir a alguien que se comunique bien, que (preferentemente) tenga experiencia previa en ingeniería y sea empático con los desarrolladores puede marcar una gran diferencia.

Al principio, ofrece generosamente recompensas y reconocimiento para motivar a las personas y aumentar su interés en seguir avanzando. Empieza a crear una guía de prácticas recomendadas que puedas usar más adelante con otros equipos. Además, actualiza la documentación y las guías existentes según sea necesario para que los próximos equipos cuenten con información útil y vigente.

A medida que el programa se extienda por la empresa, considera incluir otros grupos de distintas áreas de la organización para representar mejor todas las áreas del negocio. Podrías organizar una gira de presentaciones para recopilar más información sobre qué otra ayuda necesitan y que aún no ofreces, además de compartir los logros de los equipos que ya participan en el programa. Compartir esos logros dentro del programa para que los equipos vean cómo les va a los demás también puede generar una sana competencia y ayudar a que todos mejoren.

A medida que implementes el programa en un equipo de desarrollo, recompensa sus acciones, sus nuevos aprendizajes y su sentido de responsabilidad con más responsabilidades. Puede sonar extraño, pero en última instancia queremos que los equipos de desarrollo sean más autónomos. Cuando demuestren que tienen la capacidad y la disposición para hacerse cargo de la seguridad, dales más autoridad y autonomía.

Cómo lograr la participación de los desarrolladores

Comprender los puntos débiles y las necesidades de la organización de desarrollo es clave para lograr que los desarrolladores participen en el programa. Tanto si decides ampliar el programa únicamente con voluntarios, mediante la selección de la gerencia o con una combinación de ambas opciones, debes asegurarte de que quienes participen se involucren y contribuyan.

Es importante explicar claramente por qué existe el programa. Definir sus objetivos y las funciones y responsabilidades de las personas de desarrollo y seguridad ayuda a que todos se sientan cómodos y participen. Una característica fundamental del programa es que los equipos de desarrollo y seguridad trabajan juntos para alcanzar un objetivo común: desarrollar y entregar código y aplicaciones seguras. En particular, para lograr el compromiso y el entusiasmo de los desarrolladores con el desarrollo seguro, es importante que este se considere, en gran medida, parte del trabajo de desarrollo.

Al elegir temas de capacitación, pedirles tareas a los desarrolladores e incluso dar seguimiento a tickets, es importante tener siempre presente a quiénes va dirigido el contenido. A menudo, a los desarrolladores les interesan más las prácticas recomendadas que aprender conceptos básicos que probablemente ya conocen. Para que el contenido sea eficaz, debe ser concreto, técnico y aplicable a la resolución de problemas.

A menudo, los detalles son importantes, como los lugares donde se llevan a cabo las comunicaciones y las interacciones. Por ejemplo, si quieres crear un ticket para que lo atienda el equipo de desarrollo, asegúrate de usar el sistema de tickets que prefiere. Si ya usa Jira, crea los tickets allí. Considera que cada herramienta o servicio adicional que esperes que use el equipo de desarrollo representa una barrera más para su participación.

Como mencionamos, también es importante definir claramente las responsabilidades y tareas que se esperan de los referentes de seguridad. Esto resulta más fácil cuando existe un rol oficial que especifica cuánto tiempo deben dedicar a las actividades de seguridad del equipo. En cualquier caso, basta con establecer dos o tres objetivos y actividades para que los referentes trabajen durante los próximos 3 a 6 meses. Así evitarás abrumarlos y los ayudarás a enfocarse en las actividades más importantes.

Antes mencionamos la importancia de las recompensas y el reconocimiento, y compartimos algunas ideas para demostrar el valor que estas actividades aportan a la empresa. Sin embargo, celebrar los logros no siempre significa pagarle a alguien un viaje a una conferencia. La mayoría de las veces, se trata de destacar el esfuerzo de una persona para motivarla a hacer más, actuando como su defensor o referente. Al mismo tiempo, este comportamiento anima a los demás a esforzarse más para recibir el mismo reconocimiento.

¿Cómo se ve el éxito?

Ante todo, es fundamental no esperar resultados extraordinarios en semanas ni siquiera en meses. El objetivo de crear un programa como este es mejorar los procesos y las prácticas de desarrollo para poder entregar software de forma segura. No hay una solución inmediata y, cuando se trata de personas, estos cambios tardan aún más. Se necesitan plazos realistas para el cambio y el éxito, de modo que las decisiones se tomen correctamente y no solo para alcanzar una meta arbitraria.

Adopción

Un indicador clave de cualquier programa de referentes de seguridad es su nivel de adopción. Como dijimos, es importante que la participación de cada referente sea voluntaria. Por eso, algunos indicadores de una adopción exitosa podrían ser la cantidad total de referentes, el crecimiento del grupo con el tiempo y la permanencia de sus integrantes.

Otro buen indicador es la cantidad de equipos de desarrollo a los que llegó el área de seguridad mediante el programa de referentes y qué proporción de la organización de desarrollo representan. Recuerda que crecer demasiado rápido puede llevar al fracaso; por eso, las metas deben ser alcanzables y surgir de forma orgánica, no ser agresivas ni impuestas.

Participación

El nivel de participación de los integrantes es otro indicador que permite saber si el programa y la relación están funcionando. Es difícil hacer un seguimiento para comprobar si los referentes realmente dedican entre el 10 y el 20 % de su tiempo a las actividades de seguridad, y probablemente ni siquiera quieras hacerlo. Se trata más bien de brindar apoyo oficial a los ingenieros para que este trabajo de seguridad forme parte de sus funciones, en lugar de ser una tarea adicional que quizás hagan, o no, en su tiempo libre. Además, el tiempo dedicado es aproximado y variará de una semana a otra según la demanda.

Un indicador mucho mejor es el nivel de participación en actividades que van desde reuniones periódicas hasta iniciativas que los referentes impulsan en sus equipos. Es fácil hacer seguimiento a las primeras anotando cuántos referentes asisten regularmente a las llamadas mensuales o participan en reuniones semanales con sus asesores de seguridad. Estos datos no deben usarse en contra de los referentes, sino para mejorar el contenido y las actividades del programa, y lograr que sean más atractivos y relevantes para ellos.

Impacto

Como mencionamos antes, es importante darles a los equipos de desarrollo la capacidad de hacerse cargo de los cambios y las mejoras en sus equipos. Tú decides hasta dónde quieres llegar, pero entender qué está asumiendo el equipo, qué está mejorando y qué ha completado es una medida real del impacto que ha tenido el programa.

Una buena forma de lograrlo con la técnica del cuadro de mando es pedirle al equipo de desarrollo que evalúe sus propias prácticas y procesos. Para empezar, ¿cuántas personas están completando los cuadros de mando de sus equipos? Después de trabajar con ellos para que conozcan los mayores riesgos, las soluciones más rápidas, etc., ¿elaboraron un plan de mejora que les pertenece y que lideran con el apoyo del equipo de seguridad? Y, por supuesto, hay que medir cómo avanzan los equipos respecto de sus planes. Esto debería ser un KPI del que se hagan responsables tanto el promotor como el coach, y que mida este progreso.

Progreso

Como ya mencionamos, hay una diferencia entre el tipo de capacitación que puede interesarle a un promotor y el que puede interesarle a un desarrollador menos interesado en la seguridad. Y aunque eso está bien, también es importante medir y dar seguimiento a su progreso de aprendizaje. Una vez que decidas cómo quieres capacitarlos —ya sea con recursos internos, certificaciones externas o incluso horas de trabajo práctico en seguridad—, usa un modelo de niveles, medallas o certificaciones que muestre el nivel de conocimientos de tus equipos en conjunto, con objetivos de mejora para cada trimestre.

Paneles

El último aspecto que se debe medir, que podría considerarse una métrica de influencia, son los paneles de seguridad de productos, que muestran estadísticas sobre tus vulnerabilidades, la cantidad de pruebas, la adopción entre los equipos, etc. Sin contexto, es fácil que estas cifras no reflejen la calidad ni el riesgo de un proyecto. Por ejemplo, el hecho de que un equipo realice más pruebas que otro probablemente significa que encontrará más vulnerabilidades, porque tiene mayor visibilidad y conocimiento de sus problemas. Esto no significa que represente un riesgo mayor, aunque las cifras sean más altas.

Poder mostrar el impacto por equipo, con contexto y explicaciones, es muy valioso. Al medir estas métricas, asegúrate también de medir los procesos y las prácticas que influyen en ellas. Por ejemplo, hacer que tu equipo cree modelos de amenazas para cada función que desarrolla reduce considerablemente el riesgo del proyecto. Esto influirá en la cantidad de vulnerabilidades que se encuentren durante el desarrollo, y ese contexto aporta mucha riqueza a los resultados.