GitHub Actions: revisa quién puede ejecutar tus workflows

GitHub Actions está añadiendo una capa de control sobre el inicio de los workflows. La disponibilidad general de las workflow execution protections se anunció el 17 de septiembre de 2026; no es un anuncio de hoy ni una sustitución de la revisión del YAML. La fecha operativa que conviene preparar es el 2 de noviembre de 2026, cuando se aplicará una regla predeterminada a determinados repositorios públicos.

Qué cambia y a quién afecta

Para repositorios públicos que no tengan una política de evento aplicable, GitHub aplicará por defecto el bloqueo de pull_request_target el 2 de noviembre. Esa regla no se extrapola automáticamente a repositorios privados o internos. La disponibilidad general de las protecciones sí cubre niveles enterprise, organización y repositorio, pero el alcance concreto depende del plan y de los permisos administrativos.

La función permite expresar tres dimensiones que conviene mantener separadas:

Dimensión	Pregunta	Ejemplos
Actor	¿Quién puede iniciar la ejecución?	usuario, equipo, GitHub App, Copilot, Dependabot o rol del repositorio
Evento	¿Qué puede iniciarla?	push, pull_request, pull_request_target, workflow_dispatch
Workflow	¿Qué archivo queda cubierto?	deploy.yml, publicación, mantenimiento o todos los workflows coincidentes

Una política puede limitar actores y eventos a la vez, y workflow_path permite no aplicar la misma regla a un workflow de pruebas que a uno de despliegue. La política de ejecución no revisa por sí sola las acciones de terceros, los permisos del token, los artefactos, las cachés, los secretos ni la seguridad del script.

Primero inventaría, después decide

Haz una búsqueda de solo lectura en la copia local del repositorio. El patrón incluye archivos .yml y .yaml y encuentra tanto una clave en bloque como una forma inline como on: [pull_request_target]:

rg -n --glob '*.yml' --glob '*.yaml' 'pull_request_target|workflow_run|workflow_dispatch' .github/workflows

Para cada coincidencia anota si el workflow hace checkout de una contribución, ejecuta scripts derivados de ella, lee secretos, publica paquetes, escribe en despliegues o usa un runner con acceso adicional. El comando es una búsqueda textual heurística de solo lectura, no un parser YAML universal: puede omitir o malinterpretar anclas, alias, expresiones, generación de workflows o la configuración efectiva. No activa workflows ni necesita un token; su salida no demuestra que una política vaya a permitir o bloquear una ejecución. Confirma siempre el contenido YAML y la configuración efectiva.

Revisa también los permisos declarados en permissions: y los del GITHUB_TOKEN, pero no los confundas con la autorización para iniciar el workflow. Un actor puede estar autorizado a contribuir y no a ejecutar un despliegue; un workflow puede arrancar y tener un token con permisos mínimos. Son controles distintos.

El caso delicado de pull_request_target

pull_request_target usa el contexto de la rama base y puede tener acceso a secretos del repositorio. El evento no es malicioso por definición: el riesgo aparece cuando código, acciones o comandos que un fork puede influir terminan ejecutándose con ese contexto privilegiado. El problema es la combinación de confianza, checkout, scripts y permisos, no el nombre del evento aislado.

Clasifica cada uso antes de escoger una política:

1. Si solo necesitas probar código aportado por un fork, diseña el workflow para que esa prueba no reciba secretos ni permisos de publicación y revisa qué checkout y qué comandos ejecuta.
2. Si necesitas el contexto base para una tarea confiable, separa la parte que decide o publica de cualquier código no confiable. No uses una allowlist de actores como sustituto de revisar el YAML.
3. Si el evento no es necesario, retíralo del diseño y comprueba que el reemplazo conserva el resultado esperado sin elevar el contexto de la contribución.

La decisión debe considerar también workflow_run: aunque el primer workflow no tenga secretos, el segundo puede recibirlos y consumir artefactos cuya procedencia necesita validación.

Evalúa el impacto sin activar enforcement

GitHub ofrece los estados disabled, evaluate y active. evaluate permite ver en Policy insights qué ejecuciones resultarían afectadas antes de aplicar el bloqueo, pero la documentación lo limita a GitHub Enterprise Cloud; no lo presentes como una función disponible en cualquier plan.

En Enterprise Cloud, el recorrido prudente es:

