Secret scanning open source en 2026: seis escáneres frente a un repositorio con 12 secretos plantados

¿Qué escáneres de secretos open source siguen mantenidos en 2026?

De los once escáneres de secretos open source que revisamos el 29 de octubre de 2026, seis publicaron al menos una release en 2026: Betterleaks, Gitleaks, TruffleHog, Kingfisher, Titus y secretlint. Nosey Parker está archivado, y detect-secrets y git-secrets llevan más de dos años sin publicar ninguna.

La tabla recoge lo que decían ese día la API de GitHub y el README de cada proyecto: la licencia, la última release, si la herramienta puede probar un secreto contra su proveedor y si escribe SARIF. Las estrellas miden la atención que recibe un proyecto, no su mantenimiento, así que las hemos dejado fuera.

Dos filas cambian el consejo habitual. Gitleaks sigue funcionando y su repositorio sigue recibiendo commits, pero desde el 21 de mayo de 2026 su README en GitHub lo da por «feature complete» y avisa de que las próximas releases «serán solo parches de seguridad». Su autor original se pasó a Betterleaks, un proyecto nuevo con licencia MIT creado en febrero de 2026 por la gente que hizo Gitleaks, con un desarrollo que respalda Aikido Security. Y Nosey Parker, que todavía aparece en muchas listas, fue archivado por Praetorian, que lo sustituyó por Titus, un escáner escrito en Go cuyas 487 reglas proceden de Nosey Parker y de Kingfisher.

También importa quién está detrás de cada herramienta. Kingfisher es de MongoDB, detect-secrets es de Yelp, git-secrets viene de AWS Labs y Talisman, de Thoughtworks. TruffleHog es el escáner open source de Truffle Security, con licencia AGPL-3.0 desde su versión 3.0. Whispers, de Skyscanner, que algunas listas siguen incluyendo, está archivado, y su última release fue la 1.5.3, en agosto de 2021.

¿Qué encontró cada escáner en un repositorio con secretos plantados?

Probamos seis escáneres de secretos open source el 29 de octubre de 2026 con un repositorio de 12 credenciales falsas: Betterleaks encontró 12, Titus 11, Gitleaks y Kingfisher 10, TruffleHog y detect-secrets 9. Se escaparon contraseñas y un secreto JWT sin prefijo, una clave que solo estaba en el historial de git y, a Titus, una clave live de Stripe.

Titus y detect-secrets marcaron además un señuelo cada uno. Ese día montamos un repositorio pequeño con pinta de API de tienda online, con TypeScript, Python, un fichero de settings de Django, un Docker Compose y un script de despliegue en shell, repartido en tres commits. Plantamos las 12 credenciales falsas en los sitios donde suelen acabar:

• un par de claves de acceso de AWS en un fichero de configuración de TypeScript;
• un personal access token de GitHub en una cabecera de curl;
• una clave live de Stripe en .env;
• un token de bot de Slack en YAML;
• una clave de OpenAI y otra de Anthropic en llamadas a sus SDK;
• una clave de API de Google en una etiqueta script de HTML;
• una contraseña dentro de una cadena de conexión de Postgres;
• un secreto de firma JWT en Node.js;
• la contraseña de la base de datos de Django;
• una clave privada RSA;
• una clave de SendGrid en un fichero .env.production que un commit posterior borró.

Todos los valores eran aleatorios y seguían el formato de cada proveedor, y ninguno era una clave real. En el README había dos señuelos: la clave de ejemplo que documenta AWS, AKIAIOSFODNN7EXAMPLE, y un placeholder de Stripe hecho de equis. Cada herramienta se ejecutó con sus reglas por defecto, en modo historial de git cuando lo tiene, en un Mac y con las versiones que traía Homebrew ese día. La verificación en vivo estaba desactivada, porque una clave falsa no se puede verificar:

gitleaks git . --report-format json --report-path gitleaks.json
betterleaks git . --report-format json --report-path betterleaks.json
trufflehog git file://. --no-verification --json > trufflehog.jsonl
kingfisher scan . --no-validate --format json --output kingfisher.json
titus scan --git . --format json --output :memory: > titus.json
detect-secrets scan --all-files > detect-secrets.json

