npm permite desde el 30 de septiembre que las configuraciones de trusted publishing gestionen dist-tags mediante credenciales OIDC de corta duración. Esto permite promover una versión a latest o actualizar etiquetas como next y beta sin conservar un token de acceso de larga duración únicamente para esa operación, según el changelog oficial de GitHub.
El permiso llega desactivado por defecto
Cada configuración de trusted publishing incorpora ahora la opción Allow npm dist-tag. Tanto las configuraciones nuevas como las existentes la reciben desactivada, de modo que ninguna automatización obtiene capacidad adicional sin una decisión explícita del mantenedor.
El permiso es independiente de la publicación directa. Una configuración utilizada solo para staging también puede recibir autorización para gestionar dist-tags si el equipo lo necesita.
Por qué reduce la exposición de secretos
Trusted publishing utiliza tokens OIDC de vida corta emitidos para un flujo concreto. Hasta ahora, una organización que hubiera eliminado tokens permanentes para publicar paquetes podía seguir necesitando uno únicamente para modificar dist-tags después de una release o de un rollback.
Con la nueva opción, ese último paso también puede ejecutarse con credenciales efímeras. Reducir secretos persistentes limita el impacto de una filtración en un repositorio, un runner o un sistema de CI.
Qué debe cambiar una empresa
Los mantenedores deben entrar en la configuración de trusted publishing del paquete y activar Allow npm dist-tag solo en los workflows que realmente lo requieran. GitHub mantiene sin cambios el método basado en tokens tradicionales, por lo que no existe una migración obligatoria inmediata.
Conviene separar permisos de publicación, staging y promoción de versiones. Un workflow que solo construye o valida paquetes no necesita capacidad para mover la etiqueta latest.
Qué revisar antes de retirar el token antiguo
Antes de eliminar un token de acceso de los secretos del repositorio, el equipo debería ejecutar una release de prueba, confirmar que OIDC identifica la configuración correcta y verificar que las operaciones de rollback siguen funcionando. Después, el token antiguo puede revocarse y eliminarse de los sistemas de CI donde permanezca almacenado.
Para reforzar la misma cadena de desarrollo pueden revisarse también la actualización de GitHub CodeQL, el proof of presence, las métricas de revisión, las propiedades externas de repositorios, el parche crítico de GitLab y la adopción de passkeys empresariales.
La mejora es especialmente relevante para cadenas de publicación que separan creación y promoción de versiones. Un paquete puede publicarse como prerelease y mover después next o beta sin exponer una credencial permanente. Eso permite reducir el número de secretos almacenados y acotar mejor qué workflow puede modificar cada etiqueta.
Fotografía: Alicia Christin Gerald / Pexels.
