01 · Contexto
Qué está ocurriendo
GitHub publicó el 3 de septiembre tres cambios orientados a control operacional. La nueva API GET /actions/runners/deprecations/{version} entrega las fechas en que una versión de runner dejará de aceptar registros y de ejecutar jobs, permitiendo administrar la obsolescencia como dato verificable.
El GITHUB_TOKEN incorpora el permiso vulnerability-alerts con valores read y none. Un workflow puede consultar alertas de Dependabot sin recibir alcances más amplios, reforzando el principio de mínimo privilegio para automatizaciones de seguridad.
Los jobs definidos mediante workflows reutilizables ahora exponen job.workflow_ref, job.workflow_sha, job.workflow_repository y job.workflow_file_path. A diferencia de las propiedades github.workflow_ref y github.workflow_sha, estos valores representan el archivo que realmente define el job. Las nuevas propiedades todavía no están disponibles en GitHub Enterprise Server.
02 · Impacto
Por qué importa
Los cambios mejoran dos puntos débiles habituales de DevSecOps: runners olvidados y pérdida de procedencia en automatizaciones compartidas. Capturar la identidad exacta del workflow ejecutado facilita auditoría, respuesta a incidentes y validación de supply chain. El nuevo permiso también reduce la necesidad de entregar tokens sobredimensionados a jobs que solo agregan información de vulnerabilidades.
03 · Recomendaciones
Qué conviene hacer
- Integrar la API de deprecaciones en el inventario de runners y generar avisos antes del fin de registro y ejecución.
- Declarar permisos explícitos por workflow y job, usando vulnerability-alerts: read únicamente en procesos que consultan Dependabot.
- Incluir las cuatro propiedades job.workflow_* en logs, attestations o evidencias de release para identificar código reutilizable y versión ejecutada.
- Mantener una compensación documentada en GHES hasta disponer de las propiedades nuevas, fijando referencias y registrando manualmente repositorio, ruta y SHA.