¿Se filtró un secreto en git? Primero revócalo, después limpia

Un desarrollador sube un commit con una clave de acceso a la nube en un archivo de configuración. Diez minutos después alguien lo nota, borra la línea, vuelve a subir y cierra el ticket. El repositorio se ve limpio. La clave sigue funcionando.

Ese es el error más común al manejar un secreto filtrado: tratarlo como un problema de código y no como un problema de acceso. Borrar el valor del último commit cambia lo que se ve en el repositorio. No cambia lo que la clave permite hacer. Esta guía recorre la respuesta en el orden que de verdad reduce el riesgo y explica por qué "ya lo borramos" no es lo mismo que "ya lo resolvimos".

El problema es más grande, y más viejo, de lo que parece

El informe State of Secrets Sprawl 2026 de GitGuardian contó unos 29 millones de secretos detectados en GitHub público durante 2025, con un aumento del 34% en secretos nuevos filtrados respecto al año anterior. Pero hay dos hallazgos del mismo informe que importan más para la respuesta que la cifra total:

• Los secretos filtrados siguen siendo válidos durante años. GitGuardian volvió a probar secretos que había confirmado como válidos en 2022 y encontró que el 64% seguía sin revocarse en 2026.
• Los repositorios privados no son más seguros. En sus datos, el 32,2% de los repositorios internos tenía al menos un secreto en el código, frente al 5,6% de los públicos: unas seis veces más probable.

El informe también encontró que cerca del 28% de los incidentes se originan en herramientas de colaboración y productividad, no en el código. Un token pegado en un chat o en un ticket necesita la misma respuesta que uno subido a git.

La conclusión es incómoda: detectar está bastante resuelto; remediar, no. Como dice el informe, en la mayoría de las organizaciones la rotación y la revocación todavía no son rutinarias, no tienen dueño y no están automatizadas.

Paso 1: revoca o rota antes que nada

La propia documentación de GitHub es explícita. Si el dato sensible es un secreto, el primer paso es revocarlo o rotarlo. Una vez revocada, la credencial ya no sirve para acceder, y GitHub señala que eso puede ser suficiente por sí solo.

La guía de gestión de secretos de OWASP (Secrets Management Cheat Sheet) dice lo mismo en su sección de respuesta a incidentes: las claves expuestas deben revocarse de inmediato, y hay que poder crear y desplegar un secreto nuevo rápido, idealmente con un proceso automatizado.

¿Por qué no limpiar primero el historial? Porque el riesgo no vive en el historial. Aun después de reescribirlo y forzar el push, GitHub advierte que los commits viejos pueden seguir accesibles en clones, en forks y directamente por su hash SHA-1 en vistas en caché. No puedes borrar datos de las copias de otras personas. La revocación es el único paso que funciona sin importar quién ya copió el valor.

Revoca rápido, pero no a ciegas

La guía de respuesta de GitGuardian agrega un matiz útil: antes de revocar, entiende qué abre ese secreto y qué se va a romper cuando cambie. Una contraseña de base de datos que usan doce servicios puede provocar una caída si la rotas sin un plan. La respuesta no es esperar; es tener el plan listo antes de la filtración:

• Saber qué sistemas consumen cada secreto crítico.
• Guardar el reemplazo en un lugar seguro, como un gestor de secretos, no en otro archivo de configuración.
• Avisar a los equipos afectados de que hay una rotación en curso.

Si no puedes saber rápido a qué da acceso un secreto, trátalo como crítico hasta que puedas demostrar lo contrario.

Paso 2: revisa si se usó

La revocación impide el uso futuro. No dice nada del pasado. OWASP enumera las preguntas que el equipo de respuesta debe contestar con los logs:

1. ¿Quién tenía acceso al secreto?
2. ¿Cuándo se usó, y desde dónde?
3. ¿Cuándo se rotó por última vez? Eso define la ventana de exposición.

En una clave de nube, significa revisar los logs de auditoría del proveedor en busca de llamadas hechas con ella. En una credencial de base de datos, mira los logs de conexión y cualquier exportación inusual. GitGuardian recomienda seguir con la remediación aunque no encuentres abuso, porque no ver evidencia en los logs que tienes no es una prueba.

