Los parches implementados para vulnerabilidades de dependencia causan fallas el 75% de las veces, según reveló un nuevo informe. Se descubrió que las actualizaciones menores dañaban a los clientes el 94 % de las veces, y en el caso de las actualizaciones de versión, esto era el 95 %.
Las dependencias de software (el código externo o las bibliotecas que un proyecto requiere para funcionar correctamente) son muy difíciles de gestionar durante el desarrollo de aplicaciones. Remediar las vulnerabilidades en las dependencias requiere una actualización importante de la versión el 24% de las veces.
“Aparentemente, la solución más sencilla es actualizar a una versión no vulnerable de la dependencia”, dijeron los autores del nuevo Informe de gestión de dependencias 2024 de la empresa de seguridad de la cadena de suministro de software Endor Labs.
“Sin embargo, lo que parece fácil en principio: después de todo, sólo hay que actualizar el identificador de la versión a uno que no sea vulnerable, ¿verdad? – puede causar problemas de compatibilidad y regresiones que interrumpen una aplicación durante el desarrollo”.
Los investigadores de Endor Labs analizaron datos de vulnerabilidad de fuentes internas y externas para medir las tendencias en la gestión de la dependencia del software para el informe.
VER: Los ataques a la seguridad de la cadena de suministro de software aumentan un 200%: nueva investigación de Sonatype
Las vulnerabilidades de dependencia no se informan ni se reparan con la suficiente rapidez
El informe también encontró que existen varios problemas inherentes al informar y parchear las vulnerabilidades de dependencia, ya que el 69% de los avisos se publican en CVE, blogs, GitHub y plataformas similares después de que se ha lanzado un parche. El retraso medio entre la disponibilidad del parche público y la publicación de un aviso es de 25 días.
Estos factores amplían significativamente la ventana de oportunidad para que los atacantes exploten sistemas vulnerables a través de dependencias de software.
Las bibliotecas de IA están dificultando la gestión de vulnerabilidades
A pesar de facilitar la programación, las cada vez más populares bibliotecas de inteligencia artificial están exacerbando los problemas existentes de gestión de vulnerabilidades de dependencia. Más específicamente, los informes de vulnerabilidades en las bibliotecas de IA son inconsistentes, con cifras que varían hasta en un 10% entre las bases de datos de asesoramiento público, según el informe.
Según los autores del informe, las dependencias fantasma (bibliotecas ocultas y no declaradas en el código de una aplicación) también son más comunes en proyectos de software de IA y ML. Los proyectos de IA tienden a escribirse en Python, un lenguaje conocido por sus dependencias fantasmas porque permite instalaciones de paquetes dinámicas o indirectas que omiten los archivos de manifiesto.
Las dependencias fantasma solo formaron una parte significativa de la huella de dependencia para el 27% de las empresas cuyos datos se analizaron para este informe. Pero dentro de ese grupo, más del 56% informó que las vulnerabilidades de la biblioteca estaban en sus dependencias fantasmas.
Los profesionales de la seguridad se ven abrumados con alertas de vulnerabilidad irrelevantes
Según el informe, una cuarta parte de los avisos contienen datos incorrectos o incompletos, lo que puede dar lugar a falsos positivos y falsos negativos.
Casi la mitad de los que se encuentran en bases de datos públicas de vulnerabilidades en seis ecosistemas comunes de código abierto tampoco contienen ninguna información de vulnerabilidad a nivel de código, como los nombres de las funciones afectadas o las confirmaciones de correcciones. De hecho, sólo el 2% contiene alguna información sobre las funciones afectadas.
Identificar conexiones entre aplicaciones y vulnerabilidades dentro de sus dependencias es un desafío técnico. Sin embargo, esta información es esencial para que los profesionales de la seguridad sepan si las vulnerabilidades representan un riesgo para sus aplicaciones.
Sin él, no pueden filtrar rápidamente vulnerabilidades irrelevantes, como muchas de ellas lo son. El equipo de Endor Labs descubrió que más del 90,5% de las vulnerabilidades de dependencia de código abierto en Java, Python, Rust, Go, C#, .NET, Kotlin y Scala no son realmente explotables a nivel de función, es decir, no tienen al menos una ruta de llamada desde la aplicación a la función vulnerable en esa biblioteca.
VER: El código fuente abierto para aplicaciones de software comerciales es omnipresente, pero también lo es el riesgo
Darren Meyer, ingeniero de investigación de Endor Labs, dijo que las organizaciones se están “ahogando en alertas de vulnerabilidad, muchas de las cuales no representan un riesgo relevante”.
“Investigar las alertas es costoso para los equipos de seguridad (y de software), y tratar de arreglarlo todo es aún más costoso”, añadió.
Los beneficios de actualizar los 20 componentes principales de Python
La actualización de dependencias a versiones no vulnerables tiene un impacto notable en la cantidad de vulnerabilidades relevantes. Por ejemplo, la actualización de los 20 componentes principales de Python elimina más del 75 % de todos los hallazgos de vulnerabilidad, incluido el 60 % para Java y el 44 % para npm.
Además, filtrar las vulnerabilidades de dependencia a las que no se puede acceder (no se puede acceder a ellas ni explotarlas) y que tienen una puntuación EPSS inferior al 1% puede reducir significativamente el número que los profesionales de seguridad deben monitorear. Combinarlos con filtros para vulnerabilidades que no tienen una solución disponible y no están presentes en el código de prueba deja solo el 4% de las vulnerabilidades de Java y JavaScript y menos del 1% de las vulnerabilidades de Python, lo que reduce drásticamente los costos de remediación.
Los autores del informe escribieron: “Cuando se combina con datos de análisis de accesibilidad a nivel de función y otras estrategias de alcance basadas en el contexto, la priorización de EPSS a menudo es tan efectiva que se requieren estrategias adicionales de priorización de mayor esfuerzo (como realizar ejercicios de puntuación de CVSS ambientales y temporales para determinar la gravedad). en su entorno) a menudo son innecesarios.
“Esto ahorra costos de análisis de vulnerabilidades para su organización”.
