En muchas organizaciones, el “dominio” ya no es el centro de gravedad. La identidad se fragmentó: Okta centraliza el acceso, GitHub concentra credenciales de automatización y permisos de cambio, y Microsoft sigue siendo crítico pero ya no es el único lugar donde se materializa el impacto. En ese contexto, la expansión de BloodHound para cubrir Okta y GitHub apunta a un problema operativo muy concreto: descubrir y priorizar rutas de ataque cuando el adversario no necesita moverse “dentro” de una red, sino entre identidades y relaciones de confianza.
Este cambio no es cosmético. Para un equipo de seguridad, pasar de “auditar configuraciones” a “ver rutas de ataque” significa discutir con producto y plataforma en términos de riesgo encadenado (qué combinación de accesos lleva a qué capacidad), no de hallazgos aislados. Y cuando el entorno real mezcla SSO, repos y automatización, esa visibilidad cruzada suele ser el factor que desbloquea remediaciones con impacto.
Qué cambia cuando BloodHound mira Okta y GitHub a la vez
Tradicionalmente, muchos programas de hardening trataban Okta como “la puerta” y GitHub como “herramienta de desarrollo”. El problema es que, en incidentes reales, la puerta y la herramienta se convierten en el mismo camino: una sesión en Okta, una asignación de app, un equipo en GitHub, un token o un workflow, y de ahí a acciones de alto impacto (cambios de código, exfiltración de secretos, publicación de artefactos, o modificación de pipelines).
La expansión de capacidades de BloodHound hacia Okta y GitHub permite modelar esas relaciones como un grafo de ataque: no solo quién tiene acceso a qué, sino qué combinaciones de permisos y vínculos habilitan un salto. En empresa, esto aterriza en preguntas operables: “Si comprometen a este usuario, ¿qué es lo peor que puede pasar en GitHub?” o “¿Qué grupo de Okta está abriendo el acceso a repos críticos sin que nadie lo haya explicitado?”.
Un efecto práctico es que baja el coste de priorización. En vez de abrir decenas de tickets por configuraciones “mejorables”, puedes concentrarte en rutas con impacto demostrable: por ejemplo, una cadena que termina en capacidad de modificar workflows en repositorios sensibles o administrar organizaciones/equipos que controlan permisos amplios. Eso suele reducir fricción con ingeniería porque la conversación deja de ser “cumplimiento” y pasa a ser “ruta concreta hacia un incidente”.
Escenarios de abuso realistas: del SSO en Okta al control efectivo en GitHub
El abuso típico no empieza con “admin global”. Empieza con acceso suficiente para engancharse al ecosistema: un usuario con MFA debilitado, una sesión persistente, o un grupo de Okta demasiado amplio asignado a la aplicación de GitHub. Cuando esa asignación se traduce en pertenencia a equipos con permisos de escritura o administración, el atacante no necesita explotar nada sofisticado: opera con permisos legítimos.
En GitHub, la capacidad de “hacer daño” no siempre es obvia para no especialistas. Un atacante con acceso de escritura a un repositorio que alimenta pipelines puede introducir cambios sutiles, modificar workflows o aprovechar secretos de Actions si la configuración lo permite. Aunque la empresa tenga revisiones de PR, hay rutas donde el control efectivo viene por otras vías: repos de infraestructura, repos de plantillas, repos donde se definen acciones reutilizables, o equipos con administración de permisos sobre otros repos.
- Asignaciones de app en Okta que derivan en privilegio operativo
Es común que el equipo de IAM asigne GitHub a grupos “de departamento” por comodidad. El resultado real es que el control de acceso a repos críticos queda indirectamente gobernado por dinámicas de RR. HH. (altas/movimientos) y no por criticidad técnica. Cuando un grafo evidencia que “miembro de X grupo” implica “maintainer de Y repos”, aparece un punto único de fallo que antes se percibía como normal.
- Permisos en GitHub que permiten alterar la cadena de suministro
En muchas empresas, el mayor impacto no es “ver código”, sino “cambiar qué se despliega”. Si un equipo puede tocar workflows, acciones compartidas o repos de configuración de despliegue, puede introducir un cambio mínimo con efecto máximo. La visualización de rutas ayuda a identificar esos nodos (repos/teams) que funcionan como multiplicadores de riesgo y que requieren controles más estrictos.
Señales tempranas que deberían disparar una revisión de rutas
Cuando una organización opera a escala, los síntomas aparecen antes que el incidente, pero se pierden entre herramientas. Un ejemplo típico: aumentan las invitaciones/altas a equipos en GitHub o se crean nuevos equipos “para un proyecto” que luego se quedan con permisos heredados. Otro: en Okta, proliferan grupos con nombres parecidos y owners difusos, y la asignación de la aplicación GitHub se vuelve una rutina sin revisión.
Otra señal frecuente es la rotación de personal y consultores. Si la empresa usa Okta como broker de acceso, pero la gestión de equipos en GitHub se hace “a mano”, el desfase es inevitable. En auditorías internas se ve como “usuarios fuera de la org” o “membresías huérfanas”; en una ruta de ataque se ve como “entrada persistente con capacidad de cambio”. El valor de un enfoque tipo BloodHound es convertir ese desorden en caminos priorizados.
- Equipos de GitHub con permisos amplios y owners no claros
En la práctica, los teams acaban actuando como roles. Si un team administra repos o controla settings de seguridad, debería tener ownership explícito, revisión periódica y criterios de membresía. Cuando no existe, el riesgo no está en un permiso aislado sino en la facilidad con la que alguien entra y conserva ese rol.
- Grupos de Okta usados como “bolsa” para acceso a múltiples apps
El patrón de “grupo comodín” simplifica operaciones, pero es una autopista para el movimiento lateral por identidad. Si GitHub (u otras apps) se asignan por ese grupo, cualquier fallo en su gobernanza se propaga. La ruta de ataque deja de depender de explotar una vulnerabilidad: depende de estar en el grupo correcto.
Cómo hacerlo en la práctica: operar el mapeo y convertirlo en remediación
Para que la expansión hacia Okta y GitHub sea útil, el objetivo no es “coleccionar datos”, sino integrar el grafo en el ciclo de control: cambios de acceso, revisiones periódicas y gates para repos críticos. En empresa, esto suele fallar por falta de acuerdos entre IAM, plataforma y seguridad sobre quién remedia qué. Lo primero es definir el perímetro operativo: qué organizaciones de GitHub entran, qué tenants de Okta, y qué repos/teams se clasifican como críticos.
Después, hay que convertir rutas en tickets accionables con propietario claro. Un ticket útil no dice “reducir privilegios”, dice “este grupo de Okta asigna GitHub a 340 usuarios y deriva en maintainer de estos repos; proponemos dividir en dos grupos, limitar a X, y poner ownership en Y”. Si no aterriza en cambios concretos de grupos/teams/repos, el grafo se queda como una foto interesante.
- Configurar un inventario mínimo viable de criticidad en GitHub
Crear una lista de repositorios “crown jewels” (infra, despliegue, acciones compartidas, plantillas) y mapear qué teams/roles tienen permisos de escritura/administración. La remediación típica es reducir quién puede cambiar workflows/acciones compartidas y exigir revisiones obligatorias en ramas protegidas para esos repos, además de limitar quién puede administrar settings del repo.
- Revisar gobernanza de grupos en Okta vinculados a GitHub
Identificar grupos que asignan la app de GitHub y exigir: owners definidos, justificación de membresía, caducidad para accesos temporales y un proceso de revisión. Si el acceso a GitHub depende de atributos dinámicos (departamento/puesto), validar que esa lógica no está metiendo a usuarios en teams con privilegios por accidente tras un cambio organizativo.
La validación de que “funcionó” no es solo ver menos permisos. Es comprobar que la ruta se rompe: que ya no existe un camino desde un usuario de bajo privilegio (o un grupo amplio) hasta capacidades de alto impacto en repos críticos. Operativamente, eso implica re-ejecutar el análisis tras cada cambio relevante y tratarlo como parte de la higiene de identidad, no como un proyecto puntual.
Recomendaciones para entornos corporativos
La expansión de BloodHound hacia Okta y GitHub es valiosa cuando se usa para evidenciar rutas de ataque que atraviesan SSO y control de cambios, porque ahí es donde hoy se materializa el impacto: acceso legítimo que se encadena hasta capacidad de modificar código, pipelines o configuraciones críticas. El mayor retorno suele venir de identificar unos pocos nodos “multiplicadores” (grupos de Okta y teams/repos de GitHub) y tratarlos como activos de alto riesgo.
En la práctica, el éxito depende de gobernanza: ownership claro de grupos en Okta, criterios de membresía y caducidad para accesos, y una clasificación realista de repos críticos en GitHub con permisos ajustados. Cuando esos elementos se conectan con el grafo, la remediación deja de ser una lista interminable y se convierte en cortar rutas específicas que, en un incidente, harían la diferencia.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.