Tanto si trabajas tu solo en tus propios proyectos personsales, como si trabajas en grupo hay que tener en cuenta siempre algunas medidas mínimas de seguridad cuanto trabajamos con repositorios GIT.

Aparte de lo seguro que sea tu código, una de las primeras cosas que debes de configurar en cualquier repositorio es el fichero .gitignore

El fichero .gitignore

Este fichero evita que los ficheros que indiquemos en él se suban al repositorio y podamos tener un problema de seguridad si alguien ha introducido en el proyecto alguna contraseña, un token, un secreto, una api-key, etc.

Es importante entender que el uso de .gitignore no es un mecanismo de seguridad, solo evita añadir ficheros a Git por defecto.

La protección real debe complementarse con pre-commit hooks, escáneres de secretos o políticas en el servidor

Empecemos viendo un ejemplo completo de .gitignore para evitar subir credenciales, tokens y secretos:

########################################
# Variables de entorno y secretos
########################################

# Archivos típicos de variables sensibles
.env
.env.*
*.env

# Archivos de configuración con secretos
config/secrets.yml
config/secrets.yaml
secrets.yml
secrets.yaml
secret.key
*.key
*.pem
*.crt
*.p12
*.pfx
*.jks

########################################
# Credenciales y tokens
########################################

# Tokens y credenciales genéricas
*token*
*secret*
*password*
*cred*
*credential*

# Ficheros habituales de APIs
apikeys.json
credentials.json
auth.json

########################################
# Configurations locales (no compartidas)
########################################

# Configuración local de desarrollador
*.local
local.settings.json

# Docker overrides con credenciales
docker-compose.override.yml

########################################
# Herramientas cloud (pueden contener claves)
########################################

# AWS
.aws/
*.aws

# Azure
.azure/
azureProfile.json

# GCP
.gcloud/
gcloud.json
application_default_credentials.json

########################################
# SSH y claves privadas
########################################

# Claves SSH (por si están dentro del repo accidentalmente)
id_rsa
id_dsa
id_ecdsa
id_ed25519
*.pub

########################################
# Backup o dumps que puedan incluir datos sensibles
########################################

*.bak
*.backup
*.dump
*.sql

########################################
# Archivos de log (pueden incluir tokens)
########################################

*.log

########################################
# Editor/IDE puede guardar credenciales
########################################

.vscode/
.idea/

########################################
# Otros casos peligrosos comunes
########################################

# Archivos temporales susceptibles de contener datos sensibles
tmp/
temp/

El fichero anterior intenta cubrir un poco todas los casos, cada uno debe ajustarlo a su IDE, lenguaje de programación y forma de codificar.

Recomendaciones importantes (más allá del .gitignore)

Si eres un responsable técnico de un grupo de trabajo, es recomendable reforzar esto con varias capas de protección extra:

Uso de .env.example

En caso de necesitar un fichero de variables, preparamos un ejemplo de uso de .env seguro para el equipo de trabajo.
Y por supuesto incluimos el fichero .env en nuestro .gitignore

Nombre de fichero de ejemplo a crear: .env.example

En él ponemos un contenido de que campos vamos a usar en el fichero real, algo similar a esto:

DB_HOST=localhost
DB_USER=usuario
DB_PASSWORD=changeme
API_TOKEN=changeme

De esta forma obligamos a los desarrolladores a crear su propio .env

La herramienta gitleaks

gitleaks no forma parte de los comandos de Git.

Es una herramienta externa (open source) diseñada específicamente para detectar secretos (tokens, API keys, contraseñas, etc.) en repositorios.

Cómo se usa con Git

Se puede integrar en varios puntos:

1. Manualmente

gitleaks detect

O sobre commits:

gitleaks detect --source .

2. Como hook de pre-commit (muy habitual)

Se ejecuta antes de cada commit:

gitleaks protect --staged

Esto evita que se haga commit si detecta un secreto.

NOTA: En entornos AWS se suele usar git-secrets en su lugar.

3. En CI/CD (ej. GitLab)

Ejemplo simple para una tarea en GitLab .gitlab-ci.yml:

gitleaks:
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --exit-code 1

Si detecta secretos, falla el pipeline y evitamos que se suba al servidor Git y quede registrado.

4. Protección en Servidor Git

Dependiendo del servidor con el que trabajaes deberás activar la herramienta propia que evita fugas

Protección del Servidor Git con herramientas de detección de fugas

Algunos servidores GIT incluyen sus propias herramientas para detectar contraseñas, tokens, etc. y en otras será necesario usar herramientas externas como gitleaks

