Septiembre no está siendo precisamente un mes fácil para npm, el registro de paquetes de JavaScript gestionado por GitHub. En las últimas semanas, la plataforma se ha visto sacudida por ataques de phishing dirigidos a desarrolladores y por la aparición de cientos de paquetes infectados con malware diseñado para robar secretos. Ante este panorama, GitHub ha decidido ponerse manos a la obra y reforzar la seguridad de su ecosistema.
Un mes complicado para npm
El propio jefe del laboratorio de seguridad de GitHub, Xavier René-Corail, reconoció la magnitud del problema: más de 500 paquetes comprometidos tuvieron que ser retirados y muchos otros fueron bloqueados gracias a las herramientas de escaneo automático de seguridad. Una situación que evidencia la necesidad de elevar el nivel de protección en la publicación de paquetes.
Pero los planes de GitHub no se limitan a apagar fuegos. René-Corail detalló una serie de cambios que buscan blindar la plataforma de forma más estructural.
Adiós a los métodos de autenticación antiguos
Uno de los puntos clave es la eliminación de métodos de autenticación heredados, como los clásicos tokens de larga duración y las contraseñas de un solo uso para la autenticación en dos pasos (2FA). Estos sistemas, aunque en su día fueron útiles, hoy representan un riesgo porque son mucho más vulnerables a filtraciones y robos.
En su lugar, GitHub apuesta por acortar la vida útil de los tokens y migrar hacia un modelo en el que la publicación local con 2FA y la publicación confiable (Trusted Publishing) sean la norma.
¿Qué es la publicación confiable?
La idea de “publicación confiable” no es nueva: ya fue adoptada por el índice de paquetes PyPI y ahora GitHub quiere llevarla a npm. Básicamente, se trata de un sistema que utiliza OpenID Connect (OIDC) para verificar que un paquete proviene de una fuente legítima antes de emitir un token de corta duración. Esto evita la existencia de tokens de larga vida que pueden ser robados y explotados por atacantes.
Por ahora, este sistema solo funciona con GitHub Actions y GitLab CI/CD, pero otros repositorios como RubyGems, crates.io (para Rust) y NuGet (para .NET) también han comenzado a dar soporte a este modelo. Microsoft, de hecho, lo anunció para NuGet hace apenas unos días.
En el caso de npm, una vez que los cambios entren en vigor, las opciones para publicar quedarán limitadas a:
-
Publicación local protegida por 2FA.
-
Tokens granulares con una vida útil máxima de siete días.
-
Publicación confiable mediante OIDC.
Una transición complicada
René-Corail admitió que la idea original era permitir que los desarrolladores adoptaran poco a poco este nuevo sistema. Sin embargo, la realidad es que “los atacantes no están esperando”. Aun así, GitHub es consciente de que un cambio brusco podría romper muchos flujos de trabajo actuales, por lo que los ajustes se aplicarán de manera gradual. La fecha definitiva en la que estas nuevas reglas serán obligatorias todavía no ha sido anunciada.
Un reto añadido es que no todos los desarrolladores quieren depender de GitHub Actions o GitLab CI/CD. Por eso, GitHub planea ampliar pronto la lista de proveedores admitidos. De momento, la publicación confiable solo funciona con runners de GitHub, pero el soporte para runners auto-hospedados ya está en camino. Vale la pena señalar que cada paquete solo podrá tener un editor de confianza configurado a la vez.
Críticas y dudas de la comunidad
Aunque la publicación confiable resuelve muchos problemas, no todos están convencidos de que sea suficiente. El desarrollador Andrey Sitnik, conocido por su trabajo en PostCSS, expresó sus reservas:
“Uso 2FA con una clave de hardware (como YubiKey) para publicar. Si añado Trusted Publisher a través de CI, estoy aumentando los riesgos. Cualquier malware en los nodos de PostCSS podría hacer un commit con etiqueta y empujarlo a GitHub”.
Otro desarrollador añadió que OIDC no es una solución mágica, ya que en la práctica traslada la responsabilidad de la autorización a otra plataforma. Según su visión, GitHub debería implementar medidas adicionales como requerir múltiples revisiones antes de cambiar configuraciones críticas, para que una sola cuenta comprometida no tenga el poder de modificar ajustes clave de seguridad.
El futuro de la seguridad en npm
Lo que está claro es que GitHub está decidido a dar un paso más en la lucha contra los ataques que afectan al ecosistema npm. La publicación confiable, el fin de los tokens de larga duración y el refuerzo de la 2FA marcan un cambio de paradigma en la forma en que se gestionan los paquetes.
Eso sí, la transición no será sencilla. GitHub tendrá que encontrar el equilibrio entre seguridad y flexibilidad, escuchando las preocupaciones de los desarrolladores mientras mantiene a raya a los atacantes. Y, como siempre, el tiempo dirá si estas medidas son suficientes para frenar la creciente ola de amenazas.
Fuente: the registrer
Añadir comentario
Comentarios