Estimado lector:

Esta semana ha sido extraña. En los últimos meses, hemos sido testigos de una serie de importantes ataques a la cadena de suministro. La comunidad lleva tiempo dando la voz de alarma y lo cierto es que hemos estado caminando sobre hielo fino. Parece inevitable que se avecine algo más grande, algo peor.

En esta publicación, quiero compartir algunas de las conclusiones clave de esta semana. Tuve la oportunidad de sentarme con Josh Junon, más conocido como Qix, y entrevistarlo sobre su experiencia en medio de esta dura prueba. Josh es el mantenedor que se vio comprometido en el ataque de phishing, y también está detrás de algunos de los paquetes más utilizados en el ecosistema npm.

Antes de sumergirnos en esa conversación (véase la entrevista más abajo), echemos un vistazo rápido a los acontecimientos que nos han llevado hasta aquí.

Prólogo - Impacto

El lunes, cuando vi por primera vez las alertas en nuestro panel interno de Aikido Intel, me quedó claro de inmediato que este podía ser uno de esos peores escenarios que me quitan el sueño. Paquetes importantes como debug, chalk y otros dieciséis habían sido comprometidos con malware. Las posibles consecuencias eran nada menos que catastróficas.

Las cifras hablan por sí solas:

• En conjunto, los paquetes comprometidos se descargan alrededor de 2600 millones de veces cada semana.
• JFrog estima que solo las versiones maliciosas se descargaron aproximadamente 2,6 millones de veces.
• Wiz que el 99 % de sus entornos en la nube dependen de al menos uno de estos paquetes y que, en el 10 % de los casos, se detectó la presencia de código malicioso.

Desde cualquier punto de vista, fue por los pelos. Como muchos han señalado desde entonces, esquivamos por poco una bala. La única razón por la que los daños no fueron mucho peores se reduce a dos factores:

• Los atacantes estaban totalmente enfocados en robar criptomonedas.
• Hicieron todo lo posible por pasar desapercibidos.

Pero la historia nos recuerda lo frágil que puede ser esa suerte. Solo tenemos que mirar atrás , al 26 de agosto de 2025, para ver lo que ocurre cuando un atacante es menos cuidadoso en su ejecución.

Prólogo - Compromiso Nx

El 26 de agosto, el gestor de paquetes Nx fue comprometido, pero los atacantes optaron por una estrategia muy diferente:

• Exfiltraron secretos y tokens de las máquinas de los desarrolladores y los publicaron en GitHub.
• A continuación, utilizaron esas claves para acceder a cuentas de GitHub y convertir repositorios privados en públicos.

Fue un clásico golpe rápido. Un recordatorio contundente de que comprometer un paquete ampliamente utilizado no solo crea inconvenientes. Puede causar daños reales y duraderos. En muchos sentidos, fue una advertencia que nos mostró lo expuestos que estamos.

La conversación con Josh

Después de contactar con Josh para alertarle sobre el compromiso y continuar nuestras conversaciones posteriormente, mi colega Mackenzie y yo nos dimos cuenta de que sería fascinante sentarnos con él y escuchar de primera mano cómo había sido esta experiencia. Afortunadamente, Josh se mostró receptivo. 

Lo que siguió fue una conversación reflexiva y sincera que me dejó una gran impresión. Me gustaría compartir aquí algunas de las ideas más importantes que extraje de ella. Si desea conocer el contexto completo, puede ver la discusión completa de 45 minutos aquí:

Perspectiva: Confianza a través de la vulnerabilidad

La seguridad suele consistir en eliminar la vulnerabilidad. Pero en el código abierto, la confianza solo es posible gracias a la vulnerabilidad. Los mantenedores exponen su código, y una parte de sí mismos, al mundo, exponiéndolo a miles de millones de descargas y a innumerables usuarios. Esa exposición requiere un acto de fe.

Cuando Josh habló abiertamente sobre cómo fue víctima de phishing, mostró el tipo de vulnerabilidad que realmente fortalece la confianza. Al admitir sus errores, ser transparente y mantenerse comprometido con la comunidad, nos recordó que el código abierto no está gestionado por corporaciones anónimas, sino por personas. Y la confianza en esas personas es lo que hace que todo el sistema funcione.

Al final, la paradoja es que la seguridad busca eliminar la vulnerabilidad, pero la confianza en el código abierto se basa precisamente en ella.

