becwright vs gitleaks

gitleaks y becwright se solapan en exactamente un trabajo — frenar secretos al momento del commit — y divergen en todo lo demás. gitleaks es un escáner de secretos dedicado que llega más lejos en ese problema que becwright: un gran conjunto de reglas de detección, análisis de entropía y auditorías del historial completo de git. becwright es un motor de constraints de propósito general cuyos checks integrados incluyen secretos, pero cuyo verdadero trabajo es imponer cualquier regla del equipo de forma determinista. El veredicto honesto es solapamiento, no rivalidad: muchos repos deberían correr ambos.

TL;DR — si tu único problema es detectar secretos, gitleaks detecta más secretos. Si tu problema es «los agentes de IA y los humanos siguen commiteando cosas que no deberían» — secretos, pero también líneas debugger, eval(), APIs prohibidas, convenciones rotas — becwright lo impone todo con un solo motor, ata cada regla a su porqué y habla JSON/MCP con los agentes. Usa gitleaks para profundidad en secretos y becwright para amplitud de constraints; se encuentran amistosamente en el hook pre-commit.

¿Qué es gitleaks?

gitleaks es un escáner de secretos open source escrito en Go, distribuido como un único binario. Detecta claves de API, tokens y credenciales usando un gran conjunto de reglas curadas más heurísticas de entropía para cadenas de alta aleatoriedad, y puede escanear un directorio, los cambios en stage o todo el historial de git — cada commit que se haya hecho, no solo el árbol actual. Soporta allowlists y baselines para gestionar hallazgos, es un fijo en pipelines de CI y auditorías de seguridad, e incluso publica un hook de pre-commit.

En su terreno, sus ventajas sobre becwright son reales y vale la pena decirlas sin rodeos: más patrones de secretos, análisis de entropía que atrapa secretos que ningún regex fijo atraparía, y escaneo de historial que becwright sencillamente no hace.

¿Qué cubre becwright que gitleaks no cubre?

gitleaks responde una pregunta: «¿hay un secreto aquí?». becwright responde una más amplia: «¿este commit viola alguna regla que este equipo decidió?». En concreto:

• Constraints arbitrarias, no solo secretos. Los checks integrados atrapan restos de depuración (breakpoint(), import pdb), eval()/exec(), imports con wildcard y tokens en llamadas de log; el check genérico forbid convierte cualquier regex en una regla blocking para cualquier lenguaje; y el contrato de checks — rutas de archivos por stdin, código de salida hacia fuera — te permite escribir checks propios en el lenguaje que quieras.
• Cada regla atada a su intención. Una regla de becwright lleva intent y why_it_matters, impresos cuando falla. Cuando un agente de IA se topa con un commit bloqueado, ve por qué existe la regla — el contexto que necesita para arreglar el código en vez de pelear con la regla.
• Bundles de reglas portables. becwright export empaqueta una regla — incluido el código fuente de un check propio — en un solo .bec.yaml; becwright import la instala en otro repo después de mostrarte exactamente qué va a ejecutarse.
• Una superficie de primera clase para agentes de IA. becwright check --json devuelve pasa/no-pasa estructurado con las intenciones adjuntas, y un servidor MCP expone check y list_checks a Claude Code, Cursor, Windsurf o cualquier cliente MCP — mira la integración con Claude Code.

becwright vs gitleaks: lado a lado

Aspecto	gitleaks	becwright
Qué es	Escáner de secretos dedicado	Motor de constraints con checks propios
Runtime necesario	Ninguno — un solo binario en Go	Ninguno — binario autocontenido vía npm/pnpm (pipx opcional)
Profundidad de detección de secretos	Gran conjunto de reglas + análisis de entropía	Regex conservador: claves AWS, claves privadas, literales de password
¿Escanea el historial de git?	Sí — cada commit que se haya hecho	No — archivos en stage, o el árbol de trabajo con --all
¿Más allá de secretos?	No — solo secretos	Sí — restos de debug, eval, cualquier regex, checks propios
Vínculo regla ↔ intención	No — los hallazgos referencian ids de reglas	Sí — intent y why_it_matters en cada regla
Bundles de reglas portables	Config en TOML, copiada a mano	Un solo archivo .bec.yaml vía export / import
Salida para agentes de IA	Formatos de reporte (p. ej. JSON)	check --json + servidor MCP + plugin de Claude Code

