Los números que deberían enterrar la conversación de “ya lo arreglamos después”

El informe State of Secrets Sprawl 2026 de GitGuardian contabilizó 28,65 millones de secretos hardcodeados nuevos añadidos a commits públicos de GitHub solo en 2025, un aumento interanual del 34% y el mayor salto en un solo año que la empresa ha registrado. Desde 2021, los secretos filtrados han crecido un 152% mientras que la población global de desarrolladores creció un 98%. Los secretos se filtran más rápido de lo que la gente escribe el código.

Los propios datos de seguridad de GitHub sitúan el total en más de 39 millones de secretos filtrados en su plataforma durante 2024. No son credenciales de prueba de proyectos de fin de semana. Son claves de producción, tokens de cuentas de servicio y secretos OAuth que permanecen en el historial de commits, los logs de CI y los canales de Slack, esperando ser recolectados.

El informe Cost of a Data Breach Report 2024 de IBM sitúa el coste medio de una brecha que involucra credenciales comprometidas en 4,88 millones de dólares por incidente, un aumento del 10% respecto al año anterior. El dato más doloroso operativamente es la ventana de detección: aproximadamente 219 días para identificar y contener una brecha en la nube. Son siete meses de movimiento lateral silencioso antes de que alguien lance una alerta.

Las herramientas de IA son el acelerador, no un factor secundario

El problema de los secretos tiene un nuevo motor, y es el mismo flujo de trabajo de programación asistida por IA que supuestamente hace más rápidos a los equipos. GitGuardian encontró que los commits co-autorados por Claude Code filtraban secretos a aproximadamente el doble de la tasa base en GitHub público. En su punto máximo, en agosto de 2025, los commits asistidos por Claude Code alcanzaron 31 secretos por cada 1.000 commits, aproximadamente 2,4 veces la línea base humana.

El mecanismo no es misterioso. Los asistentes de programación con IA optimizan para que el código funcione, no para gestionar credenciales de forma segura. Cuando un desarrollador pide una integración rápida con una API de LLM, el asistente produce un fragmento que hardcodea la clave porque ese es el patrón en los datos de entrenamiento. El desarrollador lo sube. La clave aterriza en el control de versiones.

Los archivos de configuración MCP, el estándar emergente para la invocación de herramientas en pipelines agénticos, expusieron 24.008 secretos únicos en el período analizado por GitGuardian, en parte porque la documentación oficial fomentaba activamente los patrones de hardcoding. De las diez categorías de filtración de mayor crecimiento, ocho están ligadas a servicios de IA. La infraestructura de LLM, que abarca pipelines RAG, capas de orquestación y backends de almacenamiento vectorial, filtró cinco veces más rápido que los proveedores de modelos principales. La capa de IA del stack es actualmente el eslabón más débil en la higiene de credenciales.

Los secretos se filtran más rápido de lo que crece la base de desarrolladores, y las herramientas de IA están ampliando esa brecha. El radio de impacto de una sola clave expuesta abarca desde un shock en la facturación hasta un compromiso total de la cadena de suministro.

Los pipelines CI/CD como principal superficie de recolección

El incidente de tj-actions/changed-files en marzo de 2025 es la ilustración más clara y reciente de la dimensión de la cadena de suministro. Más de 23.000 repositorios dependían de esta GitHub Action ampliamente utilizada. Los atacantes comprometieron la dependencia compartida y la modificaron para exfiltrar secretos silenciosamente durante la ejecución del workflow. Los propios repositorios nunca fueron tocados; el ataque vivió enteramente en el grafo de dependencias.

La campaña TeamPCP de marzo de 2026 ejecutó el mismo manual en múltiples objetivos simultáneamente, comprometiendo Trivy (Aqua Security), Checkmarx KICS y AST GitHub Actions, y LiteLLM en cuatro oleadas. Los tokens robados durante el compromiso de Trivy se utilizaron cinco días después para acceder al pipeline de publicación en PyPI de LiteLLM. Una credencial, un pivote, un paquete envenenado llegando a los consumidores posteriores.

Cuando las credenciales de AWS quedan expuestas públicamente, los atacantes intentan acceder en un promedio de 17 minutos y, en casos documentados, en tan solo 9 minutos. La suposición de que una clave brevemente expuesta puede rotarse antes de que alguien la detecte no es sostenible. La ventana es más corta de lo que la mayoría de los runbooks de respuesta a incidentes pueden ejecutar.

Los repositorios internos agravan esto. GitGuardian encontró que tienen seis veces más probabilidades que los públicos de contener secretos hardcodeados, precisamente porque los equipos tratan las herramientas internas como implícitamente confiables. Y el 28% de los incidentes se originan completamente fuera de los repositorios de código, en Slack, Jira y herramientas de colaboración similares. La investigación de GitGuardian encontró secretos filtrados en el 2,4% de los canales corporativos de Slack analizados.

