Entrar Pedir acceso a la beta Pedir acceso
El sector lo llamaSecrets detection Qué revisa · 4 de 7

La clave que se fue en un commit

Para probar rápido, la clave de pagos acaba en el código. Se sube en un commit, y desde ese momento está en el historial de todo el que clone el repo, y en el navegador de todo el que cargue la app. Borrarla después no la borra de ahí. Vibethia la encuentra sin enseñarla: su valor nunca sale de tu GitHub.

Léelo en
Para quien programa con IA y quiere entender el riesgo, sin siglas. Para quien ya conoce Secrets detection: motor, cobertura, pipeline y límites.
El riesgo

Se sube en un segundo. Se queda para siempre

Una clave en el código no es un descuido pequeño: es la puerta abierta. Quien la tenga puede cobrar con tu cuenta de pagos, leer tu base de datos o levantar servidores a tu nombre. Y hay programas que recorren GitHub buscándolas en cuanto se suben.

commit→historial→navegador
Una clave expuesta se rota. No basta con borrarla.
VibethiaCorregirClave de pagos en el código. Rótala.

  • En el historial, aunque la borres.

    Git recuerda. El commit donde estaba sigue ahí, y cualquiera con acceso al repo lo puede leer. Por eso una clave que se subió se cambia, no se borra.

  • En el navegador de tus usuarios.

    Si la clave está en código que se manda al navegador, cada visitante la tiene. Con abrir las herramientas de desarrollo.

  • Con la IA pasa más.

    Le pegas la clave para que «lo haga funcionar», y la IA la escribe donde le parece. El código funciona. La clave se queda.

Qué hace Vibethia

La encuentra sin verla

En cada subida busca en tu código lo que tiene forma de clave o contraseña: las de los proveedores conocidos, por su formato; y las variables con nombre de secreto y un valor que parece aleatorio. Antes de que nada salga de tu GitHub, la tapa.

  • El valor nunca sale de GitHub. Lo que llega a Vibethia es «AKIA…[20]»: cuatro letras, el tipo y la longitud. Ni en la base, ni en el panel, ni en la conversación con el analista.
  • Distingue una clave de un ejemplo. «changeme», «your_key», «xxx» o una clave en un fichero de test son avisos que se descartan solos. Una con formato de proveedor real, no: esa la confirma una persona.
  • Te dice qué hacer. Rotarla en el proveedor, sacarla a una variable de entorno y comprobar que no se usó. El prompt para tu IA lleva los tres pasos; el primero lo tienes que hacer tú.
  • Solo lo que hay ahora. Mira el código tal como está, no todo el historial. Una clave que se subió hace un año y se borró no la ve. Lo decimos.
Medido

Seis de seis

En nuestro repo de pruebas sembramos seis secretos con la forma de los de verdad, generados para la ocasión. Vibethia encontró los seis; el plan gratuito de Xygeni, cinco.

  • Secretos sembrados encontrados 6 de 6.

    Ninguno de los seis llegó a la base con su valor.

  • Y los que no eran secretos Fuera.

    Los marcadores y ejemplos sembrados como falsas alarmas se descartaron en el triaje.

La comparativa entera.

Motor

Gitleaks con --redact, y seis capas detrás

El escáner es solo la primera capa. Lo que de verdad protege el valor es que se enmascara en el runner, antes de salir, y que la API vuelve a comprobarlo al recibir.

Escáner
Gitleaks sobre el árbol actual, con --redact: su SARIF no lleva el valor.
Enmascarado en el runner
preparar_envio tapa el tramo exacto de cada resultado en los fragmentos: hasta 4 caracteres de prefijo, elipsis y longitud (AKIA…[20]). Después pasa a todo fragmento los formatos de alta confianza y las asignaciones con nombre de secreto y valor de entropía ≥ 3,5.
Lo que calcula para el analista
Entropía de Shannon, si encaja con el formato de un proveedor (AWS, GitHub, Stripe, Slack, claves privadas…) y si parece un marcador (xxx, changeme, <…>, ruta de test o .example).
La API repite
Borra snippet y contextRegion de Gitleaks y pasa su propio detector a todo lo recibido. Si algo encaja, se enmascara y queda el evento secreto_enmascarado_en_servidor: señal de que el workflow tiene un fallo.
Huella
Se calcula sobre la línea ya enmascarada, y el SARIF se guarda solo tras el saneado. Nada de fragmentos en los registros: solo recuentos e ids.
Guardarraíl
Un secreto con formato de proveedor, que no parece marcador y está fuera de rutas de test, no se descarta sin una persona: Revisar.
Límites

Lo que esta capa no hace

  • No Historial de git

    Solo el árbol actual. Un secreto que se subió y se borró no se ve. Está documentado como trabajo futuro.

  • No Validar si la clave está activa

    No llama al proveedor para comprobarla: eso sería usar vuestra clave. Se trata como activa hasta que la rotéis.

  • No Rotarla por vosotros

    La rotación la hacéis en el proveedor. El prompt la pone como primer paso.

  • Todavía no Hook de pre-commit

    Pararla antes del commit, en la máquina de cada uno. En estudio.

  • Medido Repo de pruebas

    6 de 6 secretos sembrados (Xygeni gratuito: 5 de 6). El repo publicado no lleva secretos: se generan al grabar y nadie los imprime. La tabla.

Lo demás que revisa

Del ruido a la decisión

Conecta un repo y mira qué hay que corregir. Sin hablar con nadie.

Pedir acceso a la beta