01 · Contexto
Qué está ocurriendo
GitHub anunció el 17 de septiembre la disponibilidad general de workflow execution protections para empresas, organizaciones y repositorios. Las reglas combinan identidad del actor y tipo de evento para decidir si un workflow puede ejecutarse.
Las políticas pueden apuntar a archivos específicos, como un workflow de despliegue, y operar inicialmente en evaluate mode. La vista Insights muestra qué regla habría permitido o bloqueado cada ejecución, lo que facilita probar el efecto antes de aplicar una denegación.
Una API REST permite crear, consultar, actualizar y eliminar reglas para tratarlas como política versionada. Esto resulta especialmente útil cuando varias organizaciones deben compartir una línea base y conservar excepciones trazables.
En repositorios públicos, GitHub incorpora una regla predeterminada que deshabilita pull_request_target cuando no existe una política de eventos aplicable. Comienza en evaluación y GitHub prevé activar su aplicación automática el 2 de noviembre para repositorios afectados que dependían de la política anterior.
02 · Impacto
Por qué importa
pull_request_target puede ejecutarse en el contexto del repositorio base y acceder a secretos; si además procesa código controlado desde un fork, una contribución externa puede convertir el pipeline en vía de exfiltración. Las nuevas protecciones desplazan el control desde convenciones dispersas hacia decisiones explícitas, pero una allowlist demasiado amplia o una regla sin propietario conserva el mismo riesgo bajo una apariencia más formal.
03 · Recomendaciones
Qué conviene hacer
- Inventariar workflows que usan pull_request_target, workflow_run, secretos, tokens de escritura, runners propios o despliegues; clasificar cada uno por efecto y procedencia del código.
- Crear una política mínima para actores y eventos confiables, aplicarla primero en evaluate mode y revisar falsos bloqueos y ejecuciones inesperadas en Insights.
- Dirigir reglas más estrictas a workflows de publicación y producción, reducir permisos de GITHUB_TOKEN y evitar ejecutar código de forks en contextos con secretos.
- Gestionar reglas por API desde un repositorio controlado, con revisión, pruebas, propietario, caducidad de excepciones y evidencia periódica de que la política sigue aplicándose.