Si encuentras actividad que no puedes explicar, ya no es una tarea de higiene. Es un incidente, y debe seguir tu plan de respuesta a incidentes: contención, alcance y, si hace falta, notificación.

Paso 3: limpia el historial y las copias

Solo cuando el secreto ya no sirve tiene sentido limpiar el historial. Aun así vale la pena: incluso una credencial inválida revela qué sistemas, cuentas y almacenes de datos usas. La guía de GitHub cubre los detalles:

• Reescribe el historial con una herramienta dedicada y coordina el push forzado con todos los que trabajan en el repositorio.
• Pide a los colaboradores que borren o vuelvan a clonar sus copias locales.
• Contacta a los dueños de los forks, porque ahí el commit sigue accesible.
• Elimina el secreto de cualquier otro lugar donde se copió: logs, tickets, conversaciones de chat y artefactos de compilación. OWASP menciona los logs de forma específica.

Paso 4: corrige la causa, no solo el caso

Un secreto que se filtró una vez se volverá a filtrar si nada cambia. La prevención tiene tres capas:

• Atrápalo antes de que llegue. Los hooks de pre-commit y las comprobaciones en el IDE frenan la mayoría de las filtraciones antes de llegar al remoto. Escanear en cada push y en todo el historial atrapa el resto. Nuestra guía sobre SAST, SCA, secretos e IaC explica dónde encaja cada control.
• Haz que los secretos duren poco. OWASP recomienda secretos dinámicos con tiempos de vida cortos donde sea posible, y rotación automatizada en todo lo demás, para que una credencial robada solo sirva por poco tiempo.
• Vigila fuera de tu código. Los secretos también se filtran por herramientas de chat, sitios de pegado e infostealers. Esa exposición aparece en la monitorización de credenciales filtradas, no en tu escáner de repositorios.

Cómo priorizar cuando tienes cientos

La mayoría de los equipos que activan el escaneo de todo el historial encuentran un backlog, no una sola filtración. No todos los hallazgos son igual de urgentes:

• Activo le gana a muerto. Un secreto que todavía autentica es una puerta abierta. Uno ya revocado es trabajo de limpieza. Validar si un secreto sigue activo es la mejor señal de triage, aunque GitGuardian señala que cerca del 46% de los secretos críticos no tiene un mecanismo de validación del proveedor.
• El privilegio importa. Una clave de administrador en la nube o la contraseña de una base de datos de producción va antes que un token de API de pruebas.
• La exposición importa. Un secreto en un repositorio público o en un chat compartido está al alcance de más personas que uno en un repositorio privado con tres colaboradores, aunque privado no significa seguro.

Preguntas frecuentes

¿Basta con borrar el commit si el repositorio es privado? No. Todos los que tienen acceso, cada clon y cada sistema de CI que guardó el código en caché siguen teniendo el valor. Revócalo.

¿Hay que rotar aunque los logs no muestren uso? Sí. Los logs pueden estar incompletos y la credencial sigue expuesta en copias que no controlas.

¿Qué tan rápido es suficiente? OWASP no fija un plazo; dice que la revocación debe ser inmediata. Si el secreto está en un repositorio público, trátalo como una tarea del mismo día.

Cómo ayuda priorIQ.ai

CodeIQ escanea secretos en todo el historial de git con validación de secretos activos, para que distingas una rotación urgente del ruido histórico, y suma una puerta en el pipeline y extensiones para el IDE que frenan las filtraciones nuevas antes de que lleguen. OnGuardIQ vigila deep y dark web, canales de Telegram y paste sites en busca de credenciales filtradas de tus dominios. SentinelIQ hace el triage de las alertas del SIEM que ya usas, para que la actividad sospechosa ligada a una credencial filtrada llegue a tu equipo como un incidente confirmado. Y PriorIQ Core pone los hallazgos de código en el mismo modelo de riesgo que endpoints y nube, para que un secreto activo compita por atención según su riesgo real y no por el volumen del escáner. Solicita una demo.