La ciberseguridad de las cadenas de software de código abierto es hoy en día una de las principales preocupaciones de los responsables de seguridad de la información (RSSI), los directores de sistemas de información (DSI)… pero también de las aseguradoras. El ataque ocurrido a finales de agosto de 2025 en torno al paquete JavaScript nx, publicado en la plataforma npm, ilustra hasta qué punto evolucionan rápidamente los vectores de exposición y cómo una vulnerabilidad situada en una fase anterior puede afectar a un gran número de actores en fases posteriores.

Lo que revela este ataque va mucho más allá de una simple falla en una herramienta de código abierto. Pone en tela de juicio la forma en que se desarrolla y actualiza el software hoy en día, especialmente a través de las denominadas cadenas CI/CD, que automatizan las distintas etapas de desarrollo, pruebas y puesta en línea del código. Estos procesos, muy eficaces, permiten a los equipos técnicos implementar cambios de forma rápida y frecuente, pero también se convierten en puntos débiles si se descuida su seguridad. El ataque también pone de relieve cuestiones críticas como la gestión de las credenciales de acceso, la dependencia de componentes de software compartidos entre proyectos y la inventiva cada vez mayor de los atacantes para extraer discretamente datos sensibles. Un elemento especialmente novedoso en este caso es la integración de la inteligencia artificial directamente en el programa malicioso, para adaptar en tiempo real la forma en que se identifican los archivos que se van a extraer.

Todo comenzó con una vulnerabilidad en un archivo de configuración utilizado para automatizar ciertas tareas en la plataforma en la nube GitHub. 

A grandes rasgos, GitHub es un sitio web y un servicio en la nube que ayuda a los desarrolladores a almacenar y gestionar su código, así como a realizar un seguimiento y controlar los cambios que se le introducen. Lo utiliza el 90 % de los desarrolladores. 

Un proceso automatizado, encargado de verificar los títulos de las solicitudes de modificación del código en GitHub, contenía un error clásico pero con graves consecuencias: en él se ejecutaba un comando del sistema sin la protección suficiente contra entradas maliciosas. Un atacante pudo aprovechar esta vulnerabilidad para insertar un script malicioso, que a su vez activó un segundo proceso, aún más sensible, utilizado para publicar automáticamente nuevas versiones del componente nx en el registro de módulos JavaScript npm.

Estas nuevas versiones, publicadas oficialmente a nombre del equipo de desarrollo, contenían un script malicioso que se ejecutaba nada más instalar el paquete, es decir, de forma local en los equipos de los desarrolladores. 

Una vez ejecutado, este script rastreaba los archivos de los usuarios en busca de datos sensibles: tokens de autenticación, archivos de configuración, variables de entorno e incluso claves SSH o archivos de carteras criptográficas. Lo más preocupante es que estos datos no se exfiltraban a un servidor de terceros, sino directamente a un repositorio de GitHub creado a espaldas del usuario, en su propia cuenta, es decir, una página web de acceso público. Esta página creada por el malware pertenecía a la propia víctima. 

Este método de exfiltración, discreto y muy difícil de rastrear, utiliza la infraestructura de GitHub como canal de fuga: ninguna solicitud a un dominio desconocido, ningún flujo saliente sospechoso… todo pasa por el propio GitHub. En ocasiones, la víctima tardaba en darse cuenta de que tenía una página pública que no había creado y que contenía información confidencial, susceptible de ser recuperada por los hackers. 

Al mismo tiempo, el programa malicioso incorporaba un mecanismo inédito. Era capaz de detectar la posible presencia, en el ordenador de la víctima, de herramientas de inteligencia artificial de línea de comandos, como Claude, Gemini o Amazon Q. Cuando estaban disponibles, el software generaba automáticamente instrucciones redactadas en lenguaje natural para que estas herramientas identificaran por sí mismas los archivos potencialmente sensibles que debían buscar. 

Se trata de un software malicioso denominado «potenciado por inteligencia artificial»: el ataque se basa en la capacidad de estas herramientas para comprender el contexto y adaptarse, con el fin de mejorar la fase de localización de los datos que se van a robar. Aunque la eficacia de esta técnica sigue siendo limitada —menos de una cuarta parte de los intentos permitieron una recopilación realmente aprovechable—, su nivel de sofisticación supone un hito y una evolución significativa en los métodos utilizados por los atacantes.

