Malventy Software se infiltra en el ecosistema de desarrollo para el software libre a un ritmo alarmante, según un nuevo informe de Sonatype, que se especializa en la gestión de la cadena de suministro de software. La compañía ha identificado más de 500,000 nuevos paquetes maliciosos desde noviembre de 2023 en los registros Java, JavaScript, Python y .NET.

Los nuevos componentes representan más del 70% de unos 700,000 paquetes de malware seguidos por la compañía desde 2019, cuando comenzó a incluir estas estadísticas en su Informe anual En el estado de la cadena de suministro de software (estado de la cadena de suministro de software).

El 80% de los componentes vulnerables no se actualizan rápidamente

Esta ola de software malicioso se agrega a los desafíos preexistentes a los que se enfrentan las organizaciones con respecto a la calidad de los componentes de código abierto integrados en sus aplicaciones. Según los datos de Sonatype, cada aplicación comercial tiene un promedio de al menos 180 componentes de tercera parte, un volumen que es difícil de administrar.

En consecuencia, el editor descubrió que más del 80 % de las aplicaciones vulnerables debido a estas dependencias a los componentes del tercer partido no se corrigen durante más de un año, mientras que el 95 % de ellas podrían ser a través del despliegue de alternativas más seguras. Incluso cuando se aplican actualizaciones, en el 3.6 % de los casos, los componentes vulnerables se actualizan a otras versiones no garantizadas.

"La imposibilidad de ralentizar a DevOps"

Tome el ejemplo de log4j. La biblioteca de periodización de Java utilizada en millones de aplicaciones presentó una vulnerabilidad crítica llamada Log4Shell, descubierta en diciembre de 2021. Esta falla y otras que siguieron poco después fueron objeto de amplias publicidad, pero casi tres años después, el 13 % de las descargas Log4J del repertorio de Java Central Maven continúan con respecto a las versiones vulnerables.

"La gestión de riesgos vinculada al software libre requiere la optimización de las políticas y prácticas de seguridad para seguir el rápido desarrollo de las bibliotecas OSS", escribe Sonatype en su informe. "Las organizaciones se enfrentan a la imposibilidad de ralentizar los procesos DevOps para llevar a cabo exámenes de vulnerabilidad manual, lo que despertaría la frustración en los desarrolladores.» »

Del componente militante al phishing, incluido el robo de datos

Al igual que las amenazas dirigidas a las computadoras de oficina, los componentes maliciosos descargados en paquetes de código abierto pueden tener objetivos diferentes y no todos tienen el mismo impacto. Sonatype en clase casi la mitad en la categoría de "aplicaciones potencialmente indeseables" (PUA para 'aplicaciones potencialmente no deseadas'), que en su mayoría no son dañinas en la práctica, pero cuyas características no se divulgan al usuario final. Estos incluyen ProTetware, en el que el creador del componente incluye mensajes de protesta o acciones destinadas a llamar la atención sobre una causa cercana a su corazón. Además, el 12% de los componentes se informan como "paquetes de retención de seguridad", lo que significa que los gerentes del ecosistema los informaron como maliciosos en algún momento y los reemplazaron con un componente saludable, para atraer la atención de quienes los usan.

Las otras amenazas destacadas por Sonatype tienen consecuencias bastante graves que pueden comprometer la cadena de suministro de software. Alrededor del 14 % de los paquetes se distribuyen a través de técnicas de phishing, es decir que utilizan la confusión que prevalece en torno a las dependencias para fingir ser paquetes internos dentro de las organizaciones para depositar otro malware en los entornos de desarrollo.

Alrededor del 14 % de los paquetes maliciosos están diseñados para robar archivos confidenciales y datos en máquinas, como variables ambientales, tokens de autenticación, archivos de contraseña y otra información que podría ayudar a los atacantes a comprometer otros sistemas a partir de entonces. Un subconjunto del 3% de los componentes verolados también se dirige a la información personal identificable, mientras que un 3% adicional de las amenazas despliegan puertas robadas y caballos troyanos en las máquinas.

Infiltrarse en un proyecto de código abierto para configurar una puerta trasera

Otros tipos de acciones maliciosas, coticemos el depósito de programas de minería de criptomonedas (1.2 %), corrupción de sistemas de archivos o el compromiso de los entornos de desarrollo utilizados por los desarrolladores.

Entre los incidentes recientes vinculados a estos paquetes no deseados, podemos citar a un desarrollador que descargó alrededor de 14,000 paquetes falsos en NPM para beneficiarse de un sistema de criptomonedas que recompensó las contribuciones al código abierto. O atacantes que usan un tipo de tipográfico para empujar un paquete de Python con un nombre muy similar a una biblioteca popular que implementa el malware de Windows Lumma (un infoporte). Sin olvidar el Zx utiliza puerta pisadaUn ejemplo de un ataque por la infiltración actual durante varios años durante el cual un desarrollador deshonesto ha apuntado a un proyecto de desarrollo con la intención de envenenar el código.

Cierta información sobre vulnerabilidades no es confiable

Sonatype estima que cada aplicación comercial hereda un promedio de 13 vulnerabilidades críticas o graves cada año, de sus dependencias. Esto subraya, para el editor, la necesidad de tener herramientas automatizadas capaces de seguir todas las dependencias directas e indirectas, dependencias, así como las vulnerabilidades que se descubren allí.

Problema, las fuentes de información sobre vulnerabilidades no son de calidad homogénea. Por ejemplo, la base de datos NVD (base de datos de vulnerabilidad nacional) tiene una acumulación de más de 17,000 vulnerabilidades que aún no han sido tratadas. Sonatype señaló, en la práctica, que más de dos tercios de las vulnerabilidades inicialmente clasificadas con un puntaje de gravedad CVSS inferior a 7 (un nivel de gravedad promedio) se corrigieron en más de 7 (altos o críticos) cuando un investigador de seguridad fue más detallado.

En consecuencia, según la fuente de información sobre las vulnerabilidades que utilizan, las empresas pueden perder por completo las vulnerabilidades o posponer su remediación, pensando que son menos críticos de lo que son en realidad. Y si la puntuación de una vulnerabilidad cambia después de la evaluación de una aplicación por el RSSI, es difícil saber cuánto tiempo fluirá antes de que se analice nuevamente.

La utilidad de la sbom ... y sus límites

"Es posible reducir los riesgos persistentes al centrarse en las herramientas que ayudan a gestionar las dependencias y llevar a cabo la detección de vulnerabilidades en tiempo real", escriben los investigadores. "De hecho, encontramos que los proyectos que utilizan un inventario de software (SBOM, para la factura de software de materiales) para administrar las dependencias de código abierto permitieron reducir el tiempo necesario para los problemas de resolución en comparación con aquellos que no lo usaron".

El aumento en los estándares de SBOM y las regulaciones que los alientan han impulsado fuertemente un número creciente de desarrolladores de software libre para que los adopten. Desafortunadamente, la tasa de adopción no sigue el ritmo de los nuevos componentes publicados. Se han publicado casi 7 millones de nuevos componentes de código abierto en los últimos 12 meses, solo 61,000 han tenido SBOM.