Respuesta a incidentes

Hiciste commit de una clave API, contraseña o llave privada. Eliminarla del último commit no es suficiente — Git mantiene el archivo en cada commit anterior hasta que reescribas la historia. Esta página recorre la respuesta completa al incidente.

Paso 1: rotar inmediatamente

Antes de tocar el repo, revoca la credencial. Asume que cualquier historia subida ya ha sido replicada, raspada o cacheada por el programa de archivo de GitHub. Rotar es la única solución verdadera; reescribir solo ralentiza a los atacantes.

Paso 2: reescribir la historia con filter-repo

git clone --mirror [email protected]:org/repo.git repo-mirror
cd repo-mirror
git filter-repo --path config/secrets.yml --invert-paths

Para eliminación basada en patrones a través de muchos archivos:

cat > replace.txt <<'EOF'
regex:AKIA[0-9A-Z]{16}==>REDACTED
literal:hunter2==>REDACTED
EOF
git filter-repo --replace-text replace.txt

Paso 3: force-push

git push --force --all
git push --force --tags

Coordina con los colaboradores: cada clone que tienen contiene el secreto. Deben re-clonar o hacer rebase.

Paso 4: podar objetos locales

git reflog expire --expire=now --all
git gc --prune=now --aggressive

Detectar secretos pronto

Instala un hook pre-commit que escanee el contenido staged con gitleaks o trufflehog:

#!/usr/bin/env bash
gitleaks protect --staged --redact || exit 1

Errores comunes

Creer que un force-push es suficiente — los caches, forks, mirrors y clones del equipo aún tienen los datos. Saltarse la rotación. Usar git filter-branch, que está obsoleto y es lento. Olvidar los tags: los secretos a menudo viven también en releases tageadas.

Auditoría

git log -p --all -S "AKIA"
git grep "hunter2" $(git rev-list --all)