Otras opciones importantes son activar las Push rules y prohibir patrones tipo:

(?i)(api[_-]?key|token|secret|password)

5. Nunca confiar en patrones tipo *token*

Aunque tengas configurada una regla en tu .gitignore dependiendo del lenguaje de programación, cualquier desarrollador puede usar otros nombres de ficheros y no lo detectarías.

Ejemplo de riesgo:

• Un fichero legítimo puede llamarse mytokenizer.py
• Y uno malicioso puede ser cred.txt sin patrón detectable

Por eso:

• .gitignore = prevención básica
• detección automática = obligatorio

6. Rotación de secretos

Si un token se ha subido por error, no pasa nada, pero hay que tomar las siguientes medidas de precaución:

1. Revocar inmediatamente
2. Rotar credenciales
3. Eliminar del historial (git filter-repo o BFG)

Resumen de .gitignore

.gitignore puede ayudar, pero no evita fugas de secretos por sí solo, la combinación correcta sería:

• .gitignore bien definido
• Hooks de pre-commit
• Escaneo en CI/CD (GitLab)
• Políticas de repositorio

Como Obtener e Instalar gitleaks

Hay versiones de GitLeaks para diferentes sistemas operativos.

GitLeaks para Windows

Lo recomendado es descargar y usar el Binario oficial.
Lo puedes descargar directamente el ejecutable desde su repositorio en GitHub

• Archivo tipo:
  gitleaks_windows_x64.zip

Una vez descargado:

# Descomprimir
Expand-Archive gitleaks_windows_x64.zip

# Ejecutar
.\gitleaks.exe detect

No requiere instalación adicional.

Lo puedes integrar como hook en Windows (copia el funcionamiento de como se hace en Linux):

Simplemente necesitas el archivo:

.git/hooks/pre-commit

Ejemplo:

#!/bin/sh
gitleaks protect --staged
if [ $? -ne 0 ]; then
  echo "Commit bloqueado: se detectaron secretos"
  exit 1
fi

Nota:

• Si usas Git for Windows, este hook funciona en su entorno Bash.
• También puedes hacerlo en PowerShell.

Gitleaks para Debian

gitleaks está disponible para Debian/Linux y se puede instalar de varias formas.

Binario oficial (recomendado en entorno corporativo)

Es la opción más controlada (sin depender de repos externos).

# Descargar (ajusta versión si procede)
wget https://github.com/gitleaks/gitleaks/releases/latest/download/gitleaks_linux_x64.tar.gz

# Descomprimir
tar -xzf gitleaks_linux_x64.tar.gz

# Mover al PATH
sudo mv gitleaks /usr/local/bin/

# Verificar
gitleaks version

Ventajas:

• No se depende de repositorios de terceros
• Puedes fijar versión (importante en CI/CD y para la realización de auditorías)

Instalación con apt

Dependiendo de tu distribución de Debian, puede que no sea la versión más actualizada, o puede que incluso no esté en los repositorios oficiales, para saber si dispones de una versión para instalarlo, simplemente ejecuta:

apt search gitleaks

Si está, puede instalarlo ejecutando:

sudo apt install gitleaks

Integración como pre-commit hook en Debian

Ejemplo básico:

cat > .git/hooks/pre-commit << 'EOF'
#!/bin/sh

gitleaks protect --staged
if [ $? -ne 0 ]; then
  echo "Commit bloqueado: se detectaron secretos"
  exit 1
fi
EOF

chmod +x .git/hooks/pre-commit

GitLeaks con Docker

Esta es una opción útil y reproducible en cualquier entorno. Es una buena opción para incluirlo en pipelines o entornos controlados:

docker run --rm -v $(pwd):/repo zricethezav/gitleaks:latest detect --source /repositorio

Uso típico de GitLeaks

Escaneo completo:

gitleaks detect --source .

Escaneo en staging:

gitleaks protect --staged

Analizando Código heredado

Puede ser que hayas heredado código o simplemente quieras revisar todos los commits que se han producido en un proyecto.

Simplemente tienes que entrar al directorio de el proyecto a analizar y desde dentro de él puedes ejecutar el comando: gitleaks detect --verbose

Si por desgracia no se han seguido buenas prácticas, puede veas varios mensajes de las fugas de seguridad sobre todo lo que vaya encontrando la herramienta.

Seguramente se hayan detectado posibles secretos en el historial y en el código.

