Comprender la actitud de los desarrolladores hacia la seguridad

Lo hacen porque deben

La mejor manera de lograr que los equipos de desarrollo incorporen la seguridad es convertirla en una parte esperada de sus funciones y objetivos. Así, los equipos de desarrollo tienen el mandato y los medios para priorizar la seguridad. En este modelo, es importante definir claramente quién es responsable para evitar que los equipos supongan que otro se encarga de la seguridad de un proyecto compartido o heredado.

No basta con que las personas sepan qué deben hacer. También es igual de importante contar con procesos que ayuden a los equipos a cumplir sus objetivos de seguridad. Por ejemplo, tener visibilidad de los resultados de las pruebas o explicar los niveles adicionales de exposición y riesgo que aparecen después de que un desarrollador escribe una nueva función. La visibilidad y transparencia que ofrece un cuadro de mando pueden aportar la rendición de cuentas que cada desarrollador necesita para asegurarse de que la seguridad se integre en el flujo de trabajo. Esta técnica también funciona especialmente bien con equipos subcontratados que suelen rotar entre proyectos y sienten menos responsabilidad o orgullo por ellos.

Lo hacen porque deben

¡Es una razón tan buena que la repetimos! Hay otro motivo por el que los desarrolladores deberían programar de forma segura: es lo correcto. A algunos desarrolladores les importa la seguridad, o sienten un gran orgullo y responsabilidad, personal o profesional, por escribir código sostenible y seguro.

Haz que el camino correcto sea el más fácil (también llamado camino pavimentado)

Cada obstáculo que impide que un desarrollador realice una tarea de seguridad puede evitar que la complete. Estos obstáculos van desde no saber cómo hacerlo hasta tener un flujo de trabajo desesperadamente lento, sentirse abrumado por los problemas y no saber por dónde empezar. Para que se adopten las prácticas de seguridad, es clave que la seguridad se integre fácilmente en los flujos de trabajo existentes.

Fomentar el uso de prácticas estándar mediante un enfoque de camino pavimentado es una excelente manera de brindar apoyo útil y prácticas recomendadas comprobadas. Además, permite crear documentación y recomendaciones precisas y actualizadas que otras personas pueden reutilizar y mantener al día con regularidad.

«A ese concepto lo llamamos camino pavimentado. Sin duda, podrías abrirte paso entre la maleza y avanzar por el bosque. Pero si tienes un camino pavimentado y despejado que te lleva a tu destino, es probable que elijas ese camino».

Jason Chan, vicepresidente de Seguridad en Netflix, en The Secure Developer, hablando sobre la empatía con los desarrolladores

Piensa en lo que necesitan los desarrolladores para avanzar. Analizar, probar e identificar problemas es relativamente fácil en comparación con corregirlos. Un desarrollador no quiere saber que hay diez vulnerabilidades en el grafo de dependencias; quiere saber que, si actualiza una dependencia a una versión menor, resolverá los problemas que bloquean el lanzamiento. Por eso, piensa en soluciones en lugar de problemas: ¡la lista suele ser mucho más corta!

También debes tener muy presente en qué quieren invertir su tiempo los desarrolladores y cómo prefieren recibir los resultados y las acciones de seguridad. Todo lo que esté fuera de su flujo de trabajo habitual es una distracción que tendrán que recordar. Las integraciones en los flujos de trabajo existentes, implementadas por personas que conocen los procesos y la tecnología subyacentes, pueden ofrecer una excelente experiencia para los desarrolladores. Procura que los resultados sean útiles, que los comentarios sean claros y permitan actuar, y que el flujo de trabajo sea rápido y sencillo. En resumen, implementa con empatía por tus desarrolladores.

Automatiza, automatiza, automatiza

Los pipelines de DevOps más sólidos están bien automatizados. En un estudio reciente, Snyk descubrió que la automatización también se correlacionaba fuertemente con el éxito de los programas de seguridad shift left. Los datos mostraron que las organizaciones con pipelines de implementación totalmente automatizados tienen el doble de probabilidades de incorporar herramientas de pruebas estáticas de seguridad de aplicaciones (SAST) y análisis de composición de software (SCA) en su ciclo de vida de desarrollo de software (SDLC). Además, las organizaciones con automatización completa tenían más de cuatro veces más probabilidades de corregir problemas de seguridad en un día y más del doble de probabilidades de hacerlo en una semana.

Está claro que, cuanto más automatizamos, más pruebas podemos ejecutar y más problemas podemos detectar. Si lo pensamos bien, podemos agregar barreras de seguridad y políticas a nuestros pipelines para tener visibilidad y estar al tanto de los problemas que requieren nuestra atención y acción. Esto crea una dinámica familiar para los desarrolladores que ya automatizan tareas como las pruebas de integración.

