GitHub Actions permite a los flujos de trabajo obtener identificadores de máquina mediante tokens OpenID Connect (OIDC), exactamente el mismo mecanismo sobre el que se apoyan sistemas como Trusted Publishing de PyPI o Sigstore para autenticar integraciones con servicios externos sin necesidad de gestionar claves estáticas. Sin embargo, la forma en que GitHub expone esos tokens presenta un flanco débil: con el permiso id-token: write, un trabajo puede solicitar en tiempo de ejecución un token para cualquier audiencia que desee, no solo la prevista por el autor del workflow.
Esta capacidad resulta crítica porque los trabajos con id-token: write suelen ejecutar también código de terceros. Una vulnerabilidad o un paquete malicioso en ese código puede pedir un token dirigido a otro servicio —por ejemplo, un token para AWS cuando el job estaba pensado solo para publicar en PyPI— y usarlo como pivote hacia recursos no autorizados.
La propuesta es añadir una restricción sintáctica sencilla, al estilo del bloque que ya usa GitLab CI/CD: declarar la audiencia (o audiencias) permitidas en el propio manifiesto del trabajo, con algo como id-token: [pypi]. Así, si el job intenta pedir un token para otra audiencia, la operación falla. El cambio es pequeño en la superficie para el usuario, aunque podría requerir ajustes no triviales en el backend de GitHub.
El autor también discute el caso de Trusted Publishing, que mitiga parte del problema incluyendo el nombre del workflow en la identidad, una solución demasiado rígida para muchas integraciones que se conforman con validar el repositorio. La audiencia estática, en cambio, es una defensa en profundidad fácil de aplicar y compatible con casi todos los casos de uso actuales.