Un agente de código abre una pull request y GitHub Actions ejecuta la prueba. El workflow falla y el log muestra, por error, una clave de una API externa que el agente añadió a un comando de depuración. Es un caso hipotético, pero la decisión es real: si alguien pudo leer ese log, borrar el texto no devuelve la seguridad de la clave. Hay que invalidarla y comprobar qué acceso tenía.
GitHub anunció el 9 de noviembre de 2026 una vista previa de secret scanning en logs de GitHub Actions. Puede ayudar a detectar algunas fugas, pero su alcance es estrecho: está dirigida a organizaciones de GitHub Enterprise Cloud con GitHub Secret Protection o Advanced Security, requiere que un propietario la active y examina logs nuevos una vez terminada la ejecución. No es una alerta instantánea disponible para cualquier repositorio. Esta guía funciona incluso si tu cuenta no tiene esa función.
Los primeros 15 minutos
1. Revoca y reemplaza la clave en el proveedor. Si es una API de IA, abre la consola del proveedor, crea una credencial nueva cuando sea necesario y revoca la expuesta. Anota el identificador de la clave, la hora aproximada, el repositorio y la ejecución sin copiar el secreto a otro documento. Si la credencial da acceso a dinero, datos de clientes o despliegues, trata la exposición como incidente y avisa al responsable de esa cuenta. La guía de GitHub sobre secretos expuestos recomienda rotar o revocar de inmediato; un secreto enmascarado después tampoco deshace una lectura anterior.
2. Retira el log accesible. Conserva primero la evidencia mínima que tu proceso de incidentes necesite, sin reproducir la clave en tickets públicos. GitHub permite eliminar los logs de una ejecución mediante la API de Actions con permisos adecuados. Si no administras el repositorio, pide al propietario que lo haga. Comprueba también si el valor terminó en comentarios de PR, artefactos, cachés o capturas. Borrar el log reduce exposición futura; no invalida la credencial ni garantiza que nadie la haya copiado.
3. Audita el uso y el alcance. Revisa en el proveedor llamadas, cargos, direcciones o ubicaciones de acceso y cambios durante la ventana de exposición. En GitHub, identifica quién podía ver la ejecución y cuándo se creó el log. Comprueba si la clave tenía permisos de lectura, escritura o administración y si alcanzaba producción. La documentación de investigación de incidentes de GitHub incluye workflows, logs y credenciales entre las áreas a examinar. Ausencia de una alerta no equivale a ausencia de uso.
4. Corrige el workflow y vuelve a probar. Busca el comando que imprimió la variable, el modo de depuración, el `echo` o la salida de un proceso que incluyó encabezados HTTP. Sustituye el valor en cualquier archivo comprometido y guarda la nueva credencial como secreto del entorno correspondiente. GitHub documenta los secrets de Actions y recomienda pasar valores sensibles por entradas seguras; su enmascaramiento es una protección secundaria, no una licencia para imprimirlos. En servicios compatibles, usa OIDC para obtener credenciales de corta vida y limita permisos por trabajo. Ejecuta una prueba sin credenciales reales y revisa los logs antes de restaurar el flujo.
Qué cambia con el anuncio de GitHub
Para una organización elegible, el propietario puede activar la vista previa y revisar hallazgos de patrones de proveedores admitidos en el panel de seguridad. Según el anuncio, solo procesa logs nuevos y completados, no analiza el historial, no cubre todos los secretos genéricos y todavía no envía notificaciones de alerta. Un hallazgo puede permanecer aunque se borre el log, precisamente para preservar el rastro de respuesta. Por eso conviene comprobar el panel después de la ejecución, sin depender de él como único detector.
Si un agente de IA modifica tus workflows, exige revisión humana de cambios en `.github/workflows/`, permisos de `GITHUB_TOKEN`, pasos de depuración y servicios externos antes de fusionar. El agente puede ayudar a localizar el comando que filtró el valor, pero no debe recibir la clave expuesta de nuevo en el prompt. Usa una cadena ficticia en la reproducción y un test que confirme que los logs no contienen secretos.
Límites de esta guía
No ocurrió aquí un incidente de SoyJB ni ejecuté la vista previa de GitHub en una cuenta Enterprise. El plazo de 15 minutos es una secuencia de actuación, no una garantía de contención. Si la clave tenía privilegios amplios o pudo acceder a datos personales, tu equipo necesitará investigación y comunicación adicional. La prueba de hoy es simple: toma un workflow de prueba, introduce un marcador falso como `EXAMPLE_KEY_DO_NOT_USE`, verifica qué registra y elimina ese marcador. Nunca pongas una clave real para comprobar si secret scanning la detecta.
Fuentes
GitHub Changelog, 9 de noviembre de 2026; GitHub Docs: alcance de secret scanning; GitHub Docs: uso seguro de Actions; GitHub REST API: logs de ejecuciones. Revisado el 10 de noviembre de 2026.