Detección de secretos: ¿Cómo evitar que tus claves se filtren con el código?

El error fue tan sencillo como habitual: un compañero empujó un commit a producción con una clave API escrita directamente en el archivo de configuración. No hubo mala intención, solo prisa. Pero esa clave fue rastreada, utilizada y, en cuestión de horas, generó miles de peticiones fraudulentas. Desde entonces, tengo un protocolo sagrado: automatizar la detección de secretos en cada repositorio que toco.

¿Qué es la detección de secretos en ciberseguridad?

La detección de secretos consiste en identificar de forma automatizada cualquier tipo de información sensible —como tokens, claves API, contraseñas, certificados o hashes— que haya sido accidentalmente incluido en el código fuente o los archivos del proyecto.

Aunque parezca básico, este tipo de exposición es más común de lo que pensamos. Según el 2024 Global DevSecOps Report de GitLab, las organizaciones han aumentado su uso de herramientas de secret detection, pero aún está lejos de ser una práctica universal. Y eso deja a miles de proyectos expuestos innecesariamente.

¿Por qué la detección de secretos es crítica para cualquier equipo de desarrollo?

He trabajado con decenas de equipos donde, incluso con experiencia, los secretos terminaban en el repo. ¿Por qué?

• Porque usamos .env mal configurados o no ignorados.
• Porque hacemos pruebas rápidas y olvidamos limpiar el código.
• Porque creemos que “como es privado”, nadie lo verá.
• Porque confiamos demasiado en los entornos y poco en los procesos.

La realidad es esta: una vez que un secreto llega al control de versiones, ya es tarde. Incluso si lo borras en el siguiente commit, el historial sigue ahí. Y los bots que escanean GitHub 24/7 lo saben.

Tipos de secretos que pueden filtrarse (y que debes detectar)

A lo largo de mi experiencia, estos son los secretos más propensos a exponerse en un repo:

• Claves de acceso a bases de datos (MySQL, MongoDB, PostgreSQL)
• Tokens de API (Stripe, Twilio, Mailgun, etc.)
• Credenciales de servicios cloud (AWS, GCP, Azure)
• Certificados SSL privados o archivos .pem
• Claves de acceso a dashboards internos (Grafana, Jenkins, etc.)
• Tokens de acceso personal (PATs) para GitHub, GitLab, Bitbucket
• Credenciales hardcodeadas para pruebas (pero que luego nadie elimina)

La detección de secretos te permite actuar antes de que esta información llegue a producción (o a manos equivocadas).

Herramientas para la detección de secretos en entornos reales

Después de probar varias soluciones, estas son las herramientas que recomiendo y uso en mis flujos de trabajo:

• GitLeaks: escanea el historial de Git y los commits en tiempo real. Muy configurable.
• TruffleHog: detecta secretos y patrones de acceso usando regex y entropía.
• GitHub Advanced Security: incluye detección automática de secretos en repos privados.
• GitGuardian: potente y orientado a entornos empresariales, con alertas y dashboards.
• Pre-commit hooks: puedes usar linters personalizados que detecten secretos antes de permitir un commit.

Lo ideal es combinarlas con tu pipeline CI/CD, para que el escaneo ocurra cada vez que alguien sube código o crea una PR. En mis proyectos, tengo reglas que bloquean despliegues si se detecta cualquier patrón sospechoso.

Mejores prácticas para prevenir filtraciones de secretos

Más allá de las herramientas, la detección de secretos debe integrarse en una cultura de desarrollo seguro. Estas son algunas prácticas que recomiendo siempre:

• Nunca subas archivos .env o config locales al repositorio, ni siquiera en ramas feature.
• Utiliza variables de entorno seguras en entornos productivos.
• Configura .gitignore correctamente para excluir claves y archivos sensibles.
• Revoca cualquier secreto que haya sido expuesto, aunque sea por segundos.
• Gestiona los secretos con herramientas como Vault, AWS Secrets Manager o Doppler.
• Revisa el historial del repo antes de hacerlo público o compartirlo con terceros.

Y sobre todo: forma a tu equipo. Muchos errores vienen del desconocimiento, no de la negligencia.

¿Qué hago si ya filtré un secreto por error?

Si ya lo hiciste (nos ha pasado a todos), estos son los pasos que debes seguir:

1. Revoca inmediatamente el secreto desde el servicio donde fue generado.
2. Elimina el commit del historial (con git filter-branch o BFG Repo-Cleaner).
3. Fuerza un push limpio y reconfigura los accesos.
4. Notifica al equipo de seguridad, si aplica, y registra el incidente.
5. Activa detección automática de ahora en adelante para evitar que vuelva a pasar.

Lo más importante es asumir el error y corregirlo cuanto antes. Lo que duele de verdad es ignorarlo.

Conclusión: no proteger tus secretos es una brecha que ya está abierta

Los desarrolladores solemos preocuparnos mucho por las inyecciones, el acceso no autorizado, los parches de seguridad… pero a veces ignoramos lo más básico: el secreto que nosotros mismos dejamos en el código.

La detección de secretos no es opcional. Es una práctica fundamental si quieres trabajar de forma segura, escalar tus proyectos y evitar incidentes que podrían haberse prevenido con una simple regla en tu repo.

¿Quieres aprender a proteger tu código como un profesional, detectar secretos antes de que se filtren y gestionar tus entornos de forma segura? Fórmate con el Bootcamp de Ciberseguridad de KeepCoding y lleva tus habilidades al siguiente nivel. Porque el código seguro no se escribe solo. Se entrena.