Creo que lo que marcó una gran diferencia fue el tipo de respuesta general. Sé que se señaló en varias ocasiones que se agradeció la vulnerabilidad. Y creo que ya lo sabía de antemano. He tenido algunos casos en código abierto en los que yo mismo he metido la pata, no en materia de seguridad, sino simplemente por ser transparente y honesto, y eso ha ahorrado inmediatamente a mucha gente dolores de cabeza, tiempo y dinero. Y siempre se agradece.

Perspectiva: Caer en el código abierto

Josh nunca se propuso convertirse en un pilar del ecosistema JavaScript. Comenzó a programar cuando era adolescente, experimentando con PHP, C# y JavaScript, y el código abierto era solo un lugar para compartir proyectos que le interesaban. Le atraían cosas como añadir colores a los terminales o crear pequeñas utilidades, sin imaginar que acabarían siendo el núcleo del software moderno.

Con el tiempo, sus contribuciones le llevaron a asumir mayores responsabilidades. En algunas bibliotecas, como chalk, fue invitado a unirse como mantenedor tras aportar correcciones. En otras, como debug, heredó la administración de los mantenedores anteriores. Lo que comenzó como un pasatiempo por diversión se convirtió gradualmente en el mantenimiento de algunos de los paquetes más utilizados del ecosistema.

Años más tarde, Josh se encontró a cargo de miles de millones de descargas semanales. Lo que antes habían sido pequeños proyectos secundarios se había convertido en una infraestructura fundamental de Internet. No gracias a una planificación cuidadosa ni a la ambición, sino simplemente por estar en el lugar adecuado en el momento adecuado y decir «sí» cuando le pidieron ayuda.

Empezaron a utilizarse en cada vez más sitios, probablemente incluso en algunos en los que nunca deberían haberse utilizado. Sinceramente, algunos de esos paquetes no deberían existir en absoluto, y soy el primero en admitirlo. Entonces, un día te despiertas y te das cuenta de que una pequeña utilidad que escribiste para mover valores de matriz es utilizada por 55 000 personas y se descarga 300 millones de veces a la semana. Nunca pediste esa responsabilidad.

Perspectiva: La impotencia de perder el control

Quizás lo más difícil del incidente para Josh no fue darse cuenta de que había sido víctima de phishing, sino la impotencia que sintió a continuación. Una vez que los atacantes obtuvieron su contraseña y su código 2FA, se convirtieron en él a los ojos de npm. Restablecieron sus tokens 2FA, cambiaron los datos de autenticación y le bloquearon el acceso a su propia cuenta. Ni siquiera acciones básicas como restablecer su contraseña o recuperar el acceso funcionaron.

Durante casi 12 horas, lo único que Josh pudo hacer fue observar desde fuera cómo versiones maliciosas de sus paquetes se propagaban por Internet. No tenía forma de intervenir directamente, ningún botón que pulsar, ningún canal rápido para contactar con el servicio de asistencia de npm. En su lugar, se vio obligado a recurrir a foros públicos de ayuda y esperar. 

La sensación de impotencia es lo que se le quedó grabado. Según él, no había transparencia ni herramientas para que un administrador en crisis recuperara el control. En medio de uno de los mayores compromisos de la cadena de suministro que se recuerdan, la persona en la que más se confiaba para esos paquetes se quedó al margen.

El botón para restablecer la contraseña no funcionaba. No recibí ningún correo electrónico durante todo este proceso. El restablecimiento de la contraseña no sirvió de nada. Así que, aunque el correo electrónico de la cuenta seguía siendo el mismo, lo cual sigo creyendo que era así, el restablecimiento de la contraseña no funcionaba... No había otra solución que ponerse en contacto con npm a través de su formulario de ayuda público no autenticado.

Perspectiva: Una bala esquivada

El malware implantado en chalk, debug y otros paquetes comprometidos era grave, pero su alcance era extrañamente limitado. Intentaba robar criptomonedas inyectándose en los contextos del navegador. Esa decisión de los atacantes, ya fuera por codicia o por miopía, es la única razón por la que las consecuencias no fueron mucho peores.

Como dijo Josh, esto podría haber sido fácilmente catastrófico. Esos paquetes se ejecutan en todas partes: ordenadores portátiles, servidores empresariales, canalizaciones CI/CD y entornos en la nube. Podrían haber estado filtrando claves de AWS, revelando secretos o cifrando archivos para pedir rescate. En cambio, los atacantes se limitaron a un objetivo concreto.