Analicemos algun ejemplo y veamos que podemos hacer.
Vamos a suponer que se ha detectado una api-key en un playbook.

1. Qué ha detectado exactamente

Ejemplo relevante:

Secret: YW5zaWJ******zQ3ODgy...
RuleID: generic-api-key
File: reinicio/.../configurar_mantenimiento_srv.yml

Ese valor:

YW5zaWJ******zQ3ODgy...

tiene pinta clara de Base64.

Si lo decodificas:

echo "YW5zaWJ******zQ3ODgy..." | base64 -d

Verás algo similar a lo siguiente (es un ejemplo ficticio):

ansible_user:xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Esto encaja perfectamente con:

• Basic Auth (usuario:token o usuario:password)
• Token embebido en un playbook Ansible

2. Problema real

Tienes varios problemas simultáneos:

2.1 Secretos en claro (aunque estén en base64)

Base64 no cifra nada, solo codifica.

Cualquiera puede recuperar la credencial

2.2 Secretos dentro del repositorio

Incluso peor:

Commit: 13748bfc91e7xxxxxx4491e0b84

Está en el historial Git, no solo en el fichero actual

2.3 Aparece incluso en comentarios

# auth: YW5zaWJ******zQ3ODgy...

Gitleaks también detecta comentarios (correcto)

3. Cómo corregirlo

Debemos corregirlo de una forma profesional, para ello lo vamos a abordar con un enfoque de 4 fases.

FASE 1 — Contención inmediata

1. Revocar las credenciales

Esto es obligatorio antes de nada:

• Token
• Usuario asociado
• Claves derivadas

Hay que hacerlo ya, podemos suponer que el repositorio ya está comprometido

FASE 2 — Limpieza del código actual

Editar el playbook:

Antes (incorrecto)

auth: YW5zaWJ******zQ3ODgy...

Después (correcto)

Opción A: variables Ansible

auth: "{{ aplicacion_auth }}"

Y en vars o inventario:

aplicacion_auth: "{{ vault_aplicacion_auth }}"

Opción B: Ansible Vault (recomendado)

ansible-vault encrypt_string 'ansible_user:xxxxx' --name 'aplicacion_auth'

Resultado:

aplicacion_auth: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          624153...

FASE 3 — Eliminar secretos del historial Git

Esto es lo crítico que muchos equipos se olvidan y no lo hacen.

Opción recomendada: git filter-repo

git filter-repo --path reinicio/playbooks/tasks/configurar_mantenimiento_srv --invert-paths

O más fino (reemplazandoi):

git filter-repo --replace-text replacements.txt

replacements.txt:

YW5zaWJ******zQ3ODgy....==>REMOVED_SECRET

Después:

git push --force

Y avisar al equipo de desarrollo que deben reclonar

Alternativa: BFG Repo Cleaner

bfg --replace-text secrets.txt

FASE 4 — Evitar que vuelva a ocurrir

Si eres responsable del grupo de trabajo o de un grupo de desarrollo, aquí es donde debes de intervenir.

4.1 Integrar gitleaks en pre-commit

#!/bin/sh
gitleaks protect --staged
if [ $? -ne 0 ]; then
  echo "Commit bloqueado: secretos detectados"
  exit 1
fi

4.2 Integrarlo en tus CI

gitleaks:
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --exit-code 1

4.3 Ajustar falsos positivos (si aplica)

Si sabes que algo es falso positivo, puedes crear .gitleaks.toml:

[allowlist]
paths = [
  "tests/",
  "docs/"
]

4.4 Políticas para el equipo

Hay que definir reglas claras que todos entiendan y apliquen:

• Prohibido:
  • Credenciales en playbooks
  • Tokens en scripts
• Obligatorio:
  • Uso de Vault
  • Variables de entorno

5. Interpretación del resultado global

Si tras ejecutar gitleaks te encuentras en el resultado final algo similar a esto:

...
WRN leaks found: 43
...

Esta información sobre fugas de seguridad es importante y hay que interpretar lo siguiente:

• No son 43 secretos distintos
• Son coincidencias en commits/ficheros

Lo que probablemente se ha detectado es:

• Reutilización del mismo token
• Repeticiones en el historial

RECUERDA

Si al usar la herramienta gitleaks detectas fugas, no tienes un error de uso de la herramienta, lo que existe es un problema real de seguridad:

• Hay credenciales en el código
• Están en el historial
• Son recuperables

La corrección pasa por:

1. Revocar credenciales
2. Sacarlas del código
3. Limpiar historial
4. Implantar controles preventivos