Para quién es esto: desarrolladores que mantienen código en repositorios públicos como GitHub, y empresas que operan APIs. Este artículo reproduce las cifras del estudio de una empresa de seguridad con las palabras propias de este sitio. No explica cómo encontrar credenciales ajenas.
Qué es este estudio (no es un estudio oficial de GitHub)
El 29 de septiembre de 2026, Truffle Security, una empresa de seguridad que vende herramientas de escaneo de secretos, publicó un estudio sobre credenciales dejadas en repositorios públicos. Como proveedor de herramientas de detección, la empresa que lo publica tiene un interés comercial en el tema. Este artículo usa las cifras del estudio tal como se informaron y marca por separado la interpretación de este sitio.
GitHub no filtró nada. Las credenciales fueron escritas en el código y publicadas por los propietarios de cada repositorio. El papel de GitHub es ofrecer funciones de prevención como la protección de push (bloquear los push que contienen secretos), y, como se muestra a continuación, esas funciones cubren un conjunto limitado de tipos.
Cómo funcionó el estudio y cómo leer las cifras
- Los datos de origen son The Stack v3, un conjunto de datos de repositorios públicos recopilado por un tercero para entrenar LLM (modelos de lenguaje de gran tamaño). La recopilación cerró el 7 de agosto de 2025.
- Solo se examinó la rama por defecto (como main) en el momento de la recopilación. No se incluyen commits antiguos, otras ramas ni nada eliminado previamente. No es un escaneo de todo el código público de GitHub.
- "Activa" significa que el proveedor confirmó que la credencial seguía autenticando el 27-28 de julio de 2026. Algunas pueden haber sido revocadas desde entonces.
- El tiempo desde la exposición se cuenta desde la fecha de la última modificación del archivo que contiene la credencial. El estudio señala que esto tiende a subestimar la antigüedad real.
- Algunos tipos se excluyen de ciertas cifras. Las claves de API de Google solo se probaron con Gemini, y las claves privadas no pueden probarse sin el host al que pertenecen, así que ninguna se incluye en las cifras de supervivencia por tipo.
Las cifras: qué quedó y cuánto
En la semana del 29 de febrero de 2024, GitHub empezó a activar por defecto la protección de push para los push a repositorios públicos de todos los usuarios. Según el estudio, 199.843 (36,8 %) de las 543.699 credenciales activas aparecieron después de esa fecha.
Además, el 51,8 % de las credenciales activas eran cadenas de conexión, claves de API de Google o claves privadas, tipos que la protección de push no bloquea por defecto. En los tipos que la protección de push sí cubre, el número de filtraciones por millón de archivos bajó alrededor de un 53 % al comparar los 12 meses anteriores y posteriores al cambio. Los tipos no cubiertos bajaron solo alrededor de un 7 %. El propio estudio señala que pueden influir otros factores, como que los proveedores de nube empujaran a los clientes hacia credenciales de corta duración durante el mismo periodo.
Cuántas sobrevivieron, por tipo
La siguiente tabla recalcula los porcentajes a partir de los recuentos que publicó el estudio. "Encontradas" es el número de credenciales halladas en las ramas por defecto; "Activas" es cuántas de ellas seguían autenticando en el momento de la prueba.
| Tipo | Encontradas | Activas | Proporción activa |
|---|---|---|---|
| Tokens de npm | 101.886 | 1 | 0,001 % |
| Tokens de Hugging Face | 30.437 | 15 | 0,05 % |
| Tokens de GitHub | 73.048 | 260 | 0,4 % |
| Tokens de Slack | 8.903 | 198 | 2,2 % |
| Claves de Stripe (incluidas las de modo de prueba) | 124.132 | 4.493 | 3,6 % |
| Claves de acceso de AWS | 82.411 | 6.819 | 8,3 % |
| Tokens de Docker Hub | 3.790 | 1.244 | 32,8 % |
| Claves de SendGrid | 22.800 | 9.189 | 40,3 % |
| Claves de cuenta de servicio de Google Cloud | 126.963 | 69.041 | 54,4 % |
| Cadenas de conexión de MySQL | 2.421 | 1.806 | 74,6 % |
| Cadenas de conexión de PostgreSQL | 12.985 | 11.465 | 88,3 % |
| Cadenas de conexión de MongoDB | No contabilizadas | 51.067 | — |
El detector usado para MongoDB solo registra las cadenas con las que logró conectarse, así que no se puede calcular ninguna proporción y el tipo se excluye de las cifras de supervivencia. Solo se informa el recuento de activas.
Por qué los tipos difieren tanto
La diferencia depende menos de lo fácil que es encontrar las credenciales y más de si alguien las detiene después de encontrarlas. Según lo que pudimos confirmar en la documentación oficial de cada proveedor, la situación es la siguiente.
El emisor las detiene automáticamente
- Tokens de GitHub: GitHub documenta que los tokens válidos subidos a un repositorio público o a un gist se revocan automáticamente
- Tokens de npm: desde 2019, npm revoca los tokens válidos encontrados a través de GitHub y envía un correo al propietario
- Hugging Face: un mecanismo oficial permite a cualquiera, no solo al propietario, invalidar un token filtrado
Solo tú puedes detenerlas
- Cadenas de conexión a bases de datos: no hay emisor; funcionan hasta que cambies la contraseña
- Muchas claves de API: lo que haga el emisor tras la notificación de GitHub depende de él
- Claves privadas de tus propios servidores: solo el propietario sabe dónde se usan
El programa de socios de escaneo de secretos de GitHub notifica a los emisores sobre credenciales encontradas en repositorios públicos. La documentación de GitHub recomienda tratar cualquier secreto que informe como público y comprometido, pero deja la implementación en manos del emisor. Es el emisor quien decide si revoca, reemite o contacta al usuario.
Los dos proveedores de nube responden de formas que no equivalen a una revocación completa.
- AWS: AWS asocia a un usuario de IAM cuya clave de acceso pudo haber sido expuesta una política administrada llamada "AWSCompromisedKeyQuarantineV3". Deniega ciertas acciones, como lanzar instancias o cambiar IAM, pero no elimina la clave. AWS pide a los clientes que no quiten la política y que sigan las instrucciones del caso de soporte que abre.
- Google Cloud: desde el 16 de junio de 2024, las claves de cuenta de servicio detectadas en lugares como repositorios públicos se desactivan automáticamente por defecto. Las organizaciones pueden optar por no hacerlo (
WAIT_FOR_ABUSE) mediante la restricción de política de organizacióniam.serviceAccountKeyExposureResponse. El estudio encontró que más de la mitad seguían activas; no explica por qué.
Opinión de este sitio: borrar deja copias en otros lugares
El propio estudio usó un conjunto de datos construido en agosto de 2025. Si un propietario borró un archivo después de esa fecha, la credencial sigue en el conjunto de datos. Lo mismo ocurre con los forks, los clones de otras personas, las réplicas y los datos de búsqueda o de entrenamiento de IA.
Por eso, trata "subido a un repositorio público" como "filtrado", e invalida la credencial en el lado del emisor. Reescribir el historial es una limpieza para frenar una mayor difusión.
Tu repositorio
Borrar o reescribir el historial
Forks, clones, réplicas
En equipos de otras personas
Conjuntos de datos, archivos
Copias del momento de la recopilación
Revocada por el emisor
Cada copia deja de funcionar
Si descubres que filtraste una
Revoca la clave con el emisor
Revisa si hubo uso y cargos
Emite una clave nueva y reemplázala
Limpia el historial al final
Si encuentras la clave de otra persona, no la pruebes
Si encuentras una credencial en el repositorio de otra persona, no compruebes si funciona. Avisa al propietario o al emisor. Para los tipos compatibles en repositorios públicos de GitHub, GitHub notifica al emisor.
Cómo prevenir filtraciones
La protección de push ayuda, pero no basta por sí sola. Como muestran las cifras, los tipos que no bloquea por defecto pasan sin control, y los usuarios pueden saltarse un bloqueo eligiendo un motivo. Combínala con lo siguiente.
- Escanea antes de hacer commit: detén los secretos en tu propia máquina antes del push con un escáner como gitleaks (véase detén los secretos antes de que se confirmen con gitleaks).
- Escanea el historial de los repositorios antiguos: la protección de push no hace nada con los commits realizados antes de activarla. Escanea al menos una vez el historial completo de los repositorios descuidados y archivados.
- Usa credenciales de corta duración: GitHub Actions puede conectarse a AWS o Google Cloud mediante OIDC (recibiendo una credencial válida solo por poco tiempo en cada ejecución) en lugar de guardar una clave de larga duración. Hugging Face ofrece el mismo enfoque.
- Limita lo que puede hacer cada clave: solo lectura, solo APIs específicas, restricciones de IP de origen o de referrer, y una fecha de caducidad. Esto limita lo que una filtración puede costarte.
- Mantén las bases de datos fuera de internet: una cadena de conexión filtrada es inútil si no se puede alcanzar desde fuera. Las cadenas de conexión a bases de datos fueron el tipo con mayor duración en la tabla.
Los conceptos básicos para mantener los secretos fuera del código están en lo que realmente es peligroso de .env y las claves de API, y los secretos dejados en servidores web se tratan en auditoría de directorios públicos.
Para empresas que operan APIs
Lo que separó la parte superior de la tabla de la inferior fue si el emisor detiene automáticamente las claves filtradas. Como parte que protege las claves de tus usuarios, considera:
- Unirte al programa de socios de escaneo de secretos de GitHub, y revocar las claves válidas y notificar a los usuarios cuando recibas la notificación
- Dar a las claves un prefijo distintivo (por ejemplo, uno que empiece por el nombre de tu servicio) para que sean fáciles de detectar
- Ofrecer un canal o una API mediante la cual cualquiera pueda reportar e invalidar una clave filtrada
- Hacer que las claves con caducidad y con alcance restringido sean la opción por defecto
Fuentes (registro público)
Las cifras de este artículo proceden de las fuentes públicas siguientes. No hemos reproducido el texto ni los gráficos del estudio; solo usamos sus recuentos y los reorganizamos.
- Estudio de Truffle Security (proveedor de herramientas de escaneo de secretos), 29 de septiembre de 2026 — trufflesecurity.com
- Cobertura: BleepingComputer (30 de septiembre de 2026) / SecurityWeek (1 de octubre de 2026) / GIGAZINE (2 de octubre de 2026, en japonés)
- GitHub: protección de push activada por defecto (GitHub Blog) / Acerca de la protección de push / Patrones compatibles / Programa de socios / Caducidad y revocación de tokens
- npm: Blog de npm (18 de junio de 2019)
- Hugging Face: Tokens de acceso de usuario (revocar un token filtrado)
- AWS: AWSCompromisedKeyQuarantineV3
- Google Cloud: Desactivación automática de claves de cuenta de servicio filtradas (16 de mayo de 2024) / Prácticas recomendadas para gestionar claves de cuenta de servicio
Lectura recomendada
- Un caso del mismo periodo en el que unas 4.800 cuentas de GitHub fueron abusadas con tokens robados: Secretos de CI y credenciales de nube robados (noviembre de 2026)
- Configuración de GitHub: Cómo configurar la autenticación de dos factores en GitHub
- Prevención: Detén los secretos antes de que se confirmen con gitleaks / Comprobador de filtración de secretos (pega para escanear)
- Conceptos básicos: Lo que realmente es peligroso de .env y las claves de API / Qué es un archivo .env
- Lo que puede costar una filtración: Código escrito con IA filtró una clave de API y generó cargos fraudulentos
- Ataques que apuntan a credenciales de desarrolladores: Cómo defenderse de los gusanos de la cadena de suministro / La cadena de compromiso de TanStack, Nx Console y GitHub (mayo de 2026)
- Limitar los permisos de las claves: Mínimo privilegio en claves SSH