En muchas empresas, las integraciones SaaS se aprueban como si fueran “automatizaciones”: conectar GitHub con Slack, sincronizar Notion con el IdP, dar acceso a un asistente de IA al drive corporativo o habilitar un bot para crear tickets desde un canal. El problema es que, en la práctica, estás delegando decisiones de seguridad (y parte de la observabilidad) a un tercero que opera fuera de tu control directo.
El riesgo rara vez está en el “SaaS principal” que ya gobiernas con SSO y políticas, sino en el ecosistema de apps conectadas: tokens personales que sobreviven a bajas de empleados, scopes demasiado amplios concedidos por comodidad, y permisos que se heredan a datos más sensibles a medida que la organización crece. Cuando algo sale mal, el incidente no parece un “hackeo al SaaS”, sino una cadena de confianza rota por una integración.
Superficie de ataque real: la cadena de confianza que casi nadie mapea
Una integración SaaS introduce un nuevo sujeto de confianza con capacidad de actuar en tu nombre. En términos operativos, eso suele materializarse como OAuth (scopes), tokens de acceso (a veces sin expiración corta), webhooks entrantes/salientes y, en algunos casos, llaves API estáticas. Cada pieza abre un canal de exfiltración o de acción remota, aunque el SaaS base tenga MFA y SSO impecables.
En empresa se ve a menudo el mismo patrón: se conecta una app “de productividad” a GitHub para generar resúmenes, luego se le habilita acceso a issues y PRs, y con el tiempo termina leyendo repos privados completos porque “si no, falla”. En paralelo, el mismo proveedor se integra con Slack para notificaciones y acaba teniendo acceso a histórico de mensajes o a archivos compartidos en canales. El resultado es una ruta lateral desde una app externa hacia activos críticos sin pasar por los controles habituales de red.
- Tokens y scopes como “perímetro”: un OAuth con scopes amplios equivale, en la práctica, a credenciales de servicio. Si se filtra el token (logs, CI, un portátil), la app externa deja de ser “integración” y pasa a ser un actor que puede leer o escribir datos corporativos.
- Webhooks como canal de entrada: webhooks mal validados (sin firma, sin allowlist de IP cuando aplica) permiten inyectar eventos falsos. En incidentes reales, esto termina en automatizaciones que abren tickets, disparan pipelines o publican mensajes con enlaces maliciosos “con el sello” de la integración.
La dificultad no es conceptual: es inventariar de verdad qué está conectado, con qué permisos, y qué datos toca. Sin ese mapa, el SOC persigue síntomas (alertas de acceso, cambios en repos) sin ver que el origen fue una app autorizada y “legítima”.
Cuando lo “legítimo” es el problema: tokens olvidados y permisos heredados
El riesgo oculto aparece cuando el acceso persiste más allá de su necesidad. En GitHub, por ejemplo, un token personal (PAT) creado para una prueba puede quedarse vivo meses; en Slack, una app instalada en un workspace puede conservar capacidades aunque el usuario que la autorizó ya no esté; en Notion u otros wikis, integraciones con acceso a espacios completos siguen funcionando aunque el proyecto haya terminado.
En entornos corporativos, la rotación de personal y la presión por entregar hace que se normalicen “excepciones temporales”. El problema es que lo temporal rara vez se revierte. Un ejemplo típico: un proveedor externo pide acceso a un repositorio para integrar despliegues; se le concede con scopes amplios “para no estar bloqueando”, y ese token acaba circulando entre equipos (o quedando almacenado en un gestor de secretos del proveedor). Si un día ese proveedor sufre un incidente, tu exposición no es teórica: el atacante entra con una credencial válida y acciones permitidas.
Hay además un efecto silencioso: los permisos se vuelven más peligrosos con el tiempo. Una integración que inicialmente solo veía un repositorio “de utilidades” puede terminar viendo información sensible porque el repositorio se reutiliza para configuración, credenciales de ejemplo o scripts internos. La autorización no cambió; lo que cambió fue el valor de los datos accesibles.
Cómo hacerlo en la práctica: auditoría de integraciones en GitHub, Slack y Notion (sin depender de “sensaciones”)
Auditar integraciones no es revisar una lista una vez al año; es establecer un proceso repetible con evidencias. El primer paso es inventariar todas las vías de autorización: apps OAuth, GitHub Apps, tokens personales, webhooks y conexiones de terceros. El segundo es clasificar por alcance real (qué puede leer/escribir) y por criticidad del dato tocado. En empresas, esto se vuelve accionable cuando lo conviertes en backlog con propietarios y fechas.
GitHub (org/enterprise): revisa las GitHub Apps instaladas y sus permisos, las apps OAuth autorizadas y, si aplica, el uso de PATs. En organizaciones maduras, se fuerza “OAuth app restrictions” y se permite solo un allowlist. Operativamente, busca integraciones con permisos de escritura en repos y acceso a contenido privado; suelen ser las que convierten una fuga en un incidente de integridad (commits maliciosos, cambios en workflows, modificación de dependencias).
- Acción concreta: habilita restricción de apps OAuth y requiere aprobación de admins para nuevas apps. Luego revisa las apps ya aprobadas y reduce permisos o reemplázalas por GitHub Apps con permisos más finos. Esto reduce el riesgo de “scopes genéricos” típicos de OAuth.
- Validación: verifica en los registros/auditoría de GitHub (Audit Log) que no haya instalaciones nuevas sin ticket asociado, y cruza eventos de acceso de apps con repositorios sensibles. Si una app toca repos que no debería, no es debate: es hallazgo.
Slack (workspace/enterprise grid): inventaría apps instaladas y sus permisos, especialmente aquellas con acceso a canales privados, lectura de mensajes, descarga de archivos o capacidades de administración. Un caso frecuente: apps de “archivado” o “búsqueda” que terminan teniendo acceso a archivos que contienen secretos operativos (capturas, exports, logs). La consecuencia suele ser exfiltración silenciosa, difícil de detectar por DLP si la salida ocurre vía API autorizada.
Notion (y wikis similares): revisa integraciones que acceden a espacios completos. El error habitual es conceder acceso “a todo el workspace” porque el producto lo sugiere para funcionar mejor. En empresa, eso equivale a dar a un tercero acceso a runbooks, diagramas de arquitectura, procedimientos de respuesta a incidentes y, en el peor caso, credenciales pegadas en una página antigua.
Escenarios de abuso que se ven en empresa (y por qué los controles tradicionales no los paran)
El abuso más dañino suele ser el que no dispara alertas: acciones realizadas por una app autorizada con credenciales válidas. Si tu defensa está orientada a detectar inicios de sesión sospechosos o IPs anómalas, una integración operando por API puede pasar como “ruido normal”. El atacante no necesita romper MFA; necesita un token, un secreto de webhook o comprometer al proveedor que opera la integración.
En incidentes reales, los escenarios más repetidos combinan persistencia y baja fricción. Por ejemplo: un token con scopes amplios permite leer repos privados y extraer código; luego, el atacante modifica un workflow de CI para añadir un paso de exfiltración de secretos; finalmente, usa Slack para moverse socialmente, enviando mensajes desde un bot que parece legítimo. Todo esto puede ocurrir sin un solo “login” interactivo.
- Exfiltración de datos por API: una app con lectura de canales o documentos puede descargar contenido de forma incremental para evitar picos. En la práctica, se detecta tarde porque el patrón se parece a un “sync” normal.
- Manipulación de integridad: integraciones con permisos de escritura (repos, wikis, automatizaciones) permiten introducir cambios que luego se propagan por procesos internos. En empresas con CI/CD rápido, un pequeño cambio en un pipeline puede convertirse en despliegue con código alterado.
Los controles de red (proxy, CASB parcial) ayudan, pero no sustituyen el gobierno de permisos. Cuando el canal de salida es una API legítima hacia un proveedor aprobado, la pregunta clave es: ¿por qué esa app tenía ese alcance y por qué nadie lo estaba revisando?
Recomendaciones para entornos corporativos
Las integraciones SaaS no son “herramientas auxiliares”: son extensiones de tu identidad y de tus datos. El riesgo oculto aparece cuando se delega la seguridad a terceros sin inventario completo, sin gobierno de permisos y sin evidencia de uso real. Lo que más reduce incidentes no es prohibir integraciones, sino hacerlas operables: saber qué existe, qué puede hacer y quién responde por ello.
Si tuviera que condensarlo en práctica corporativa: inventario vivo de integraciones, reducción sistemática de scopes, caducidad/rotación de tokens y una revisión basada en logs de auditoría (no en declaraciones del proveedor). A partir de ahí, cualquier integración que no tenga propietario, justificación y permisos mínimos deja de ser “automatización” y pasa a ser deuda de seguridad lista para explotarse.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.