Una investigación reciente sobre repositorios públicos de GitLab Cloud ha sacado a la luz una filtración masiva de credenciales, claves API y otros secretos aún válidos, expuestos abiertamente en el código. Este hallazgo confirma una tendencia preocupante ya observada en otras plataformas Git: la gestión de secretos sigue siendo uno de los eslabones más débiles en la seguridad de entornos DevOps y de la cadena de suministro de software.
Filtración de secretos en GitLab Cloud: alcance y magnitud del problema
El análisis de 5,6 millones de repositorios públicos en GitLab Cloud permitió identificar 17 430 secretos confirmados y todavía activos, distribuidos entre más de 2800 dominios únicos. Bajo el término “secretos” se incluyen claves API, contraseñas, tokens de acceso, credenciales de bases de datos y otros datos sensibles que, por buenas prácticas, deberían almacenarse exclusivamente en gestores de secretos o bóvedas seguras.
En comparación con un estudio similar realizado en Bitbucket —donde se revisaron 2,6 millones de repositorios y se detectaron 6212 secretos válidos—, la filtración en GitLab resulta significativamente más extensa. La densidad de secretos expuestos por repositorio en GitLab es aproximadamente un 35 % superior, lo que indica deficiencias más acusadas en la gestión de credenciales dentro de esta plataforma y de los flujos de trabajo que la rodean.
Metodología de escaneo: automatización a escala con TruffleHog y AWS
Para localizar los secretos, el estudio empleó TruffleHog, una herramienta de código abierto diseñada para detectar claves, contraseñas y tokens tanto en el historial de Git como en el contenido de los archivos. Esta solución se integró en una infraestructura totalmente automatizada en la nube.
Arquitectura técnica del análisis de GitLab
Mediante la API pública de GitLab, un script en Python iteró sobre todos los proyectos ordenados por su identificador, enviando cada repositorio a una cola de tareas en AWS Simple Queue Service (SQS). Para cada repositorio, una función AWS Lambda se encargó de invocar TruffleHog, ejecutar el escaneo y registrar los resultados.
El proceso completo se ejecutó en poco más de 24 horas, con un coste aproximado de 770 dólares estadounidenses en recursos de cómputo. Este dato es especialmente relevante desde el punto de vista de ciberseguridad: la explotación masiva de repositorios públicos ya no requiere grandes recursos estatales. Cualquier actor motivado —incluidos potenciales atacantes— puede replicar este tipo de análisis a bajo coste y a gran escala.
Tipos de secretos expuestos y servicios comprometidos
La mayoría de los secretos identificados datan de 2018 en adelante, pero también se hallaron claves emitidas en 2009 que seguían siendo válidas. Este tipo de credenciales antiguas suelen estar asociadas a sistemas heredados (legacy), con menor supervisión y medidas de seguridad más débiles, lo que incrementa el riesgo de compromiso silencioso y prolongado.
Servicios más afectados: GCP, bases de datos, bots y APIs de IA
Entre los secretos expuestos, destacaron especialmente las credenciales de Google Cloud Platform (GCP), con más de 5200 casos detectados. Además, se encontraron:
— claves y cadenas de conexión de MongoDB;
— tokens de bots de Telegram;
— claves de acceso a OpenAI y otras plataformas de inteligencia artificial;
— más de 400 secretos vinculados directamente a servicios de GitLab.
La combinación de estos elementos puede ser suficiente para comprometer por completo la infraestructura de una organización: acceso no autorizado a bases de datos, despliegue o borrado de recursos en la nube, uso fraudulento de APIs de IA o envío de campañas de phishing mediante bots legítimos.
Respuesta de las organizaciones y rol de los programas de bug bounty
Dado que los secretos estaban asociados a 2804 dominios diferentes, la notificación manual a cada propietario resultaba impracticable. Para agilizar el proceso, se combinaron búsquedas web, scripts en Python y generación automatizada de avisos con ayuda de un modelo de lenguaje basado en IA.
Muchas organizaciones revocaron rápidamente las claves expuestas y las sustituyeron por nuevas, y una parte de los casos se canalizó a través de programas de bug bounty, que generaron en conjunto alrededor de 9000 dólares en recompensas para el investigador. No obstante, una fracción significativa de los secretos permanece accesible en repositorios públicos, lo que evidencia un problema estructural de gobernanza y cultura de seguridad.
Buenas prácticas de gestión de secretos en GitLab y entornos DevOps
La filtración en GitLab Cloud, sumada a incidentes similares en Bitbucket y en conjuntos de datos públicos, refuerza la idea de que el riesgo no es solo técnico, sino sobre todo organizativo. Entre las medidas clave para reducir la superficie de ataque destacan:
1. No almacenar secretos en repositorios de código. Las credenciales deben residir en gestores de secretos (servicios nativos de los proveedores cloud, HashiCorp Vault u otros). En el código solo deberían aparecer identificadores o referencias, nunca claves en texto claro.
2. Integrar el escaneo de secretos en el pipeline CI/CD. Herramientas como TruffleHog, Gitleaks y soluciones equivalentes deberían ejecutarse automáticamente en cada commit o merge request. Esto permite bloquear la introducción de claves y tokens antes de llegar a la rama principal.
3. Aplicar rotación frecuente de claves y tokens. Diseñar políticas de tokens de corta duración y rotación periódica automatizada limita el impacto de una filtración inadvertida, incluso cuando la clave queda registrada en el historial de Git.
4. Formar a los desarrolladores en seguridad y gestión de secretos. Muchos incidentes se originan en pruebas rápidas, depuración o “parches temporales” que nunca se eliminan. Es esencial reforzar la idea de que ningún repositorio es intrínsecamente seguro y que la exposición pública puede producirse por errores de configuración, accesos comprometidos o fugas en la cadena de suministro.
La situación observada en los repositorios públicos de GitLab Cloud envía un mensaje claro: la gestión de secretos debe convertirse en una prioridad estratégica para cualquier equipo de desarrollo y operaciones. Auditar de forma sistemática los repositorios —públicos y privados—, integrar escáneres de secretos en los flujos CI/CD y establecer procesos maduros de revocación y rotación de credenciales son pasos imprescindibles. Las organizaciones que adopten estas prácticas de forma proactiva reducirán de manera significativa la probabilidad de que la próxima filtración masiva de claves y tokens afecte directamente a su infraestructura.
