Herramientas de detección de secretos: TruffleHog vs Gitleaks vs GitGuardian vs GitHub

El secret scanning, o detección de secretos, es buscar de forma automática credenciales (API keys, tokens, contraseñas, claves privadas) en lugares donde no deberían estar: el código, el historial de git, logs de CI, imágenes de contenedor. En casi cualquier evaluación aparecen los mismos cuatro nombres: TruffleHog, Gitleaks, GitGuardian y el secret scanning de GitHub. Se superponen bastante, pero no son intercambiables: cambian la licencia, si verifican o no que el secreto siga vivo y dónde corren.

En esta guía los comparamos de forma justa, a partir de la documentación de cada proyecto, y después vamos a la parte que casi todas las comparaciones se saltean: qué hacer cuando el secreto ya se filtró, y por qué borrarlo del código no resuelve nada.

Cómo funciona la detección de secretos

Casi todas las herramientas combinan tres técnicas:

• Patrones por proveedor. Muchas credenciales tienen una forma reconocible. Los access key IDs de AWS empiezan con AKIA, los personal access tokens de GitHub con ghp_, las secret keys live de Stripe con sk_live_. Un detector por formato da coincidencias muy precisas.
• Entropía y palabras clave. Los secretos genéricos (una contraseña de base de datos random, un token interno) no tienen prefijo fijo. Las herramientas buscan strings de alta entropía cerca de palabras como password, secret o token. Encuentra más, pero con más ruido.
• Verificación. La señal más fuerte es probar el candidato contra el proveedor: si una key de AWS logra autenticarse, está viva. Verificar convierte "esto parece una key" en "esta key está activa", y eso cambia la urgencia de la respuesta.

Por qué un secreto sigue en el historial de git aunque lo borres

Git es un historial de snapshots al que solo se le agregan cosas. Si sacás una key en un commit nuevo, todos los commits anteriores la siguen teniendo, y cualquiera la puede leer con git log -p o haciendo checkout de una versión vieja. Revertir el commit tampoco sirve: un revert es otro commit más arriba.

Y empeora cuando el repo ya se pusheó. Cada clon en la notebook de alguien del equipo, cada fork, cada cache de CI y cada mirror tiene su propia copia. En un repo público asumí que el secreto ya lo vio alguien: hay bots que miran los pushes públicos buscando credenciales. Por eso la primera regla es simple: un secreto filtrado es un secreto comprometido. Rotalo. Limpiar el historial es un paso secundario, y lo vemos más abajo.

Por lo mismo, un buen scanner mira el historial completo y no solo los archivos actuales. Una key que se borró hace dos años y todavía funciona es igual de peligrosa que una que está hoy en main.

TruffleHog

TruffleHog, de Truffle Security, es open source con licencia AGPL-3.0. Según su repositorio clasifica más de 800 tipos de secretos, y lo que lo distingue es la verificación: para cada tipo de secreto que puede clasificar, también puede intentar loguearse para confirmar si está activo. Los resultados se marcan como verified, unverified o unknown (se intentó verificar pero falló, por ejemplo por un error de red).

Escanea mucho más que git: GitHub y GitLab, imágenes Docker, S3 y Google Cloud Storage, Jenkins, Elasticsearch, Postman y el filesystem local. Tiene una GitHub Action y soporte para pre-commit. Un escaneo típico del historial que solo reporta credenciales vivas confirmadas:

trufflehog git https://github.com/tu-org/tu-repo --results=verified

También existe TruffleHog Enterprise, comercial, que suma monitoreo continuo sobre Git, Jira, Slack, Confluence y Microsoft Teams. Encaja bien si querés un escaneo gratis que prioriza la verificación y no tenés problema con los términos de la AGPL para tu uso.

Gitleaks

Gitleaks es open source con licencia MIT. Detecta secretos con expresiones regulares combinadas con entropía de Shannon, y todo se configura en un archivo .gitleaks.toml: reglas propias, umbrales de entropía, palabras clave, allowlists (globales o por regla) y filtros por path. También puede decodificar contenido en base64, hex o percent-encoding antes de buscar.

