La última edición del informe GitGuardian State of Secrets Sprawl 2026 confirma una tendencia preocupante: la exposición de secretos (API keys, tokens, credenciales en texto claro) en código e infraestructura no solo no se reduce, sino que se acelera. Solo en 2025 se identificaron 29 millones de nuevos secretos en repositorios públicos de GitHub, un incremento del 34% interanual, el mayor registrado hasta la fecha.
Secretos expuestos en GitHub e IA: una combinación explosiva
Desde 2021, el volumen de secretos filtrados ha crecido un 152%, mientras que la base de desarrolladores públicos en GitHub aumentó aproximadamente un 98%. La brecha refleja un efecto combinado: más desarrolladores, ciclos de entrega más rápidos y la adopción masiva de herramientas de IA generativa de código, que a menudo replican patrones inseguros o incluso incorporan credenciales reales de ejemplos previos.
El segmento de servicios de IA y LLM destaca especialmente. En 2025 se registraron 1 275 105 secretos relacionados con IA, un crecimiento del 81% respecto a 2024. Ocho de las diez categorías de claves que más crecieron están vinculadas al ecosistema de IA: interfaces de búsqueda y retrieval (por ejemplo, Brave Search, con incrementos superiores al 1000%), plataformas de orquestación como Firecrawl y backends gestionados tipo Supabase. Cada nuevo componente de integración LLM introduce una identidad de máquina adicional y amplía la superficie de ataque.
Repositorios internos y herramientas colaborativas: riesgo crítico oculto
A pesar de que la atención mediática suele centrarse en GitHub público, los datos más sensibles residen en entornos privados. El estudio muestra que el 32,2% de los repositorios internos contienen al menos un secreto embebido, frente a solo un 5,6% de los repositorios públicos. Además, en el entorno interno predominan tokens de CI/CD, credenciales de nube y contraseñas de bases de datos, es decir, activos de alto valor que facilitan el movimiento lateral tras una intrusión inicial.
La filtración de secretos se ha desplazado también hacia las herramientas colaborativas corporativas. En el 28% de los incidentes de 2025, las fugas se produjeron exclusivamente en plataformas como Slack, Jira o Confluence. Estas exposiciones resultan más críticas: el 56,7% de los secretos detectados solo en herramientas colaborativas fueron clasificados como críticos, frente al 43,7% cuando la fuga se limitó a repositorios. El motivo es operativo: los equipos comparten credenciales durante la resolución de incidentes, depuración o onboarding, a menudo sin controles técnicos ni políticas claras.
GitLab, contenedores y un perímetro cada vez más difuso
En 2025 se descubrieron miles de instancias self-hosted de GitLab y Docker Registry expuestas accidentalmente a Internet. El análisis de estos sistemas reveló alrededor de 80 000 secretos, de los cuales 10 000 seguían siendo válidos. Los contenedores resultan especialmente sensibles: el 18% de las imágenes Docker analizadas contenían secretos y, de estos, el 15% seguían activos. En repositorios GitLab, se encontraron secretos en el 12% de los proyectos, con el mismo porcentaje permaneciendo válido.
Los secretos embebidos en imágenes de contenedor son especialmente peligrosos porque se despliegan muy cerca de entornos de producción y suelen «congelarse» en el artefacto, quedando fuera de los flujos de rotación habituales. Esto evidencia cómo el límite entre lo privado y lo público se ha vuelto altamente poroso: bastan errores mínimos de configuración para exponer registros y repositorios internos.
Remediación deficiente: secretos válidos durante años
Detectar un secreto no equivale a neutralizarlo. Al reevaluar en 2026 secretos marcados como válidos en 2022, GitGuardian comprobó que el 64% seguían siendo explotables cuatro años después. Esto indica que la rotación y revocación de claves raramente están automatizadas o integradas en los procesos diarios de desarrollo y operaciones.
Los secretos incrustados en pipelines de compilación, variables de CI, imágenes de contenedor o integraciones con terceros son complejos de sustituir sin arriesgar interrupciones de servicio. Para muchas organizaciones, el coste percibido de «no tocar nada» es menor que el de una rotación agresiva, lo que genera una ventana de oportunidad prolongada para los atacantes. Buenas prácticas como las recogidas por OWASP en su Secret Management Cheat Sheet siguen sin aplicarse de forma sistemática.
Supply chain, agentes de IA y nuevas superficies de ataque
Las ataques a la cadena de suministro de software (supply chain) se han consolidado como vector clave de exfiltración de secretos. En la campaña Shai-Hulud 2, el acceso a estaciones de trabajo de desarrolladores permitió identificar 294 842 apariciones de secretos en 6 943 sistemas, correspondientes a 33 185 valores únicos. Cada secreto activo aparecía, de media, en ocho ubicaciones distintas de una misma máquina: archivos .env, historial de consola, configuración de IDE, tokens en caché o artefactos de compilación. Resulta significativo que el 59% de los equipos comprometidos fueran runners de CI/CD, no portátiles personales.
Un ataque más reciente contra el paquete LiteLLM repitió el patrón: el código malicioso recolectaba claves SSH, credenciales de nube y tokens API en estaciones de desarrollo, ahora fuertemente vinculadas a herramientas de IA. Paralelamente, el auge del Model Context Protocol (MCP) y marcos similares para agentes de IA introduce otra vía de riesgo: en 2025 se detectaron 24 008 secretos únicos en configuraciones MCP públicas en GitHub, de los cuales 2 117 seguían siendo válidos. Configuraciones en JSON locales, banderas de ejecución y ficheros de config se están convirtiendo en contenedores habituales de credenciales.
De la búsqueda de secretos a la gestión de identidades no humanas (NHI)
El problema deja de ser «¿hay secretos en mi código?» para convertirse en tres preguntas estratégicas: ¿cuántas identidades no humanas (Non‑Human Identities, NHI) existen en la organización, quién es su responsable y a qué recursos acceden? Esto incluye cuentas de servicio, trabajos de CI/CD, agentes de IA, integraciones de terceros y cualquier entidad que utilice un secreto para autenticarse.
Las organizaciones que dependen de IA y DevOps intensivo necesitan evolucionar desde la detección puntual hacia una gestión continua del ciclo de vida de las NHI. Los pilares de este enfoque incluyen: minimizar los secretos estáticos de larga duración; adoptar acceso de corta vida basado en identidad (por ejemplo, tokens efímeros y credenciales bajo demanda); normalizar el uso de secret vaults como patrón estándar de desarrollo; y tratar cada cuenta de servicio, job de CI y agente de IA como un elemento pleno de gobernanza IAM, con alta trazabilidad y caducidades definidas.
Los datos del informe muestran que los secretos ya no son incidentes aislados, sino un factor estructural de riesgo ligado al crecimiento de la IA, la automatización y el desarrollo distribuido. Las organizaciones que amplíen su visibilidad más allá de los repositorios públicos —hacia sistemas internos, herramientas colaborativas, registros de contenedores y estaciones de trabajo de desarrolladores— y automaticen la rotación y revocación de claves estarán mejor posicionadas frente a la próxima ola de ataques. Es recomendable iniciar cuanto antes un programa de secret management y NHI que combine inventario continuo, escaneo automatizado en CI/CD, vaults centralizados, formación de equipos y revisiones periódicas de configuración en GitHub, GitLab, Slack, Docker y servicios de IA. Quienes integren la protección de secretos en el núcleo de su estrategia de ciberseguridad obtendrán no solo mayor protección, sino también una resiliencia operativa superior a largo plazo.
