Como se ve CTEM en la capa del navegador: un script de tercero, cinco hallazgos
Respuesta rapida: Continuous Threat Exposure Management (CTEM), el marco definido por Gartner para reducir exposicion de forma continua, se rompe en la capa del navegador en la mayoria de los programas empresariales. El analisis en vivo de c/side sobre un unico widget de feedback de Skeepers en un gran banco minorista internacional encontro dos hallazgos altos y tres medios, incluido un sub-script controlado por servidor que faltaba en la Content Security Policy y una cookie de rastreo de 360 dias con alcance al subdominio de autenticacion del banco, aunque no habia coincidencias previas en bases de amenazas. Este articulo mapea cada hallazgo a las cinco etapas de CTEM y muestra por que las clausulas PCI DSS 4.0.1 6.4.3 y 11.6.1 exigen mas que un inventario de scripts.
Un gran banco minorista internacional carga un widget de feedback de clientes en su sitio principal. El widget configura una cookie de rastreo de 360 dias con alcance a todo el dominio del banco, incluido el subdominio de autenticacion. Tambien inyecta dinamicamente un sub-script cuyo nombre de archivo decide el servidor del proveedor en tiempo de ejecucion, y ese sub-script no esta en la propia Content Security Policy del banco. Las paginas de login no tienen CSP.
Nada de eso es hipotetico. Es lo que c/side encontro en un analisis profundo de un script de Skeepers / MyFeelBack ejecutandose en una propiedad bancaria real.
Este articulo usa ese desglose real, anonimizado y con nombres de proveedores conservados, para mostrar como se ve Continuous Threat Exposure Management (CTEM) cuando se aplica de verdad a la capa del navegador y donde la mayoria de los programas dejan abierto el ciclo.
TL;DR
- CTEM, el marco de Gartner para tratar la exposicion como un ciclo continuo, tiene cinco etapas: alcance, descubrimiento, priorizacion, validacion y movilizacion. La mayoria de los programas cubre las dos primeras y se detiene en el navegador.
- Un analisis en vivo de un unico widget de Skeepers en un banco internacional encontro dos hallazgos HIGH y tres MEDIUM, incluido un sub-script controlado por servidor que no estaba en el allowlist de CSP.
- Las paginas de autenticacion del banco no tenian cabecera CSP, en aparente conflicto con la clausula PCI DSS 4.0.1 6.4.3.
- Una cookie de rastreo de 360 dias tenia alcance a todo el dominio bancario y viajaba con los flujos de login.
- La cadena mediana de inclusiones de terceros en la web moderna tiene tres niveles de profundidad, con una profundidad maxima observada de 2.285 (Web Almanac 2025).
- La actividad de Magecart y skimmers comprometio mas de 23 millones de transacciones online en 2025 (Recorded Future via Mastercard).
- Visibilidad sin enforcement es documentacion, no proteccion.
Que es CTEM y donde suele romperse?
CTEM es el marco de Gartner para tratar la exposicion como un ciclo continuo en cinco etapas: alcance, descubrimiento, priorizacion, validacion y movilizacion. La idea del ciclo es que la exposicion cambia constantemente, por lo que la respuesta tambien debe ser continua.
La mayoria de los programas de seguridad ha avanzado mucho en las tres primeras etapas para activos tradicionales. Las configuraciones cloud se escanean. La dispersion de identidades se mapea. Las vulnerabilidades se puntuan.
Despues el ciclo se rompe en validacion y movilizacion para cualquier cosa que se ejecute en el navegador.
CTEM del navegador frente a CTEM cloud
| Etapa CTEM | Cloud e identidad | Capa del navegador |
|---|---|---|
| Alcance | Maduro | A menudo omitido |
| Descubrimiento | Herramientas solidas | Parcial, sobre todo via tag managers |
| Priorizacion | Con puntuacion de riesgo | Rara vez puntuada |
| Validacion | Pentests, BAS | Casi nunca probada |
| Movilizacion | Parchear, aislar, revocar | Enviar un email al equipo de marketing |
La exposicion del navegador no se moviliza porque normalmente el equipo de seguridad no puede movilizarla. Puede ver un script. Puede abrir un ticket. No puede impedir que el script se ejecute en la siguiente carga de pagina.
Esa es la brecha. El recorrido siguiente muestra como se ve esa brecha en produccion.
Caso de estudio: un script, cinco hallazgos relevantes para CTEM
El script en cuestion es el loader principal del widget de feedback de clientes de Skeepers, antes MyFeelBack. Esta alojado en cdnactor.myfeelback.com y se carga en paginas generales del sitio principal de un banco minorista internacional.
No es malicioso. No hubo coincidencias YARA, ni entradas en bases de amenazas, ni alertas de analisis estatico. Ese es el punto. La mayoria de la exposicion del navegador no viene de actores evidentemente malos. Viene de terceros aprobados y contratados cuyo comportamiento nadie gobierna activamente.
Hallazgo 1: el allowlist de CSP esta incompleto
Las paginas generales del banco envian una Content Security Policy que permite *.myfeelback.com. Hasta ahi, normal.
Pero el loader de Skeepers inyecta un sub-script en runtime desde room.cxr.skeepers.io, hojas de estilo desde actor.cxr.skeepers.io y una llamada GeoIP a un endpoint AWS Lambda en c7hn3ry3r4.execute-api.us-east-1.amazonaws.com. Ninguno de esos dominios esta en el CSP. Por lo tanto, el widget esta parcialmente roto en produccion o el CSP se esta evitando de formas que el equipo de seguridad no autorizo.
Este es el tipo de desajuste que una revision unica de proveedor nunca captura. El script envia una URL *.myfeelback.com el primer dia. Seis meses despues, tras un rebrand corporativo, el comportamiento en runtime carga desde *.cxr.skeepers.io. Un descubrimiento con nivel CTEM debe seguir las llamadas reales en runtime, no el contrato.
Hallazgo 2: un sub-script controlado por servidor con hash movil
El loader construye una URL en runtime con esta forma:
https://room.cxr.skeepers.io/lib/frontend/handy/js/libraries/{themeDeployment}-libraries.js
La parte {themeDeployment} la decide el servidor del proveedor. El hash del loader permanece estable. El hash de lo que descarga cambia cuando Skeepers quiere. Una revision estatica del loader pasara el lunes y perdera un cambio de sub-script el martes.
Este es el patron clasico de supply chain en el navegador. Polyfill.io funciono igual en 2024: un script primario limpio, un payload mutable de segunda etapa y ningun control de integridad desde la pagina host. Cuando la segunda etapa cambia, cada visitante de cada sitio que carga el script primario se convierte en objetivo.
En este contexto, la validacion CTEM significa fingerprinting continuo del codigo inyectado en runtime, no solo del loader.
Hallazgo 3: una cookie de rastreo de 360 dias con alcance al dominio apex
El widget configura una cookie llamada _MFB_ con estas propiedades:
- Dominio: todo el apex del banco, incluido el subdominio de autenticacion
- Expiracion: 360 dias
- Contenido: un blob codificado en Base64 con un ID aleatorio persistente de visitante de 11 caracteres, contadores de visitas de campana y deployment, historial de paginas vistas, contadores de clics, TTL de sesion y selectores CSS
En paralelo, el widget escribe 15 claves en localStorage y las sincroniza de vuelta a la cookie en cada carga de pagina.
De esto se derivan varias cosas:
- El alcance a nivel apex significa que la cookie viaja con solicitudes al subdominio de autenticacion, aunque el widget no se cargue alli.
- Un identificador seudonimo de 360 dias en una propiedad bancaria necesita consentimiento explicito bajo GDPR / CNIL y una justificacion documentada de retencion. Es una pregunta de Record of Processing Activities (ROPA), no solo de seguridad.
- La sincronizacion entre cookie y
localStoragesignifica que borrar cookies de forma estandar no reinicia el ID de visitante.
Esta es exactamente la exposicion de privacidad de cola larga que los marcos CTEM deberian sacar a la luz durante la priorizacion.
Hallazgo 4: no hay CSP en las paginas de autenticacion
Este es el hallazgo mas serio. El flujo de login del banco no envia cabecera Content Security Policy.
El script de Skeepers no se carga alli. Pero ese no es el punto. El punto es que cualquier script futuro, como una etiqueta de marketing, una herramienta de A/B testing o un proveedor comprometido, se ejecutaria en el flujo de login sin restriccion y con acceso completo al DOM de los campos de credenciales.
La clausula PCI DSS 4.0.1 6.4.3 exige un mecanismo para confirmar y autorizar scripts en paginas de pago. La clausula 11.6.1 exige un mecanismo de deteccion de manipulacion en esas paginas. Ninguna queda satisfecha por la ausencia total de cabecera.
La infraestructura existe. Ya hay un endpoint de reporting CSP para el sitio general. Simplemente no se extendio a las paginas mas sensibles de la propiedad.
Hallazgo 5: la encuesta se renderiza dentro del DOM host
Cuando se dispara una encuesta, el widget inyecta #mfbIframeOverlay y #mfbIframeBlock directamente en document.body. Eso suena inocuo, y lo es para la encuesta en si. Pero significa que el sub-script cargado dinamicamente, el que tiene hash movil, se ejecuta en el mismo origen que la pagina del banco. Mismo acceso al DOM, mismos formularios, mismas cookies.
Se adjunta un listener de keydown por accesibilidad para atrapar el foco con Tab. Hoy no exfiltra nada. Pero el listener esta en el contenedor superior de la encuesta, y el codigo que lo controla puede cambiar cada vez que el proveedor publica un nuevo theme deployment. La priorizacion CTEM deberia marcar esto como una dependencia de confianza en el proceso de releases del proveedor.
Que requirio el analisis y que encontro
Como contexto sobre el esfuerzo de descubrimiento y validacion CTEM:
| Metrica | Valor |
|---|---|
| Scripts analizados | 2 (loader primario + sub-script) |
| Herramientas llamadas | 20+ en script, infra, amenazas y comportamiento |
| Tiempo total de ejecucion | 281,9 segundos |
| Hallazgos de riesgo | 8 (2 HIGH, 3 MEDIUM, 3 INFO) |
| Coincidencias en bases de amenazas | 0 |
| Coincidencias YARA | 0 |
Cero indicadores de amenaza existentes. Dos hallazgos HIGH. Esa es la asimetria que CTEM fue disenado para capturar: la exposicion mas comun del navegador no es un script conocido como malo. Es un script aprobado que hace cosas que nunca fueron autorizadas explicitamente.
Por que crawlers y escaneres tradicionales no encuentran esto
Una pregunta razonable es por que ninguna herramienta existente del banco mostro estos hallazgos. La respuesta es que casi nada en el stack de seguridad estandar ejecuta la pagina como lo hace un usuario real.
Piensa en lo que ve un escaner tipico:
- Escaneres de aplicaciones web (DAST) rastrean URLs e inspeccionan respuestas. No cargan la pagina en un navegador real, no ejecutan JavaScript ni esperan a que scripts inyectados en runtime descarguen payloads de segunda etapa. El loader de Skeepers devuelve 200 OK con JS valido. Fin.
- Crawlers de busqueda y SEO renderizan con un navegador headless, pero no puntuan scripts de terceros por comportamiento de seguridad. Les importa el contenido, no las cookies.
- Analisis estatico (SAST) y SCA miran codigo en tu repositorio. El script de Skeepers no esta en tu repositorio. Se carga desde el CDN de otra empresa en runtime.
- CSP en modo report-only puede detectar violaciones, pero solo para los dominios que ya sabes que debes permitir. No puede avisarte sobre sub-scripts inyectados en runtime cuyas URLs decide el servidor despues de cargar la pagina.
- Escaneres de vulnerabilidades comparan CVEs contra inventarios de software. No existe un CVE para "el widget de marketing de tu proveedor configura una cookie de 360 dias en tu subdominio de autenticacion".
- Pentests son puntuales. El hash del loader de Skeepers no tenia historial de observacion en la ventana de 90 dias. El hash del sub-script cambia cuando el proveedor publica un nuevo tema. Un pentest en marzo no te dice que se carga en octubre.
El sitio del banco tiene infraestructura CSP, un endpoint de reporting CSP y un equipo de seguridad que sabe lo que hace. Nada de eso capturo estos hallazgos porque ninguna de esas herramientas observa continuamente el entorno real del navegador.
Esa es la razon estructural por la que el navegador queda en el punto ciego de CTEM. La exposicion no esta en codigo que alguien escanea. Esta en codigo que se carga, muta y se ejecuta en la maquina del usuario, en un contexto que termina cuando se cierra la pestana. Capturarlo exige observar el runtime, no el repositorio ni la red.
Por que las herramientas solo de visibilidad no cierran el ciclo
El recorrido de Skeepers es el tipo de salida que puede producir una herramienta solo de visibilidad. La parte dificil viene despues.
| Enfoque | Descubre scripts | Puntua riesgo | Detecta cambios | Detiene ejecucion |
|---|---|---|---|---|
| Tag managers | Si | No | Parcial | No |
| Solo CSP | No | No | Parcial | Si, pero de forma poco precisa |
| Seguridad de navegador centrada en visibilidad | Si | Si | Si | No |
| Seguridad de navegador centrada en enforcement | Si | Si | Si | Si |
Sin la ultima columna, el unico camino de movilizacion del equipo de seguridad es un ticket para el equipo que gestiona la relacion con el proveedor, normalmente marketing o CX. Ese ticket compite con trabajo de producto. El proveedor publica un nuevo sub-script antes de que el ticket se cierre. El ciclo se repite.
Esta es la razon operativa por la que CTEM se atasca en el navegador, incluso en empresas con muchos recursos.
Por que los numeros generales deberian preocupar a los lideres de seguridad
El recorrido de Skeepers es un script en un sitio. La imagen agregada es mucho mayor.
- La cadena mediana de inclusiones de terceros en la web moderna tiene 3 niveles de profundidad, con una profundidad maxima observada de 2.285 (Web Almanac 2025).
- Ataques de skimming y Magecart comprometieron mas de 23 millones de transacciones online en 2025 (Recorded Future via Mastercard).
- La mayoria de las herramientas CTEM trata esta capa como problema de otro equipo.
Un banco que carga dos scripts de Skeepers es un caso pequeno. Un checkout de e-commerce que carga entre 80 y 200 scripts de terceros es normal. La exposicion escala con el numero de scripts, la profundidad de la cadena de inclusion y la cadencia con la que los proveedores publican cambios.
Mapeo de cside al ciclo CTEM usando este caso
Asi se ve cada etapa de CTEM para este unico script cuando la plataforma cside es la capa de control en runtime.
| Etapa CTEM | Que significa en el navegador | Ejemplo Skeepers |
|---|---|---|
| Alcance | Definir que sitios y paginas entran en el alcance | Todos los subdominios del banco, con rigor extra en el flujo de autenticacion |
| Descubrimiento | Inventariar todos los scripts de primera, tercera y cuarta parte | Loader + sub-script en runtime + Lambda GeoIP + 3 endpoints CSS |
| Priorizacion | Puntuar scripts por acceso a datos y comportamiento | Cookie de 360 dias en subdominio auth, sub-script controlado por servidor: HIGH |
| Validacion | Probar lo que los scripts hacen de verdad, no lo que dicen hacer | Confirmar brecha CSP, confirmar alcance de cookie, fingerprint del sub-script |
| Movilizacion | Detener, restringir o permitir ejecucion | Restringir el widget a paginas no auth, fijar hash del sub-script, alertar ante cambios |
Las capturas que muchos equipos devuelven dicen lo mismo una vez desplegado cside. Sabian que el panorama de terceros era grande. No sabian que podia ser de 16.000 scripts en una semana tipica de retail. No sabian cuantos necesitaban revision PCI. No tenian un camino rapido desde "encontramos un problema" hasta "el problema no puede ejecutarse".
Para e-commerce en concreto, esta es la linea de defensa contra campanas de proteccion contra Magecart y web skimming, que siguen funcionando precisamente porque el script sigue ejecutandose.
Que pedirle a una herramienta de exposicion del navegador
Si estas evaluando herramientas y quieres mantener el marco CTEM, las preguntas son concretas:
- Descubre scripts que cargan en runtime, no solo en la carga inicial de la pagina?
- Sigue la cadena de dependencias hasta cargas de cuarta parte?
- Detecta cuando cambia el hash de un script que antes estaba limpio?
- Te dice que lee cada script del DOM, cookies y almacenamiento?
- Puede bloquear o restringir un script en produccion sin redesplegar el sitio?
- Su evidencia mapea a PCI DSS 6.4.3 y 11.6.1?
- Cuanto tarda el camino desde deteccion hasta enforcement? Minutos, horas o un sprint?
Si la respuesta a las ultimas tres no es "si, rapido, si", la herramienta esta haciendo descubrimiento CTEM sin movilizacion CTEM.
El encuadre que importa
CTEM funciona porque trata la exposicion como continua. El navegador solo encaja en ese marco si la respuesta tambien es continua. Las auditorias trimestrales de scripts no igualan la cadencia con la que cambia el codigo de terceros. Los tickets al equipo de marketing no igualan la velocidad de un skimmer Magecart.
El caso Skeepers es moderado. No hay actor malicioso, es un proveedor reputado y un patron SaaS conocido. Aun asi produjo dos hallazgos HIGH en un gran banco internacional, incluido uno que mapea directamente a PCI DSS 4.0.1 6.4.3.
Si un proveedor benigno en un cliente cuidadoso produce tanta exposicion, la pregunta no es si la capa del navegador necesita cobertura CTEM. La pregunta es cuanto tiempo seguiran las empresas tratandola como fuera de alcance.
Para ver como se ve tu propia exposicion con el mismo lente, el monitoreo de scripts del navegador en una propiedad real te da el ciclo de descubrimiento, priorizacion y enforcement en menos de una hora.
Si tambien estas comparando una plataforma centrada en visibilidad con una centrada en enforcement, la comparacion Reflectiz vs cside recorre los trade-offs lado a lado.
