El equilibrio perfecto: seis claves para superar las tensiones entre los equipos de seguridad y desarrollo de aplicaciones

Siempre habrá una tensión natural entre los equipos de ciberseguridad y los desarrolladores. Después de todo, la función de los desarrolladores es «desarrollar». Quieren crear y lanzar nuevas aplicaciones y funciones que ayuden a impulsar la organización, y reciben un pago por hacerlo. En cambio, la función del equipo de seguridad es asegurarse de que no ocurran problemas cuando se implementa software nuevo, como sufrir una filtración de datos o perder la disponibilidad de los servicios empresariales debido a software vulnerable.

Aunque esta dinámica genera una tensión natural entre ambas funciones, mi experiencia me ha enseñado que no tiene por qué ser así. Siempre que se tomen las medidas adecuadas para mejorar el entendimiento entre los dos grupos.

Por desgracia, muchas organizaciones no toman las medidas adecuadas. Esto hace que el equipo de desarrollo vea a los equipos de seguridad como un «obstáculo» que debe superar. Del mismo modo, la animosidad del equipo de seguridad hacia los equipos de desarrollo aumenta cuando consideran que los desarrolladores «no se toman la seguridad lo suficientemente en serio».

Se ha escrito mucho sobre cómo mejorar la relación entre los desarrolladores y los equipos de seguridad. Además, en la última década se expandieron rápidamente las prácticas de DevOps, cuyo objetivo es aliviar esta tensión. Se han logrado algunos avances, pero, en mi opinión, no son suficientes. Por eso decidí compartir lo que aprendí al dirigir el equipo de seguridad de aplicaciones de una gran empresa de telecomunicaciones, donde logramos cierto éxito al equilibrar las tensiones entre desarrollo y seguridad.

Todas las organizaciones son diferentes. Algunos equipos de desarrollo y seguridad trabajan principalmente en las oficinas, mientras que otros trabajan en su mayoría de forma remota, y otros combinan ambas modalidades. Algunos equipos cuentan con expertos en seguridad de aplicaciones con mucha experiencia, y otros no. El equipo en el que trabajé iba principalmente a la oficina. Y lo que nos funcionó quizá no les sirva a todos. Aun así, creo que quienes pongan en práctica estas claves mejorarán la relación fundamental entre sus equipos de seguridad y desarrollo.

Clave número uno: prioriza la capacitación.

Las organizaciones deberían ofrecer capacitación en seguridad de aplicaciones a los nuevos desarrolladores, a cargo del equipo de AppSec y de alguien con suficiente experiencia en desarrollo como para ganarse su respeto. Los expertos de AppSec con experiencia en desarrollo entienden los problemas y las frustraciones que enfrentan los desarrolladores cuando los equipos de seguridad se comunican de forma poco adecuada.

Esto también se aplica, en general, al equipo de AppSec. Si el equipo de AppSec está integrado únicamente por personas de seguridad que nunca han trabajado en desarrollo, es probable que surjan roces entre ambos grupos porque casi siempre hablarán «idiomas» diferentes. Ninguno de los grupos entenderá los problemas y desafíos que enfrenta el otro. Si el equipo de AppSec incluye a personas que antes trabajaron como desarrolladores, la relación entre los equipos será muy distinta.

Clave número dos: en la capacitación de AppSec, usa ejemplos reales que los equipos de desarrollo y seguridad hayan encontrado internamente.

En todas las capacitaciones de AppSec, quienes las imparten explicarán cómo se introducen vulnerabilidades en el código, como las fallas de inyección, el cross-site scripting (XSS) y los controles de acceso deficientes. También describirán lo que estas vulnerabilidades implican para la seguridad de las aplicaciones y los datos. Aunque la presentación puede ser precisa, también resulta muy aburrida.

Para hacerla más interesante y captar la atención, nos funcionó agregar vulnerabilidades de aplicaciones que el equipo de seguridad había encontrado durante sus revisiones internas. El objetivo no es que la capacitación de AppSec sea algo personal. No se debe señalar a desarrolladores en particular.

Se trata de aprender sobre estos problemas en equipo. Se trata de mostrar que los desarrolladores se enfocan en la lógica empresarial y el funcionamiento de la aplicación que están creando, no en la seguridad. A veces, la seguridad queda en segundo plano, y es comprensible. Pero captarás su atención e interés si incluyes algunos ejemplos de vulnerabilidades comunes encontradas internamente que afectan la seguridad de la organización.

Clave número tres: elimina el estigma de descubrir vulnerabilidades.

Al inicio de nuestra presentación, mostramos una diapositiva que ayudó a eliminar el estigma de tener vulnerabilidades de seguridad en el código. No revelaré el nombre de la persona mencionada, pero la diapositiva hablaba de un profesional de seguridad muy conocido. Desarrolla software de seguridad que se publica como código abierto. Una vulnerabilidad en uno de sus programas, también publicado como código abierto, resultó ser muy grave.

