Los atacantes prefieren el camino de menor resistencia: ¿por qué forzar la entrada cuando se puede iniciar sesión? Eso es lo que hace que las credenciales activas sean tan valiosas. Una contraseña, token o clave API filtrada no solo revela datos sensibles: ofrece una vía de acceso. No se necesita ninguna vulnerabilidad ni cadena de escalada de privilegios. Si la credencial es válida, el atacante puede usarla directamente, y la sesión parecerá una actividad normal.

Esto desplaza la pregunta de '¿dónde pueden infiltrarse los atacantes?' a '¿dónde suelen acumularse las claves utilizables?'. Cada vez más, la respuesta es el portátil del desarrollador: una de las máquinas más instrumentadas que poseen las empresas, y uno de los lugares más fáciles para que las credenciales pasen desapercibidas.

El endpoint es una mina de oro para el acceso

Las máquinas de los desarrolladores acumulan secretos porque el trabajo local se optimiza para la velocidad. Las CLI en la nube, los registros de contenedores, los gestores de paquetes y los clientes de control de versiones necesitan credenciales para mantener el flujo de trabajo. Esas credenciales suelen terminar almacenadas localmente, en archivos de configuración, cachés de tokens, asistentes de credenciales o almacenes específicos de herramientas, convirtiendo la conveniencia en acumulación. Un secreto extraído de un almacén para uso local puede dejar una copia olvidada.

Los agentes de IA han multiplicado exponencialmente esta acumulación. Leen y reescriben configuraciones, invocan herramientas, generan registros y operan a través de servidores locales e integraciones, creando aún más lugares donde pueden depositarse credenciales. Cada nuevo agente o servidor MCP puede introducir otra integración, token o identidad delegada que gestionar. El código asistido por IA ha mostrado tasas de fuga de secretos aproximadamente el doble de la línea base de GitHub, y GitGuardian State of Secrets Sprawl 2026 catalogó 24,008 secretos únicos en archivos de configuración MCP públicos solo en 2025.

Muchas de esas credenciales sobreviven al flujo de trabajo que las creó. Las claves estáticas no están vinculadas a una sesión y no desaparecen cuando la tarea termina. Esa persistencia ayuda a explicar por qué el 64% de los secretos expuestos en 2022 seguían siendo válidos en 2026. Una clave escrita para un flujo de trabajo local único puede seguir siendo utilizable durante años a menos que alguien la encuentre y la rote.

Los atacantes ya entienden el valor del endpoint

El manual del atacante se ha puesto al día con el lugar donde reside el acceso. Campañas recientes en la cadena de suministro no han necesitado un día cero para causar daños. Han comprometido las herramientas en las que confían los desarrolladores, utilizando ese punto de apoyo para exfiltrar secretos de entornos locales, trabajos de CI y flujos de trabajo de desarrolladores.

Shai-Hulud y sus muchas variantes se propagaron a través de paquetes npm, cosechando credenciales de los entornos a los que llegaba y utilizando tokens robados para propagarse más. El ataque Nx 's1ngularity' escaneó sistemas infectados en busca de tokens de GitHub, claves npm, claves SSH privadas, variables de entorno e incluso archivos de billetera, y luego utilizó el acceso robado para exponer más repositorios. GhostAction trasladó la misma lógica a GitHub Actions, donde flujos de trabajo maliciosos exfiltraban credenciales de PyPI, npm, DockerHub y AWS desde entornos CI.

El patrón es inquietantemente simple: comprometer la ruta del software, encontrar las credenciales y luego usarlas para moverse, publicar, exponer o persistir. Estos ataques no necesitaron forzar la entrada. El acceso ya existía en los flujos de trabajo de desarrolladores y automatización. Una vez que los atacantes alcanzaban esos entornos, solo tenían que copiar las claves.

El endpoint está vigilado, pero no para credenciales

El portátil del desarrollador que contiene este acceso ya es uno de los dispositivos más monitorizados de la empresa. La detección y respuesta de endpoints (EDR) vigila procesos maliciosos, comportamientos sospechosos y signos de compromiso. La gestión de dispositivos móviles (MDM) verifica el cumplimiento, la configuración y las políticas del dispositivo.

Ambos son valiosos. Pero ninguno fue diseñado para responder a la pregunta de las credenciales: ¿qué claves activas hay en esta máquina, dónde están, qué desbloquean y siguen siendo válidas?

