 14 de junio de 2025  El hacker NewsSecrets Management / SaaS Security Mientras que el phishing y el ransomware dominan los titulares, otro riesgo crítico persiste silenciosamente en la mayoría de las empresas: repositorios de GIT expuestos que filtran datos confidenciales. Un riesgo que crea silenciosamente el acceso a la sombra en Core Systems Git es la columna vertebral del desarrollo moderno de software, alojando millones de repositorios y atendiendo a miles de organizaciones en todo el mundo. Sin embargo, en medio del ajetreo diario del código de envío, los desarrolladores pueden dejar sin darse cuenta las claves API, los tokens o las contraseñas en los archivos de configuración y los archivos de código, entregando efectivamente a los atacantes las claves del reino. Esto no se trata solo de pobre higiene; Es un riesgo sistémico y creciente de la cadena de suministro. A medida que las amenazas cibernéticas se vuelven más sofisticadas, también lo hacen los requisitos de cumplimiento. Los marcos de seguridad como NIS2, SOC2 e ISO 27001 ahora exigen pruebas de que las tuberías de entrega de software se endurecen y se controlan el riesgo de terceros. El mensaje es claro: asegurar sus repositorios Git ya no es opcional, es esencial. A continuación, observamos el perfil de riesgo de credenciales y secretos expuestos en repositorios de código público y privado, cómo se ha utilizado este vector de ataque en el pasado y qué puede hacer para minimizar su exposición. El paisaje de amenazas de repo GIT El paisaje de amenazas que rodea los repositorios de GIT se está expandiendo rápidamente, impulsada por una serie de causas: la creciente complejidad de las prácticas de DevOps, la dependencia generalizada de la dependencia de las plataformas de control de versiones públicas como el error humano de Github y todas las configuraciones erróneas que implican: desde los controles de acceso mal aplicados hasta los entornos de prueba olvidados de la producción, no es una sorpresa, ya que el desarrollo de los velocidad de los velocidad aumenta, lo que hace las oportunidades de los ataques de desarrollo, lo que aumenta las oportunidades de los ataques para el desarrollo de las oportunidades de desarrollo, lo que aumenta las oportunidades para el desarrollo de los ataques de desarrollo. Repositorios de código expuesto. Solo Github informó más de 39 millones de secretos filtrados en 2024, un aumento del 67% respecto al año anterior. Estos incluían credenciales de nubes, tokens API y claves SSH. La mayoría de estas exposiciones se originan en: cuentas de desarrolladores personales abandonados o bifurcados proyectos mal conformados o repositorios no auditados para atacantes, estos no son solo errores, son puntos de entrada. Los repos de git expuestos ofrecen una vía directa de baja fricción en sistemas internos y entornos de desarrolladores. Lo que comienza como una pequeña supervisión puede convertirse en un compromiso completo, a menudo sin activar ninguna alerta. ¿Cómo aprovechan los atacantes los repositorios de GIT expuestos? Las herramientas y escáneres públicos hacen que sea trivial cosechar secretos de repositorios de GIT expuestos, y los atacantes saben cómo girar rápidamente del código expuesto a la infraestructura comprometida. Una vez dentro de un repositorio, los atacantes buscan: secretos y credenciales: claves API, tokens de autenticación y contraseñas. A menudo oculto a simple vista dentro de los archivos de configuración o el historial de confirmación. Infraestructura Intel: detalles sobre sistemas internos como nombres de host, IP, puertos o diagramas arquitectónicas. Lógica de negocios: código fuente que puede revelar vulnerabilidades en la autenticación, el manejo de la sesión o el acceso a la API. Estas ideas se arman luego para: Acceso inicial: los atacantes usan credenciales válidas para autenticarse en: Entornos en la nube: por ejemplo, roles de AWS IAM a través de claves de acceso expuesto, bases de datos de principios de servicio de Azure – EG, MongoDB, PostgreSQL, MySQL usando Strings Harded Connected Straings SaaS Platforms – Aprovechando API tokens encontrados en los archivos de configuración o Historial de comisión de comandantes: Historial de compromiso: Historial de compromiso: Historial de compromisos: Historial de ataques de Connectores: Enumerating internal APIs using exposed OpenAPI/Swagger specs Accessing CI/CD pipelines using leaked tokens from GitHub Actions, GitLab CI, or Jenkins Using misconfigured permissions to move across internal services or cloud accounts Persistence and exfiltration: To maintain access and extract data over time, they: Create new IAM users or SSH keys to stay embedded Deploy malicious Lambda functions or Los contenedores para combinar con las cargas de trabajo normales exfiltran los datos de los cubos S3, el almacenamiento de blob de Azure o las plataformas de registro como CloudWatch y Log Analytics, una única clave AWS filtrada puede exponer una huella de la nube completa. Un archivo .git/config o compromiso olvidado aún puede contener credenciales en vivo. Estas exposiciones a menudo omiten las defensas perimetrales tradicionales por completo. Hemos visto a los atacantes girar desde repositorios de GIT expuestos → a las computadoras portátiles de desarrolladores → a redes internas. Esta amenaza no es teórica, es una cadena de matar que hemos validado en entornos de producción en vivo usando Pentera. Las estrategias de mitigación recomendadas que reducen el riesgo de exposición comienzan con lo básico. Si bien ningún control único puede eliminar los ataques basados en GIT, las siguientes prácticas ayudan a reducir la probabilidad de que los secretos se filtren y limiten el impacto cuando lo hacen. 1. Secretos de la tienda de gestión de la tienda fuera de su base de código utilizando soluciones de gestión secreta dedicadas como Hashicorp Vault (código abierto), AWS Secrets Manager o Azure Key Vault. Estas herramientas proporcionan almacenamiento seguro, control de acceso de grano fino y registro de auditorías. Evite los secretos de codificación dura en los archivos de origen o los archivos de configuración. En su lugar, inyecte secretos en tiempo de ejecución a través de variables de entorno o API seguras. Automatice la rotación secreta para reducir la ventana de exposición. 2. Code Hygiene aplica las políticas estrictas .Gitignore para excluir archivos que pueden contener información confidencial, como .env, config.yaml o credencials.json. Integre herramientas de escaneo como Gitleaks, Talisman y Git-Secrets en flujos de trabajo de desarrolladores y tuberías de CI/CD para atrapar secretos antes de que se comprometan. 3. Los controles de acceso hacen cumplir el principio de menor privilegio en todos los repositorios de GIT. Los desarrolladores, herramientas de CI/CD e integraciones de terceros solo deben tener el acceso que necesitan, ya no. Use tokens de corta duración o credenciales limitados en el tiempo siempre que sea posible. Haga cumplir la autenticación multifactor (MFA) y el inicio de sesión único (SSO) en las plataformas GIT. Auditar regularmente los registros de acceso al usuario y la máquina para identificar privilegios excesivos o comportamientos sospechosos. Encuentre los datos de GIT expuestos antes de que los atacantes hagan los repositorios de GIT expuestos no son un riesgo en el borde, sino un vector de ataque convencional, especialmente en entornos de DevOps de movimiento rápido. Si bien los escáneres secretos y las prácticas de higiene son esenciales, a menudo no tienen la imagen completa. Los atacantes no solo leen tu código; Lo están usando como un mapa para caminar directamente a su infraestructura. Sin embargo, incluso los equipos que usan las mejores prácticas se quedan ciegos a una pregunta crítica: ¿podría un atacante usar esta exposición para entrar? Asegurar sus repositorios requiere más que solo controles estáticos. Pide validación continua, remediación proactiva y mentalidad de un adversario. A medida que el cumplimiento exige que las superficies de ataque se expandan, las organizaciones deben tratar la exposición del código como una parte central de su estrategia de seguridad y no como una ocurrencia tardía. Para obtener más información sobre cómo su equipo puede hacer esto, unirse al seminario web, están fuera para GIT el 23 de julio de 2025 ¿Encontró este artículo interesante? Este artículo es una pieza contribuida de uno de nuestros valiosos socios. Síganos en Twitter  y LinkedIn para leer más contenido exclusivo que publicamos.