En diciembre de 2025, en respuesta al incidente de Sha1-Hulud, npm completó una importante revisión de la autenticación destinada a reducir los ataques a la cadena de suministro. Si bien la revisión es un sólido paso adelante, los cambios no hacen que los proyectos npm sean inmunes a los ataques a la cadena de suministro. npm todavía es susceptible a ataques de malware: esto es lo que necesita saber para tener una comunidad Node más segura.
Comencemos con el problema original.
Históricamente, npm se basó en tokens clásicos: credenciales de larga duración y amplio alcance que podían persistir indefinidamente. Si son robados, los atacantes podrían publicar directamente versiones maliciosas de los paquetes del autor (no se necesita 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 esto, npm realizó los siguientes cambios:
- npm revocó todos los tokens clásicos y, en su lugar, utilizó de forma predeterminada tokens basados en sesiones. El equipo de npm también mejoró la gestión de tokens. Los flujos de trabajo interactivos ahora utilizan tokens de sesión de corta duración (normalmente dos horas) obtenidos mediante el inicio de sesión npm, que valores predeterminados al MFA para su publicación.
- El equipo de npm también fomenta OIDC Trusted Publishing, en el 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 requieran un segundo factor durante operaciones confidenciales.
Quedan dos cuestiones importantes
Primero, la gente debe recordar que el ataque original a herramientas como ChalkJS fue un intento exitoso de phishing MFA en la consola de npm. Si observa el correo electrónico original adjunto a continuación, podrá ver que se trataba de un correo electrónico de phishing centrado en MFA (nada como intentar hacer lo correcto y aún así salir perjudicado). La campaña engañó al responsable para que compartiera tanto el inicio de sesión del 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 aún les dará a los atacantes tiempo suficiente para cargar malware (ya que eso solo tomarí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 extremadamente similares a los tokens clásicos de antes.
Estos tokens le permiten leer y escribir en los paquetes mantenidos por el autor de un token. Esto significa que si los delincuentes obtienen acceso a la consola de un mantenedor con esta configuración de token, pueden publicar paquetes (y versiones) nuevos y maliciosos en nombre de ese autor. Esto nos devuelve al problema original con npm antes de que ajustaran sus políticas de credenciales.
Para ser claros, que más desarrolladores utilicen MFA en la publicación es una buena noticia, y los ataques futuros deberían ser menores y más pequeños. Sin embargo, hacer que OIDC y MFA estén en publicación opcional todavía deja la cuestión central sin resolver.
En conclusión, si (1) los intentos de phishing de MFA en la consola de npm aún funcionan y (2) el acceso a la consola equivale al acceso para publicar nuevos paquetes/versiones, entonces los desarrolladores deben ser conscientes de los riesgos de la cadena de suministro que aún existen.
Recomendaciones
En el espíritu de la seguridad del código abierto, aquí hay tres recomendaciones que esperamos que GitHub y npm consideren en el futuro.
- Lo ideal sería que siguieran presionando por la ubicuidad de OIDC a largo plazo. OIDC es muy difícil de comprometer y borraría casi por completo los problemas relacionados con los ataques a la cadena de suministro.
- De manera más realista, aplicar MFA para 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 explosión de gusanos como Shai-Hulud. En otras palabras, sería una mejora para no permitir tokens personalizados que omiten MFA.
- Como mínimo, sería bueno agregar metadatos a los lanzamientos de paquetes, para que los desarrolladores puedan tomar precauciones y evitar paquetes (o mantenedores) que no tomen medidas de seguridad de 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 de corta duración y vinculadas a la identidad se conviertan en la norma (y ya no sea necesaria la omisión de MFA para la automatización), el riesgo en la cadena de suministro debido a sistemas de construcción comprometidos seguirá estando materialmente presente.
Una nueva forma de hacerlo
Todo este tiempo hemos estado hablando de ataques a la cadena de suministro mediante la carga de paquetes en npm en nombre de un mantenedor. Si pudiéramos construir cada paquete npm a partir de código fuente 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.
Analizamos la base de datos pública en busca de paquetes comprometidos en npm y descubrimos que para el 98,5% de los paquetes maliciosos, el malware no estaba presente en el código fuente ascendente (solo el artefacto publicado). Esto significa que un enfoque de construcción desde el código fuente reduciría su superficie de ataque en aproximadamente un 98,5%, según datos anteriores, porque el repositorio de JavaScript de Chainguard nunca publicaría las versiones maliciosas disponibles en npm.
En un mundo ideal, los clientes estarán más seguros cuando utilicen las bibliotecas Chainguard y apliquen las recomendaciones anteriores. Según el “modelo de seguridad del queso suizo”, todas estas características son capas de medidas de seguridad aditivas, y sería mejor para las empresas utilizar una combinación de ellas.
Si desea obtener más información sobre las bibliotecas Chainguard para JavaScript, comuníquese con nuestro equipo.
Nota: Este artículo fue escrito cuidadosamente y contribuido para nuestra audiencia por Adam La Morre, ingeniero senior de soluciones de Chainguard.