Staged publishing en npm: la aprobación con 2FA que frena la publicación automática y protege la cadena de suministro

GitHub ha activado una nueva herramienta en npm llamada staged publishing que exige la aprobación manual de un mantenedor (mediante desafío de doble factor) antes de que una versión publicada sea visible y descargable desde npmjs.com. En la práctica, el tarball preconstruido ya no se hace público al instante: se sube a una cola de staging y requiere que una persona con acceso de publicación y 2FA confirme su liberación. Esta pequeña pero significativa modificación busca añadir prueba de presencia humana a cada publicación, incluso para artefactos generados por CI/CD.

El mecanismo cambia el modelo tradicional en el que una pipeline podía publicar automáticamente una versión en cuanto finalizaba: ahora la pipeline puede subir el paquete con el comando "npm stage publish" (disponible a partir de npm CLI 11.15.0), pero la versión no será instalable hasta que un mantenedor supere el reto 2FA. Esto mitiga escenarios en los que credenciales comprometidas o workflows mal configurados permiten la publicación automatizada de artefactos maliciosos, porque exige una interacción humana autenticada antes del push final.

Es importante entender sus límites: no puede aplicarse a paquetes nuevos que aún no existan en el registro, requiere que la cuenta del mantenedor tenga 2FA activado y que los equipos actualicen su cliente npm a 11.15.0 o superior. Además, el control solo eleva la dificultad para ataques automatizados; no impide que un atacante que supere la 2FA del mantenedor (por phishing o acceso a tokens) publique código malicioso. Por eso GitHub recomienda combinar staged publishing con trusted publishing mediante OIDC, que reduce la dependencia de tokens de larga duración en CI y mejora la trazabilidad de la identidad de la pipeline.

En paralelo, npm ha añadido tres banderas para controlar orígenes de instalación no-registro: --allow-file, --allow-remote y --allow-directory, junto a la ya existente --allow-git. Estas opciones permiten aplicar una estrategia de lista de permitidos más estricta para instalaciones desde archivos locales, URLs remotas o directorios: controles que son útiles para evitar inyecciones de tarballs maliciosos o la instalación accidental de dependencias de orígenes no verificados desde scripts o pruebas locales.

Para equipos y mantenedores la recomendación práctica inmediata es clara: activa 2FA en todas las cuentas con permisos de publicación, actualiza el npm CLI a 11.15.0+, y habilita staged publishing para paquetes críticos. A nivel organizacional, adopta OIDC para tus runners CI/CD y elimina tokens de larga duración; limita los scopes de los tokens supervivientes; registra y alerta sobre actividades de publicación inusuales; y usa firmas o mecanismos de verificación adicionales para artefactos cuando sea posible. Complementa esto con análisis de composición de software (SCA), revisiones de cambios obligatorias y generación de SBOMs para cada build.

No olvides reforzar las políticas de instalación en entornos de desarrollo y producción: considera negar por defecto las instalaciones desde URLs o archivos y permitir explícitamente solo lo necesario mediante las nuevas banderas, y educa a los desarrolladores sobre riesgos de instalar paquetes desde fuentes externas. Estas medidas reducen la superficie por la que campañas de "poisoning" masivo —como las atribuidas recientemente a grupos que manipulan paquetes populares— consiguen propagarse.

Staged publishing no es una panacea, pero representa un avance valioso en la defensa del ecosistema open source: introduce un punto de control humano que complica los ataques automatizados y mejora la trazabilidad de publicaciones. Para profundizar en prácticas de seguridad de la cadena de suministro de software y recomendaciones complementarias consulte la documentación oficial de npm en https://docs.npmjs.com/ y recursos sobre seguridad de la cadena de suministro como el proyecto OWASP en https://owasp.org/www-project-supply-chain-security/. También resulta útil seguir el blog de GitHub para actualizaciones y guías prácticas en este ámbito: https://github.blog/.