Los desarrolladores solucionan solo el 32% de las vulnerabilidades y el 42% de ellos insertan regularmente código vulnerable, revela un informe de Tromzo. Esto se debe al alto volumen de alertas de falsos positivos y a que no saben cuál necesita corregirse. Lo que podría ayudar en este proceso es la capacitación y experiencia en seguridad.

Además, la reducción del ruido permitiría a los desarrolladores abordar los problemas de seguridad con mayor precisión.

El informe se basó en una encuesta de más de 400 desarrolladores con sede en los EE.UU. que trabajan en organizaciones donde actualmente tienen implementadas herramientas de CI/CD.

"Estos hallazgos muestran que los desarrolladores ignoran regularmente los problemas de seguridad, pero ¿realmente podemos culparlos?" dijo Tromzo CTO Harshit Chiitalia. "Los equipos de seguridad los bombardean con un sinfín de problemas que deben abordarse y no tienen forma de separar lo que es realmente crítico de todo el ruido, todo mientras se espera que lancen software con más frecuencia y más rápido que nunca".

"Si queremos que los desarrolladores realmente implementen la seguridad, debemos facilitarles la tarea. Esto significa integrar controles de seguridad contextuales y automatizados en el SDLC para que podamos pasar de las puertas de seguridad a las barandas de seguridad".

Los desarrolladores y el código vulnerable

El 42% de los desarrolladores insertan código vulnerable una vez al mes. Cuando un desarrollador publica a sabiendas un código que cree que es vulnerable, está claro que piensa que no es su responsabilidad arreglar el código antes de que se envíe o de que otras presiones organizacionales resten prioridad a la seguridad.

Los desarrolladores corrigen solo el 32% de las vulnerabilidades conocidas. Dado el volumen de alertas de falsos positivos con las que se enfrentan los equipos hoy en día, corregir ese porcentaje de las vulnerabilidades podría producir un resultado aceptable si los desarrolladores pudieran determinar qué 32% corregir. Desafortunadamente, sin capacitación y experiencia en seguridad, no se debe esperar que los desarrolladores tomen esa determinación con precisión.

Un tercio de las vulnerabilidades son ruido. Para reducir las vulnerabilidades de falsos positivos, los escaneos deben tener acceso a toda la información de activos requerida para que las herramientas de seguridad puedan determinar con precisión si realmente existe una vulnerabilidad. La reducción del ruido de seguridad permitirá a los desarrolladores abordar los problemas de seguridad con confianza.

El 23% cree que los desarrolladores y seguridad están aislados. Cuando los desarrolladores y los equipos de seguridad operan en silos aislados, se generan ineficiencias y brechas en la seguridad a lo largo del ciclo de vida del desarrollo de software. Estos silos finalmente conducen a vulnerabilidades de seguridad y malas experiencias de usuario.

El 62% de los desarrolladores utilizan 11 o más herramientas de seguridad de aplicaciones. Hay decenas de herramientas de escaneo de códigos y pruebas de seguridad en el mercado hoy en día. Muchos tienen un propósito único o identifican mejor un tipo de vulnerabilidad de seguridad que otros. Algunos son más generalizados pero ofrecen facilidad de uso o escalabilidad. Sin embargo, el uso de demasiadas herramientas conlleva su propio conjunto de desafíos. La mayoría de los encuestados (62%) indicó que usa once o más herramientas de seguridad de aplicaciones, y el 17% usa veinte o más herramientas.

Unas pocas herramientas que analizan una gran cantidad de datos es el método preferido para obtener señales de seguridad de alto valor. Desafortunadamente, demasiadas empresas han recurrido a acumular más herramientas para burlar a sus adversarios cibernéticos. Existen herramientas de prueba de seguridad y productos de protección de aplicaciones: herramientas para pruebas estáticas, dinámicas, interactivas y móviles. El resultado para los desarrolladores puede ser un tsunami de señales de seguridad que pueden ocultar vulnerabilidades críticas.

El 80% se sorprendería si vieran a su empresa en las noticias por una brecha de seguridad. Un desarrollador que se sorprende cuando su aplicación se ve comprometida es a la vez un poco ingenuo y tiene la confianza adecuada en la calidad de su trabajo. Es un poco ingenuo creer que los esfuerzos aislados de incluso el mejor desarrollador son suficientes para producir una aplicación impenetrable y, sin embargo, confían en que han hecho todo de la manera más segura posible. Como líder de un equipo de desarrollo, esperaría que ese número sea de al menos el 80%, e incluso más alto sería mejor. Como administrador de riesgos, sabrá que cuando se convierte en el objetivo de un adversario cibernético avanzado, hay pocas posibilidades de que su código se sostenga.

Los equipos de desarrollo deben incorporar prácticas de codificación seguras en todas las etapas del ciclo de vida del proceso de desarrollo de aplicaciones. Garantizar el desarrollo de una aplicación segura es una responsabilidad que excede la capacidad de cualquier miembro del equipo. Todo el equipo debe centrarse en los riesgos de seguridad e integrar prácticas de codificación seguras en sus operaciones diarias.

Casi el 20% cree que más del 75% de las alertas son falsas. Estos resultados son una severa condena de las herramientas de seguridad comúnmente utilizadas en los negocios hoy en día. Las herramientas de seguridad modernas brindan la capacidad de suprimir o reclasificar alertas para reducir la tasa de falsos positivos, pero tomar estas medidas puede enmascarar vulnerabilidades críticas y crear una falsa sensación de seguridad.

El equipo de AppSec siempre será el experto en tomar decisiones basadas en riesgos. Su capacitación y experiencia califican a los profesionales de la seguridad para tomar determinaciones críticas y evaluaciones de riesgos. Si bien pueden impulsar la responsabilidad de la seguridad en los equipos de desarrollo y ser invaluables para resolver desafíos de seguridad complejos y capacitar a los especialistas en desarrollo, toda la organización se beneficiará al cambiar las tareas diarias de prueba y escaneo de seguridad del equipo de seguridad a los desarrolladores responsables de crear aplicaciones.

Fuente: Tromzo