InformesInfraestructuras

El 83% de software aún tiene fallos en el primer escaneo

El décimo informe sobre el Estado de la Seguridad del Software de Veracode marca una década de conocimiento sobre la seguridad de apps y muestra a los equipos avanzando hacia un desarrollo seguro.

Veracode ha anunciado hoy los resultados de su informe sobre el Estado de Seguridad del Software (SoSS). La décima entrega de esta investigación revela que más de la mitad de todos los fallos de seguridad (56%) están solucionados, pero remediar los nuevos errores conduce a una mayor “deuda en seguridad”, ya que se acumulan los no resueltos y se unen a la lista de fallos sin resolver.  

Después de analizar más de 85.000 aplicaciones en más de 2.300 compañías en todo el mundo, la investigación indica que corregir las vulnerabilidades se ha convertido en una parte igual de importante del proceso de desarrollo como lo es mejorar la funcionalidad, lo que sugiere que los desarrolladores están cambiando su mentalidad para ver la seguridad de su código de la misma manera que otras métricas de valor.

"En los últimos 10 años, hemos visto una gran mejora en el estado general de la seguridad de las aplicaciones (AppSec). Hemos pasado de tener que discutir por qué dicha seguridad es importante, a tener conversaciones sobre la mejor manera de abordar el problema. Este cambio se refleja en los datos que muestran que las empresas están solucionando un mayor porcentaje de fallos que nunca”, indica Chris Wysopal, cofundador y CTO de Veracode. “Sin embargo, el informe también nos revela que hay mucho margen de mejora, específicamente cuando se trata del tema del aumento de la deuda de seguridad. Al igual que las deudas en las tarjetas de crédito, haciendo pequeños gastos de forma recurrente se puede acumular una gran deuda”.

La décima edición del informe de Veracode muestra las mejores prácticas que las organizaciones deben tener en cuenta para lograr que la seguridad sea algo habitual y alivie la deuda de seguridad, incluyendo las pruebas o testeos frecuentes y un plan específico.

Si bien mucho ha cambiado desde que se publicó el primer informe de Veracode hace casi 10 años, esta entrega revela que la mayoría de los fallos que vimos en el pasado siguen estando presentes hoy en día. En general, el 83% de las aplicaciones tienen al menos un error en el escaneo inicial, y la filtración de información (64%), problemas criptográficos (62%) e inyección de CRLF (61%) son los problemas más comunes. Curiosamente, los errores criptográficos y la fuga de información también fueron los dos fallos más repetidos en el SOSS Volumen 1. A pesar de la prevalencia continua de vulnerabilidades, los equipos de desarrollo están avanzando para mantenerse al día con ellas: el 70% está reduciendo el número de errores después del primer escaneo o están logrando no introducir ningún otro al momento del escaneo final. La tasa de aprobación para el cumplimiento de OWASP Top 10 en el análisis inicial de este año también revirtió una disminución de tres años al aumentar al 32%, lo que demuestra que la educación en seguridad del software está ayudando a reducir las vulnerabilidades.

Los desarrolladores están en la carrera para solucionar más rápido la deuda de seguridad

El informe SoSS de Veracode también revela que mientras más tiempo se mantengan activas las vulnerabilidades, las posibilidades de que se corrijan disminuyen, lo que se suma a la deuda de seguridad de una organización. Dicha deuda se está convirtiendo en un aspecto importante para las organizaciones de todas las industrias. Aproximadamente la mitad de las aplicaciones acumulan deudas con el tiempo, una cuarta parte las está reduciendo y otra cuarta parte está llegando al punto de equilibrio.

“La prevalencia general de las vulnerabilidades aumentó un 11% desde que lo reportamos por primera vez hace 10 años, pero la proporción de las que se han evaluado como de alta gravedad cayó un 14% durante el mismo período. Los datos muestran que es muy probable que los desarrolladores sean quienes se den cuenta y corrijan los fallos de esta categoría, por lo que existe una evidencia sólida de que los equipos de desarrollo están mejorando para determinar qué fallos son los más importantes para solucionarlos primero”, explica Chris Eng, CRO de Veracode.