Los seis encontraron la clave de AWS, el token de GitHub, el token de Slack, la clave de Anthropic y la clave privada. Los huecos más grandes los abrieron los secretos que no llevan prefijo: Gitleaks, Kingfisher y TruffleHog no detectaron la contraseña de la base de datos de Django, y Kingfisher y TruffleHog tampoco el secreto de firma JWT. Las claves de proveedor tampoco salieron todas indemnes: TruffleHog y detect-secrets no vieron la clave de API de Google, detect-secrets tampoco la de OpenAI, y Titus no vio la clave live de Stripe. Un valor asignado a JWT_SECRET es una cadena aleatoria sin un formato con el que hacer match, así que solo lo atrapan las reglas que leen el nombre de la variable o la entropía de la cadena.

La clave de SendGrid solo existía en un commit que el commit siguiente borró. Todas las herramientas que leen el historial de git la encontraron. detect-secrets no, y su README explica por qué: evita «escarbar en todo el historial de git» y escanea los ficheros actuales, apoyándose en una baseline de hallazgos conocidos.

Los dos señuelos engañaron a herramientas distintas. Gitleaks y Betterleaks ignoran las claves de AWS que terminan en EXAMPLE, porque su regla de AWS por defecto incluye esa excepción, así que la clave de la documentación pasó sin hacer ruido; detect-secrets sí la marcó. Titus reportó el placeholder de equis como una clave de Stripe y no vio la clave de Stripe real de .env. Nosey Parker 0.24.0, que también ejecutamos, hizo exactamente lo mismo, algo que encaja con unas reglas sacadas de las de Nosey Parker.

El número de hallazgos supera al de credenciales. Titus reportó 16 hallazgos para 11 credenciales y detect-secrets 15 para 9, porque varias reglas coincidían con el mismo valor: un token de GitHub detectado a la vez como token y como cabecera de curl, una clave de OpenAI detectada una segunda vez como clave genérica. Cada duplicado es una línea más que triar.

Gitleaks vs TruffleHog vs Betterleaks: ¿cuál te conviene?

Empieza con Betterleaks si partes de cero, quédate con Gitleaks si ya está en tus hooks y solo necesitas que siga funcionando, y añade TruffleHog o Kingfisher cuando saber si una clave está viva te importe más que atrapar todas las contraseñas. Las tres se diferencian en sus reglas, su mantenimiento y lo que hacen tras una coincidencia.

Gitleaks (MIT, v8.30.1) sigue haciendo su trabajo: en nuestra prueba no dio ninguna falsa alarma y se le escaparon dos contraseñas. No va a recibir reglas nuevas. Cambiar de herramienta cuesta poco, porque Betterleaks lee un fichero .gitleaks.toml y respeta los comentarios gitleaks:allow.

Betterleaks (MIT) lo encontró todo en nuestra prueba. La versión 1.9.0 es la release estable, y la validación se activa con un flag, --validation. La versión 2 está en release candidate, y su guía de migración dice que los reporters CSV, JUnit, SARIF y de plantillas «se han eliminado». Si tu pipeline lee SARIF, quédate de momento en la 1.x.

TruffleHog (AGPL-3.0) afirma reconocer más de 800 tipos de secretos y tener más de 700 detectores que prueban las credenciales contra la API de cada servicio, y ejecuta esas pruebas por defecto. Para AWS, su README indica que llama a GetCallerIdentity. --results=verified deja solo los secretos confirmados como vivos, y en nuestra prueba, con la verificación desactivada, fue además el que menos hallazgos reportó. Se le escaparon la clave de API de Google, el secreto de firma JWT y la contraseña de Django. Tiene licencia AGPL-3.0, así que revisa la licencia con tu equipo legal antes de integrarlo en un producto o redistribuirlo.

Kingfisher (Apache-2.0, Rust) valida los hallazgos por defecto y puede revocar algunos. Desde su versión 2.0.0, del 23 de agosto de 2026, sus reglas salen del catálogo de Betterleaks: 462 de sus 488 reglas, más 26 de Veles, el proyecto de Google. Probamos la 2.14.0; la 2.15.0 salió el día anterior.

Titus (Apache-2.0, Go) es adonde van los usuarios de Nosey Parker. Valida con --validate y escribe SARIF.

¿Un escáner de secretos debería comprobar si la clave sigue activa?

Sí, para triar, siempre que controles dónde se ejecuta la comprobación. Una verificación en vivo envía la credencial encontrada a la API de su proveedor y te dice qué hallazgos son un incidente y cuáles son claves muertas. TruffleHog y Kingfisher lo hacen por defecto, Betterleaks y Titus solo si se lo pides con un flag, y Gitleaks nunca.

La comprobación es una petición real con el secreto real. Ejecútala donde tu política de red permita llamadas a esos proveedores, y deja los resultados fuera de los logs públicos del CI. El propio secret scanning de GitHub ofrece la misma idea con sus «validity checks» opcionales.

