Credenciales expuestas en GitHub: 543,699 siguen activas

Credenciales expuestas en GitHub: Truffle Security verificó 543,699 claves que siguen activas en repositorios públicos. El equipo escaneó 224 millones de repositorios y más de 58,000 millones de archivos. De hecho, la mediana de antigüedad de esas claves es de 784 días. En consecuencia, el problema no fue la filtración, sino que nadie las revocó.

Credenciales expuestas en GitHub: medio millón de llaves vivas

Además, el estudio partió del dataset público The Stack v3 y verificó cada secreto contra el proveedor que lo emitió. Así confirmó 543,699 credenciales activas provenientes de 1,103,438 exposiciones distintas. La más antigua data de junio de 2009, es decir, más de 16 años en línea. Por su parte, el percentil 90 de antigüedad llega a 6.3 años.

En este sentido, el desglose por proveedor explica el riesgo real. Las cuentas de servicio de Google Cloud suman 69,041 claves vivas y las URIs de MongoDB, otras 51,067. En cambio, de 101,886 tokens de npm filtrados solo sobrevivía uno. Esa diferencia no es casual y tiene una sola explicación.

Revocar importa más que bloquear el push

Los datos muestran un patrón claro: la supervivencia depende de la revocación automática del proveedor, no del bloqueo en el momento del push. Por ejemplo, MongoDB no revoca y su tasa de supervivencia es del 100%. Los tokens de GitHub, que sí se revocan, siguen vivos en apenas el 0.36% de los casos.

No obstante, la protección por push de GitHub sí funciona. Entre marzo de 2024 y julio de 2025 la densidad de credenciales protegidas cayó 53%, mientras que las no protegidas bajó apenas 7%. Aun así, el 51.8% de las claves vivas son formatos que un repositorio público acepta sin alertar. Entre ellos están las cadenas de conexión de Postgres y MySQL, con tasas de supervivencia del 91% y 82%.

Qué hacer con tus credenciales expuestas en GitHub

Por lo tanto, la recomendación del equipo es tratar cualquier secreto filtrado como quemado desde el primer segundo. En la práctica, eso implica tres pasos concretos:

• Rotar primero: cambia la credencial antes de limpiar el historial del repositorio.
• Escanear tu propio historial: nada publicado antes de febrero de 2024 estuvo cubierto por la protección por defecto.
• Preferir claves con expiración: la mayoría de los secretos hallados habría caducado de forma inofensiva.

Asimismo, verifica si tu proveedor participa en un programa de revocación, porque la detección sin revocación deja la llave funcionando. Puedes ver más artículos sobre seguridad en nuestro blog.

Finalmente, auditar las credenciales expuestas en GitHub de tus propios proyectos cuesta mucho menos que responder a un incidente. Una clave de 784 días sigue abriendo la misma puerta que el día que se filtró.

Recuerda que estaremos publicando constantemente en nuestro blog más contenido sobre tecnología.

Puedes encontrarnos en Facebook y LinkedIn para más contenido relacionado con seguridad en internet y muchos temas más.

Fuentes: Truffle Security, Invictus IR, Unit 42.