Además, automatizar la seguridad también reduce la fricción entre los equipos de seguridad y desarrollo, porque es un proceso —no un equipo ni una persona— el que indica que hay que corregir un problema. Así, el equipo de seguridad puede apoyar al equipo de desarrollo y ayudarlo con los problemas que requieren conocimientos especializados, en lugar de convertirse en un cuello de botella o en quien trae malas noticias.

«Diría que lo que tienen que hacer es automatizar todas las herramientas de seguridad (que tenga sentido usar) e integrarlas en su pipeline de DevOps. Ojalá lo hubiéramos hecho antes; es algo que deberíamos haber implementado mucho antes. Poder avisar a los desarrolladores de un problema en su código lo antes posible, de forma automatizada, es fundamental. Incluso se podría hacer al momento de confirmar el código, para que lo sepan en ese instante, o con una herramienta que marque de inmediato un problema en el IDE mientras escriben. Implementar esa automatización es fundamental. Intentar corregir un problema justo antes de lanzar un producto es mucho más difícil».

Ryan Ware, arquitecto de seguridad y director del equipo de herramientas de seguridad y garantía de productos de Intel

Educación y conocimientos sobre desarrollo seguro

La educación puede ser una experiencia positiva o negativa para los equipos de desarrollo. En especial, cuando hay tantos cursos y materiales de capacitación irrelevantes que los equipos deben completar (y luego dedicar tiempo a un breve examen), todo lo cual probablemente termina marcado como una casilla más en una lista de cumplimiento de capacitación.

Integrar la educación en el día a día de los desarrolladores para que les ayude a hacer su trabajo, corregir un error o desarrollar con más seguridad puede acelerar la adopción de prácticas de seguridad. El curso o módulo educativo debe aportar valor a los desarrolladores, ayudarlos a estar más seguros y ofrecer resultados rápidamente.

Al planificar la educación, considera cómo ayuda a tus equipos a enfocarse en el desarrollo seguro. Piensa en las acciones que podrán aprender y aplicar en sus procesos o flujos de trabajo. Considera cómo puedes adaptar la capacitación para ofrecerles ayuda relevante justo cuando más la necesitan. También piensa en cómo puede ir más allá de la tecnología y abordar los procesos y la cultura.

Aquí tienes algunos consejos para aprovechar al máximo la educación en seguridad:

• La capacitación debe ser lo suficientemente atractiva para que quieran realizarla. Una manera sencilla de mejorar su calidad es poner en marcha programas piloto, recopilar comentarios y hacer ajustes antes de implementarla a gran escala.

• Ten en cuenta que los vectores de ataque pueden variar considerablemente entre los equipos de desarrollo y ofrece lecciones relevantes para cada uno. Por ejemplo, los ataques de directory traversal pueden ser más pertinentes para tus desarrolladores de backend.

• Al capacitar sobre vulnerabilidades, asegúrate de abordar las que afectan al equipo según los lenguajes, frameworks, bibliotecas y otros elementos que utiliza. Las historias sobre incidentes que afectaron a otras empresas con ecosistemas similares pueden ayudar a mostrar las posibles consecuencias.

• Aunque es bueno mostrar ejemplos reales de problemas de seguridad, no uses el miedo como principal motivador. Puede ayudarte a generar avances a corto plazo, pero no es una estrategia a largo plazo. La excepción son los problemas de seguridad realmente alarmantes, como los que podrían devastar un negocio.

• Incluye la educación en los cuadros de mando para que los equipos se hagan responsables de completarla.

• Asegúrate de que la capacitación se enfoque en cómo prevenir ataques concretos. Si explicas una vulnerabilidad, muestra cómo se puede explotar. Si explicas cómo reforzar una parte de un pipeline, explica qué superficie de ataque se está mitigando. Haz que sea algo real y concreto.

• Asegúrate de que exista documentación para todas las tareas que quieres que realicen los desarrolladores. Pídeles que validen la utilidad de la documentación o, mejor aún, que la escriban para el próximo desarrollador o equipo. Recuerda que la documentación no sustituye a las barreras de seguridad, pero también debes documentarlas.

• Si un equipo rojo detecta un incidente, aprovéchalo para crear una capacitación relevante y realista. Analizar el incidente en profundidad permite mostrar los riesgos reales. Si es posible, invita al equipo rojo a una sesión de preguntas y respuestas.

¿Por qué los desarrolladores evitan la seguridad?

Hemos hablado de por qué los desarrolladores dedican tiempo a crear software seguro. Pero es igual de importante, o más, entender por qué se resisten y evitan dar pasos adicionales para asegurarse de entregar código seguro.

Fricción

Las barreras que identifican los equipos pueden variar según la etapa de adopción de la seguridad en la que se encuentren y su madurez en el desarrollo moderno. En los equipos que recién comienzan a incorporar la seguridad, vemos resistencia cuando no se comunican con claridad las razones ni el valor de los cambios en los procesos. El nuevo proceso debe ser poco invasivo y tener en cuenta al equipo de desarrollo y sus flujos de trabajo. Para impulsar la adopción, comunica de forma clara y frecuente, reduce la fricción al mínimo integrándote en los procesos existentes y, cuando sea posible, consolida las herramientas para reducir la complejidad.

