Gestión de secretos

Los secretos (claves de API, contraseñas, tokens, certificados) filtrados son una de las causas más comunes de brecha. La gestión de secretos busca que nunca estén en el código ni en el repo, se almacenen cifrados, se roten y se auditen.

El problema

- secretos hardcodeados en código, configs, o commiteados por error al repo
- un repo público (o filtrado) con una clave = compromiso inmediato (bots escanean GitHub en minutos)
- secretos en variables de entorno, logs, imágenes de contenedor, historial de git

Detección de secretos (secret scanning)

gitleaks / trufflehog   escanear repo e HISTORIAL de git (un secreto borrado sigue en el log)
pre-commit hooks        bloquear el commit ANTES de que el secreto entre
GitHub secret scanning  detección + push protection (bloquea el push con secretos)
# clave: escanear el HISTORIAL -> `git rm` no basta, el secreto sigue en commits antiguos

Qué hacer si se filtra un secreto

1. ROTAR el secreto YA (invalidar el comprometido) -> borrarlo del repo NO basta
2. revocar/regenerar la credencial en el proveedor
3. revisar accesos con esa credencial (¿se usó?)
4. limpiar el historial (git filter-repo/BFG) SOLO tras rotar, y comunicar el rewrite
# asumir que todo secreto que tocó un repo público está comprometido

Gestores de secretos (almacenamiento correcto)

HashiCorp Vault           bóveda central, secretos dinámicos, rotación, auditoría
Cloud: AWS Secrets Manager / Azure Key Vault / GCP Secret Manager
Kubernetes: Secrets (base64 ≠ cifrado) + sealed-secrets / external-secrets / CSI driver
-> la app pide el secreto en runtime; no vive en el código ni en la imagen

Buenas prácticas

- secretos fuera del código: inyección en runtime (env/volumen) desde el gestor
- rotación automática y secretos de vida corta (dinámicos) donde se pueda
- mínimo privilegio por secreto; auditoría de acceso
- NUNCA en logs, imágenes de contenedor, ni en el historial de git

Blue Team / AppSec

Secret scanning en pre-commit + CI + push protection; escanear el historial, no solo HEAD.
Centralizar en un gestor (Vault/cloud KMS) con rotación y auditoría; nada hardcodeado.
Proceso de rotación inmediata ante filtración (rotar primero, limpiar historial después).
Preferir secretos dinámicos/de vida corta y mínimo privilegio por secreto.

CVEs y casos reales

Innumerables brechas por claves AWS commiteadas a GitHub (minería de cripto en minutos).
Uber (2016) y Toyota: credenciales en repos/código expuestas llevaron a accesos masivos.
Bots que escanean GitHub en tiempo real explotan secretos filtrados en minutos desde el push.

Checklist de prueba

Secret scanning en pre-commit + CI + push protection
Escaneo del HISTORIAL de git (no solo HEAD)
Gestor de secretos centralizado (Vault/KMS), nada hardcodeado
Inyección en runtime (no en imagen/código)
Rotación automática y secretos de vida corta
Proceso de respuesta a filtración (rotar → limpiar historial)
Sin secretos en logs ni imágenes de contenedor