Fíjate en la fila del runtime: ambas herramientas son binarios autocontenidos, así que «sin runtime» es una virtud compartida, no una ventaja de becwright. Las verdaderas líneas divisorias son profundidad de detección (gitleaks) frente a amplitud de constraints y vínculo con la intención (becwright).

¿Dónde se solapan exactamente?

En los cambios en stage al momento del commit. El check integrado hardcoded_secrets de becwright bloquea claves AWS, claves privadas y literales password = "..." — deliberadamente conservador, basado en texto/regex, afinado para evitar falsos positivos que enseñan a la gente a saltarse los hooks. El escáner de gitleaks lanza una red mucho más amplia sobre el mismo diff en stage. Un secreto que no coincida ni con una regla curada de gitleaks ni con los patrones de becwright puede colarse por ambos, pero la asimetría es honesta: un secreto inusual tiene más probabilidades de caer en el análisis de entropía de gitleaks que en los patrones fijos de becwright.

Donde no se solapan en absoluto: todo lo que hay en tu .bec/rules.yaml que no es un secreto, y todo lo que hay en tu historial de git anterior al hook.

Usa ambos

Las configuraciones se combinan limpiamente porque responden preguntas distintas:

• gitleaks en CI y auditorías — escaneos de historial completo con calendario o en cada push, análisis de entropía, baselines para triar hallazgos heredados. Esa es tu profundidad de detección.
• becwright en el commit — el hook nativo de pre-commit corre becwright check sobre los archivos en stage: hardcoded_secrets da un bloqueo de secretos inmediato y determinista, y cada otra regla que tu equipo codificó viaja gratis en el mismo pase. Esa es tu amplitud de imposición.

Y como un check de becwright es solo un comando de shell que sale con código distinto de cero ante una violación, puedes incluso correr gitleaks como una regla de becwright — la detección de gitleaks con el vínculo de intención de becwright en el mensaje de fallo:

- id: deep-secret-scan
  intent: >
    Ningún secreto puede entrar en un commit, incluidos patrones
    fuera del conjunto integrado de becwright.
  why_it_matters: >
    Una credencial filtrada en git está comprometida desde el momento
    del push; rotarla es caro, prevenir es barato.
  paths: ["**/*"]
  check: "gitleaks protect --staged --no-banner"
  severity: blocking

Cualquier comando funciona en check mientras siga el contrato del código de salida; ajusta la invocación de gitleaks a la versión que uses.

¿Cuál deberías elegir?

Elige según la forma del problema. Los secretos son tu única preocupación y necesitas auditar el historial: gitleaks solo es una buena respuesta. Quieres bloquear secretos en los commits sin configuración extra — e imponer el resto de las reglas de tu equipo con el mismo motor, con una salida sobre la que un agente de IA puede actuar: empieza por el quickstart de becwright y estás protegido en tres comandos. Los equipos maduros suelen terminar con ambos. Para las comparativas vecinas — frameworks de hooks en vez de escáneres — mira becwright vs pre-commit y becwright vs husky.

FAQ

¿Debería usar gitleaks o becwright para atrapar secretos?

Para profundidad de detección de secretos, gitleaks: tiene un gran conjunto de reglas, análisis de entropía y puede auditar todo el historial de git. Para un bloqueo determinista en el commit más cualquier otra constraint del equipo — restos de depuración, APIs prohibidas, reglas propias — becwright. Solo se solapan al escanear cambios en stage, así que muchos equipos corren gitleaks en CI y becwright en el commit.

¿Puede becwright escanear mi historial de git en busca de secretos filtrados?

No. becwright revisa los archivos en stage al momento del commit, o todo el árbol de trabajo con becwright check --all; nunca inspecciona commits pasados. Auditar el historial es exactamente para lo que está hecho gitleaks. Si un secreto ya fue commiteado, primero rótalo y luego usa gitleaks para encontrar cada aparición — becwright evita entonces que el siguiente llegue al repo.

¿becwright detecta algo más que secretos?

Sí — esa es la diferencia principal. Los checks integrados cubren secretos hardcodeados, tokens en llamadas de log, eval()/exec() y restos de depuración, y el check genérico forbid convierte cualquier regex en una regla blocking para cualquier lenguaje. También puedes escribir checks propios como scripts en cualquier lenguaje, cada uno atado a un intent y un why_it_matters que se imprimen cuando la regla falla.