Qué cambia exactamente en la publicación de paquetes
A partir de ahora, cada paquete subido a npm pasa por un escaneo automático antes de quedar disponible para instalación. El resultado de ese escaneo puede ser la publicación normal, la retención del paquete para que un humano lo revise, o el bloqueo directo si el sistema detecta indicios de malware.
Ese proceso no es instantáneo. Según el changelog oficial de GitHub, el retraso habitual será de unos 5 minutos, pero puede extenderse hasta 15 minutos o más dependiendo de la hora, el contenido del paquete o su tamaño. Para equipos que despliegan software de forma automatizada y dependen de que una dependencia recién publicada esté disponible al instante, ese margen de espera obliga a ajustar calendarios y pipelines.
El cambio se enmarca en lo que GitHub denomina su estrategia de supply-chain security, es decir, la protección de toda la cadena de proveedores de software: cada dependencia que un proyecto instala es, en la práctica, código de un tercero que se ejecuta con los mismos permisos que el proyecto principal. Un paquete malicioso publicado hoy puede acabar en miles de aplicaciones antes de que nadie lo note.
El problema de fondo: cuando una herramienta de seguridad parece malware
El segundo anuncio responde a una paradoja del propio escaneo automático: existen paquetes legítimos, pensados precisamente para tareas de seguridad —pruebas de penetración, análisis de vulnerabilidades, simulación de ataques— cuyo comportamiento técnico es indistinguible del de un malware real para un sistema automatizado. GitHub llama a este contenido "dual-use": código con doble uso, defensivo y potencialmente ofensivo según quién lo maneje.
Para resolverlo, npm introduce un campo nuevo en el archivo de configuración package.json, llamado contentPolicy, junto a la obligación de incluir un archivo de texto llamado DISCLOSURE en la raíz del paquete. Ambos elementos sirven para que el mantenedor declare de forma explícita que su paquete tiene capacidades sensibles y por qué son legítimas.
Esa declaración, sin embargo, no es un salvoconducto automático. El equipo de Trust & Safety de npm y GitHub revisa estos paquetes caso por caso, y la etiqueta dual-use debe mantenerse en todas las versiones futuras del paquete: no puede retirarse una vez declarada, lo que en la práctica convierte esa declaración en una marca permanente sobre el proyecto.
2FA obligatorio: se cierra la vía de publicación sin autenticación reforzada
El cambio más restrictivo afecta a cómo se puede publicar un paquete dual-use. La política de npm establece que la publicación directa solo es válida si se hace desde una sesión interactiva con 2FA activo, es decir, con un segundo factor de autenticación además de la contraseña habitual.
Fuera de ese supuesto, los mantenedores deben recurrir a trusted publishing mediante OIDC —un mecanismo que verifica la identidad del publicador a través de un proveedor externo de confianza sin necesidad de credenciales estáticas— o a staged publishing, un flujo de publicación por etapas que introduce comprobaciones intermedias antes de que el paquete quede disponible.
Queda explícitamente prohibido publicar contenido dual-use usando tokens granulares que permitan saltarse el 2FA, una práctica que hasta ahora era técnicamente posible y que algunos mantenedores usaban por comodidad en flujos de publicación automatizados. Esa vía se cierra por completo para este tipo de paquetes.
Lo que el anuncio no aclara
El changelog de GitHub detalla el funcionamiento técnico de ambos mecanismos, pero no ofrece cifras sobre el volumen de paquetes maliciosos detectados hasta ahora en npm ni casos concretos que hayan motivado esta decisión. Tampoco hay referencias a costes de implementación, ni para GitHub ni para los mantenedores que deban adaptar sus flujos de publicación a los nuevos requisitos de autenticación.
Tampoco se detalla qué ocurre si un paquete legítimo es bloqueado por error por el escáner automático antes de que su mantenedor tenga ocasión de declararlo como dual-use, ni cuánto tiempo puede tardar el equipo de Trust & Safety en resolver una revisión manual. Son las preguntas que previsiblemente empezará a responder la propia comunidad de desarrolladores en cuanto el sistema esté en funcionamiento y aparezcan los primeros casos reales.