Si esta persona puede publicar software con vulnerabilidades graves, cualquier desarrollador puede cometer los mismos errores. Mostramos esa diapositiva para dejar claro que tener fallas de seguridad en el código es normal, incluso para alguien con mucha experiencia en seguridad de aplicaciones. Lo importante es encontrarlas y corregirlas.

Clave número cuatro: enseña el impacto real de las vulnerabilidades.

No solo presentamos las vulnerabilidades que encontramos internamente. También las explotamos. Debemos mostrarles a los desarrolladores cómo se puede explotar una vulnerabilidad y qué puede hacer un atacante con ella.

En una de las primeras sesiones de capacitación, un desarrollador comentó sobre XSS y afirmó que esas vulnerabilidades no podían ser tan dañinas. Le mostramos lo que un atacante podía hacer con un ataque XSS, como suplantar a una víctima, acceder a datos confidenciales, secuestrar sesiones, registrar pulsaciones de teclas, propagar malware y mucho más.

Fue muy revelador. De hecho, creo que este es un problema de AppSec. Cuando los desarrolladores no entienden el impacto de las vulnerabilidades, no tienen motivación para corregirlas ni para evitar que aparezcan en sus aplicaciones. Es parte de la naturaleza humana ignorar los riesgos cuando no se entiende su impacto. Por eso, demostrar el riesgo real puede tener un efecto tan grande. Incluir esto en nuestra capacitación nos ayudó a mejorar drásticamente la relación con los desarrolladores.

Clave número cinco: los equipos de seguridad deben entender qué es razonable.

He observado que los roces entre estos dos equipos suelen deberse a que el equipo de seguridad pide completar tareas poco razonables. Durante la capacitación, es fundamental enseñar al equipo de desarrollo cómo trabajar mejor con el equipo de seguridad, sin duda. Pero es igual de importante que el equipo de seguridad se asegure de que sus solicitudes sean razonables.

A veces, las solicitudes no son razonables porque el equipo de seguridad pide corregir problemas que en realidad no existen. Esto ocurre cuando ejecutan un escáner de vulnerabilidades de aplicaciones y este reporta una vulnerabilidad inexistente o que no representa un riesgo real. El equipo de seguridad transmite el reporte a los desarrolladores para que lo corrijan, sin revisarlo. Si lo hacen con frecuencia, los desarrolladores se frustrarán y te ignorarán.

Además, los equipos de seguridad deben tener expectativas razonables, por ejemplo, dar el tiempo adecuado para abordar las vulnerabilidades y más tiempo para corregir las que sean complejas.

Clave número seis: usa herramientas precisas que empoderen a los desarrolladores.

Elegir herramientas de evaluación precisas es fundamental, porque ofrecen explicaciones claras de los problemas detectados, asignan niveles de gravedad adecuados y brindan orientación para corregir las vulnerabilidades. Esto ayuda a los desarrolladores a entender cómo abordar los problemas en cuestión. Es aún mejor ofrecer herramientas diseñadas para que las usen los desarrolladores, ya que así podrán trabajar de forma independiente.

Aunque siempre habrá cierto grado de tensión entre los equipos de seguridad y desarrollo, y las organizaciones tendrán que esforzarse continuamente para reducirla, descubrimos que tomar algunas medidas sencillas para mejorar el entendimiento y la empatía entre estos equipos contribuye mucho a mejorar sus relaciones.

Alinea a los desarrolladores y los equipos de seguridad para lograr mejores resultados con Snyk AI Trust Platform

Las seis claves descritas arriba son principios fundamentales para cerrar la brecha entre los equipos de desarrollo y seguridad. No son solo teorías, sino medidas prácticas que fomentan la empatía, generan un entendimiento compartido y construyen respeto mutuo. Sin embargo, los principios por sí solos no bastan. Deben contar con el respaldo de herramientas que permitan llevar esta forma de trabajar a la práctica.

Cuando las herramientas están diseñadas para los desarrolladores, desaparece la división tradicional entre desarrollar rápido y desarrollar de forma segura. La seguridad deja de ser un guardián y se convierte en un socio de confianza para la innovación. Snyk AI Trust Platform ofrece ese terreno común y permite que ambos equipos hablen el mismo idioma y trabajen por un mismo objetivo: entregar software seguro y de alta calidad, más rápido.

Snyk AI Trust Platform está diseñada para integrar la seguridad de forma fluida en el SDLC y abordar directamente las causas fundamentales de los roces. La plataforma empodera a los desarrolladores al ofrecerles inteligencia de seguridad rápida, precisa y práctica justo donde trabajan: en su IDE, repositorio y pipeline de CI/CD.

¿Listo para crear una verdadera colaboración entre tus equipos de desarrollo y seguridad? Reserva una demostración en vivo y descubre cómo puedes empoderar a tus equipos para integrar la seguridad desde el principio.