El fracaso en la remediación: el problema del 64%

El 64% de los secretos válidos filtrados en 2022 siguen sin revocarse en 2026. Esto no es principalmente un fallo técnico. La rotación es sencilla. El fallo es de gobernanza: sin propietario, sin un camino de remediación repetible, sin un inventario autoritativo de qué credenciales existen y a qué pueden acceder. Los equipos de seguridad encuentran la clave filtrada, abren un ticket y descubren que nadie sabe a qué servicio pertenece ni si rotarla romperá una dependencia de producción.

Una política de rotación de claves API que existe solo como documento es indistinguible de no tener ninguna política. Lo que hace cumplir la rotación es la automatización: credenciales de corta duración emitidas bajo demanda, gestores de secretos que rechazan claves estáticas en el límite del pipeline y runners de CI que no retienen credenciales persistentes entre trabajos.

Cómo es una respuesta arquitectónica real

Los controles operativos que reducen el radio de impacto son bien conocidos. La dificultad está en aplicarlos de forma consistente en un pipeline que abarca múltiples nubes, múltiples registros y un conjunto creciente de integraciones con servicios de IA.

  • Sin secretos estáticos en los runners de CI. Usa federación OIDC para intercambiar tokens de corta duración al inicio del trabajo. El runner nunca retiene una credencial que sobreviva al límite del trabajo.
  • Gestión centralizada de secretos con trazas de auditoría. Cada recuperación de secreto queda registrada, atribuida a una identidad de pipeline y es revisable. HashiCorp Vault, AWS Secrets Manager y Azure Key Vault soportan este patrón; la elección importa menos que su aplicación.
  • Escaneo pre-commit y pre-push. Herramientas como ggshield de GitGuardian o truffleHog se ejecutan localmente antes de que nada llegue al remoto. Esto captura la mayoría de los commits accidentales antes de que entren en el historial que los atacantes analizan.
  • Fijación de dependencias con verificación por hash. Las campañas de tj-actions y TeamPCP explotaron referencias de actions sin fijar. Fija cada action externa a un SHA de commit, no a una etiqueta mutable.
  • Aislamiento del radio de impacto. Las credenciales deben llevar solo los permisos que el trabajo realmente necesita. Una credencial de despliegue que también puede leer todo tu almacén de secretos es un único punto de compromiso total.

Arquitectura de red y la ruta de exfiltración de credenciales

Una dimensión de la higiene de credenciales que rara vez aparece en la conversación sobre herramientas es la ruta de red por la que viajan las credenciales exfiltradas. Cuando un runner de CI comprometido llama a un endpoint controlado por el atacante, ese tráfico cruza la internet pública a menos que el pipeline se ejecute dentro de un perímetro de red con controles de egreso. Operamos 44 puntos de presencia en Europa y Oriente Medio, con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en cada sitio. Esa densidad de peering significa que las cargas de trabajo de los clientes pueden ejecutar pipelines CI/CD con rutas privadas y de baja latencia hacia las APIs de nube, mientras el egreso a endpoints públicos arbitrarios queda restringido a nivel de red, eliminando un vector de exfiltración significativo antes de que se invoque cualquier control a nivel de aplicación.

La infraestructura soberana también cambia el modelo de confianza IAM. Cuando el proveedor de nube opera bajo legislación europea y no es filial de una entidad extranjera, las políticas IAM que gobiernan quién puede emitir credenciales, quién puede leer los logs de auditoría y quién puede responder a un incidente están sujetas a la jurisdicción legal europea. Para las organizaciones bajo DORA o NIS2, esa claridad jurisdiccional no es un argumento de marketing; es un requisito que determina qué proveedores pueden estar en la ruta crítica de una carga de trabajo regulada.

La postura de higiene de credenciales que realmente se sostiene

El objetivo no es cero secretos filtrados. Dado el volumen de código asistido por IA y el ritmo de iteración de los pipelines, eso no es un objetivo realista. El objetivo es una postura en la que una credencial filtrada tenga una ventana de validez corta, un alcance de permisos reducido, una ruta de detección rápida y un proceso de revocación repetible. Esa combinación reduce el radio de impacto de un compromiso de la cadena de suministro a un incidente contenido.

Empieza por el problema del inventario: no puedes rotar lo que no puedes encontrar. Ejecuta un escaneo de secretos en tus repositorios, logs de CI y herramientas de colaboración antes de construir cualquier otra cosa. La tasa de fracaso en remediación del 64% existe porque los equipos descubren las filtraciones de forma reactiva. Un inventario autoritativo de secretos, mantenido por automatización en lugar de convención, es la base sobre la que se asienta todo lo demás.