En diciembre de 2025, en respuesta al incidente de Sha1-Hulud, npm completó una importante revisión de certificación destinada a reducir los ataques a la cadena de suministro. Si bien esta revisión es un sólido paso adelante, este cambio no hace que los proyectos de npm sean inmunes a los ataques a la cadena de suministro. npm sigue siendo 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 que pueden durar indefinidamente, son duraderas y tienen un amplio alcance. En caso de robo, un atacante podría publicar una versión maliciosa directamente en el paquete del autor (no se requiere código fuente verificable públicamente). Esto ha convertido a npm en un vector importante para los ataques a la cadena de suministro. Con el tiempo, numerosos incidentes del mundo real han demostrado este punto. Shai-Hulud, Sha1-Hulud y choke/debug son ejemplos recientes de ataques notables.
solución npm
Para solucionar esto, npm ha realizado 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 ha mejorado la gestión de tokens. Los flujos de trabajo interactivos ahora utilizan tokens de sesión de corta duración (normalmente 2 horas) obtenidos mediante el inicio de sesión de npm. La publicación utiliza MFA de forma predeterminada. El equipo de npm también fomenta OIDC Trusted Publishing, donde los sistemas de CI recuperan credenciales de corta duración para cada ejecución en lugar de almacenar secretos.
Combinarlos mejorará la seguridad. Estos permiten que las credenciales caduquen rápidamente y requieran un segundo factor durante operaciones confidenciales.
Quedan dos preguntas importantes
Primero, es importante recordar que los primeros ataques contra herramientas como ChalkJS fueron intentos exitosos de phishing MFA en la consola npm. Si observa el correo electrónico original adjunto a continuación, verá que es un correo electrónico de phishing centrado en MFA (no se deje intimidar si está intentando hacer lo correcto). La campaña engañó a los administradores para que compartieran tanto los inicios de sesión de los usuarios como las contraseñas de un solo uso. Esto significa que en el futuro, correos electrónicos similares pueden obtener tokens de corta duración, pero aún así darán a los atacantes tiempo suficiente para cargar malware (ya que esto sólo lleva unos minutos).
En segundo lugar, la MFA cuando se publica es opcional. Los desarrolladores pueden crear tokens de 90 días con la omisión de MFA habilitada en la consola. Esto es muy similar al token clásico anterior.
Estos tokens le permiten leer y escribir paquetes administrados por el creador del token. Esto significa que una vez que una parte malintencionada obtiene acceso a la consola de un mantenedor usando esta configuración de token, puede publicar nuevos paquetes (y versiones) maliciosos en nombre de sus autores. Esto vuelve al problema original con npm antes de ajustar la política de credenciales.
No se equivoque: que más desarrolladores utilicen MFA al publicar es una buena noticia y debería generar menos ataques y de menor tamaño en el futuro. Sin embargo, hacer que OIDC y MFA sean opcionales en el momento de la publicación deja sin resolver el problema central.
En conclusión, los desarrolladores deben ser conscientes de los riesgos de la cadena de suministro que aún existen si (1) el phishing de MFA pretende mantener la consola de npm en funcionamiento y (2) el acceso a la consola es equivalente al acceso para publicar nuevos paquetes/versiones.
Recomendaciones
En el espíritu de la seguridad del código abierto, aquí hay tres recomendaciones que espero que GitHub y npm consideren en el futuro.
Lo ideal sería que siguieran promoviendo la adopción de OIDC a largo plazo. OIDC es extremadamente difícil de comprometer y elimina casi por completo los problemas relacionados con los ataques a la cadena de suministro. De manera más realista, aplicar MFA en las cargas de paquetes locales (mediante códigos de correo electrónico o contraseñas de un solo uso) reduce aún más el radio explosivo de gusanos como Shai-Hulud. Es decir, la mejora consiste en no permitir tokens personalizados que omitan MFA. Como mínimo, es una buena idea agregar metadatos a las versiones de paquetes para que los desarrolladores puedan tomar precauciones y evitar paquetes (o mantenedores) que no cuentan con medidas de seguridad de la cadena de suministro.
En resumen, npm ha dado un paso importante al eliminar los tokens persistentes y mejorar los valores predeterminados. Hasta que las credenciales de corta duración asociadas a la identidad se conviertan en la norma y la automatización ya no requiera eludir la MFA, los riesgos de la cadena de suministro derivados de sistemas de construcción comprometidos seguirán siendo sustanciales.
nueva manera
Todo este tiempo hemos estado hablando de ataques a la cadena de suministro mediante la carga de paquetes en npm en nombre de los mantenedores. Sería mejor si todos los paquetes de npm pudieran compilarse a partir de código fuente ascendente verificable, en lugar de descargar artefactos de npm. Eso es exactamente lo que Chainguard está haciendo por sus clientes con la biblioteca Chainguard para JavaScript.
Examinamos la base de datos pública 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 en los artefactos públicos). Esto significa que nuestro enfoque de construcción desde el código fuente reduce la superficie de ataque en aproximadamente un 98,5 %, según datos históricos, ya que el repositorio de JavaScript de Chainguard no expone versiones maliciosas disponibles en npm.
En un mundo ideal, los clientes estarían más seguros al utilizar la biblioteca Chainguard y aplicar las recomendaciones anteriores. Según el «Modelo de seguridad del queso suizo», todas estas características son capas adicionales de medidas de seguridad y las empresas pueden utilizarlas mejor en conjunto.
Si desea obtener más información sobre la biblioteca Chainguard para JavaScript, comuníquese con nuestro equipo.
Nota: Este artículo fue escrito cuidadosamente y contribuido a nuestros lectores por Adam La Morre, ingeniero senior de soluciones de Chainguard.
Source link
