Según Endor Labs, casi todas las actualizaciones de versiones (95 %) de software de código abierto contienen al menos un cambio importante que hace que otros componentes fallen, y los parches tienen un 75 % de posibilidades de causar una falla. El proveedor de seguridad reveló los hallazgos en su tercer Informe de gestión de dependencias anual, que se basa en datos de vulnerabilidades y clientes de Endor Labs, información en la base de datos de vulnerabilidades de código abierto (OSV) y archivos Java (JAR) relacionados con las 15 principales dependencias de código abierto. El desafío de los cambios importantes se ve agravado por el hecho de que una cuarta parte (24 %) de los componentes vulnerables requieren una actualización de versión importante, según los hallazgos. Sin embargo, existen formas de mitigar estos desafíos. «Los gráficos de llamadas de todo el programa y el análisis de jerarquías de tipos pueden aclarar si los cambios importantes de las actualizaciones de bibliotecas realmente importan en un contexto de aplicación específico», señaló el informe. Documentación de retrasos Endor Labs también identificó otro desafío importante para los usuarios finales de software de código abierto con errores: los retrasos en la publicación de información vital sobre vulnerabilidades. “El primer retraso potencial ocurre entre la corrección de una vulnerabilidad en el repositorio de código fuente de un proyecto y la publicación de una versión de seguridad correspondiente en un repositorio público como Maven o npm, lo que facilita el consumo de la corrección por parte de los usuarios posteriores”, explicó el informe. “Este retraso es importante, porque los atacantes pueden detectar las confirmaciones de corrección y, por lo tanto, conocer los detalles técnicos de la vulnerabilidad y cómo explotarla, mientras que los usuarios no tienen una forma sencilla de aplicar parches a sus sistemas”. Endor Labs agregó que el 69% de los avisos de seguridad se publican después de la versión de seguridad correspondiente, con un retraso medio de 25 días. Ya sea que esos avisos vengan en forma de publicaciones de blog, CVE o GitHub Security Advisories (GHSA), contienen información vital sobre la presencia de vulnerabilidades y la disponibilidad de versiones de seguridad. Por lo tanto, un retraso en su publicación proporciona a los actores de amenazas otra ventana de oportunidad para explotar los sistemas vulnerables, advirtió Endor Labs. El informe agregó que pueden producirse más retrasos si las herramientas de análisis de composición de software (SCA) vitales para el proceso de remediación tienen fuentes de información tardías o imprecisas. La Base de Datos Nacional de Vulnerabilidades (NVD, por sus siglas en inglés) está sufriendo retrasos bien documentados en el procesamiento de CVE, por ejemplo. El informe señaló que, en seis ecosistemas de código abierto estudiados, casi la mitad (47%) de los avisos en las bases de datos de vulnerabilidades públicas no contenían ninguna información de vulnerabilidad a nivel de código, el 51% contenía una o más referencias para corregir confirmaciones y solo el 2% contiene información sobre las funciones afectadas. Reducción del ruido Sin este tipo de información, es efectivamente imposible establecer si las funciones vulnerables conocidas se pueden ejecutar en el contexto de una aplicación posterior, advirtió. Todo lo cual hace que la priorización de vulnerabilidades para parches sea cada vez más difícil, aunque es vital para reducir costos y mejorar la resiliencia. Endor labs afirmó que menos del 9,5% de las vulnerabilidades son explotables a nivel de función. Argumentó que una técnica de escaneo de código conocida como «análisis de accesibilidad a nivel de función», que determina si una vulnerabilidad se puede explotar en una aplicación, es la técnica de priorización más importante. En segundo lugar, se encuentra el sistema de puntuación de predicción de exploits (EPSS) basado en datos, afirmó, y señaló que los programas que combinan esto con el análisis de accesibilidad experimentan una “reducción de ruido” de hasta el 98%. Lea más sobre las vulnerabilidades de código abierto: La mayoría del código comercial contiene errores de código abierto de alto riesgo