El 9 de noviembre de 2026, GitHub anunció una vista previa pública que detecta secretos dentro de los registros de ejecución de GitHub Actions. Hasta ahora, el secret scanning cubría el código fuente y algunos otros lugares, pero dejaba fuera los registros generados por los propios workflows, un vector de fuga habitual cuando un paso de compilación muestra por error un valor sensible.
Por qué importaba este punto ciego
Un workflow de CI/CD maneja constantemente tokens, claves de API y credenciales de despliegue. Un comando de depuración olvidado, una instrucción de impresión que no se eliminó o un error mal gestionado bastan para exponer esos valores en un registro público o compartido, sin que ninguna de las herramientas de escaneo habituales los detecte, ya que nunca se incorporaron al repositorio.
Cómo funciona la función
Una vez activada, GitHub analiza los registros de cada ejecución al finalizar; las ejecuciones pasadas no se reanalizan de forma retroactiva. Los secretos detectados aparecen en la lista de alertas de secret scanning del repositorio, junto a las alertas procedentes del código, con un enlace directo a la ubicación en el registro. Se aplican comprobaciones de validez a los tipos de secretos que lo permiten, y las alertas siguen disponibles incluso después de eliminar los registros correspondientes.
| Aspecto | Detalle |
|---|---|
| Estado por defecto | Desactivado |
| Quién lo activa | Los propietarios de la empresa, a nivel de organización |
| Tipos de secretos cubiertos | Solo patrones de proveedores reconocidos |
| No cubiertos | Patrones genéricos, patrones personalizados, secretos detectados por IA, valores ya enmascarados por Actions |
| Notificaciones | Ninguna durante la vista previa |
| Disponibilidad | GitHub Enterprise Cloud con Secret Protection o Advanced Security, incluido GHE.com |
Cómo activarla
La opción se encuentra a nivel de empresa, en Policies, luego Advanced Security, donde hay que poner Secret scanning for Actions workflow logs en Enabled para los repositorios correspondientes. La función solo se aplica a los repositorios que ya tienen activado el secret scanning estándar.
name: build
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
run: |
# un comando de depuracion que filtrara esta variable
# ahora tambien terminaria en la lista de alertas
./build.shLos registros ya existentes no se reanalizan de forma retroactiva: solo quedan cubiertas las ejecuciones que finalizan después de activar la función.
Los límites de esta vista previa
La cobertura sigue siendo parcial: solo se detectan patrones de proveedores conocidos, quedando fuera los patrones genéricos o personalizados y los secretos identificados por métodos heurísticos. La ausencia de notificaciones durante la fase de vista previa obliga también a consultar manualmente la lista de alertas del repositorio en lugar de confiar en un aviso automático. La disciplina de fondo es la misma que ya se trató cuando GitHub empezó a bloquear pull_request_target por defecto: activar una salvaguarda con antelación importa más que reaccionar tras un incidente.
Lo que hay que recordar
Esta ampliación cierra un punto ciego conocido para los equipos que operan pipelines de GitHub Actions, sin sustituir las buenas prácticas básicas: enmascarar sistemáticamente los secretos, rotarlos con regularidad y limitar el alcance de los tokens usados en CI/CD. Se suma a otros cambios recientes de la plataforma orientados a reducir la superficie de ataque de los workflows.
Este tipo de función suele llegar después de una serie de incidentes documentados, y este no es la excepción: las fugas de secretos a través de los registros de ejecución son un hallazgo clásico en las auditorías de seguridad de CI/CD. Lo más revelador no es la herramienta en sí, sino su estado desactivado por defecto, que dice mucho sobre la prudencia que todavía exige una función que va a leer el historial completo de registros de una organización — Simon Janvier.
Para profundizar
Fuente primaria: el changelog oficial de GitHub, 9 de noviembre de 2026.
