Como o CTEM se parece na camada do navegador: um script de terceiro, cinco achados
Resposta rapida: Continuous Threat Exposure Management (CTEM), o framework definido pela Gartner para reducao continua de exposicao, quebra na camada do navegador na maioria dos programas empresariais. A analise ao vivo da c/side sobre um unico widget de feedback da Skeepers em um grande banco internacional de varejo revelou dois achados altos e tres medios, incluindo um sub-script controlado por servidor ausente da Content Security Policy e um cookie de rastreamento de 360 dias com escopo no subdominio de autenticacao do banco, apesar de zero hits anteriores em bases de ameacas. Este artigo mapeia cada achado para as cinco etapas do CTEM e mostra por que as clausulas PCI DSS 4.0.1 6.4.3 e 11.6.1 exigem mais do que um inventario de scripts.
Um grande banco internacional de varejo carrega um widget de feedback de clientes em seu site principal. O widget define um cookie de rastreamento de 360 dias com escopo em todo o dominio do banco, incluindo o subdominio de autenticacao. Ele injeta dinamicamente um sub-script cujo nome de arquivo e decidido pelo servidor do fornecedor em runtime, e esse sub-script nao esta na Content Security Policy do banco. As paginas de login nao possuem CSP.
Nada disso e hipotetico. Foi o que a c/side encontrou em uma analise profunda de um script Skeepers / MyFeelBack executando em uma propriedade bancaria real.
Este artigo usa esse caso real, anonimizado e com nomes de fornecedores preservados, para mostrar como o Continuous Threat Exposure Management (CTEM) se parece quando e realmente aplicado a camada do navegador, e onde a maioria dos programas deixa o ciclo aberto.
TL;DR
- CTEM, o framework da Gartner para tratar exposicao como um ciclo continuo, tem cinco etapas: escopo, descoberta, priorizacao, validacao e mobilizacao. A maioria dos programas cobre as duas primeiras e para no navegador.
- Uma analise ao vivo de um unico widget Skeepers em um banco internacional revelou dois achados HIGH e tres MEDIUM, incluindo um sub-script controlado por servidor fora da allowlist de CSP.
- As paginas de autenticacao do banco nao tinham cabecalho CSP, em aparente conflito com a clausula PCI DSS 4.0.1 6.4.3.
- Um cookie de rastreamento de 360 dias tinha escopo em todo o dominio bancario e acompanhava os fluxos de login.
- A cadeia mediana de inclusao de terceiros na web moderna tem tres niveis de profundidade, com profundidade maxima observada de 2.285 (Web Almanac 2025).
- Atividades de Magecart e skimmers comprometeram mais de 23 milhoes de transacoes online em 2025 (Recorded Future via Mastercard).
- Visibilidade sem enforcement e documentacao, nao protecao.
O que e CTEM, e onde ele costuma quebrar?
CTEM e o framework da Gartner para tratar exposicao como um ciclo continuo em cinco etapas: escopo, descoberta, priorizacao, validacao e mobilizacao. A ideia do ciclo e que a exposicao muda constantemente, entao a resposta tambem precisa ser continua.
A maioria dos programas de seguranca fez progresso real nas tres primeiras etapas para ativos tradicionais. Configuracoes cloud sao escaneadas. Espalhamento de identidades e mapeado. Vulnerabilidades recebem pontuacao.
Depois o ciclo quebra na validacao e na mobilizacao para qualquer coisa que execute no navegador.
CTEM do navegador vs CTEM cloud
| Etapa CTEM | Cloud e identidade | Camada do navegador |
|---|---|---|
| Escopo | Maduro | Frequentemente ignorado |
| Descoberta | Ferramentas fortes | Parcial, principalmente via tag managers |
| Priorizacao | Com score de risco | Raramente pontuada |
| Validacao | Pentests, BAS | Quase nunca testada |
| Mobilizacao | Corrigir, isolar, revogar | Enviar email ao time de marketing |
Exposicao no navegador nao e mobilizada porque a equipe de seguranca normalmente nao consegue mobiliza-la. Ela pode ver um script. Pode abrir um ticket. Nao consegue impedir que o script execute no proximo carregamento de pagina.
Essa e a lacuna. O passo a passo abaixo mostra como essa lacuna aparece em producao.
Estudo de caso: um script, cinco achados relevantes para CTEM
O script em questao e o loader principal do widget de feedback de clientes da Skeepers, antes MyFeelBack. Ele e hospedado em cdnactor.myfeelback.com e carregado nas paginas gerais do site principal de um banco internacional de varejo.
Ele nao e malicioso. Nao houve hits YARA, entradas em bases de ameacas nem alertas de analise estatica. Esse e o ponto. A maior parte da exposicao no navegador nao vem de atores obviamente ruins. Vem de terceiros aprovados e contratados cujo comportamento ninguem governa ativamente.
Achado 1: a allowlist de CSP esta incompleta
As paginas gerais do banco enviam uma Content Security Policy que permite *.myfeelback.com. Ate ai, normal.
Mas o loader da Skeepers injeta em runtime um sub-script a partir de room.cxr.skeepers.io, folhas de estilo de actor.cxr.skeepers.io e uma chamada GeoIP para um endpoint AWS Lambda em c7hn3ry3r4.execute-api.us-east-1.amazonaws.com. Nenhum desses dominios esta no CSP. Portanto, o widget esta parcialmente quebrado em producao, ou o CSP esta sendo contornado de formas que a equipe de seguranca nao autorizou.
Esse e o tipo de divergencia que uma revisao unica de fornecedor nunca captura. O script entrega uma URL *.myfeelback.com no primeiro dia. O comportamento runtime puxa de *.cxr.skeepers.io seis meses depois, apos um rebrand corporativo. Descoberta em nivel CTEM precisa seguir chamadas reais em runtime, nao o contrato.
Achado 2: um sub-script controlado por servidor com hash movel
O loader constroi em runtime uma URL assim:
https://room.cxr.skeepers.io/lib/frontend/handy/js/libraries/{themeDeployment}-libraries.js
A parte {themeDeployment} e decidida pelo servidor do fornecedor. O hash do loader fica estavel. O hash do que ele puxa muda quando a Skeepers quiser. Uma revisao estatica do loader passa na segunda e perde uma troca de sub-script na terca.
Esse e o padrao classico de supply chain no navegador. Polyfill.io funcionou do mesmo jeito em 2024: um script primario limpo, um payload mutavel de segunda etapa e nenhum controle de integridade pela pagina host. Quando a segunda etapa muda, cada visitante de cada site que carrega o script primario vira alvo.
Nesse contexto, validacao CTEM significa fazer fingerprinting continuo do codigo injetado em runtime, nao apenas do loader.
Achado 3: um cookie de rastreamento de 360 dias no dominio apex
O widget define um cookie chamado _MFB_ com estas propriedades:
- Dominio: todo o apex do banco, incluindo o subdominio de autenticacao
- Expiracao: 360 dias
- Conteudo: um blob Base64 com um ID aleatorio persistente de visitante de 11 caracteres, contadores de visitas de campanha e deployment, historico de paginas visitadas, contadores de cliques, TTL de sessao e seletores CSS
Em paralelo, o widget escreve 15 chaves em localStorage e as sincroniza de volta para o cookie em cada carregamento de pagina.
Algumas coisas decorrem disso:
- O escopo no apex significa que o cookie viaja com requisicoes para o subdominio de autenticacao, mesmo que o widget nao seja carregado la.
- Um identificador pseudonimo de 360 dias em uma propriedade bancaria precisa de consentimento explicito GDPR / CNIL e justificativa documentada de retencao. E uma questao de Record of Processing Activities (ROPA), nao apenas de seguranca.
- A sincronizacao entre cookie e
localStoragesignifica que apagar cookies de forma padrao nao redefine o ID de visitante.
Esse e exatamente o tipo de exposicao de privacidade de cauda longa que frameworks CTEM devem revelar durante a priorizacao.
Achado 4: nenhum CSP nas paginas de autenticacao
Esse e o achado mais serio. O fluxo de login do banco nao envia cabecalho Content Security Policy.
O script da Skeepers nao e carregado ali. Mas esse nao e o ponto. O ponto e que qualquer script futuro, uma tag de marketing, uma ferramenta de A/B testing ou um fornecedor comprometido, executaria no fluxo de login sem restricao e com acesso total ao DOM dos campos de credenciais.
A clausula PCI DSS 4.0.1 6.4.3 exige um mecanismo para confirmar e autorizar scripts em paginas de pagamento. A clausula 11.6.1 exige um mecanismo de deteccao de adulteracao nessas paginas. A ausencia total de cabecalho nao satisfaz nenhuma das duas.
A infraestrutura existe. Um endpoint de reporting CSP ja roda para o site geral. Ele simplesmente nao foi estendido para as paginas mais sensiveis da propriedade.
Achado 5: a pesquisa renderiza dentro do DOM host
Quando uma pesquisa e disparada, o widget injeta #mfbIframeOverlay e #mfbIframeBlock diretamente em document.body. Isso parece benigno, e e para a pesquisa em si. Mas significa que o sub-script carregado dinamicamente, aquele com hash movel, executa na mesma origem da pagina do banco. Mesmo acesso ao DOM, aos formularios e aos cookies.
Um listener keydown e anexado para acessibilidade, como armadilha de foco da tecla Tab. Ele nao exfiltra nada hoje. Mas o listener fica no container superior da pesquisa, e o codigo que o controla pode mudar sempre que o fornecedor publicar um novo theme deployment. A priorizacao CTEM deve marcar isso como uma dependencia de confianca no processo de release do fornecedor.
O que a analise exigiu e o que encontrou
Para contextualizar o esforco de descoberta e validacao CTEM:
| Metrica | Valor |
|---|---|
| Scripts analisados | 2 (loader primario + sub-script) |
| Ferramentas chamadas | 20+ entre script, infra, ameaca e comportamento |
| Runtime total | 281,9 segundos |
| Achados de risco | 8 (2 HIGH, 3 MEDIUM, 3 INFO) |
| Hits existentes em threat DB | 0 |
| Matches YARA | 0 |
Zero indicadores de ameaca existentes. Dois achados HIGH. Essa e a assimetria para a qual o CTEM foi criado: a exposicao mais comum no navegador nao e um script conhecido como ruim. E um script aprovado fazendo coisas que nunca foram explicitamente autorizadas.
Por que crawlers e scanners tradicionais nao encontram isso
Uma pergunta razoavel e por que nenhuma ferramenta existente do banco trouxe esses achados. A resposta e que quase nada no stack padrao de seguranca executa a pagina como um usuario real.
Considere o que um scanner tipico ve:
- Scanners de aplicacoes web (DAST) rastreiam URLs e inspecionam respostas. Nao carregam a pagina em um navegador real, nao executam JavaScript e nao esperam scripts injetados em runtime buscarem payloads de segunda etapa. O loader da Skeepers retorna 200 OK com JS valido. Fim.
- Crawlers de busca e SEO renderizam com um navegador headless, mas nao pontuam scripts de terceiros por comportamento de seguranca. Eles se importam com conteudo, nao com cookies.
- Analise estatica (SAST) e SCA olham codigo no seu repositorio. O script da Skeepers nao esta no seu repositorio. Ele carrega do CDN de outra empresa em runtime.
- CSP em modo report-only pode detectar violacoes, mas apenas para dominios que voce ja sabe que precisa permitir. Nao avisa sobre sub-scripts injetados em runtime cujas URLs sao decididas server-side apos a pagina carregar.
- Scanners de vulnerabilidade comparam CVEs contra inventarios de software. Nao existe CVE para "o widget de marketing do seu fornecedor define um cookie de 360 dias no seu subdominio de autenticacao."
- Pentests sao pontuais. O hash do loader Skeepers nao tinha historico de observacao na janela de 90 dias. O hash do sub-script muda quando o fornecedor publica um novo tema. Um pentest em marco nao diz o que carrega em outubro.
O site do banco tem infraestrutura CSP, endpoint de reporting CSP e uma equipe de seguranca competente. Nada disso capturou esses achados porque nenhuma dessas ferramentas observa continuamente o ambiente runtime do navegador.
Essa e a razao estrutural pela qual o navegador fica no ponto cego do CTEM. A exposicao nao esta em codigo que alguem escaneia. Esta em codigo que carrega, muda e executa na maquina do usuario, em um contexto que termina quando a aba fecha. Capturar isso exige observar runtime, nao o repositorio nem a rede.
Por que ferramentas apenas de visibilidade nao fecham o ciclo
O caso Skeepers e o tipo de saida que uma ferramenta de visibilidade pode produzir. A parte dificil vem depois.
| Abordagem | Descobre scripts | Pontua risco | Detecta mudanca | Para execucao |
|---|---|---|---|---|
| Tag managers | Sim | Nao | Parcial | Nao |
| Apenas CSP | Nao | Nao | Parcial | Sim, mas de forma grosseira |
| Seguranca de navegador focada em visibilidade | Sim | Sim | Sim | Nao |
| Seguranca de navegador focada em enforcement | Sim | Sim | Sim | Sim |
Sem a ultima coluna, o unico caminho de mobilizacao da equipe de seguranca e um ticket para o time que controla a relacao com o fornecedor, geralmente marketing ou CX. Esse ticket compete com trabalho de produto. O fornecedor publica um novo sub-script antes que o ticket seja fechado. O ciclo se repete.
Essa e a razao operacional pela qual o CTEM trava no navegador, mesmo em empresas bem equipadas.
Por que os numeros gerais deveriam preocupar lideres de seguranca
O caso Skeepers e um script em um site. O quadro agregado e muito maior.
- A cadeia mediana de inclusao de terceiros na web moderna tem 3 niveis de profundidade, com profundidade maxima observada de 2.285 (Web Almanac 2025).
- Ataques do tipo skimmer e Magecart comprometeram mais de 23 milhoes de transacoes online em 2025 (Recorded Future via Mastercard).
- A maioria das ferramentas CTEM trata essa camada como problema de outra pessoa.
Um banco carregando dois scripts Skeepers e um caso pequeno. Um checkout de e-commerce carregando 80 a 200 scripts de terceiros e normal. A exposicao escala com a quantidade de scripts, a profundidade da cadeia de inclusao e a cadencia com que fornecedores publicam mudancas.
Mapeando cside para o ciclo CTEM usando este caso
E assim que cada etapa CTEM se parece para este unico script quando a plataforma cside e a camada de controle runtime.
| Etapa CTEM | O que significa no navegador | Exemplo Skeepers |
|---|---|---|
| Escopo | Definir quais sites e paginas entram no escopo | Todos os subdominios do banco, com rigor extra no fluxo de auth |
| Descoberta | Inventariar todos os scripts first-party, third-party e fourth-party | Loader + sub-script runtime + Lambda GeoIP + 3 endpoints CSS |
| Priorizacao | Pontuar scripts por acesso a dados e comportamento | Cookie de 360 dias no subdominio auth, sub-script controlado por servidor: HIGH |
| Validacao | Testar o que scripts realmente fazem, nao o que dizem fazer | Confirmar lacuna de CSP, confirmar escopo do cookie, fazer fingerprint do sub-script |
| Mobilizacao | Parar, restringir ou permitir execucao | Restringir o widget a paginas nao auth, fixar hash do sub-script, alertar em mudanca |
Os screenshots que muitas equipes retornam dizem a mesma coisa depois que cside e implantado. Elas sabiam que o panorama de terceiros era grande. Nao sabiam que poderia ser 16.000 scripts em uma semana tipica de varejo. Nao sabiam quantos precisavam de revisao PCI. Nao tinham um caminho rapido de "encontramos um problema" para "o problema nao pode executar."
Para e-commerce especificamente, esta e a linha de defesa contra campanhas de protecao contra Magecart e web skimming, que continuam funcionando justamente porque o script continua executando.
O que perguntar a uma ferramenta de exposicao do navegador
Se voce esta avaliando ferramentas e quer manter o enquadramento CTEM, as perguntas sao concretas:
- Ela descobre scripts que carregam em runtime, nao apenas no carregamento inicial da pagina?
- Ela segue a cadeia de dependencias ate cargas fourth-party?
- Ela detecta quando o hash de um script antes limpo muda?
- Ela informa o que cada script le do DOM, cookies e storage?
- Ela consegue bloquear ou restringir um script em producao sem redeploy do site?
- As evidencias mapeiam para PCI DSS 6.4.3 e 11.6.1?
- Quanto tempo ha entre deteccao e enforcement? Minutos, horas ou um sprint?
Se a resposta para as ultimas tres nao for "sim, rapido, sim", a ferramenta faz descoberta CTEM sem mobilizacao CTEM.
O enquadramento que importa
CTEM funciona porque trata exposicao como continua. O navegador so cabe nesse quadro se a resposta tambem for continua. Auditorias trimestrais de scripts nao acompanham a cadencia de mudanca do codigo de terceiros. Tickets para marketing nao acompanham a velocidade de um skimmer Magecart.
O caso Skeepers e moderado. Nenhum ator malicioso, um fornecedor respeitavel, um padrao SaaS conhecido. Mesmo assim gerou dois achados HIGH em um grande banco internacional, incluindo um que mapeia diretamente para PCI DSS 4.0.1 6.4.3.
Se um fornecedor benigno em um cliente cuidadoso produz tanta exposicao, a pergunta nao e se a camada do navegador precisa de cobertura CTEM. A pergunta e por quanto tempo as empresas vao continuar tratando-a como fora de escopo.
Para ver sua propria exposicao pela mesma lente, o monitoramento de scripts do navegador em uma propriedade real oferece o ciclo de descoberta, priorizacao e enforcement em menos de uma hora.
Se voce tambem compara uma plataforma orientada a visibilidade com uma orientada a enforcement, a comparacao Reflectiz vs cside mostra os trade-offs lado a lado.
