Secretos en el código — cómo no regalar las claves del servidor a los hackers

Imagine la situación: trabajas en un proyecto genial toda la noche. A las 4 de la mañana todo está listo, haces un git push final y te vas a dormir tranquilo. Y por la mañana descubres que tu balance en AWS está a cero y que hay un minero corriendo en tus servidores. ¿Qué pasó? Resulta que en uno de los archivos dejaste la línea: AWS_ACCESS_KEY_ID = "AKIA...".

Es un error clásico por el que han pasado miles de desarrolladores. En este artículo veremos por qué «simplemente borrar la contraseña» no ayuda y cómo configurar una protección automática que físicamente te impedirá cometer el error.

¿Qué son los “secretos” y por qué son un problema?

En el mundo del desarrollo, los secretos son cualquier dato que da acceso a recursos protegidos:

• Contraseñas de bases de datos.
• Claves de API (Stripe, OpenAI, AWS, bots de Telegram).
• Claves SSH privadas.
• Tokens de autorización.

El problema principal: los desarrolladores a menudo tratan el código como un borrador. «Ahora pongo la clave aquí para comprobar si la integración funciona, y antes del deploy la moveré a variables de entorno».

Pero Git no funciona así.

El mito de borrar

Git es un sistema de control de versiones. Su tarea principal es recordar todo. Si hiciste commit de un archivo con la contraseña, y dos horas después lo borraste y hiciste otro commit, la contraseña no desapareció. Quedó en la historia. Cualquiera que clone tu repositorio puede retroceder al primer commit o simplemente mirar el git log y ver tu clave.

Los hackers no se sientan a revisar repositorios manualmente. Tienen bots-escrutadores que monitorean el flujo de commits públicos de GitHub 24/7. En cuanto una clave cae en la red, a menudo acaba en la base de datos del atacante en cuestión de minutos; a veces en 20–60 segundos.

Primera línea de defensa: el principio “no secretos en el código”

Antes de pasar a herramientas, hay que implantar una regla: el código debe ser público por defecto. Aunque estés desarrollando un proyecto privado, escríbelo como si mañana lo fueran a publicar en Open Source.

Uso de archivos .env

La forma más simple es guardar la configuración en un archivo .env que nunca entre en Git.

1. Crea un archivo .env.
2. Añade tus claves: DB_PASSWORD=my_super_secret_password.
3. En el código usa librerías (por ejemplo, dotenv para JS/Python) para leer esos datos.
4. Muy importante: añade la línea .env a tu .gitignore.

Automatización de la protección: introducción a los Git hooks

Somos humanos y nos equivocamos. Para excluir el factor humano, necesitamos robots que nos detengan antes de que se haga el commit. Para ello existen los Git Hooks (hooks de Git).

Los hooks son scripts que Git ejecuta automáticamente ante ciertos eventos (por ejemplo, antes del commit o antes del push).

Herramienta nº1: Gitleaks

Gitleaks es uno de los escáneres de secretos más populares y rápidos. Busca coincidencias usando una enorme base de patrones (formatos de claves de AWS, Google Cloud, Stripe, etc.).

Cómo funciona en la práctica

Instalación:
Si tienes Homebrew (macOS/Linux):

brew install gitleaks

O puedes descargar el binario desde GitHub (Releases) para Windows/Linux/macOS.

Verificación manual:
Puedes ejecutar una comprobación de todo el proyecto ahora mismo:

gitleaks detect --verbose

Si en la historia de tu proyecto hay claves olvidadas, Gitleaks las listará indicando las líneas y archivos concretos.

Herramienta nº2: pre-commit (framework para perezosos)

Para no ejecutar la comprobación manualmente cada vez, usamos el framework pre-commit. Automatiza la ejecución de Gitleaks en cada intento de hacer git commit.

Instrucciones de configuración

1. Instala pre-commit:

pip install pre-commit

2. En la raíz del proyecto crea el archivo .pre-commit-config.yaml.

3. Añade las siguientes líneas:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.0  # Usa la versión más reciente
    hooks:
      - id: gitleaks

4. Instala el hook en tu sistema:

pre-commit install

¿Qué pasará ahora? Cuando escribas git commit -m "added login logic", se ejecutará Gitleaks automáticamente. Si encuentra un secreto, interrumpirá el proceso de commit y mostrará un error. Simplemente no podrás commitear código peligroso. Esa es la idea de «seguridad por defecto».

¿Qué hacer si un secreto ya se filtró?

Si descubres que una clave se ha filtrado en un repositorio público, el procedimiento debe ser el siguiente:

1. Revocar la clave (Revoke): esto es lo más importante. No intentes simplemente borrarla del Git. Asume que la contraseña ya la conocen. Ve al panel de control (AWS, Google, Telegram) y desactiva la clave. Crea una nueva.
2. Limpiar la historia: si realmente necesitas eliminar rastros del repositorio, usa la herramienta BFG Repo-Cleaner o el comando integrado git filter-repo. Un simple git rm no ayudará.
3. Cambiar todos los accesos relacionados: si se filtró la contraseña de la BD, cámbiala en todos los lugares donde se usaba.

Resumen para principiantes

La lucha contra los secretos no es sobre algoritmos complejos, sino sobre disciplina y las herramientas adecuadas.

• Nunca escribas contraseñas directamente en el código.
• Usa .env y .gitignore.
• Configura Gitleaks mediante pre-commit una vez, y te salvará la carrera (y el bolsillo) en el futuro.

Recuerda: en seguridad es mejor prevenir y dedicar 15 minutos a configurar hooks que pasar una semana recuperando una infraestructura comprometida.