Git en la terminal y fuga de secretos

Git gestiona los cambios en tres zonas: 1) El directorio de trabajo (Working Directory), donde editas los archivos con tu editor. 2) El área de preparación (Staging Area / Index), donde seleccionas qué cambios incluirás con git add. 3) El repositorio local, donde se sellan los cambios con git commit -m 'mensaje'. Cada commit genera un hash criptográfico SHA-1 o SHA-256 único que identifica el estado exacto del código en ese instante.

Un desarrollador pega por error su clave de AWS en un script, hace commit y push a GitHub. Al notar el error cinco minutos después, borra la línea de la clave, hace un segundo commit ('fix: remove secret') y respira aliviado creyendo que la clave desapareció. Grave error: Git está diseñado para recordar toda la historia. La clave sigue intacta y visible para cualquiera que clone el repositorio e inspeccione los commits anteriores.

Para buscar secretos en un proyecto recién recibido, el auditor utiliza el comando git log -p: muestra la lista cronológica de commits junto con el diff línea a línea de todo lo añadido (+) y borrado (-). Combinando git log -p -S 'password' o git log -p -G '(api_key|secret)', Git busca instantáneamente en todos los commits del proyecto cualquier línea donde se haya introducido o eliminado esa palabra clave.

La prevención en Git se apoya en dos pilares: 1) El archivo .gitignore: lista qué archivos y carpetas locales (como .env, node_modules/ o carpetas de claves .pem) NUNCA deben añadirse al control de versiones. 2) Ganchos de pre-commit (Pre-commit hooks) y herramientas automatizadas (como TruffleHog o Gitleaks) que escanean los archivos antes de confirmar el commit, bloqueando la acción si detectan entropía o patrones de tokens privados.