La actualización de npm para fortalecer su cade...

En diciembre de 2025, en respuesta al incidente de Sha1-Hulud, npm completó un revisión importante de la autenticación con el objetivo de reducir los ataques a la cadena de suministro. Si bien la reforma representa un sólido paso adelante, los cambios no hacen que los proyectos de npm sean inmunes a los ataques a la cadena de suministro. npm sigue siendo susceptible a los ataques de malware. Esto es lo que necesita saber para una comunidad de Node más segura.

Empecemos con el problema original

Históricamente, npm se basaba en los tokens clásicos: credenciales duraderas y de amplio alcance que podían persistir indefinidamente. En caso de robo, los atacantes podían publicar directamente versiones maliciosas en los paquetes del autor (sin necesidad de un código fuente verificable públicamente). Esto convirtió a npm en un vector principal para los ataques a la cadena de suministro. Con el tiempo, numerosos incidentes del mundo real demostraron este punto. Shai-Hulud, Sha1-Hulud y chalk/debug son ejemplos de ataques recientes y notables.

La solución de npm

Para solucionar este problema, npm realizó los siguientes cambios:

1. npm revocó todos los tokens clásicos y, en su lugar, adoptó de forma predeterminada los tokens basados en sesión. El equipo de npm también mejoró la administración de los tokens. Los flujos de trabajo interactivos ahora utilizan tokens de sesión de corta duración (normalmente dos horas) que se obtienen mediante npm login, que valores predeterminados a MFA para su publicación.
2. El equipo de npm también fomenta la publicación confiable de OIDC, en la que los sistemas de CI obtienen credenciales de corta duración por ejecución en lugar de almacenar secretos en reposo.

En combinación, estas prácticas mejoran la seguridad. Garantizan que las credenciales caduquen rápidamente y requieren un segundo factor durante las operaciones delicadas.

Quedan dos cuestiones importantes

En primer lugar, la gente debe recordar que el ataque original a herramientas como ChalkJS fue un intento exitoso de suplantación de identidad por medio de MFA en la consola de npm. Si te fijas en el correo electrónico original que se adjunta a continuación, verás que se trataba de un correo electrónico de suplantación de identidad centrado en la MFA (nada como intentar hacer lo correcto y seguir siendo víctima de un ataque). La campaña engañó a la persona que lo mantenía para que compartiera tanto el nombre de usuario como la contraseña de un solo uso. Esto significa que, en el futuro, correos electrónicos similares podrían recibir tokens de corta duración, lo que daría a los atacantes tiempo suficiente para cargar malware (ya que eso solo llevaría unos minutos).

En segundo lugar, la MFA en la publicación es opcional. Los desarrolladores aún pueden crear tokens de 90 días con la omisión de MFA habilitada en la consola, que son muy similares a los tokens clásicos de antes.

Estos tokens le permiten leer y escribir en los paquetes mantenidos por el autor del token. Esto significa que, si usuarios malintencionados acceden a la consola de un responsable del mantenimiento con estos ajustes de token, pueden publicar paquetes (y versiones) nuevos y malintencionados en nombre de ese autor. Esto nos devuelve al problema original con npm antes de que ajustaran sus políticas de credenciales.

Para que quede claro, es una buena noticia que haya más desarrolladores que utilicen MFA al publicar, y los ataques futuros deberían ser menos y más pequeños. Sin embargo, hacer que OIDC y MFA sean de publicación directa opcional aún deja sin resolver la cuestión central.

En conclusión, si (1) los intentos de suplantación de identidad mediante MFA en la consola de npm siguen funcionando y (2) el acceso a la consola equivale al acceso a la publicación de nuevos paquetes o versiones, los desarrolladores deben ser conscientes de los riesgos que aún existen en la cadena de suministro.

Recomendaciones

Con el espíritu de la seguridad del código abierto, aquí hay tres recomendaciones que esperamos que GitHub y npm consideren en el futuro.

1. Lo ideal es que sigan presionando por la ubicuidad del OIDC a largo plazo. La OIDC es muy difícil de comprometer y eliminaría casi por completo los problemas relacionados con los ataques a la cadena de suministro.
2. Siendo más realistas, aplicar la MFA a la carga de paquetes locales (ya sea mediante un código de correo electrónico o una contraseña de un solo uso) reduciría aún más el radio de propagación de gusanos como Shai-Hulud. En otras palabras, sería una mejora para no permitir tokens personalizados que eluden la MFA.
3. Como mínimo, sería bueno agregar metadatos a las versiones de los paquetes, para que los desarrolladores puedan tomar precauciones y evitar los paquetes (o mantenedores) que no toman medidas de seguridad en la cadena de suministro.

En resumen, npm ha dado un importante paso adelante al eliminar los tokens permanentes y mejorar los valores predeterminados. Hasta que las credenciales efímeras y vinculadas a la identidad se conviertan en la norma (y no sea necesario eludir la autenticación multifactor para la automatización), el riesgo que suponen para la cadena de suministro los sistemas de construcción comprometidos seguirá existiendo considerablemente.

Una nueva forma de hacerlo

Todo este tiempo, hemos estado hablando de ataques a la cadena de suministro mediante la carga de paquetes a npm en nombre de un mantenedor. Si pudiéramos crear todos los paquetes de npm a partir de un código fuente original verificable en lugar de descargar el artefacto desde npm, estaríamos mejor. Eso es exactamente lo que Chainguard hace por sus clientes con las bibliotecas Chainguard para JavaScript.

Hemos analizado la base de datos pública en busca de paquetes comprometidos en npm y descubrió que, en el 98,5% de los paquetes maliciosos, el malware no estaba presente en el código fuente original (solo en el artefacto publicado). Esto significa que compilar desde el código fuente reduciría la superficie de ataque en un 98,5%, según datos anteriores, ya que el repositorio de JavaScript de Chainguard nunca publicaría las versiones maliciosas disponibles en npm.

En un mundo ideal, los clientes están más seguros cuando utilizan las bibliotecas de Chainguard y aplican las recomendaciones anteriores. Según el «modelo de seguridad más vanguardista», todas estas funciones son capas de medidas de seguridad aditivas, y las empresas preferirían utilizar una combinación de ellas.

Si quieres obtener más información sobre las bibliotecas Chainguard para JavaScript, póngase en contacto con nuestro equipo .