Reincidência é o segundo incidente na mesma empresa depois que o primeiro foi contido. Ela quase nunca repete o vetor original. O que repete é a condição que abriu o primeiro. Um ativo publicado que não estava em lista nenhuma, e que por isso ficou fora da correção e fora do monitoramento.
Boa parte das empresas que procuram a CSURFACE chega com o incidente já encerrado. O backup voltou, o jurídico fez o que tinha de fazer, o relatório de resposta foi arquivado. Sobrou uma pergunta que ninguém do time consegue responder com uma lista na mão. Por onde mais dá para entrar?
É essa pergunta que este texto trata. A que vem antes dela, o que a visão externa entrega enquanto o incidente ainda está aberto, está no artigo vizinho.
A segunda vez entra por outro lugar
Quem responde a incidente por profissão reconhece o padrão. O time fecha o vetor usado, gira as credenciais, aplica o patch, escreve o post-mortem. Meses depois o adversário volta, e volta por um endereço que não aparecia em diagrama nenhum da resposta anterior.
O motivo é desconfortável. A resposta trabalha sobre o escopo do incidente, e o escopo do incidente é aquilo que foi encontrado. Nenhuma etapa dela pergunta quantos ativos publicados existem fora daquele recorte.
O DBIR 2026 da Verizon dá o contexto em três números que só significam alguma coisa lidos juntos. A exploração de vulnerabilidade passou à frente do roubo de credencial como forma mais comum de entrada. O tempo mediano de correção subiu de 32 para 43 dias, ou seja, piorou. E apenas 26% das falhas do catálogo de exploração conhecida da CISA estavam totalmente corrigidas.
A porta principal virou a falha exposta. A fila que deveria fechá-la anda mais devagar que no ano passado. E três quartos do que já se sabe estar sob ataque continua aberto. Corrigir mais rápido parou de funcionar como plano na velocidade em que o problema anda.
Três dias parados, e a conta que veio depois
Uma operação de e-commerce ficou três dias sem vender. R$ 900 mil em vendas perdidas nesse intervalo. As despesas operacionais do período, que correm na casa das dezenas de milhões, fecharam 11% acima do projetado, somando resposta emergencial e horas extras.
Os números vieram da própria empresa. Eles não estão aqui para provar coisa alguma sobre plataforma. Estão aqui porque o que veio depois deles interessa mais. A empresa não voltou procurando quem consertasse o servidor. Voltou procurando saber o que mais estava publicado no nome dela.
Esse é o momento em que a conversa muda de assunto dentro do cliente. Sai do incidente e entra no inventário.
O inventário oficial não é a superfície
Nos dois casos publicados na página inicial da CSURFACE, uma instituição financeira de médio porte operava com 160 ativos externos no inventário oficial e a descoberta entregou 271. Uma startup de SaaS B2B monitorava 85, e a descoberta entregou 570.
O coordenador de cibersegurança de uma das maiores empresas do Brasil resumiu o efeito assim, e a frase está publicada no site: descobrir que monitorávamos apenas 15% da nossa real superfície de ataque.
Nenhum desses números fala de falha nova. Falam de denominador. Toda métrica de cobertura que um SOC reporta, o percentual de ativos monitorados e o percentual dentro da janela de patch, sai de uma lista que alguém escreveu à mão em algum momento e nunca mais auditou. Um subdomínio de campanha, um ambiente de homologação que subiu junto com uma integração, um domínio herdado de aquisição. A descoberta contínua existe para medir esse denominador em vez de assumir que ele está certo.
Uma ressalva que quase nenhum fornecedor faz. Descobrir 400 ativos novos, sozinho, dobra a fila do time e não reduz risco nenhum. Descoberta sem ordenação é dívida.
Ordenar por gravidade teórica não reduz exposição
A fila da maioria das empresas está ordenada por CVSS. É a ordenação disponível, e ela responde a uma pergunta que quase ninguém está fazendo, que é o quanto a falha seria grave se explorada.
A pergunta operacional é outra. Dentre as milhares de falhas abertas, quais estão sendo exploradas contra alguém agora, e quais delas estão em ativo meu alcançável pela internet.
Os dados do ThreatSensor publicados em threat intelligence mostram o tamanho da diferença. Das 383 vulnerabilidades do núcleo que reúnem catálogo KEV, exploit público e EPSS alto ao mesmo tempo, 168 estão sob exploração ativa neste momento. O Estado da Exposição Digital, que agrega 68 organizações com descoberta concluída, registra que um exploit público surge em média cinco dias depois de a falha ser divulgada.
Cinco dias é menos de um oitavo dos 43 dias medianos de correção. É por essa aritmética que a priorização por exposição real muda mais o resultado do que qualquer aumento de equipe na fila de patch.
O ciclo que fecha isso já tem nome
O que descrevi até aqui é um ciclo de cinco fases: escopo, descoberta, priorização, validação e mobilização. O nome dele é CTEM, continuous threat exposure management, e existe como framework público desde 2022. Uma variação mais recente do vocabulário, preemptive exposure management, fixa o que o CTEM deixou em aberto, que é o momento em que o trabalho acontece. Antes de existir alerta.
Duas observações honestas sobre o framework. A primeira é que analista de mercado não certifica produto, então nenhum fornecedor tem selo de CTEM. A segunda é que o ciclo não define cadência, o que permite rodar as cinco fases uma vez por trimestre e chamar aquilo de CTEM sem mentir uma vírgula.
Para uma empresa que já foi comprometida, a cadência é justamente a variável que interessa. A janela entre o ativo ficar exposto e alguém do time saber que ele existe é o intervalo em que a reincidência acontece.
A infraestrutura de IA que ninguém registrou
Nos últimos dois anos entrou uma classe nova de ativo esquecido, e ela merece um parágrafo próprio porque quase nenhum inventário a acompanha.
Times de produto e de dados subiram painéis de orquestração, endpoints de inferência e ambientes de teste com modelos. Boa parte disso foi publicada por engenharia sem passar por segurança, ficou em pé depois do experimento e nunca entrou em CMDB alguma. O verbete de shadow AI descreve o resultado: boa parte do shadow AI vira ativo exposto na internet antes de virar incidente de dado. E o de segurança de IA agêntica explica por quê. Todo agente em produção acrescenta um endpoint, uma chave e uma integração, e ativo novo entra na superfície externa como qualquer outro.
O limite precisa estar escrito, porque é ele que decide se a frase acima é vendável ou verdadeira. A CSURFACE não protege agentes de IA. Ela encontra a infraestrutura de IA que a empresa publicou e esqueceu, o painel, o endpoint e a chave, e verifica se aquilo está alcançável. Inventário de identidade de agente, análise de escopo de token OAuth e teste de prompt injection exigem acesso interno e são outra categoria de produto.
O que já funciona sem nada de novo é a fila. Quando sai CVE crítico em um componente de stack de IA, a priorização reordena pelo que está sob exploração observada, sem perguntar que tipo de software é o afetado.
Quem opera SOC para terceiros vê o mesmo roteiro se repetir
Um provedor que atende dezenas de clientes assiste ao ciclo inteiro várias vezes por ano, sempre com o mesmo desenho. O cliente contrata monitoramento sobre a lista que entregou, o incidente entra por fora dela, e o pós-incidente vira uma discussão sobre escopo de contrato.
É por isso que a superfície externa costuma ser o primeiro módulo que um SOC terceirizado embute no próprio serviço. Ela ataca o problema anterior ao monitoramento, que é saber sobre o que monitorar. A plataforma tem visão de organização com separação por cliente, controle de acesso por escopo e trilha de auditoria, que é o mínimo para operar assim. A página de parceiros descreve o modelo.
O ganho comercial para o provedor está no relatório do trimestre seguinte, quando ele consegue mostrar ao cliente uma linha que nenhum concorrente mostra: quantos ativos entraram e saíram da superfície do cliente desde a última reunião, e quantos deles ninguém tinha registrado.
Perguntas frequentes
A reincidência acontece sempre pelo mesmo caminho?
Raramente. O vetor usado no primeiro incidente costuma ser o mais bem tratado depois dele, porque é o que a resposta documentou. O que sobrevive é a condição de fundo, ou seja, ativos publicados fora do inventário. O segundo incidente entra por um deles.
Um SOC bem montado não resolve isso sozinho?
Um SOC resolve a detecção do que está sob monitoramento. A pergunta de onde vem a lista de ativos monitorados nunca fez parte do escopo dele, e é anterior à detecção. Os dois trabalhos são complementares, e o de superfície externa vem primeiro na ordem.
Quanto tempo leva para ter a superfície externa mapeada?
Os primeiros ativos aparecem em poucas horas a partir de um domínio semente, e a cobertura se consolida nos primeiros dias. O que leva mais tempo é a atribuição de propriedade, ou seja, provar que um ativo achado pertence mesmo à empresa e não a um homônimo.
A CSURFACE protege agentes de IA?
Não. Ela encontra a infraestrutura de IA publicada na internet e verifica se está exposta. Proteção de agente em tempo de execução, inventário de identidade não humana e teste de injeção de prompt exigem acesso interno ao ambiente e não são feitos por uma plataforma externa.
O que fazer enquanto o incidente ainda está aberto?
Essa é a outra metade do assunto e está tratada em o que a visão externa entrega ao time de resposta, que descreve as listas que dá para levantar de fora em poucas horas com o incidente em curso.