Que no esté verificado no quiere decir que sea inofensivo. La contraseña de una base de datos de tu red privada no se puede probar desde un runner de CI que está fuera de esa red, así que una herramienta que verifica la reporta como no verificada, y un filtro que solo deja los resultados verificados la descarta.

¿Dónde se ejecuta el secret scanning: en pre-commit, en el CI o dentro del agente?

En tres sitios: un hook de pre-commit en cada portátil, un escaneo en el CI en cada push que un desarrollador no pueda saltarse, y un escaneo de todo el historial cuando adoptas la herramienta. Con el hook de pre-commit solo no basta, porque git commit --no-verify se salta los hooks pre-commit y commit-msg, como recoge la documentación de git.

En GitHub, la push protection bloquea cualquier push que contenga un secreto detectado. El secret scanning es gratuito en los repositorios públicos; en los repositorios privados e internos que pertenecen a una organización hace falta GitHub Secret Protection en GitHub Team o GitHub Enterprise Cloud, que se factura por committer activo.

Los agentes de código añaden un paso antes del commit. Claude Code, Cursor o Codex pueden leer un fichero .env cuando nada se lo impide, como mostramos al explicar qué envía Claude Code a Anthropic y cómo dejar el .env fuera de su alcance, y un valor que un agente ha leído puede acabar en un fichero que escribe.

Ese es el paso en el que trabaja CybeDefend: los guards de VibeDefend rechazan la lectura de .env por parte del agente en Claude Code, Cursor y Codex y le indican la variable de entorno, y su escaneo del diff revisa los ficheros que ha cambiado el agente en busca de secretos y de problemas de SAST e IaC antes del commit. Cómo funciona VibeDefend enseña las dos cosas.

La pull request sigue siendo el último filtro, y los controles de seguridad para la pull request de un agente de IA incluyen una pasada dedicada a los secretos.

¿Cómo juntas los resultados del escáner de secretos con los del resto de escáneres?

Haz que cada escáner escriba SARIF 2.1.0, el formato que leen las plataformas de código y las herramientas de gestión de vulnerabilidades, y fusiona después. Cinco de las seis herramientas que probamos lo escriben, y cada comando de abajo generó un fichero SARIF 2.1.0 válido sobre nuestro repositorio de prueba.

Hay dos trampas: Betterleaks v2 elimina su reporter SARIF, y la propia ayuda de Kingfisher sigue calificando de experimental su salida SARIF.

gitleaks git . --report-format sarif --report-path gitleaks.sarif
betterleaks git . --report-format sarif --report-path betterleaks.sarif   # 1.x only
trufflehog git file://. --sarif > trufflehog.sarif
kingfisher scan . --format sarif --output kingfisher.sarif
titus scan --git . --format sarif --output :memory: > titus.sarif

Escaneos en pre-commit y en el CIUn fichero SARIF por herramientaFusionar y deduplicarTriar y guardar el historial

Un fichero fusionado no es una lista triada. La misma clave te llega de dos herramientas con dos nombres de regla, un falso positivo que descartaste reaparece en la siguiente ejecución, y nada guarda el registro que te va a pedir un auditor. Es el mismo problema de clasificación que contamos en por qué la mayoría de los hallazgos SAST son ruido.

CybeDefend Open Source está pensado para ese paso. Ejecuta los escáneres que elijas, cualquier herramienta que escriba SARIF, y reúne lo que encuentran en una sola cola deduplicada, gratis y en tus propios servidores. Sale pronto, y la lista de espera de CybeDefend Open Source ya está abierta.

¿Qué escáneres de secretos gratuitos no son del todo open source ni locales?

El secret scanning de GitHub y ggshield, de GitGuardian, son gratis para empezar, pero ninguno se ejecuta entero en tu máquina con licencia open source. GitHub escanea gratis los repositorios públicos y pide un plan de pago de Secret Protection para los privados. El CLI de ggshield es MIT, pero escanea con la API de GitGuardian y exige una cuenta.

El escaneo de GitHub es una funcionalidad alojada: lee el historial completo de un repositorio en GitHub, en todas las ramas, y su push protection funciona en el servidor. Eso lo convierte en una buena red de seguridad y en una mala opción para el código que vive en otro sitio. Lo que detecta y lo que se le escapa en un flujo de trabajo con Copilot lo contamos en nuestra guía de riesgos de seguridad de GitHub Copilot.

