La mayoría de las empresas de la cadena de suministro creen que no utilizan bibliotecas de software de código abierto con vulnerabilidades conocidas. Sin embargo, una nueva investigación las encuentra en el 68% de las aplicaciones empresariales seleccionadas.
La cantidad de ataques documentados a la cadena de suministro que involucran componentes maliciosos de terceros han crecido un 633% durante el último año, alcanzando las 88.000 instancias conocidas.
Así se desprende de un nuevo informe de la empresa de gestión de la cadena de suministro de software, Sonatype. En él también se pone de manifiesto que los casos de vulnerabilidades que los componentes de software heredan de sus propias dependencias también han alcanzado niveles sin precedentes y afectan a dos terceras partes de las bibliotecas de código abierto.
Asimismo, se apunta la importancia de cómo afectan al software, por lo que comprender sus orígenes es clave para dar una respuesta a esa vulnerabilidad. La falta de visibilidad ha llevado en muchos casos a que la respuesta a incidentes se haya prolongado más de lo deseado, como ocurrió con Log4Shell.
Log4Shell es una vulnerabilidad crítica descubierta en noviembre de 2021 en Log4j, una biblioteca Java de código abierto r que se utiliza para iniciar sesión y se incluye en millones de aplicaciones empresariales y productos de software.
La mayoría de las organizaciones están lejos de donde deben estar en gestión de la cadena de suministro de código abierto
Log4Shell puso de manifiesto los riesgos inherentes que existen en el ecosistema de software de código abierto y la necesidad de gestionarlos adecuadamente. También llevó a poner en marcha varias iniciativas para asegurar la cadena de suministro de software por parte de organizaciones privadas, administradores de repositorios de software, la Fundación Linux y organismos gubernamentales.
Sin embargo, la mayoría de las organizaciones están lejos de donde deben estar en términos de gestión de la cadena de suministro de código abierto.
Técnicas de ataque a la cadena de suministro
El ritmo de adopción del código abierto no muestra signos de agotarse en el corto plazo. No obstante, los tipos de ataques a la cadena de suministro se han diversificado.
Sonatype había rastreado alrededor de 12.000 casos conocidos de ataques maliciosos a la cadena de suministro hasta finales del año pasado, pero ese número ha aumentado a más de 88.000, lo que significa un crecimiento interanual del 633 %. La empresa también ha descubierto 97.334 paquetes maliciosos distribuidos de diversas formas.
Uno de los principales contribuyentes al crecimiento de los paquetes maliciosos es una técnica de ataque llamada ‘confusión de dependencia’ que explota el comportamiento de la mayoría de los clientes de gestión de paquetes configurados.
Otros tipos de ataques masivos que se conocen desde hace un tiempo son el typosquatting y el brandjacking. La primera implica que los atacantes registren paquetes maliciosos con nombres similares a los de algunos paquetes populares y ampliamente utilizados. Este es un ataque pasivo que se basa en que los desarrolladores cometen errores (errores tipográficos) al escribir nombres de paquetes en sus scripts o comandos de compilación.
Por su parte, el brandjacking es similar, pero se dirige a otros mantenedores de paquetes con la esperanza de que incluyan un paquete secuestrado o con errores tipográficos como una dependencia en sus propios componentes.
La inyección de código malicioso es otra técnica que está más dirigida e involucra a los atacantes que comprometen el sistema o el repositorio de código de un desarrollador e inyectan código malicioso en su paquete sin su conocimiento.
Otro tipo de ataque similar a la inyección de código malicioso pero perpetrado por desarrolladores legítimos se conoce como protestware. Esto se refiere a incidentes en los que un desarrollador agrega código malicioso a su propio paquete previamente limpio como señal de protesta.
Rastrear vulnerabilidades y tener políticas claras sobre la procedencia de los componentes será clave para la seguridad
Crear y mantener un inventario de los componentes utilizados en todos los esfuerzos internos de desarrollo de software y rastrear las vulnerabilidades descubiertas en ellos es un aspecto clave para mitigar los riesgos de seguridad. Sin embargo, tener políticas claras sobre la procedencia de los componentes es igual de importante.
Elegir componentes o bibliotecas con una baja incidencia de vulnerabilidades en su código no es una garantía, porque muchos de ellos pueden heredar vulnerabilidades y el tiempo que tardan en responder a dichas vulnerabilidades y actualizar sus propias dependencias es crítico.
Además, elegir componentes basándose en una tasa más baja de vulnerabilidades no se traduce necesariamente en mejores resultados de seguridad a largo plazo. Un proyecto podría tener una mayor cantidad de vulnerabilidades descubiertas solo porque hay más ojos sobre él.
Imagen inicial | Erik Odiin
