NPM refuerza la seguridad con tokens efímeros y OIDC, pero la cadena de suministro sigue en riesgo

En diciembre de 2025, npm aplicó un cambio profundo en su sistema de autenticación para reducir el riesgo de ataques a la cadena de suministro: revocó los llamados “classic tokens” y promovió tokens de sesión y flujos basados en OIDC. Es una mejora significativa en las defensas por defecto, pero no elimina completamente la posibilidad de que un actor malicioso publique código dañino.

Durante años la base del problema fue sencilla: las credenciales antiguas eran largamente válidas, con un amplio alcance, y si caían en manos equivocadas permitían publicar nuevas versiones de paquetes sin que fuera necesario demostrar la procedencia del código. Ese modelo convirtió a npm en un objetivo atractivo para quienes buscan insertar malware directamente en bibliotecas muy usadas. Incidentes bien documentados en el ecosistema han mostrado cómo bastan credenciales comprometidas para causar un daño grande y rápido.

La respuesta de npm se centró en tres ideas: caducidad corta de credenciales interactivas, mejor gestión de tokens y promover el uso de identidades ligadas a ejecuciones de CI a través de OIDC. Puedes leer la explicación oficial de estos cambios en el anuncio del equipo de npm aquí. En la práctica esto significa que, para operaciones normales, los tokens interactivos expiran rápido y las publicaciones pueden requerir autenticación multifactor.

Sin embargo, la seguridad real depende tanto de las mejoras técnicas como de cómo las usan las personas y los equipos. Dos puntos clave siguen dejando abierta la puerta a ataques. Primero, los ataques de phishing dirigidos a la autenticación multifactor siguen siendo efectivos: si un mantenedor es engañado y entrega su contraseña y el código de un segundo factor, un atacante puede obtener un token de sesión válido y publicar una versión maliciosa en cuestión de minutos.

Segundo, la plataforma sigue permitiendo flujos pensados para la automatización que, si se configuran con bypass de MFA o con tokens de larga duración (por ejemplo, tokens de 90 días), recrean en esencia el problema anterior. Es decir, la existencia de tokens permanentes o con MFA omitido conserva un vector de riesgo importante cuando esos secretos se almacenan o exponen en sistemas de CI/CD.

Esto nos lleva a una conclusión práctica: las mejoras de npm reducen la ventana de exposición y elevan la dificultad para el atacante, pero no la eliminan. Mientras existan vías para generar credenciales persistentes o para engañar a un humano para que entregue credenciales de un único uso, siempre habrá un riesgo de publicación no autorizada.

En términos concretos de mitigación, conviene impulsar tres líneas de trabajo complementarias. La primera es la adopción amplia de OIDC en las integraciones de CI; usar tokens vinculados a una ejecución específica y de vida muy corta reduce drásticamente la utilidad de cualquier secreto robado. GitHub ofrece documentación sobre cómo configurar OIDC para despliegues que puede servir como referencia práctica: configurar OIDC en GitHub Actions.

La segunda línea es endurecer las políticas de MFA y minimizar excepciones: no permitir tokens que eludan el factor adicional para operaciones de publicación y forzar MFA en la consola reduce la posibilidad de que un phishing sea suficiente para publicar código. Las guías sobre prevención de phishing y buenas prácticas de autenticación publicadas por agencias como CISA ayudan a entender por qué incluso usuarios con MFA pueden ser víctimas si no se combinan controles adicionales: recomendaciones sobre phishing (CISA).

La tercera línea va más allá de la autenticación: reexaminar cómo llegan los artefactos a nuestros entornos. Si en lugar de descargar paquetes precompilados desde el registro nosotros reconstruimos cada dependencia a partir de su código fuente verificable, el riesgo de que una versión publicada con malware llegue a nuestras cadenas de suministro disminuye mucho. Una investigación práctica de Chainguard sostiene que, en su base de datos pública de paquetes comprometidos, la mayoría de los casos investigados mostraban malware presente únicamente en el paquete publicado, no en el código fuente upstream. Puedes consultar ese análisis en el sitio de Chainguard: Chainguard: mitigando malware en npm.

Este enfoque de “reconstruir desde la fuente” no es trivial: implica invertir en reproducibilidad, firma de artefactos y cadenas de confianza, pero tiene un efecto tangible en la reducción de la superficie de ataque. Herramientas y servicios que ofrecen bibliotecas construidas de manera verificable pueden encajar en un modelo de defensa en profundidad que combine políticas de acceso estrictas, auditoría y verificaciones en tiempo de ejecución.

Al final, lo que llama la atención es que no existe una única solución milagrosa. La seguridad efectiva es una suma de capas: buenas prácticas en la gestión de credenciales, uso generalizado de OIDC para automatización, obligatoriedad de MFA en acciones sensibles y, cuando sea posible, reconstrucción verificada de artefactos desde el origen. Cada medida reduce el riesgo restante que dejan las otras.

Para proyectos y organizaciones esto se traduce en decisiones concretas: revisar y rotar tokens, habilitar MFA y eliminar excepciones de bypass, migrar pipelines a OIDC cuando sea viable, y considerar la adopción de repositorios o servicios que garanticen que lo que se instala proviene del código fuente verificado. Las recomendaciones prácticas y las guías de herramientas públicas —como la de GitHub para OIDC o los análisis de incidentes de proveedores de seguridad— son recursos útiles para planear esa transición.

npm ha avanzado en la dirección correcta al cambiar las políticas por defecto y eliminar credenciales imperecederas. Aun así, mientras existan vectores humanos (phishing) y la posibilidad de generar tokens de larga duración, la amenaza sobre la cadena de suministro permanece. Lo más sensato para la comunidad es combinar mejoras en la plataforma con cambios en los procesos y en la adopción de tecnologías que eleven la barrera para un atacante hasta el punto de que explotar el sistema deje de ser rentable.

Si quieres profundizar en antecedentes y casos concretos de cómo se han aprovechado las credenciales comprometidas en el pasado, Snyk ofrece un análisis divulgativo del incidente “event-stream”, uno de los ejemplos más citados de ataque a la cadena de suministro en JavaScript: análisis del incidente event-stream (Snyk). Y si te interesa explorar alternativas técnicas centradas en construir artefactos desde la fuente, la documentación de Chainguard sobre sus bibliotecas para JavaScript explica esa aproximación con ejemplos y datos.

Para terminar, conviene recordar que este artículo se apoya en trabajos y análisis de la comunidad técnica. Las recomendaciones no buscan alarmar, sino poner en perspectiva que las mejoras de npm reducen riesgo pero no lo desaparecen, y que la respuesta más efectiva pasa por combinar controles técnicos con higiene operativa y verificación de orígenes.