El README de ggshield dice que para usarlo «tienes que autenticarte contra los servidores de GitGuardian», con una cuenta o una clave de API; también dice que tus ficheros y tus secretos no se almacenarán. Para muchos equipos es un intercambio razonable, y es otro intercambio distinto de ejecutar Betterleaks en tu propio runner.

¿Qué hago si un escáner encuentra un secreto real?

Revócalo o rótalo primero, y luego decide si hace falta reescribir el historial. La guía de GitHub para eliminar datos sensibles dice que el primer paso ante una contraseña, un token o una credencial es revocarlo, rotarlo o las dos cosas, y que un secreto revocado ya no sirve para acceder, lo que por sí solo puede bastar.

1. Revoca o rota la credencial en el proveedor. Kingfisher, y Betterleaks a partir de la versión 2, pueden revocar por su cuenta algunos tipos de credenciales.
2. Revisa en los logs de acceso del proveedor cómo se usó mientras estuvo expuesta.
3. Sácala del código y llévala a un gestor de secretos o a una variable de entorno que lea el código.
4. Reescribe el historial solo si no te queda otra; la guía de GitHub explica los pasos.
5. Registra los falsos positivos para que dejen de volver: un comentario gitleaks:allow o betterleaks:allow, una entrada en el fichero de exclusiones de la herramienta o una baseline de detect-secrets.

Preguntas frecuentes

¿Cuál es el mejor escáner de secretos open source en 2026?

En nuestra prueba del 29 de octubre de 2026, Betterleaks 1.9.0 encontró las 12 credenciales plantadas en un repositorio pequeño y no saltó con ninguno de los señuelos. TruffleHog es mejor opción cuando necesitas saber si una clave está viva, porque verifica por defecto. Gitleaks sigue funcionando, y su README limita las releases futuras a parches de seguridad.

¿Qué es Gitleaks?

Gitleaks es un escáner de secretos open source con licencia MIT que busca credenciales por patrones en el código y en el historial de git, y que puedes ejecutar como hook de pre-commit y en el CI. En nuestra prueba encontró 10 de las 12 credenciales sin ninguna falsa alarma. Su última release es la v8.30.1, del 21 de marzo de 2026.

¿Gitleaks se sigue manteniendo?

Gitleaks se sigue manteniendo, pero solo con parches de seguridad. Desde el 21 de mayo de 2026 su README dice que está completo en funcionalidades y que no se aceptarán funcionalidades nuevas; su última release es la v8.30.1, del 21 de marzo de 2026. Su autor original trabaja ahora en Betterleaks, que lee los ficheros de configuración de Gitleaks y sus comentarios de exclusión.

¿Qué es Betterleaks?

Betterleaks es un escáner de secretos con licencia MIT creado en febrero de 2026 por la gente que hizo Gitleaks, su autor original incluido, con un desarrollo que respalda Aikido Security. La versión 1.9.0 es la release estable. La versión 2 está en release candidate, deja la validación en vivo desactivada por defecto y elimina el reporter SARIF.

¿TruffleHog es gratis y open source?

Sí. TruffleHog en GitHub es open source, con licencia AGPL-3.0 desde la versión 3.0, y ejecutarlo es gratis. Afirma reconocer más de 800 tipos de secretos, verifica las credenciales contra sus proveedores por defecto y escribe SARIF desde la versión 3.97.0, publicada en agosto de 2026.

¿detect-secrets escanea el historial de git?

No, por diseño. detect-secrets escanea los ficheros de tu directorio de trabajo, por defecto los que sigue git, y guarda una baseline de hallazgos conocidos para que solo los secretos nuevos bloqueen un commit. En nuestra prueba no detectó una clave que solo existía en el historial de un fichero borrado. Su última release, la 1.5.0, es de mayo de 2024.

¿Cómo detectar API keys hardcodeadas en el código fuente?

Pasa un escáner basado en patrones, como Betterleaks o Gitleaks, por el código y por todo su historial de git una vez, y después en cada commit y cada push. Las claves de proveedor, como las de AWS, GitHub o Stripe, se detectan por su prefijo y su formato. Los secretos genéricos, como las contraseñas, necesitan reglas sobre el nombre de las variables y la entropía, y ahí es donde más se diferencian las herramientas.

¿El secret scanning de GitHub es gratis?

En los repositorios públicos, sí: el secret scanning se ejecuta automáticamente y gratis. En los repositorios privados e internos de una organización hace falta GitHub Secret Protection en GitHub Team o GitHub Enterprise Cloud, que se factura por committer activo.