Las organizaciones deben abordar los nuevos fallos mientras eliminan los viejos. Los datos que recoge el informe de Veracode indican que la frecuencia con la que se escanea una aplicación tiene un impacto directo a la deuda de seguridad en general. El 1% de las aplicaciones con la frecuencia de escaneo más alta desencadena aproximadamente cinco veces menos deudas de seguridad, lo que sugiere que una exploración frecuente va más allá del hecho de encontrar los fallos; también ayuda a las empresas a reducir significativamente el riesgo.

DevSecOps proporciona un gran aumento en las tasas de reparación

La frecuencia y la cadencia de las pruebas de seguridad están vinculadas a los cambios de hábitos, con la finalidad de reducir la deuda de seguridad. Las aplicaciones escaneadas menos de una vez al mes requieren un tiempo medio de solución de 68 días, pero los equipos de desarrollo que hacen el escáner diario solo tardan 19 días, lo que contribuye a reducir la acumulación de la deuda de seguridad a través del tiempo. Las organizaciones también pueden reducir dicha deuda creando listas de verificación de seguridad para desarrolladores para todas las nuevas funciones, y escaneando bases de código después de cada compilación nocturna.

"Los equipos de desarrollo no pueden ignorar los fallos ni elegir reparar los nuevos en lugar de los antiguos. En su lugar, deberían hacer un plan para arreglar los errores más actuales y usar "sprints de seguridad" periódicos para corregir fallos no resueltos que podrían ser atacados", añade el CRO de Veracode.

Los datos revelan que el 30% de las aplicaciones muestran un mayor número de fallos en su último análisis, un indicador de que se está acumulando la deuda de seguridad. Esto no implica necesariamente que esos equipos de desarrollo estén haciendo un mal trabajo a la hora de manejar los fallos – el periodo de tiempo analizado podría estar asociado a un tiempo de rápido crecimiento y cambio, por ejemplo –, si bien destaca que las organizaciones deberían pensar en la frecuencia con la que las pruebas de AppSec en los entornos DevOps pueden tener un impacto positivo en la deuda de seguridad.

EMEA se retrasa a la hora de corregir fallos, pero mantiene bajo control la deuda de seguridad

El informe de Veracode también muestra diferencias por regiones en varias medidas clave de las pruebas de seguridad del software. Las empresas en EMEA tuvieron la menor cantidad de fallos graves (32%), seguido de América (norte y sur) (37%) y Asia-Pacífico (40%). Ambos continentes americanos y EMEA fueron capaces de arreglar sus vulnerabilidades al mismo ritmo (73 y 72%, respectivamente), mientras que Asia-Pacífico (APAC) reparó un poco más de la mitad (55%). En el pasado, las discrepancias entre las regiones de América y EMEA eran mucho mayores. Las tasas de fijación similares en la región sugieren que las organizaciones en EMEA están madurando sus programas AppSec para competir con los de América. Sin embargo, cuando se trata del tiempo medio para remediar los problemas, los resultados son muy diferentes. APAC se adelanta a los 42 días, seguido de América a los 56 días, mientras que las empresas en EMEA siguen a 147 días de tiempo medio para poner solución a las vulnerabilidades.

En cuanto a la deuda de seguridad por aplicación, las organizaciones en América destacan por tener la menor cantidad de fallos por aplicación (156), mientras que EMEA tiene 210 errores y APAC 732. Si bien las organizaciones en EMEA generalmente parecen tomarse más tiempo para corregir los problemas, aún logran mantener la deuda bajo control, lo que probablemente se remonta al punto de partida más bajo para la prevalencia de fallos. Esto nuevamente indica que tienen puesto el foco en la reparación y en la seguridad del software a lo largo del tiempo (durante toda la cadena de valor de la app, incluyendo el desarrollo), en lugar de solo arreglarlo cuando salen a la luz o se encuentran los fallos.

Computing 786