Estimado lector,

Esta semana ha sido extraña. En los últimos meses, hemos sido testigos de una serie de ataques significativos a la cadena de suministro. La comunidad ha estado dando la voz de alarma desde hace tiempo, y la verdad es que hemos estado en una situación precaria. Parece inevitable que algo más grande, algo peor, esté por venir.

En esta publicación, quiero compartir algunas de las principales conclusiones de esta semana. Tuve la oportunidad de sentarme con Josh Junon, más conocido como Qix, y entrevistarle sobre su experiencia en medio de esta difícil situación. Josh es el mantenedor que fue 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 (Ver la entrevista a continuación), repasemos rápidamente los eventos que nos trajeron hasta aquí.

Prólogo - Impacto

El lunes, cuando vi por primera vez las alertas en nuestro panel interno de Aikido Intel, quedó inmediatamente claro que este podría ser uno de esos escenarios de pesadilla 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.

Los números hablan por sí solos:

• En conjunto, los paquetes comprometidos se descargan alrededor de 2.600 millones de veces cada semana.
• JFrog estima que las versiones maliciosas por sí solas fueron descargadas aproximadamente 2,6 millones de veces.
• Wiz informó que el 99% de sus entornos de nube dependen de al menos uno de estos paquetes, y en el 10% de los casos, el código malicioso estaba presente.

Sin lugar a dudas, fue un momento crítico. Como muchos han señalado desde entonces, evitamos por poco una catástrofe. La única razón por la que el daño no fue mucho peor se debe a dos factores:

• Los atacantes estaban centrados exclusivamente en el robo de criptomonedas.
• Hicieron todo lo posible para pasar desapercibidos.

Pero la historia nos recuerda lo frágil que puede ser esa suerte. Solo tenemos que remontarnos al 26 de agosto de 2025 para ver qué sucede cuando un atacante es menos cuidadoso en su ejecución.

Prólogo - Compromiso de Nx

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

• Exfiltraron secretos y tokens de máquinas de desarrolladores y los publicaron en GitHub.
• Luego utilizaron esos tokens para acceder a cuentas de GitHub, haciendo públicos los repositorios privados.

Fue un ataque de 'golpe y fuga' clásico. Un crudo recordatorio de que comprometer un paquete ampliamente utilizado no solo crea inconvenientes. Puede causar daños reales y duraderos. En muchos sentidos, fue un disparo de advertencia, mostrando lo expuestos que estamos.

La conversación con Josh

Después de contactar a 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 ha sido esta experiencia. Afortunadamente, Josh estuvo dispuesto. 

Lo que siguió fue una conversación reflexiva y sincera que me dejó una verdadera impresión. Me gustaría compartir algunas de mis principales conclusiones aquí. Si deseas el contexto completo, puedes ver la discusión completa de 45 minutos aquí:

Reflexión: 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 ponen su código, y una parte de sí mismos, a disposición del 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 errores, ser transparente y mantenerse comprometido con la comunidad, nos recordó que el código abierto no está gestionado por corporaciones sin rostro, 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 construye sobre ella.

Creo que lo que marcó una gran diferencia fue el tipo de respuesta general. Sé que se señaló varias veces que la vulnerabilidad fue apreciada. Y creo que lo sabía de antemano. He tenido algunos casos en código abierto donde yo mismo he cometido errores, no en cuanto a seguridad, sino simplemente siendo transparente y honesto, y eso inmediatamente ahorró a mucha gente dolores de cabeza, tiempo y dinero. Y siempre se agradece.

Reflexión: Adentrarse en el código abierto

Josh nunca se propuso convertirse en un pilar del ecosistema JavaScript. Empezó a programar de 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 construir 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 librerías, como chalk, fue invitado a unirse como mantenedor tras aportar correcciones. En otras, como debug, heredó la gestión de mantenedores anteriores. Lo que empezó como un pasatiempo se convirtió gradualmente en el mantenimiento de algunos de los paquetes más utilizados en el ecosistema.

Años después, Josh se encontró responsable de miles de millones de descargas semanales. Lo que antes habían sido pequeños proyectos paralelos se había convertido en infraestructura crítica de internet. No por una planificación cuidadosa o ambición, sino simplemente por estar en el lugar y momento adecuados, y por decir “sí” cuando se le pidió ayuda.

Empezaron a usarse en cada vez más sitios, probablemente incluso en algunos donde nunca deberían haber estado. Sinceramente, algunos de esos paquetes no deberían existir en absoluto, y seré el primero en admitirlo. Luego, un día te despiertas y te das cuenta de que una pequeña utilidad que escribiste para mover valores de array es utilizada por 55.000 personas y descargada 300 millones de veces a la semana. Nunca pediste esa responsabilidad.

Perspectiva: La impotencia de perder el control

Quizás la parte más difícil del incidente para Josh no fue darse cuenta de que había sido víctima de phishing. Fue la impotencia que siguió. Una vez que los atacantes tuvieron su contraseña y su código 2FA, ellos eran esencialmente él a los ojos de npm. Restablecieron sus tokens 2FA, cambiaron los detalles de autenticación y le bloquearon el acceso a su propia cuenta. Incluso acciones básicas como restablecer su contraseña o recuperar el acceso no funcionaron.