Podría haber hecho cualquier cosa y se estaba ejecutando... en máquinas empresariales, máquinas personales, pequeñas empresas, canalizaciones CI/CD. Y el hecho de que no hiciera nada [peor] fue la bala que esquivamos.

La lección no es que el sistema funcionó. Es que esta vez la suerte estuvo de nuestro lado. Considerarlo como algo sin importancia es no entender el fondo del asunto. El próximo atacante podría no ser tan comedido.

Perspectiva: El coste humano del código abierto

Detrás de cada paquete ampliamente utilizado hay una persona, que a menudo trabaja en silencio y sin fanfarria. Para Josh, la parte más difícil no fue solo el compromiso técnico. Fue el desgaste emocional que siguió. Describió el primer día como puro piloto automático, luchando por contener el daño. Solo después se dio cuenta del peso que eso suponía: vergüenza, ansiedad y la inquietante idea de que su error podría haber hecho daño a otras personas.

Eso fue el lunes. Cuando recuperé mi cuenta esa tarde o esa noche, pensé: «Vale, ya puedo desconectar y ahora puedo tumbarme en la cama, mirar al techo y pensar en lo que acaba de pasar...». Al día siguiente me sentía avergonzado. No quería dar la cara. No quería salir a la calle.

Esta es la realidad oculta del código abierto. Pequeños proyectos creados «por diversión» se convierten en infraestructuras críticas, con miles de millones de descargas. Los mantenedores nunca pidieron esa responsabilidad, pero son ellos quienes soportan el estrés cuando las cosas van mal. La comunidad ve el código, pero a menudo pasa por alto el coste humano que supone mantenerlo.

La experiencia de Josh nos recuerda que la seguridad del ecosistema no solo consiste en una autenticación multifactorial más sólida o una respuesta más rápida ante incidentes. También consiste en apoyar a los mantenedores que asumen esta responsabilidad, respetando los límites, mostrando empatía y reconociendo que la confianza depende de las personas que hay detrás del código.

Llamada a la acción

Este incidente puso de manifiesto cómo un solo compromiso puede tener repercusiones en toda la cadena de suministro de software. En esta ocasión no fue catastrófico, pero fácilmente podría haberlo sido. La lección no es entrar en pánico, sino actuar.

• Para registros (npm, PyPI, etc.): Imponer la autenticación multifactorial (MFA) resistente al phishing para los mantenedores de alto impacto y proporcionar canales de respuesta clara y rápida cuando las cuentas se vean comprometidas.
• Para las organizaciones: mejoren la higiene de las dependencias. Fijen las versiones, supervisen cualquier manipulación e integren controles de seguridad de la cadena de suministro en los procesos de CI/CD.
  Para los mantenedores: utilicen claves de hardware, eviten tomar decisiones rápidas sobre seguridad bajo presión y apóyense en la transparencia si algo sale mal.
• Para la comunidad: Apoya a las personas que están detrás del código abierto. Respeta sus límites, proporciona recursos siempre que sea posible y responde con empatía cuando se produzcan errores.

La verdadera llamada a la acción es sencilla: tratar la seguridad del ecosistema como una responsabilidad compartida. Las plataformas, las empresas y las comunidades tienen un papel que desempeñar para garantizar que el próximo incidente no se convierta en algo peor.

Epílogo

Ha sido una semana surrealista, estar en el ojo del huracán que atrajo tanta atención y cobertura mediática, y con razón. Ver cómo se desarrollaban los acontecimientos en tiempo real, desde las primeras alertas en nuestro panel de control hasta la avalancha de informes públicos, fue como estar de pie sobre una falla geológica mientras el suelo se movía bajo nuestros pies. Esto nos recuerda lo frágil que es nuestro ecosistema.

Lo que ocurrió se acercó peligrosamente al peor escenario posible por el que me preocupo a diario en materia de seguridad del código abierto. Pero lo que más temo no son los correos electrónicos de phishing, el malware ni siquiera los titulares. Es que dejemos pasar este momento sin cambiar nada.

Si la industria se encoge de hombros, trata esto como un incidente más y vuelve a la normalidad, no habremos aprendido nada. Y la próxima vez, porque habrá una próxima vez, puede que no tengamos tanta suerte. La primera vez, la culpa es de los atacantes. La segunda vez, la culpa es nuestra.

Y si no tomamos medidas para aprender de esto, la silenciosa erosión de la confianza en el código abierto puede acabar siendo la consecuencia más perjudicial de todas.

‍