Secret scanning: el token que se te escapó al repo
Tarde o temprano alguien commitea una API key. Aprendé a detectarla con escaneo automático, a frenarla antes del commit y qué hacer cuando ya se filtró.
Antes de empezar necesitás
- Saber hacer un commit con git
- Una terminal en Linux, macOS o WSL
Al terminar vas a poder
- Entender por qué borrar el secreto en un commit nuevo no alcanza
- Correr un escaneo de secretos sobre un repo
- Frenar un secreto antes del commit con un hook
- Saber el orden correcto de respuesta cuando una credencial se filtra
Le pasa a todos: una API key hardcodeada “para probar”, un .env que se coló, un token en un script de deploy. Lo commiteás, lo pusheás, y ya está afuera. El problema no es solo que esté en el archivo de hoy: es que git tiene memoria.
Por qué .gitignore no te salva después
.gitignore evita que un archivo entre al repo. No saca nada de lo que ya entró. Si commiteaste .env y después lo agregás al .gitignore, el archivo deja de trackearse de ahí en más, pero el commit donde lo subiste sigue conteniéndolo.
# ¿Quedó alguna key de AWS en TODA la historia, no solo en el último commit?
git log -p -S "AKIA" -- . | grep -i "AKIA"-S "AKIA" busca commits donde aparezca o desaparezca ese texto. Es la diferencia entre mirar el presente y auditar el pasado.
Detección automática: un escáner
Revisar a mano no escala. Una herramienta de secret scanning (como gitleaks) recorre todo el repo y su historia buscando patrones de credenciales: keys de AWS, tokens, claves privadas.
gitleaks detect --source . --verboseUna detección se ve, más o menos, así (datos sintéticos):
Finding: AKIAEXAMPLE0000000000
Secret: AKIAEXAMPLE0000000000
RuleID: aws-access-key-id
File: deploy/setup.sh
Commit: 3f9a1c2 (hace 4 días)
Author: deploy-bot <bot@example.com>Frenarlo antes de que pase: pre-commit hook
Mejor que detectarlo después es no dejarlo entrar. Un hook de pre-commit corre el escáner antes de cada commit y lo aborta si encuentra algo.
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks$ git commit -m "agrego deploy"
gitleaks……………… Failed
✗ AKIAEXAMPLE0000000000 en deploy/setup.sh
commit abortado: sacá el secreto antes de continuarYa se filtró: el orden importa
Si un secreto real llegó a un repo (sobre todo público), hay un orden que no se negocia:
1. ROTAR primero. Generá una credencial nueva y revocá la vieja YA.
Mientras la vieja sirva, el repo limpio no importa.
2. Recién después, limpiá la historia (o, muchas veces, archivá el repo
y arrancá uno limpio: reescribir historia es traicionero).
3. Investigá. ¿Se usó esa key? Mirá los logs (acá entra CloudTrail).
4. Prevení. Sumá el hook + el escaneo en CI para que no se repita.Comprobá lo que entendiste
0 / 3 correctas
-
1. Commiteaste una API key, la borraste en el commit siguiente y agregaste el archivo al .gitignore. ¿Está resuelto?
-
2. Una API key real se filtró a un repo público. ¿Cuál es el primer paso?
-
3. ¿Por qué tener escaneo en CI si ya hay un hook de pre-commit?
Los secretos se van a filtrar; es cuestión de cuándo. Lo que define si es un susto o un incidente es tener la detección puesta y saber que ante una fuga se rota primero y se limpia después.
Lo que practicás en este lab
Llevátelo a tu repo si querés, pero no es obligatorio: es tu aprendizaje.
- Salida (sintética) de un escaneo que encuentra una key
- Tu config de pre-commit que bloquea el commit
- Checklist de rotación: los pasos que harías ante una fuga real
Reto
Creá un repo de juguete, commiteá una key FALSA tipo AKIAEXAMPLE..., corré un escaneo que la detecte y después escribí el checklist de qué harías si fuera real. La clave: rotar primero.
Resolvelo y escribí dos líneas explicando qué pasó. Con eso lo fijás.