Vincular la identidad de publicación en npm y PyPI con los artefactos aprobados de cada versión

Qué es

Estado al 25 de octubre de 2026. La publicación de confianza intercambia la identidad de CI por credenciales temporales del registro, en lugar de almacenar un token de publicación permanente. Antes de cambiar un flujo de publicación, volver a consultar los proveedores admitidos por los registros, las restricciones de los ejecutores y los requisitos de configuración. La documentación citada es una referencia que se actualiza continuamente y que se consultó para esta revisión, no un aviso de incidente fechado.

Para npm, los requisitos previos documentados son npm CLI 11.5.1 o posterior y Node 22.14.0 o posterior. Este artículo se centra en los flujos de GitHub Actions que publican paquetes de npm o distribuciones de Python en PyPI.

Por qué importa

El modelo de seguridad de PyPI deja explícitamente la responsabilidad sobre la integridad del flujo de trabajo en manos de quien publica. Las credenciales temporales siguen siendo sensibles, y un flujo de trabajo autorizado que haya sido comprometido puede obtenerlas. Eliminar los tokens almacenados reduce la exposición de las credenciales, pero no hace segura la ejecución de dependencias.

La documentación de npm sobre procedencia distingue entre un vínculo verificable con el código fuente y las instrucciones de compilación, y una garantía de que el código sea inocuo. La conclusión operativa es directa: un proceso automatizado autorizado puede certificar un artefacto malicioso. La aprobación debe evaluar los componentes de entrada y el resultado de la publicación, además de la identidad que lo firma.

Cómo aplicarlo

• Registrar con precisión el propietario, el repositorio y el flujo de publicación previstos. En la configuración de GitHub para npm, introducir el nombre del archivo del flujo de trabajo y vincular el nombre opcional del entorno al entorno protegido de publicación. Comprobar que la identidad configurada coincide con el trabajo real antes de retirar el método de autenticación anterior.
• Seguir el patrón de separación de PyPI: un trabajo de compilación crea las distribuciones; un trabajo de publicación reducido las recupera y las carga. Conceder permissions: {id-token: write} solo al trabajo que necesite OIDC. Mantener la instalación de dependencias, las pruebas y los cambios no confiables fuera del ámbito de los permisos de ese trabajo.
• Configurar revisores del entorno, impedir la autoaprobación, restringir las ramas o etiquetas de publicación y desactivar la posibilidad de que los administradores omitan las protecciones cuando esté disponible. Verificar la disponibilidad de estas funciones para el repositorio y el plan. De forma predeterminada, GitHub permite que los administradores eludan la protección del entorno; no basta con asignar un nombre a un entorno.
• Hacer que la aprobación sea específica: anotar la revisión del código fuente, la ejecución de compilación y el resumen criptográfico del artefacto en el registro de la publicación; después, publicar exactamente los bytes revisados. Contrastar la identidad y la información del código fuente de la certificación con ese registro. Investigar las discrepancias en lugar de dejar que una insignia de procedencia determine la decisión de publicar.
• Revisar el código de los flujos de trabajo y las acciones de terceros. Conceder a los tokens del repositorio los permisos mínimos y fijar las acciones a identificadores completos de commits revisados. Nunca imprimir credenciales ni volcar las variables del entorno para depurar. GitHub advierte de que el ocultamiento automático en los registros puede fallar, incluso cuando se transforman los valores; inspeccionar también los registros de las rutas de error, además de los de las ejecuciones correctas.
• Tras la migración, eliminar los tokens de publicación que no se utilicen y auditar los registros de publicadores de confianza. En PyPI, estos registros pertenecen a los proyectos y permanecen después de retirar a la persona que los creó. Incluirlos explícitamente en el proceso de baja de los mantenedores.

Trampas

Un control de aprobación no compensa una cuenta de aprobador comprometida ni cambios sin revisar en el propio control. Una cache de compilación reutilizable y un ejecutor persistente necesitan su propia evaluación de confianza. Registrar las comprobaciones fallidas de identidad o de artefactos como fallos de publicación; recurrir silenciosamente a un token de escritura almacenado debilita el control previsto.