Las consecuencias del ataque han sido especialmente graves. Más de 1 700 usuarios se vieron afectados ya en la primera fase. Posteriormente, miles de repositorios de código inicialmente privados se hicieron públicos, de forma voluntaria o no, mediante el uso fraudulento de las credenciales de acceso recuperadas. Hasta la fecha, se han registrado más de 6 700 cuentas pirateadas y, por lo tanto, con información sensible expuesta públicamente. 

El tiempo de reacción también ha suscitado inquietudes: según los análisis realizados por el equipo de investigación de la empresa WIZ, el 80 % de las credenciales robadas seguían activas cuarenta y ocho horas después del inicio del incidente. Varias organizaciones no se dieron cuenta de la filtración hasta varios días después, ya fuera al consultar sus registros de actividad o tras haber sido informadas por especialistas en ciberseguridad.

Este tipo de situación resulta especialmente preocupante para los actores del sector asegurador. Demuestra que la exposición al riesgo no siempre se debe a un error interno o a una vulnerabilidad propia de la empresa asegurada, sino a un tercero. 

Basta con que un proveedor de servicios, un desarrollador externo o incluso una simple extensión instalada en un entorno de trabajo descargue una versión comprometida de un componente de software para que se inicie una cadena de compromisos invisibles. Y como la fuga de información no desencadena necesariamente una alerta, la vulneración puede pasar totalmente desapercibida… hasta que aparecen las consecuencias, a veces mucho más adelante en la cadena de responsabilidad.

En este caso concreto, una parte de los desarrolladores —que a menudo son autónomos— son terceros que utilizan la plataforma GitHub. En GitHub colaboran con informáticos y otros desarrolladores asalariados de sus clientes. 

Entonces, ¿dónde recaen las responsabilidades? Ante una misma vulnerabilidad y una misma información filtrada, los datos sensibles quedan expuestos tanto a través de la cuenta de GitHub de un proveedor como de la cuenta de GitHub de un desarrollador asalariado. En definitiva, es la plataforma GitHub la que presenta una vulnerabilidad. La cuestión de la garantía a la que se puede recurrir es discutible...

Para los aseguradores, este caso plantea varias cuestiones. ¿Cómo evaluar la exposición real de un asegurado a este tipo de ataque? ¿Cómo anticipar las consecuencias de un compromiso en la cadena de suministro de software? Y, sobre todo, ¿qué criterios deben integrarse en una póliza de seguro cibernético para cubrir estos nuevos riesgos sin caer en la sobreexclusión?

En CnC Expertise, recomendamos incorporar desde ya indicadores específicos relacionados con la gobernanza de la seguridad informática en las tablas de evaluación de riesgos digitales. Esto supone, por ejemplo, la implantación de verificaciones periódicas de los procesos automatizados de desarrollo y puesta en producción, una gestión rigurosa de las credenciales y los derechos de acceso en función de los niveles de responsabilidad, un análisis en profundidad de los componentes de software de terceros utilizados, así como la capacidad de detectar comportamientos anómalos, especialmente en los repositorios de código o en las herramientas utilizadas por los equipos de desarrollo. Ya estamos ayudando a varias compañías de seguros y corredurías a integrar de forma concreta estas buenas prácticas en sus auditorías técnicas.

El caso Nx no es un caso aislado. Se inscribe en una tendencia de fondo en la que la cadena de suministro digital se está convirtiendo en uno de los principales vectores de ataque. El código abierto es una fuente de innovación, pero también una superficie de ataque masiva y, en ocasiones, mal controlada. 

En este contexto, es esencial que los actores del sector de los seguros y de la ciberseguridad avancen de la mano, con marcos de referencia comunes y una capacidad compartida de anticipación.

Este tipo de incidente pone de manifiesto una cosa: la confianza, en materia de ciberseguridad, no se impone por decreto. Se construye, archivo a archivo, canal a canal. Y hay que protegerla.