El compromiso debe mostrarse

Ha vuelto a ocurrir. Recientemente se descubrió que una librería de software abrió una puerta a ataques afectando una enorme cantidad de productos que la tienen en sus cimientos. Tenemos un nombre para eso: ataque a la cadena de suministro. Nos referimos esta vez a la explotación de polyfill.js. Para los que se acaban de enterar de esta noticia, el dominio que los productos de software utilizan para embeber esta librería, con el propósito de hacer disponibles funciones modernas en navegadores antiguos, ha estado enviando código JavaScript malicioso a dichos productos, lo que ha provocado que los usuarios sean redirigidos a sitios web no solicitados. Unas tres semanas después de conocerse la noticia, más de 80 mil páginas web siguen utilizando la biblioteca. La utilizan incluso luego de que el autor original urgió a los proyectos a eliminar polyfill.js. Es más, se sigue utilizando incluso cuando esta misma persona dice que los navegadores modernos pueden ocuparse de aquello para lo que se creó la biblioteca.

Queremos hablar de un evento anterior a los ataques mencionados, ya que creemos que es clave para entender una preocupación importante en torno a los ataques a la cadena de suministro. Y es que polyfill.js había cambiado de propietario en febrero de 2024. Y al darse cuenta de la disparidad entre el comentario del creador ("[...] eliminen [la librería] INMEDIATAMENTE") y el de otra persona importante involucrada previamente en el proyecto ("He estado en conversaciones con Funnull durante muchos meses y ellos serán los nuevos mantenedores y operadores del repositorio [de la librería] en GitHub [...]"), los usuarios empezaron a hacerse preguntas. ¿Qué se debe hacer? ¿Y quiénes son Funnull? De hecho, esta última pregunta ha dado lugar a descubrimientos preocupantes. Se ha reportado que, aunque la empresa dice ser estadounidense, su sitio web está en mandarín, las direcciones donde afirma tener oficinas son falsas y su ubicación real podría ser Filipinas. Al revisar su sitio web, hay quienes se han dado cuenta de que la empresa menciona de paso una política de privacidad, que nadie puede localizar, y afirma que los propios usuarios deben leer periódicamente los términos del servicio para enterarse de cualquier cambio en ellos. El cambio de propietario se hizo de forma descuidada, sin una comunicación transparente sobre quiénes son los nuevos dueños y cuáles serán las implicaciones para los usuarios.

Lo anterior nos lleva a preguntarnos: ¿Quién se encarga del mantenimiento de los componentes de software más usados? Ya conoces el chiste de que es una persona no reconocida la que mantiene un bloque que, si se rompiera, haría que todo el edificio se derrumbara. Un post anterior sostiene que, aunque se trata de un chiste gracioso, es algo cercano a la realidad. The Linux Foundation y The Laboratory for Innovation Science de Harvard descubrieron que, en aproximadamente una cuarta parte de las 49 librerías gratuitas y de código abierto más usadas, solo un desarrollador de cada librería evaluada había contribuido a más del 80% de las líneas de código. ¿Y hasta qué punto están comprometidos con la seguridad estos y los demás proyectos más usados? La investigación mencionada muestra que muchos de ellos se mantienen desde cuentas individuales en lugar de organizacionales. Las primeras tienen menos granularidad que las segundas en cuanto al control de permisos y publicación. Además, otra observación que se puede hacer es que la gran mayoría de las librerías más utilizadas no participan en el programa de Insignia de Mejores Prácticas de Open Source Security Foundation. Este programa es de The Linux Foundation y es una oportunidad para que los proyectos de desarrollo muestren abiertamente su grado de cumplimiento de muchos requisitos de seguridad. Aunque el hecho de que no participen en él no significa necesariamente que no sigan las buenas prácticas esperadas, cabe la duda. En serio, dado que nuestro software, como es bien sabido, se compone en gran medida de dependencias indirectas de código abierto (es decir, paquetes utilizados por los paquetes que utilizamos en nuestro proyecto), es lógico que queramos saber hasta qué punto son seguras estas dependencias. Necesitamos transparencia, es decir, que los proyectos sean abiertos y honestos sobre sus prácticas, riesgos e incidentes de seguridad, si queremos ser capaces de contrarrestar los ataques a la cadena de suministro. Incluso, nosotros mismos, dado que nuestro proyecto puede formar parte de otro(s) proyecto(s), tenemos que empezar a ser transparentes, o mantener o perfeccionar nuestra transparencia.

Los siguientes son algunos datos básicos que deberíamos mostrar públicamente y pedir a todos los demás proyectos de desarrollo de software que sigan nuestro ejemplo:

En Fluid Attacks estamos convencidos de que si exhibimos lo que hacemos, si todo el mundo puede ver la información de arriba sobre nuestro proyecto, seguro que nos irá mejor. Y este cuidado redundará sin duda en pro de la calidad de las cadenas de suministro de software.

Todo esto puede parecer abrumador, pero está claro que es justo que cada uno de nosotros actúe en favor de la certeza de nuestros colegas desarrolladores y, en última instancia, de los usuarios finales, de que nuestras prácticas de seguridad evitan ataques proactivamente. Podemos ayudarte a proteger tu software ofreciéndote las mejores técnicas y herramientas de AppSec para gestionar las vulnerabilidades en todo el SDLC, no solo las relacionadas con tu código, sino también con el estado del código de terceros que utilizas. Contáctanos.