El 82% de Brechas Ocurre con Secretos en el Código, no en Vault

La inversión en bóvedas digitales sofisticadas no compensa las deficiencias estructurales en la gestión de identidades y accesos (IAM). Varias empresas destinan presupuestos significativos a implementar HashiCorp Vault mientras dejan brechas básicas en la seguridad de Active Directory (AD). Este enfoque centrado en la herramienta, y no en el riesgo, permite que el acceso privilegiado quede sin gestionar en entornos híbridos y distribuidos.

Active Directory sostiene la identidad corporativa desde hace más de dos décadas, pero su protección sigue siendo un problema sin resolver en la mayoría de las organizaciones. Los atacantes no se limitan a las credenciales administrativas tradicionales: explotan cuentas de servicio, operadores de DNS o administradores de aplicaciones de nivel 1 para iniciar ciclos de ataque más largos. Las identidades no humanas crecen a un ritmo del 18% anual, lo que amplía esta superficie de exposición.

El modelo tradicional de almacenar y rotar secretos dentro de una bóveda tiene límites de escalabilidad. Una organización gestiona en promedio 31,500 secretos por cada 100 aplicaciones, según estimaciones del sector, y la incorporación manual de ese volumen a un Vault se vuelve un obstáculo operativo. Esa fricción lleva a los equipos de ingeniería a saltarse los controles de seguridad y mantener secretos en archivos de configuración locales o en el código fuente por comodidad.

Investigaciones recientes identificaron nueve vulnerabilidades de día cero en HashiCorp Vault, entre ellas una ejecución remota de código (RCE) que permitía tomar el control total del sistema. Estos fallos permitían eludir bloqueos de cuentas, evadir controles de políticas y escalar privilegios de administrador a nivel de root.

Un caso concreto es la escalación de privilegios mediante la normalización de nombres de políticas. La capa de validación bloqueaba la asignación de la política 'root', pero la capa de ejecución normalizaba cadenas como ' root' (con espacio) o 'ROOT', lo que permitía a un usuario obtener privilegios totales sin activar alarmas. El sistema de protección más robusto puede quedar sin efecto si la lógica interna admite ese tipo de desajuste.

Recomendado Ciberseguridad

¿Por qué las contraseñas están desapareciendo? Todo sobre la revolución de las passkeys

Hace 43 días Leer ahora

La gestión de secretos en el ciclo de vida del desarrollo de software (SDLC) es, con frecuencia, el punto donde la teoría de seguridad se fragmenta. En el ecosistema .NET, la herramienta user-secrets se usa para evitar guardar datos sensibles en el código fuente durante el desarrollo, pero no cifra esos secretos en la máquina local. Si el flujo de trabajo no es riguroso, existe un riesgo real de que terminen en producción.

Las variables de entorno, otra alternativa habitual, suelen almacenarse como texto plano sin cifrar; si el proceso o la máquina se ven comprometidos, quedan accesibles de inmediato. El 82% de las brechas de datos que involucran credenciales robadas muestra secretos integrados directamente en el código o en archivos de configuración sin protección.

En plataformas como GitHub, miles de secretos únicos nuevos se filtran cada día y afectan a más de 100,000 repositorios. Los desarrolladores suben credenciales por error en promedio una vez cada 2.5 días. Entre los tipos de secretos más expuestos figuran las claves de API (66.9%), las credenciales de bases de datos (13.4%) y las claves privadas (11.2%).

Eliminar un secreto mediante un nuevo commit no resuelve el problema, porque la credencial sigue accesible en el historial de Git. Incluso si se reescribe el historial del repositorio, existen métodos para recuperar contenidos de commits eliminados a partir del ID de SHA-1 o mediante la API de eventos de GitHub. Esa persistencia deja claro que el error humano, combinado con una arquitectura que prioriza la velocidad de desarrollo sobre la seguridad, anula la inversión en Vault si el flujo de trabajo inicial falla.

TruffleHog, uno de los escáneres más usados para prevenir fugas, registró una tasa de detección efectiva de solo el 25% en ciertos conjuntos de datos de GitHub. La mayoría de estas herramientas no identifican secretos de formato variable o carecen de una validación rigurosa de los hallazgos, lo que produce un volumen alto de falsos positivos o una confianza mal fundada cuando hay falsos negativos.

La evolución de la seguridad de aplicaciones exige pasar de un modelo centrado en la bóveda hacia el acceso basado en la identidad. En lugar de distribuir secretos estáticos de larga duración, las organizaciones pueden priorizar identidades de carga de trabajo (workload identity) y autorización en tiempo de ejecución. Este cambio se apoya en tres pilares.

Las implementaciones de JIT reducen la superficie de ataque en un 74%, y disminuyen el tiempo de exposición de cuentas privilegiadas de una disponibilidad continua a solo unas pocas horas al mes. Eliminar los privilegios estáticos previene el 91% de las brechas exitosas, en comparación con los modelos de acceso tradicionales.

Recomendado Ciberseguridad

RaaS: cómo el cibercrimen se convirtió en una industria de suscripción que cualquiera puede contratar

Hace 43 días Leer ahora

Integrar la gestión de secretos en los pipelines de CI/CD reduce la deuda técnica de seguridad. Clasificar el código en categorías específicas, como política como código y observabilidad como código, permite aplicar las prácticas habituales de ingeniería de software también a la seguridad.

El estándar NIST SP 800-204C recomienda que el pipeline de CI/CD no maneje directamente los secretos siempre que sea posible. Es preferible que el consumidor final, el microservicio o la aplicación, recupere el secreto usando su propia identidad de servicio. Cuando los secretos deben pasar por el pipeline, conviene cifrarlos y limitarlos a cada entorno (desarrollo, pruebas, producción), de modo que una fuga en uno no comprometa los demás.

Para mitigar los riesgos de una gestión de secretos deficiente, el endurecimiento (hardening) de la infraestructura debe seguir controles estrictos. El estándar NIST SP 800-53 Rev. 5 define salvaguardas para proteger la confidencialidad y la disponibilidad de la información.

La gestión de secretos no puede tratarse como una solución aislada ni como un parche para una infraestructura de identidad fragmentada. Vault, por necesaria que sea, resulta ineficaz si los desarrolladores siguen integrando secretos en el código fuente o si Active Directory carece de monitoreo contra movimientos laterales. La cifra del 82% de brechas con credenciales embebidas en el código no es un problema de herramientas, sino de procesos: ninguna bóveda corrige un flujo de trabajo que sigue tratando el secreto como un dato que se copia y pega.

La seguridad real está en integrar el control de acceso dentro del ciclo de vida del software, priorizando la identidad efímera sobre el almacenamiento estático de credenciales. El siguiente paso para una organización no es comprar más herramientas, sino rediseñar los procesos para que la confianza en el sistema sea verificable y no simplemente asumida.