Durante casi 12 horas, todo lo que Josh pudo hacer fue observar desde fuera cómo las 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 el soporte de npm. En su lugar, se vio obligado a depender de los foros de ayuda públicos y a esperar. 

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

El botón de restablecimiento de contraseña no funcionó. No recibí ningún correo electrónico durante todo este proceso. El restablecimiento de contraseña no hizo nada. Así que, incluso si el correo electrónico seguía siendo el mismo en la cuenta, lo cual sigo creyendo que era así, el restablecimiento de contraseña no funcionaba... No había otro recurso que contactar a npm a través de su formulario de ayuda público no autenticado.

Perspectiva: Una bala esquivada

El malware introducido en chalk, debug y los demás paquetes comprometidos era grave, pero su alcance era extrañamente limitado. Intentó robar criptomonedas inyectándose en contextos de 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: portátiles, servidores empresariales, pipelines de CI/CD y entornos en la nube. Podrían haber estado exfiltrando claves de AWS, filtrando secretos o cifrando archivos para pedir rescate. En cambio, los atacantes se limitaron a un objetivo estrecho.

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

La lección no es que el sistema funcionara. Es que la suerte estuvo de nuestro lado esta vez. Tratarlo como un "nothing burger" no capta la esencia. El próximo atacante podría no ser tan comedido.

Perspectiva: El coste humano del Open Source.

Detrás de cada paquete ampliamente utilizado hay un ser humano, a menudo trabajando en silencio y sin fanfarrias. Para Josh, la parte más desafiante no fue solo el compromiso técnico. Fue el coste emocional que le siguió. Describió el primer día como puro piloto automático, esforzándose por contener el daño. Solo después le sobrevino el peso: vergüenza, ansiedad y la inquietante idea de que su error podría haber dañado a personas.

Eso fue el lunes. Una vez que recuperé mi cuenta esa tarde o esa noche, fue como, vale, puedo apagar el interruptor y ahora puedo simplemente tumbarme en la cama y mirar al techo y pensar en lo que acaba de pasar… El día siguiente fue pura vergüenza. No quería mostrar mi cara. No quería salir.

Esta es la realidad oculta del Open Source. Pequeños proyectos creados "por diversión" se convierten en infraestructura crítica, soportando miles de millones de descargas. Los mantenedores nunca pidieron esa responsabilidad, sin embargo, soportan el estrés cuando las cosas van mal. La comunidad ve el código, pero a menudo pasa por alto el coste humano de mantenerlo.

La experiencia de Josh es un recordatorio de que la seguridad del ecosistema no se trata solo de una MFA más robusta o una respuesta a incidentes más rápida. También se trata de apoyar a los mantenedores que asumen esta responsabilidad: respetando los límites, mostrando empatía y reconociendo que la confianza depende de las personas detrás del código.

Llamada a la acción

Este incidente puso de manifiesto cómo una única vulneración puede propagarse por toda la cadena de suministro de software. Esta vez no fue catastrófico, pero podría haberlo sido fácilmente. La lección no es entrar en pánico, sino actuar.

• Para los registros (npm, PyPI, etc.): Implementar MFA resistente al phishing para mantenedores de alto impacto y proporcionar canales claros de respuesta rápida cuando las cuentas se vean comprometidas.
• Para las organizaciones: Mejorar la higiene de las dependencias. Fijar versiones, monitorizar manipulaciones e integrar comprobaciones de seguridad de la cadena de suministro en los pipelines de CI/CD.
  Para los mantenedores: Utilizar claves de hardware, evitar decisiones de seguridad rápidas tomadas bajo estrés y apoyarse en la transparencia si algo sale mal.
• Para la comunidad: Apoyar a las personas detrás del Open Source. Respetar sus límites, proporcionar recursos siempre que sea posible y responder con empatía cuando se cometen errores.

La verdadera llamada a la acción es sencilla: tratar la seguridad del ecosistema como una responsabilidad compartida. Plataformas, empresas y comunidades tienen un papel que desempeñar para asegurar que el próximo incidente no escale a algo peor.

Epílogo

Ha sido una semana surrealista, estando en el ojo de una tormenta que atrajo tanta prensa y atención, y con razón. Ver los acontecimientos desarrollarse en tiempo real, desde las primeras alertas en nuestro panel hasta la avalancha de informes públicos, fue como estar de pie en una falla mientras el suelo se movía bajo nosotros. Esto es un recordatorio de lo frágil que es nuestro ecosistema.

Lo que sucedió se acercó peligrosamente al tipo de escenario de pesadilla que me preocupa a diario en la seguridad de código abierto. Pero lo que más temo no es el correo electrónico de phishing, el malware, ni siquiera los titulares. Es que dejemos pasar este momento sin cambios.

Si la industria se encoge de hombros, lo trata 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 erosión silenciosa de la confianza en el código abierto podría resultar ser la consecuencia más perjudicial de todas.

‍