1. Seleccionar el enterprise, organización o repositorio correcto y acotar los workflows con sus rutas reales.
2. Separar una regla de actores de una regla de eventos para saber qué decisión provoca cada coincidencia.
3. Observar Policy insights en evaluate y clasificar ejecuciones esperadas, no solo contar fallos.
4. Revisar especialmente los repositorios públicos que llegarán al 2 de noviembre sin una política de evento aplicable.
5. Elegir active solo después de que los propietarios responsables acepten las excepciones y el plan de recuperación.

Si el plan no ofrece evaluate, conserva el inventario de solo lectura y realiza la revisión documental. Si necesitas una prueba operativa, usa un repositorio de laboratorio separado, sin secretos ni acceso productivo, con permisos mínimos, runner aislado y autorización administrativa; no lo presentes como una evaluación del repositorio real. Una rama o copia dentro del mismo repositorio no aísla una política aplicada a nivel de repositorio, organización o enterprise. No simules que una política fue evaluada si no existe una salida de Insights.

Políticas heredadas y alcance efectivo

Las políticas pueden definirse en enterprise, organización y repositorio, y esos niveles se acumulan. Una restricción superior sigue afectando al repositorio; las reglas no se vuelven menos restrictivas por añadir una política local, así que la decisión efectiva es la combinación más restrictiva. Una política del repositorio no sustituye ni anula una condición heredada de la organización o del enterprise.

Al auditar por REST, has_parents=true incluye las políticas heredadas aplicables. En el listado de una organización, incorpora las de niveles superiores; en el listado de un repositorio, incluye las configuradas en organización o enterprise. Es el valor predeterminado documentado, pero conviene dejarlo explícito en una auditoría y anotar el nivel de cada resultado.

Política mínima con alcance claro

Una política inicial suele ser más comprensible si se expresa como una tabla antes de configurarla:

Workflow	Actores	Eventos	¿Qué revisar?
deploy.yml	equipo de release y automatización aprobada	workflow_dispatch	entornos, permisos y secretos
pruebas de pull request	colaboradores según el modelo del proyecto	pull_request	checkout y acciones de terceros
mantenimiento	bot o equipo de plataforma	schedule, workflow_dispatch	identidad del bot y alcance del token

Los nombres son ilustrativos: usa rutas que existan realmente en el repositorio. El endpoint REST de Actions policies permite consultar y administrar políticas a nivel de enterprise, organización o repositorio, incluir workflow_path y distinguir reglas de actores de reglas de eventos. La documentación del listado de organización acepta tokens de usuario o instalación de GitHub App y fine-grained PAT con permiso Administration de organización (write); el listado de repositorio requiere esos mismos tipos de token con Administration de repositorio (write). Incluso esos GET documentados exigen el permiso write del nivel consultado, por lo que lectura no significa acceso sin privilegios ni se puede extrapolar a todos los endpoints de enterprise. Crear, actualizar o borrar políticas además cambia el comportamiento de CI, requiere autoridad administrativa y no forma parte de esta guía.

Decisión antes del 2 de noviembre

Hallazgo	Próximo paso	No concluyas
Repositorio público con pull_request_target y sin política de evento	revisar Insights o el procedimiento disponible y decidir antes de la fecha	que todo repositorio recibirá el mismo bloqueo
Workflow sensible con demasiados actores	limitar actores y separar el despliegue de las pruebas	que ocultar el botón elimina la autorización implícita
Monorepo con workflows de riesgo desigual	usar workflow_path para acotar	que una política global es necesaria
Evento permitido, pero YAML ejecuta código de fork	revisar checkout, acciones, scripts, secretos y token	que la allowlist demuestra seguridad del workflow
Equipo fuera de Enterprise Cloud	documentar el alcance real del plan y probar de forma controlada	que evaluate está disponible en otro plan

Las protecciones de ejecución reducen una clase concreta de inicios no deseados. Funcionan junto con revisión de código, permisos mínimos, runners aislados y manejo de secretos. No garantizan una cadena de suministro segura por sí solas, y este artículo no activa políticas ni afirma que una ejecución haya sido probada.

Fuentes oficiales

• Workflow execution protections in GitHub Actions generally available — GitHub Changelog
• About Actions policies — GitHub Docs
• Controlling who can execute GitHub Actions workflows — GitHub Docs
• Securely using pull_request_target — GitHub Docs
• REST API endpoints for GitHub Actions policies — GitHub Docs