Desde la v8.19.0 los viejos comandos detect y protect quedaron deprecados y se reemplazaron por tres modos:

# escanear todo el historial de git
gitleaks git -v

# escanear un directorio o archivos (sin git)
gitleaks dir ./config

# escanear contenido por pipe
cat build.log | gitleaks stdin

Los reportes salen en JSON, CSV, JUnit, SARIF o un template de Go a medida, así que es fácil mandar los resultados a un dashboard de code scanning. El trade-off está escrito en su documentación: Gitleaks no verifica si un secreto detectado está activo. Encaja bien si querés un scanner rápido, con licencia permisiva y muy configurable, y te bancás hacer el triage vos.

GitGuardian

GitGuardian es una plataforma comercial de seguridad de secretos. Su CLI, ggshield, es open source con licencia MIT y, según su README, detecta y valida más de 500 tipos de secretos hardcodeados. A diferencia de las dos anteriores, ggshield necesita una cuenta y una API key de GitGuardian, porque la detección pasa por la API de GitGuardian. El README aclara que de los escaneos con ggshield solo se guarda metadata como hora de la llamada, tamaño del request y modo de escaneo, no tus archivos ni tus secretos.

ggshield auth login
ggshield secret scan repo .

ggshield se integra con pre-commit, GitHub Actions y otros sistemas de CI, y puede escanear imágenes Docker y paquetes de PyPI. En precios, GitGuardian tiene un plan gratuito Starter para equipos de hasta 25 desarrolladores; los planes pagos suman cosas como monitoreo de secretos públicos, workflows de remediación y, en Enterprise, despliegue self-hosted. Encaja bien si querés una plataforma gestionada con dashboards, flujo de incidentes y manejo de equipos, en lugar de armar todo con CLIs.

Secret scanning y push protection de GitHub

Si tu código está en GitHub, ya tenés acceso a su scanner nativo. El secret scanning revisa todo el historial de git en todas las ramas, y además issues, pull requests, discussions y wikis. Es gratis en repositorios públicos. Para repos privados e internos necesitás GitHub Secret Protection, que se vende como producto independiente desde abril de 2025 a USD 19 por mes por committer activo, disponible para clientes de GitHub Team y Enterprise.

Tres features se destacan:

• Programa de partners. Cuando GitHub detecta un secreto de un proveedor partner, le avisa a ese proveedor, que puede revocar la credencial.
• Validity checks. GitHub puede consultar al emisor si un secreto detectado sigue activo, para que priorices.
• Push protection. Los pushes con secretos soportados se bloquean antes de entrar, vengan de la línea de comandos, la UI web, subidas de archivos o la REST API. Alguien con permiso de escritura puede saltearlo dando un motivo ("se usa en tests", "falso positivo", "lo arreglo después") y el bypass queda registrado como alerta. La push protection para usuarios viene activada por defecto en GitHub.com y te frena si intentás pushear secretos a repos públicos.

GitHub además soporta patrones propios para tokens de tu organización y detección con IA de secretos genéricos como contraseñas. Encaja bien si estás 100% en GitHub y querés prevención del lado del servidor, donde ningún dev se puede olvidar de instalar un hook.

Tabla comparativa

Prevención: hooks de pre-commit, CI y push protection

La filtración más barata es la que nunca llega al remoto. Un esquema en capas se ve así:

1. Hook de pre-commit en las máquinas de los devs. Con el framework pre-commit y Gitleaks, por ejemplo:

   # .pre-commit-config.yaml
   repos:
     - repo: https://github.com/gitleaks/gitleaks
       rev: vX.Y.Z  # fijá el último tag de release
       hooks:
         - id: gitleaks

   Los hooks se instalan máquina por máquina, así que tomalos como una ayuda, no como un control.
