GitHub buscará secretos en los logs de tus workflows

El problema no está solo en el repositorio

Un secreto no tiene por qué acabar en un git commit para convertirse en un incidente. Basta con que un comando de despliegue, una traza de Laravel o una herramienta de infraestructura imprima una variable de entorno en la salida del workflow. Es especialmente fácil que ocurra al depurar un fallo de php artisan, Composer, SSH, Docker o una integración con un proveedor cloud.

GitHub ha añadido una detección de secretos en los logs de GitHub Actions. El análisis se ejecuta cuando termina un nuevo workflow y las incidencias aparecen en la lista de alertas de Secret Scanning del repositorio. Desde esa alerta se puede llegar al archivo del workflow y a la línea concreta del log en la que se imprimió el valor. (docs.github.com)

Para quien ejecuta runners propios en el homelab, esto es relevante por una razón sencilla: el control se aplica al log almacenado por GitHub Actions, no al sistema operativo donde vive el runner. Si el workflow de Laravel se ejecuta en una máquina propia, pero sus logs llegan a GitHub, una credencial expuesta puede acabar como alerta de seguridad igual que una filtración en código.

Hay que activarlo desde la empresa

No es una capacidad que aparezca activada en cada repositorio. Un propietario de la empresa debe ir a Policies, abrir Advanced Security y, en Secret scanning for Actions workflow logs, activar la opción Enabled para All repositories. Además, Secret Scanning tiene que estar habilitado en cada repositorio que se quiera cubrir. (docs.github.com)

En repositorios privados e internos, Secret Scanning forma parte de GitHub Secret Protection. Conviene revisar primero qué repositorios tienen la protección habilitada y quién puede modificar esa configuración. Activar el análisis de logs sin revisar ese punto puede dar una falsa sensación de cobertura.

Evitar que el secreto llegue al log sigue siendo la primera defensa

La detección posterior no sustituye a una configuración prudente del workflow. GitHub permite registrar un valor para que se enmascare en el log con el comando add-mask; debe hacerse antes de que el valor pueda aparecer en la salida. Esto resulta útil, por ejemplo, cuando un script genera una credencial temporal durante un despliegue. (docs.github.com)

- name: Preparar credencial temporal
  shell: bash
  run: |
    DEPLOY_TOKEN="$(./scripts/create-deploy-token)"
    echo "::add-mask::$DEPLOY_TOKEN"
    ./scripts/deploy.sh "$DEPLOY_TOKEN"

No usaría este patrón para transportar secretos entre jobs. El enmascarado se aplica por job y, una vez marcado, el valor no se puede usar como output. Si un pipeline necesita compartir una credencial temporal, es mejor recuperarla desde un almacén de secretos en el job que la necesita.

La letra pequeña importa

Durante la vista previa, el análisis de logs solo detecta patrones de proveedores. No cubre patrones genéricos, patrones personalizados, secretos detectados por IA ni valores que Actions ya haya enmascarado. Eso significa que una contraseña interna, una cadena de conexión propia o un token con formato casero pueden seguir pasando desapercibidos aunque Secret Scanning detecte otros proveedores. (docs.github.com)

Tampoco hay análisis retroactivo: los logs de ejecuciones anteriores a la activación no se revisan. Y las alertas procedentes de logs no generan notificaciones durante esta fase, así que hay que consultar la lista de alertas de Secret Scanning de forma activa. No lo trataría como un sistema de monitorización en tiempo real ni como excusa para imprimir variables durante una depuración. (docs.github.com)

Qué cambia en la respuesta a incidentes

Cuando aparezca una alerta, mi primera acción no sería borrar el log ni reejecutar el job. La credencial debe considerarse expuesta y hay que rotarla o revocarla cuanto antes; después toca localizar qué comando la imprimió y corregir el workflow. GitHub también recomienda priorizar la rotación de la credencial afectada ante una filtración. (docs.github.com)

Para proyectos Laravel, revisaría especialmente comandos de despliegue, generación de .env, acceso a bases de datos, tokens de Forge o servicios equivalentes, claves SSH y credenciales de contenedores. La regla práctica es simple: si una variable sirve para autenticarse, nunca debería formar parte de una salida pensada para humanos.

Fuente: GitHub Changelog

Documentación oficial: Secret scanning