«Creo que uno de nuestros mayores desafíos ha sido lograr que los principales interesados de la organización tecnológica y los desarrolladores comprendan realmente la importancia y el valor de la seguridad. En un mundo ideal, ya tendrían esa comprensión. Un desarrollador no tendrá mucha motivación para hacer algo si no le ve el valor. Lo mismo ocurre con un responsable de producto, un gerente de desarrollo o incluso un director de ingeniería de software. Si no reconocen el valor de la seguridad, no tendrán motivos para priorizarla por encima del trabajo en sus funciones».

Nicholas Vinson, líder de DevSecOps en Pearson

Desconfianza

Para mantener un proceso a largo plazo que los equipos sigan de forma sostenida, es necesario aportar valor y mantener o ganar su confianza. Cuando dejan de confiar en los datos, las herramientas o el proceso, los consideran un obstáculo e intentan evitarlos. Por ejemplo, los falsos positivos persistentes de una herramienta o un proceso no solo desaniman o molestan a los desarrolladores, sino que también hacen que sea más probable que ignoren o descarten los resultados de vulnerabilidades o problemas reales, en comparación con datos en los que sí confían.

Complejidad

Del mismo modo, cuando las herramientas agregan complejidad a los problemas existentes y no ayudan a encontrar ni ofrecen una solución, solo generan más trabajo para los desarrolladores. Saber que existe una vulnerabilidad es apenas el comienzo. El desarrollador aún debe identificar todas las formas y los lugares en que se puede acceder a ella en la aplicación (por ejemplo, las distintas rutas del grafo de dependencias). Los desarrolladores necesitan saber de inmediato si se puede corregir y, de ser así, cuál es el proceso de remediación. Quieren herramientas intuitivas e instructivas que les permitan implementar soluciones rápidamente.

Responsabilidad

Otra razón por la que un trabajo puede dejar de estar a cargo de una persona sin pasar a manos de otra es la falta de claridad sobre quién es responsable. En proyectos o funcionalidades nuevos, la responsabilidad puede estar clara: ningún otro equipo toca el código con el problema, salvo ese equipo. Pero ¿qué pasa si una parte de la aplicación es un servicio compartido que usan y al que contribuyen muchos equipos, pero del que nadie es plenamente responsable? ¿Quién se ocuparía de un error o un problema de seguridad que no le afecta directamente? Otro ejemplo común es una imagen de contenedor que usan muchos equipos. Cuando todos los equipos están esforzándose por entregar las funcionalidades de su propio equipo, el código compartido suele ser un área en la que nadie se hace cargo de estos problemas.

Tiempo

Por supuesto, incluso cuando la responsabilidad está clara, sigue siendo un desafío encontrar tiempo para incorporar estas tareas al flujo de trabajo. Aunque ya tengas la automatización para probar tu código, esa es solo la parte fácil. El verdadero trabajo consiste en que los desarrolladores revisen los resultados y corrijan los problemas. Cuanto más arrojen malos resultados las herramientas o menos claras y autónomas sean las medidas para corregirlos, más probable será que se abandonen. Del mismo modo, si la organización no prioriza las correcciones y actividades de seguridad, los desarrolladores se resistirán o ignorarán a los equipos de seguridad cuando les pidan que hagan pruebas o correcciones.

Rendición de cuentas

La rendición de cuentas es un pilar fundamental para que los desarrolladores hagan trabajo de seguridad, pero también importa ante quién deben rendir cuentas. Por ejemplo, es más probable que un desarrollador considere importante hacer ese trabajo si su equipo, un promotor de seguridad de su equipo o alguien de su línea jerárquica le exige que lo haga. En cambio, si solo el equipo de seguridad le exige que rinda cuentas, sin consecuencias claras, sentirá menos presión para trabajar de forma segura.

Falta de referentes

Las personas modelan su comportamiento según quienes las rodean. Si no vemos que otros desarrollen de forma segura ni que otros equipos prioricen la seguridad en sus proyectos, es fácil seguir la corriente e ignorar las tareas de seguridad. Hay varias buenas formas de contrarrestar esto, como dar visibilidad a la seguridad en las revisiones de código para que se planteen preguntas que inviten a reflexionar sobre el tema. ¡Otra opción es crear referentes!

Reconoce a las personas por las conductas que quieres que se repitan en la organización. Destaca los logros de los equipos y los avances que hayan hecho para integrar la seguridad en sus pipelines o reducir su acumulación de problemas de seguridad. Asegúrate de que los logros de seguridad sean visibles, que los celebren los líderes de ingeniería y que otros puedan replicarlos mediante documentación, automatización, etc.