2. Un escaneo en CI en cada pull request que haga fallar el build si hay hallazgos nuevos. Esto agarra a todos los que no instalaron el hook.
3. Push protection del lado del servidor (la de GitHub o equivalente), para que el secreto se bloquee aunque falte la herramienta local.
4. Secretos fuera del código. Variables de entorno, un secrets manager, .env en el .gitignore, y credenciales de vida corta como federación OIDC en CI en lugar de cloud keys de larga duración.

Esto encaja con la idea de shift-left de DevSecOps, y no es un detalle: las keys hardcodeadas son un ejemplo de manual de las fallas criptográficas que cubre el OWASP Top 10.

Se filtró un secreto: primero rotá, después purgá

1. Rotá o revocá la credencial ya mismo en el proveedor. La propia documentación de GitHub lo pone primero: una vez invalidada la credencial, puede que ni siquiera necesites reescribir el historial.
2. Revisá si hubo abuso. Mirá los logs de acceso del proveedor (CloudTrail en AWS, audit log en GitHub, el dashboard de Stripe) entre la filtración y la rotación.
3. Guardá el secreto nuevo en un secrets manager y sacalo del código.
4. Si querés, purgá el historial. GitHub recomienda git-filter-repo:

   # sacar un archivo de todo el historial
   git-filter-repo --sensitive-data-removal --invert-paths --path config/secrets.yml
   
   # o reemplazar strings listados en un archivo
   git-filter-repo --sensitive-data-removal --replace-text ../passwords.txt
   
   git push --force --mirror origin

   Reescribir el historial cambia los SHAs de los commits, los forks conservan los datos viejos, el equipo tiene que volver a clonar o hacer rebase para no pushear el secreto de nuevo, y en GitHub tenés que contactar a GitHub Support para borrar vistas cacheadas y desreferenciar los pull requests afectados.

Cómo elegir

• Dev solo o equipo chico en GitHub: activá push protection y secret scanning donde esté disponible, y sumá Gitleaks o TruffleHog como hook de pre-commit.
• Lo que más te importa es la señal: priorizá verificación (TruffleHog, GitGuardian, validity checks de GitHub) para que las keys vivas queden arriba de todo.
• Necesitás reglas propias y licencia permisiva: Gitleaks y su .gitleaks.toml.
• Equipo de seguridad con muchos repos y mucha gente: una plataforma (GitGuardian, GitHub Secret Protection, TruffleHog Enterprise) con dashboards y workflows.

Elijas lo que elijas, los secretos son una sola capa. Las dependencias necesitan software composition analysis (y, para auditorías, un SBOM), y tu propio código necesita análisis estático como AI SAST; en SAST vs DAST vas a ver cómo encajan.

Dónde entra Nurbak

Nurbak no es una plataforma dedicada a secretos; la detección de secretos es una parte de un escaneo completo del repo. Conectás GitHub, escaneás un repo, y Nurbak detecta credenciales de proveedores (AWS, GitHub, Stripe, OpenAI, Anthropic, Slack, claves privadas y más) en el código actual y, con GitHub conectado, en los últimos commits del historial de git. Guarda solo una versión redactada de cada secreto y te indica que lo rotes. En el mismo escaneo, su propio modelo de IA self-hosted analiza tu código para encontrar vulnerabilidades explotables con archivo y línea (el análisis no manda tu código a OpenAI ni a Anthropic), revisa las dependencias contra OSV y marca misconfigs de GitHub Actions, Docker, Terraform y Kubernetes, con un score de 0 a 100. El escaneo gratis te muestra completos los 3 hallazgos más importantes. Probá el secret scanner o el GitHub security scanner completo.

En resumen

TruffleHog, Gitleaks, GitGuardian y el secret scanning de GitHub encuentran secretos en el historial de git; las diferencias reales están en la licencia, la verificación y dónde corren. Elegí uno para pre-commit, otro para CI o del lado del servidor, y que tu respuesta por defecto sea rotar, no borrar. Si querés saber qué hay hoy en tu repo, escaneá con un secret scanner como primer paso.

Lecturas relacionadas

• Qué es un SBOM
• Qué es DevSecOps
• SAST vs DAST
• OWASP Top 10 2025