npm staged publishing ya es oficial: así cambia la seguridad de la cadena de suministro en JavaScript

npm staged publishing ya es oficial y no es un cambio menor. GitHub acaba de activar en npm un sistema que obliga a aprobar manualmente cada paquete publicado en cola antes de que quede instalable, y además ha sumado nuevos controles para limitar desde qué fuentes puede resolver dependencias npm install. Juntas, ambas novedades apuntan a un objetivo muy claro: endurecer la seguridad de la cadena de suministro en JavaScript sin romper el flujo moderno de CI/CD.

La noticia llega desde una publicación oficial de GitHub del 22 de mayo de 2026, y afecta directamente a cualquier equipo que publique paquetes npm o que quiera reducir la superficie de riesgo en sus instalaciones automatizadas. Si sigues la evolución de herramientas y plataformas para desarrolladores, en Aketdoy también analizamos hace poco cómo Google está cerrando el círculo entre hardware y tooling con Tensor SDK Beta, aunque aquí el foco es muy distinto: seguridad operativa real para el ecosistema JavaScript.

Qué es npm staged publishing

Hasta ahora, el flujo clásico era bastante directo: se ejecutaba npm publish y, salvo error, esa versión quedaba disponible de inmediato para quien quisiera instalarla. Con staged publishing, el paquete se sube primero a una cola de aprobación. Solo cuando un mantenedor humano valida la publicación, normalmente superando un reto de doble factor, esa versión pasa a estar accesible en el registro.

Según la documentación oficial de staged publishing en npm, este sistema busca reforzar la prueba de presencia humana incluso en pipelines no interactivos. Traducido: aunque tu publicación nazca desde CI/CD o desde Trusted Publishers con OIDC, sigue existiendo un punto final de validación manual antes de liberar el artefacto.

Eso puede sonar a fricción adicional, y lo es. Pero también es una respuesta bastante lógica al historial reciente de ataques a la cadena de suministro: robo de credenciales, publicación maliciosa desde sesiones automatizadas, dependencia excesiva de tokens de larga duración o errores humanos en pipelines que empujan código demasiado pronto.

Qué cambia con los nuevos flags de instalación

El anuncio no se queda en el momento de publicar. GitHub también añade en npm 11.15.0 tres nuevos flags para controlar fuentes no registradas en npm install: --allow-file, --allow-remote y --allow-directory. Se suman al ya conocido --allow-git y permiten endurecer desde qué orígenes aceptas dependencias.

La referencia oficial de npm install y sus nuevos controles de fuentes deja claro que cada opción puede configurarse como all o none. Esto da margen para políticas bastante útiles en entornos serios:

• bloquear instalaciones desde URLs remotas si tu organización solo admite paquetes del registro;
• evitar rutas locales o directorios ambiguos en builds automatizadas;
• cerrar el paso a dependencias Git ad hoc salvo cuando estén expresamente aprobadas.

No parece un cambio glamuroso, pero sí uno de esos que marcan la diferencia entre un entorno “cómodo” y un entorno realmente gobernado. También enlaza con una tendencia más amplia: las herramientas de desarrollo están empezando a asumir que la seguridad no puede quedarse solo en el escaneo posterior. Tiene que intervenir antes, durante y después del pipeline.

Por qué importa para equipos reales

Mi lectura es que este movimiento tiene valor en cuatro frentes bastante prácticos.

1. Reduce el impacto de una publicación comprometida

Si alguien compromete una credencial o un flujo automatizado, staged publishing añade una puerta más antes de que el paquete quede disponible para todo el mundo. No elimina el riesgo, pero sí recorta el radio de daño.

2. Hace más razonable el uso de OIDC y CI/CD

GitHub recomienda combinar staged publishing con configuraciones stage-only en Trusted Publishers. Esa combinación deja que la automatización haga su trabajo sin convertir la publicación final en un acto ciego. Para proyectos medianos o grandes, suena mucho más sensato que seguir dependiendo de un publish directo desde CI.

3. Lleva la seguridad a npm install, no solo a npm publish

Muchos problemas no llegan por lo que tú publicas, sino por lo que tu entorno acepta instalar. Limitar fuentes de dependencias puede parecer incómodo al principio, pero en entornos empresariales o repositorios con varias integraciones es una mejora muy defendible.

4. Prepara el terreno para npm 12

GitHub recuerda que --allow-git cambiará su valor por defecto de all a none en la próxima gran versión del CLI. Eso significa que lo anunciado ahora no es una rareza aislada: es parte de una dirección más estricta y más segura para npm.

Qué deberías revisar desde hoy

Si mantienes paquetes npm o te apoyas mucho en builds automáticas, yo revisaría al menos esto:

• si tus runners ya usan npm CLI 11.15.0 o superior;
• si tiene sentido migrar de npm publish a npm stage publish;
• si tus flujos con OIDC deberían quedarse en modo stage-only;
• si puedes endurecer desde hoy --allow-remote, --allow-file o --allow-directory en proyectos sensibles;
• si tu documentación interna describe ya un paso humano de validación.

Y un matiz importante: esto no va de pulsar una casilla y ya está. Si tu equipo no tiene claro quién aprueba, desde qué dispositivo, con qué tiempos o con qué criterio se bloquea una release, entonces la nueva función existe, pero el proceso sigue flojo.

Límites y matices

Tampoco conviene vender esto como una vacuna mágica. Staged publishing introduce una dependencia humana más y puede ralentizar ciertas releases urgentes. Además, los nuevos flags solo son tan buenos como la disciplina con la que los configures. Si todo se queda en all, la mejora práctica será limitada.

También hay que asumir que parte del ecosistema JavaScript vive de la flexibilidad extrema: repositorios que tiran de Git, builds que ensamblan paquetes locales y scripts que dependen de rutas poco limpias. Endurecer npm puede destapar deuda técnica y obligar a ordenar procesos. Personalmente, me parece una buena noticia, aunque no vaya a gustar a todo el mundo.

Fuentes oficiales

• GitHub Changelog — Staged publishing and new install-time controls for npm
• npm Docs — Staged publishing
• npm Docs — Trusted Publishers
• npm Docs — npm install allow flags
• GitHub Community — Discussion on staged publishing rollout

Conclusión

npm staged publishing no es la típica novedad decorativa del ecosistema JavaScript. Bien usado, introduce una capa de aprobación humana que encaja con lo que muchos equipos llevaban tiempo necesitando: una forma de publicar con automatización, sí, pero sin exposición instantánea y sin fe ciega en el pipeline. Sumado a los nuevos controles de instalación, el mensaje de fondo es claro: npm quiere que la seguridad deje de ser una recomendación y se convierta en una política operativa.

La parte menos cómoda es que esto obliga a madurar procesos. La parte buena es que precisamente por eso puede acabar siendo una de las mejoras más útiles del año para quienes viven entre dependencias, automatización y riesgos de supply chain.