Escáner de secretos Betterleaks: arquitectura y claves
La detección de secretos en repositorios ha cambiado bastante en los últimos años. Antes bastaba con buscar cadenas sospechosas o claves con alta entropía en el código. Hoy la situación es diferente: repositorios más grandes, pipelines de CI/CD más rápidos y, sobre todo, cada vez más código generado por herramientas automáticas o modelos de IA.
Eso tiene una consecuencia práctica: el problema ya no es solo encontrar secretos, sino separar lo que realmente es peligroso de lo que simplemente parece serlo. Muchos equipos descubren que el verdadero coste de estos escáneres no está en ejecutar el análisis, sino en revisar cientos de falsos positivos.
Arquitectura de detección: qué cambia con Betterleaks
Betterleaks aparece precisamente en ese contexto. No intenta reinventar completamente el escaneo de secretos, pero sí cuestiona un supuesto bastante extendido: que detectar patrones es suficiente.
En muchos repositorios modernos no lo es.
El proyecto, desarrollado por Zach Rice y mantenido con apoyo de Aikido, propone algo ligeramente distinto. En vez de centrarse solo en detectar coincidencias, intenta validar si el hallazgo tiene sentido antes de escalarlo como alerta.
Esto puede parecer un detalle menor, pero en equipos grandes cambia bastante la dinámica. Cuando un sistema de escaneo genera demasiadas alertas irrelevantes, la reacción natural del equipo es ignorarlas. Y en seguridad, una alerta ignorada puede ser peor que no tener alerta.
Para abordar ese problema, Betterleaks introduce dos piezas técnicas interesantes: validación mediante CEL (Common Expression Language) y una métrica llamada “Token Efficiency”, basada en tokenización BPE.
La idea es que no todo lo que parece un secreto lo es realmente. Algunas cadenas con alta entropía son simplemente hashes, identificadores o fragmentos generados automáticamente. El objetivo del sistema es reducir ese ruido.
En la documentación del proyecto se menciona una comparación donde la tokenización BPE alcanza un 98.6% de recall frente al 70.4% obtenido mediante entropía en el dataset CredData. Como ocurre con cualquier benchmark, estos números son orientativos. Funcionan bien como punto de referencia, pero no sustituyen pruebas en repositorios reales.
Source: GitHub
Componentes que marcan la diferencia
Al revisar las características del proyecto se observa una dirección clara: facilitar el despliegue en entornos reales sin añadir demasiada complejidad técnica.
Entre los elementos más destacados aparecen:
- Rule-defined validation using CEL (Common Expression Language)
- Token Efficiency Scanning based on BPE tokenization rather than entropy, achieving 98.6% recall vs 70.4% with entropy on the CredData dataset
- Pure Go implementation (no CGO or Hyperscan dependency)
- Automatic handling of doubly/triply encoded secrets
- Expanded rule set for more providers
- Parallelized Git scanning for faster repository analysis
Aunque esta lista parezca simplemente un conjunto de mejoras técnicas, lo interesante es cómo afectan al uso cotidiano.
Por ejemplo, una implementación completamente en Go sin dependencias nativas simplifica bastante la integración en pipelines de CI/CD. En muchos equipos, pequeños detalles como ese determinan si una herramienta termina utilizándose o queda olvidada en un repositorio.
La tokenización BPE también introduce un enfoque distinto. En lugar de medir únicamente la aleatoriedad de una cadena, analiza patrones de tokens más cercanos a cómo se estructuran realmente las credenciales modernas.
Qué ocurre cuando el escáner encuentra algo
Cuando Betterleaks detecta un posible secreto, el proceso no termina ahí.
Primero se evalúa el contexto mediante reglas definidas en CEL. Esto permite añadir condiciones adicionales: por ejemplo, comprobar si el formato coincide con el proveedor esperado o descartar patrones que aparecen con frecuencia en ejemplos o datos ficticios.
Este paso puede parecer trivial, pero tiene bastante impacto en la práctica. Los falsos positivos no solo consumen tiempo: también reducen la confianza del equipo en el sistema de alertas.
Otro aspecto interesante es el manejo automático de secretos codificados varias veces. En algunos repositorios las credenciales aparecen transformadas mediante base64 u otros esquemas de codificación, lo que complica su detección.
Aun así, conviene recordar algo que a veces se pasa por alto: ningún escáner sustituye completamente la revisión humana. Detectar un secreto es solo el inicio; decidir qué hacer con él (revocar, rotar, ignorar o investigar) sigue siendo una decisión contextual.
Gobernanza y enfoque humano/AI
Betterleaks se publica bajo licencia MIT y cuenta con contribuciones externas procedentes de organizaciones como Royal Bank of Canada, Red Hat y Amazon.
El proyecto también intenta adaptarse a una realidad cada vez más visible en los repositorios modernos: la mezcla de código escrito por desarrolladores y código generado por herramientas automáticas.
En ese contexto, la herramienta busca funcionar bien tanto en flujos operados por personas como en sistemas automatizados que revisan repositorios completos. Esto conecta con el creciente uso de automatización y herramientas que analizan código o generan revisiones automáticas.
En el roadmap también aparecen ideas interesantes: integración con fuentes de datos más allá de Git, asistencia de modelos de lenguaje para clasificar hallazgos y mecanismos de revocación automática mediante APIs de proveedores.
Esto abre un debate interesante. Automatizar la revocación de credenciales puede reducir el tiempo de exposición ante un incidente, pero también implica confiar en que el sistema de clasificación no se equivoque.
Si una revocación automática falla o se dispara por error, el impacto operativo puede ser considerable.
Implicaciones prácticas y límites
Desde un punto de vista operativo, Betterleaks resulta atractivo para equipos que buscan reducir falsos positivos y simplificar despliegues.
Pero también conviene tener presentes algunos límites:
- Las métricas de recall dependen del dataset utilizado y pueden variar bastante entre repositorios.
- La automatización de acciones como la revocación de claves requiere controles adicionales y registros de auditoría.
- Los escáneres de secretos siguen siendo solo una capa de defensa dentro de una estrategia más amplia.
En muchos casos, la decisión de adoptar una herramienta de este tipo no depende tanto de su precisión teórica como de algo más simple: si se integra bien en el flujo de trabajo del equipo.
Un escáner muy preciso que genera demasiada fricción suele abandonarse. Uno razonablemente preciso pero fácil de integrar suele mantenerse.
En ese sentido, Betterleaks intenta moverse en ese equilibrio. No promete eliminar todos los falsos positivos ni sustituir procesos de seguridad existentes, pero sí apunta a reducir el ruido y facilitar la integración en pipelines modernos.
El proyecto está disponible en GitHub y se presenta como una evolución del enfoque utilizado por Gitleaks, con la intención de adaptarse a repositorios donde la automatización, los agentes de análisis y el código generado por modelos de lenguaje forman parte habitual del flujo de desarrollo.
