SentinelOne acaba de publicar su Reporte Anual de Amenazas 2026 y hay un dato que merece atención específica: el número de credenciales expuestas de empleados en compañías tecnológicas creció más de un 100% en un solo año. La causa principal no es un hackeo sofisticado. Es el uso de asistentes de IA para escribir código.
El mecanismo es más mundano de lo que parece. Un desarrollador usa GitHub Copilot, Cursor o cualquier otro asistente para generar código rápido. En el proceso, copia y pega fragmentos que contienen claves API, tokens de acceso o credenciales de entornos de prueba. El asistente no filtra esa información: simplemente trabaja con lo que le das. El código termina en un repositorio, a veces público, a veces privado pero con permisos mal configurados. Y ahí están las credenciales, esperando a que alguien las encuentre.
El problema no es nuevo, pero la escala sí
Llevar credenciales hardcodeadas al código fuente es uno de los errores más viejos del desarrollo de software. GitGuardian lleva años publicando informes sobre esto: en 2022 ya detectaban millones de secretos expuestos en GitHub cada año. Lo que ha cambiado es la velocidad a la que se genera código, y con ella, la velocidad a la que se cometen estos errores.
Los asistentes de IA han multiplicado la productividad de los equipos de desarrollo, pero también han acelerado el ciclo completo, incluidos los fallos. Un desarrollador que antes tardaba dos horas en escribir un módulo ahora lo hace en veinte minutos. Si ese módulo incluye una credencial en texto plano, esa credencial llega al repositorio veinte minutos después de escribirla, no dos horas.
SentinelOne documentó más de 100.000 credenciales expuestas en los principales proveedores de nube durante los últimos doce meses. El 65% de las empresas de IA analizadas sufrieron filtraciones a través de GitHub. No es un problema marginal de startups descuidadas: afecta a organizaciones con equipos de seguridad dedicados.
Qué tipo de credenciales son las más expuestas
No todas las credenciales filtradas tienen el mismo impacto. Las más críticas son las claves API de servicios de nube (AWS, Azure, Google Cloud) con permisos amplios: con una de esas, un atacante puede levantar infraestructura a cargo de la víctima, exfiltrar datos de almacenamiento o moverse lateralmente por el entorno. Las segundas en criticidad son los tokens de acceso a servicios internos: bases de datos, plataformas de CI/CD, registros de contenedores.
Los tokens de acceso personal de GitHub también aparecen con frecuencia, y son especialmente problemáticos porque dan acceso al propio código fuente, cerrando el círculo: con ese token, un atacante puede leer repositorios privados y potencialmente encontrar más credenciales.
Cómo se detecta y qué se puede hacer
La detección temprana es la única defensa práctica. GitHub tiene su propio sistema de Secret Scanning que bloquea automáticamente ciertos patrones de credenciales antes de que lleguen al repositorio, y avisa al propietario cuando detecta algo. El problema es que no cubre todos los formatos posibles y que muchas organizaciones no tienen activada la protección en todos sus repositorios.
Las herramientas especializadas como Gitleaks, TruffleHog o el propio servicio de GitGuardian añaden una capa adicional de detección, tanto en tiempo real como en auditorías de repositorios existentes. Para equipos que usan asistentes de IA intensivamente, integrarlo en el pipeline de CI/CD es una medida con una relación coste-beneficio muy clara.
La otra medida es cultural: tratar las credenciales como contraseñas, no como constantes. Nunca en el código. Siempre en variables de entorno o gestores de secretos como HashiCorp Vault o AWS Secrets Manager. Es básico, pero sigue siendo el punto de fallo más común.
La IA está haciendo el trabajo más rápido. También está haciendo los errores más rápido, y en mayor cantidad. El que no ajuste sus procesos de seguridad a esa nueva velocidad lo va a notar antes o después.
0 Comentarios