Esa pregunta importa más cuando algo sale mal. Si una máquina de desarrollador se ve comprometida, los respondedores necesitan saber qué acceso puede haber quedado expuesto antes de poder contenerlo. Sin un inventario, tienen que reconstruir la respuesta a posteriori, a través de archivos, historial de shell, cachés de herramientas, configuraciones de IDE y artefactos de agentes.

Cada hora que se pasa reconstruyendo esa imagen es tiempo en que los atacantes aún pueden tener acceso utilizable. IBM descubrió que las brechas que involucran credenciales comprometidas tardan un promedio de 246 días en identificarse y contenerse. En estos casos, EDR y MDM pueden haber hecho su trabajo; el problema es que la capa de credenciales nunca fue su trabajo ver.

Cerrando el círculo en la capa de credenciales

Un inventario de la capa de credenciales solo importa si un equipo puede actuar sobre él. Una vez que las claves activas en las máquinas de los desarrolladores son visibles, surge la pregunta más difícil de inmediato: ¿qué credenciales se pueden eliminar ahora, cuáles necesitan una rotación cuidadosa y cuáles son demasiado arriesgadas de tocar sin un propietario involucrado?

Ahí es donde la mayoría de los programas se estancan. Una sola clave rara vez reside en un solo lugar. La misma credencial puede vivir en un perfil de shell, un archivo .env del proyecto, una configuración de IDE y múltiples cachés de herramientas, para luego aparecer en varias máquinas. También puede autenticarse como una cuenta de servicio que ningún desarrollador posee directamente. Sin esa imagen completa, la remediación se convierte en una conjetura operativa.

El montón solo se vuelve procesable cuando los equipos saben si cada clave es válida, qué desbloquea, dónde está cada copia y quién puede rotarla o revocarla de forma segura. Enriquecido de esa manera, las claves activas de mayor acceso suben a la cima, los propietarios son informados antes de que alguien toque lo que depende de producción, y las credenciales muertas se priorizan para limpieza.

Construir esa imagen antes de que algo salga mal facilita el peor momento. Cuando una máquina se ve involucrada en un incidente, las preguntas son siempre las mismas: ¿qué había en ella, a qué llega cada clave y qué revocamos primero? Un equipo que ya tiene la respuesta está haciendo triaje. Un equipo que la reconstruye a partir del historial de shell y cachés de herramientas mientras corre el reloj está haciendo arqueología.

Sin embargo, vale la pena dejar claro el límite. Esto es descubrimiento y priorización previa al incidente, no respuesta a incidentes. Una máquina en compromiso activo se aísla; el valor está en el inventario construido un martes cualquiera.

Hay una razón más por la que la capa de credenciales necesita visibilidad separada: gran parte de ella está fuera de los lugares que los equipos de seguridad ya escanean. En el análisis de endpoints de desarrolladores de GitGuardian, aproximadamente el 40% de las credenciales altas y críticas encontradas estaban en directorios de herramientas de IA y archivos de registro, ubicaciones que el escaneo tradicional de secretos a menudo pasa por alto. Developer Endpoint Protection fue diseñado para ese tipo de trabajo previo al incidente: credenciales activas en máquinas de desarrolladores, enriquecidas con validez, ubicación, propiedad y contexto de riesgo antes de que la máquina pase a formar parte de una investigación.

Lo que la máquina vigilada no puede ver

El riesgo no se crea cuando un atacante llega a la máquina. Ya estaba allí, escrito en archivos, cachés, registros y herramientas locales, esperando ser utilizado. Por eso la capa de credenciales debe entenderse antes de la alerta, antes de la investigación y antes de que el portátil se convierta en evidencia. Porque para entonces, las claves ya pueden estar en manos de otra persona.

Acerca de la autora: Carole Winqwist es la CMO de GitGuardian, la plataforma de visibilidad e inteligencia de secretos para asegurar las credenciales que permiten que el código, las máquinas y los agentes de IA accedan a sistemas y actúen como identidades confiables. Debido a que los atacantes no necesitan forzar la entrada cuando pueden iniciar sesión con una credencial válida, GitGuardian encuentra los secretos que importan en toda la superficie de secretos, dentro y fuera del perímetro, ya estén almacenados en vaults, guardados o filtrados. Revela su contexto y radio de explosión, y luego impulsa la remediación a escala antes de que una credencial se convierta en una vía de brecha. Confiado por más de 600,000 desarrolladores y empresas, incluyendo Snowflake, ING, BASF, Datadog, Bouygues Telecom, Euronext y Orange.