El 79% de las bibliotecas de terceros en las aplicaciones nunca se actualizan



Falta de información contextual y preocupaciones sobre la interrupción de la aplicación entre los factores contribuyentes.

Los desarrolladores de software casi nunca actualizan las bibliotecas de terceros después de incluirlas en una foundation de código, aunque en la mayoría de los casos las bibliotecas se pueden actualizar con relativa facilidad sin interrumpir la funcionalidad de la aplicación, muestra un nuevo estudio.

Un resultado es un mayor riesgo para las organizaciones, así como una mayor complejidad cuando llega el momento de hacer una corrección, según Veracode, que recientemente analizó los resultados de 13 millones de escaneos de unos 86,0000 repositorios de clientes que contienen más de 301,000 bibliotecas de software program únicas. El proveedor de seguridad también encuestó a unos 2.000 desarrolladores para comprender su uso de software package de terceros.

Su análisis muestra que el 79% de las veces, los desarrolladores no actualizan las bibliotecas de terceros que utilizan en una foundation de código. Aunque las bibliotecas de terceros cambian constantemente, y lo que es seguro y lo que no es seguro sigue cambiando con la misma rapidez, los desarrolladores en general no las actualizan. Incluso en el caso de repositorios más maduros y mantenidos activamente, Veracode descubrió que las bibliotecas de terceros se agregan y nunca se actualizan el 73% del tiempo, en comparación con el 79% de todos los repositorios. En standard, el 50% de las bibliotecas tardan más de 21 meses en actualizarse, y el 25% no se actualiza hasta cuatro años, que era el plazo para la Estudio Veracode.

Curiosamente, cuando los desarrolladores actualizan bibliotecas de terceros, actúan sorprendentemente rápido. Por ejemplo, de las vulnerabilidades que se solucionan, el 17% se soluciona en una hora y el 25% en una semana.

Eso muestra que la falta de actualización de bibliotecas de terceros, o la lentitud crónica para hacerlo, no es el resultado de un problema de flujo de trabajo, dice Chris Eng, director de investigación de Veracode. Más a menudo es la falta de información contextual sobre cómo una biblioteca vulnerable podría afectar la aplicación, la preocupación por posibles interrupciones de la aplicación y problemas culturales.

Los desarrolladores que informan que necesitan más información contextual tardan más de siete meses, en promedio, solo para corregir el 50% de sus fallas conocidas, dice Eng. Por otro lado, los desarrolladores que sienten que tienen la información necesaria tardan solo tres semanas en corregir el 50% de las fallas. La falta de contexto podría ser algo tan straightforward como no comprender la gravedad o el impacto de una vulnerabilidad, dice Eng.

«Por ejemplo, si un desarrollador no comprende por qué la inyección de SQL es peligrosa, podría descartarla por no tener importancia», señala. «A veces, ilustrar la ruta del código que conecta el código de origen con la vulnerabilidad de terceros también puede ayudar al desarrollador a comprender cómo y por qué su aplicación es vulnerable».

Además, los desarrolladores a menudo temen que la actualización de una biblioteca para corregir una vulnerabilidad termine rompiendo algo más. Aunque el 69% de las vulnerabilidades en bibliotecas de terceros implican un parche menor que rara vez causaría roturas, los desarrolladores a menudo no son conscientes de este hecho.

Factores culturales
El liderazgo y la cultura también son factores.

“Los desarrolladores trabajan en lo que les dicen los gerentes de ingeniería y productos que deben trabajar”, ​​dice Eng. «El liderazgo debe crear la capacidad de dejar tiempo para trabajar en las vulnerabilidades y reducir la deuda de seguridad, al igual que el tiempo se reserva para trabajar en la escalabilidad, la resistencia, la calidad, and many others.»

De hecho, el análisis de Veracode muestra que, si bien los desarrolladores a menudo consideran la funcionalidad y las licencias como consideraciones importantes, a menudo no consideran que la seguridad sea de la misma importancia al agregar una nueva biblioteca. Más de dos tercios (67%) de los encuestados en el estudio de Veracode dijeron que siempre consideran la funcionalidad, y el 63% dijo que siempre miran las licencias cuando evalúan una nueva biblioteca.

Por el contrario, un porcentaje menor, el 52%, dijo lo mismo sobre la seguridad. Cuando los desarrolladores hicieron de la seguridad un criterio central para evaluar bibliotecas, Veracode descubrió que el porcentaje de repositorios con vulnerabilidades en bibliotecas de terceros period ligeramente menor (80,7%) en comparación con el 84,2% cuando los desarrolladores no siempre consideran la seguridad al evaluar bibliotecas de terceros. .

Numerosos estudios anteriores han demostrado que casi todas las aplicaciones empresariales modernas tienen código de fuente abierto y de terceros susceptible en diversos grados. Un estudio reciente de Sinopsis mostró que las aplicaciones empresariales en estos días tienen hasta 528 componentes de código abierto, en promedio. La compañía encontró un promedio de 158 vulnerabilidades por código foundation, muchas de ellas críticas.

Por lo tanto, las consecuencias pueden ser graves para las organizaciones cuando las bibliotecas de terceros en sus aplicaciones no se mantienen actualizadas. Por un lado, los riesgos de incumplimiento pueden aumentar. Otro problema es el aumento de la complejidad de los parches.

«Cuanto más esperemos para corregir una vulnerabilidad en una biblioteca de terceros, más complicado se vuelve solucionar, más tiempo lleva hacer el parche y mayor es el riesgo de romper algo que afecta a los usuarios», dice Eng.

Jai Vijayan es un reportero de tecnología experimentado con más de 20 años de experiencia en el periodismo comercial de TI. Más recientemente, fue editor senior en Computerworld, donde cubrió temas de seguridad de la información y privacidad de datos para la publicación. En el transcurso de sus 20 años … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia original