543,000 credenciales expuestas: la llave maestra que nadie rotó
Más de medio millón de credenciales siguen siendo válidas hoy en repositorios públicos de GitHub. No son restos de un ataque: son llaves que alguien dejó a la vista y nadie se molestó en recoger. El hallazgo de Truffle Security no habla de un fallo de la plataforma, habla de una costumbre que se repite en casi todas las empresas que escriben código.
Hay una escena que se repite en el desarrollo moderno: para que una aplicación funcione, alguien pega una clave de API, un token o una contraseña en un archivo de configuración. Después, con prisa, ese archivo termina en un repositorio. Y si el repositorio era público —o lo fue en algún momento, o existía una copia en un fork—, la llave ya no es tuya. Le pertenece a cualquiera que sepa buscar.
Lo que encontró el análisis
Truffle Security publicó un estudio sobre 224 millones de repositorios y más de 58 mil millones de archivos. El resultado fue contundente: 543,699 credenciales únicas seguían siendo válidas en julio de 2026, repartidas en más de 1.1 millones de archivos y repositorios, incluidas copias alojadas en forks. No se trata de cadenas de texto sin valor: el equipo verificó que las llaves seguían funcionando.
«More than 543,000 credentials exposed in public GitHub repositories were still valid in July despite the platform's security measures to prevent accidental leaks of sensitive data». — BleepingComputer.
Los 784 días: el dato más incómodo
Más impactante que el número total es la mediana de tiempo que una credencial permaneció pública: 784 días. Es decir, la mitad de esas llaves estuvo expuesta más de dos años. Cerca del 10% llevaba más de 6.3 años, y la más antigua databa de 2009. Estamos hablando de credenciales que sobrevivieron a tres renovaciones de equipo, a dos rediseños de arquitectura y probablemente a varias juntas de seguridad en las que nadie las mencionó.
Ese número revela algo más grave que un descuido puntual. Un secreto que vive dos años en público no se escapó por accidente: se quedó ahí porque nadie tenía un proceso para encontrarlo. La exposición no es el problema; la ausencia de rotación sí lo es. GitHub lleva años detectando patrones de credenciales y avisando a los proveedores, pero ningún aviso automático sustituye a la disciplina de asumir que todo lo que tocó un repositorio público ya está comprometido.
El fork: el agujero que casi nadie mira
Hay un detalle técnico que convierte este problema en una trampa silenciosa: las copias en fork. Cuando alguien bifurca un repositorio, hereda todo su historial, incluido aquello que ya se había borrado en la rama principal. Borrar un archivo no borra el pasado: Git guarda la historia. Y el historial de un fork vive en otro sitio, fuera de tu control y de tus escaneos habituales.
Esto significa que el típico «ya lo borré» no resuelve nada. Si la credencial estuvo aunque fuera minutos en un repositorio público, hay que asumir que alguien pudo clonarla. La única respuesta razonable no es ocultar el archivo, sino invalidar la llave y emitir una nueva.
La seguridad es cultura, no un parche
La misma semana, David Robinson —quien durante tres años y medio lideró la transparencia de seguridad en OpenAI— renunció y publicó un ensayo titulado «I Quit OpenAI Because Its Culture Is Broken». Su tesis aplica de lleno a este caso: el enfoque de lanzar rápido y parchar después funciona para funciones de bajo riesgo, pero fracasa cuando lo que queda expuesto es una llave con acceso a tus datos, tu infraestructura o tu dinero.
«El tiempo del ensayo y error terminó». — David Robinson, ex OpenAI (The Atlantic).
La conexión con las credenciales es directa. Una empresa puede comprar el mejor gestor de secretos del mercado y, aun así, seguir filtrando claves si sus desarrolladores no tienen la costumbre de usarlo. La herramienta no crea la disciplina: la disciplina decide si la herramienta se usa. Y en la mayoría de las organizaciones pequeñas, el problema no es la falta de tecnología, es la falta de un procedimiento que sobreviva a la prisa del viernes por la tarde.
Por qué esto le importa a un negocio que no es de tecnología
«Nosotros no somos una empresa de software», se dirá más de un dueño. Pero casi ninguna empresa hoy opera sin código de terceros: una agencia que hizo tu sitio, un proveedor que integró tu pasarela de pagos, un freelancer que automatizó tus campañas. Cada uno de ellos pudo haber dejado una credencial en un repositorio, y esa credencial puede ser la de tu correo corporativo, tu CRM o tu facturación.
El riesgo no distingue tamaños. Un token de acceso a la API de un servicio en la nube puede permitir crear servidores, leer bases de datos o enviar correos en tu nombre. Y como vimos con el grupo de espionaje TA419, que esta misma semana fue atribuido por Proofpoint a campañas de phishing contra expertos en política de IA, el eslabón humano y las credenciales siguen siendo el objetivo preferido porque rinden más que cualquier exploit.
Qué hacer: cuatro recomendaciones accionables
Revisa todos tus repositorios —incluidos los privados y los de tus proveedores— con herramientas de detección de secretos como gitleaks, trufflehog o el escaneo nativo de tu plataforma. No escanees solo la rama actual: revisa todo el historial, porque ahí es donde viven las llaves viejas.
Si una credencial tocó un repositorio público alguna vez, considérala comprometida. Invalídala y genera una nueva. Rotar una clave tarda minutos; responder a un incidente por una llave filtrada hace dos años tarda semanas y cuesta reputación.
Muévelos a un gestor de secretos (Vault, AWS Secrets Manager, Doppler o incluso variables de entorno bien gestionadas) y usa pre-commit hooks que bloqueen el commit antes de que la llave llegue al servidor. La prevención vale más que cualquier limpieza posterior.
Rota credenciales en un calendario fijo, aplica el principio de mínimo privilegio y audita los accesos de terceros. Un token que solo puede leer no es lo mismo que uno que puede borrar. Si cada llave tuviera solo los permisos que necesita, una filtración dejaría de ser catastrófica.
¿Tu código o el de tu proveedor tiene llaves a la vista?
En W-ADMIN construimos software con gestión de secretos, permisos mínimos y auditoría desde la primera línea. La seguridad no se agrega al final: se diseña desde el inicio.
Revisemos tu seguridad 🎯El estudio de Truffle Security no deja margen a la interpretación: en un mundo donde todo se conecta a través de credenciales, la llave que nadie rotó es la puerta que nunca cerraste. La buena noticia es que el problema tiene solución y es más barata de lo que parece. La mala es que cada día que pasa suma otro día a esa mediana de 784.