Um programa preemptivo age sobre a exposição antes de existir alerta, e não depois. Dois números dizem se o seu age: o tempo entre um ativo ficar exposto e o time saber disso, e a fração do que foi detectado que passou por alguma prova de que era explorável. Programa periódico responde o primeiro em dias ou semanas, e não responde o segundo.
Todo fabricante de segurança colou a palavra preemptivo em alguma página nos últimos doze meses. Quando um adjetivo é adotado por todo mundo ao mesmo tempo, ele para de separar qualquer coisa.
O que continua separando é medição. E aqui está a parte que costuma surpreender: bastam dois números, os dois saem de uma tarde de trabalho, e nenhum dos dois exige comprar nada. Juntos eles dão um diagnóstico mais específico que qualquer avaliação de maturidade que você contrate.
Por que essa pergunta ficou urgente
O DBIR 2026 da Verizon traz três dados que só fazem sentido lidos juntos.
Três medidas do relatório sustentam isso. Exploração de vulnerabilidade virou a forma mais comum de entrada, passando o roubo de credencial, e ao mesmo tempo a velocidade de quem fecha a porta andou para trás, com a mediana de correção saindo de 32 para 43 dias. O terceiro é o mais incômodo, porque não trata de descoberta e sim de execução. Do catálogo da CISA, que lista o que está comprovadamente sob exploração, 26% aparecia corrigido.
A porta principal virou a falha exposta, e a fila que deveria fechá-la está andando mais devagar que antes. Corrigir mais rápido virou uma promessa que os números não sustentam.
Sobra reduzir o que está exposto. Só que reduzir exige saber o que está exposto antes de o adversário saber, e é aí que os dois testes entram.
Teste 1: quanto tempo até você saber
Pegue os últimos dez ativos que apareceram na sua superfície externa. Subdomínio novo, ambiente de homologação publicado por engano, painel administrativo que subiu junto com uma integração, bucket que alguém abriu para resolver um problema de sexta-feira.
Para cada um, anote duas datas. Quando ele ficou alcançável pela internet, e quando alguém do time de segurança soube que ele existia.
A diferença entre as duas é o seu tempo até a descoberta.
Se a mediana vem em horas, o programa é preemptivo nessa dimensão. Se vem em dias, é periódico com nome novo. E se você não consegue levantar a primeira data, esse é o achado, maior que o número que você queria calcular.
Uma ressalva sobre o que esse teste não mede. Ele não diz se o ativo era perigoso. Um ambiente de homologação sem dado real e com autenticação em dia pode ficar exposto por meses sem consequência nenhuma. O que ele mede é a velocidade do seu conhecimento.
E cuidado com a armadilha do inventário. Muita empresa mede esse número contra a própria lista de ativos, o que garante um resultado bom e falso. O ativo que importa para o teste é justamente o que não estava na lista.
Teste 2: quanto do que você sabe significa alguma coisa
Pegue tudo que sua ferramenta reportou no último trimestre. Some. Depois some quantos desses itens passaram por alguma verificação de que a falha era mesmo alcançável e explorável naquele ativo específico.
Divida o segundo pelo primeiro.
Na maioria dos programas que vejo, esse número fica abaixo de 5%. O resto da fila é achado bruto, ordenado por CVSS, esperando alguém com tempo para conferir um por um.
É aqui que a maior parte do orçamento de segurança evapora. O CVSS mede dano potencial em condições ideais para o atacante e não diz nada sobre a probabilidade de alguém tentar. Existem falhas 9.8 publicadas há anos sem um único exploit conhecido. E existem falhas de nota média em campanha ativa neste momento, sentadas na posição 400 de uma fila ordenada por gravidade teórica.
Um programa que valida pouco não é preguiçoso. É um programa que recebeu mais achado do que consegue processar, e a saída natural dele é trabalhar de cima para baixo numa lista que está na ordem errada.
Os dois números se multiplicam, não se somam
Essa é a parte que muda como você lê o resultado.
Descoberta rápida sem validação não melhora o programa. Ela entrega uma pilha maior, mais depressa, e a pilha continua na ordem errada. O time descobre mais coisa e fica mais paralisado.
Validação alta sobre um inventário incompleto é pior de um jeito mais sutil: produz confiança. Você trata muito bem tudo que conhece, fecha o trimestre com métrica boa, e o ativo que vai te derrubar nunca entrou na conta.
Por isso os dois números só significam alguma coisa juntos. Combinados, eles dão quatro diagnósticos.
Descoberta rápida e validação alta. O programa é preemptivo. O que resta é mobilização: transformar achado validado em ticket com dono e prazo, que é onde a maioria trava depois de resolver as duas primeiras partes.
Descoberta rápida e validação baixa. Você sabe o que tem e não sabe o que importa. É a situação mais comum em empresa que comprou uma boa ferramenta de descoberta. O próximo passo é validação de exploitabilidade, e não mais descoberta.
Descoberta lenta e validação alta. Perfil clássico de gestão de vulnerabilidades madura sem gestão de superfície. A métrica interna parece ótima e a superfície real não está no relatório.
Descoberta lenta e validação baixa. Onde quase todo programa começa. A ordem importa: resolva a descoberta primeiro, porque validar bem uma lista incompleta só ancora você na parte errada do problema.
As mesmas duas perguntas, viradas para o fornecedor
Os dois testes funcionam melhor que qualquer pergunta sobre funcionalidade numa reunião comercial.
Pergunte quanto tempo passa entre o ativo ficar exposto e a plataforma avisar. Repare se a resposta fala de frequência de varredura ou de tempo até o aviso. Varredura diária com processamento semanal produz aviso semanal.
Pergunte quanto do que eles reportam vem com prova de exploitabilidade. A resposta honesta costuma trazer uma distinção entre achado e achado validado. Se o fabricante trata os dois como a mesma coisa, o número de achados dele está inflado por construção.
Tem uma terceira pergunta que revela mais que as duas anteriores, e quase ninguém faz: o que vocês não fazem? Permissão excessiva em conta de nuvem e credencial válida usada por quem não devia não aparecem de fora, porque não atendem em porta nenhuma. Quem promete as duas metades no mesmo produto está vendendo o nome da categoria.
Uma tarde, nenhuma compra
O primeiro número você levanta com o histórico de DNS e o registro de mudança que já existem. O segundo, com o relatório que sua ferramenta atual já emite.
Isso importa mais do que parece. Significa que você consegue descobrir onde o seu programa está quebrado antes de sentar com qualquer fornecedor, e chegar na reunião sabendo qual dos quatro quadrantes é o seu. Quem chega sem esses dois números compra pela palavra que está na capa da proposta, e a palavra, como toda a indústria adotou ao mesmo tempo, não quer dizer mais nada.
Preemptivo é uma alegação. Esses dois números são o recibo dela.
Perguntas frequentes
Qual é um bom tempo até a descoberta?
Depende do tamanho e da velocidade de mudança da superfície. Como referência prática: horas é bom, um dia é aceitável na maioria dos contextos, uma semana significa que o adversário teve seis dias de vantagem em cada ativo novo. Varredura automatizada de internet inteira roda em ciclos de horas, então essa é a régua real.
Por que a taxa de validação importa mais que o total de achados?
Porque total de achados mede o volume que a ferramenta produz, e não o risco que você tem. Uma fila de 3.000 itens sem validação e uma de 40 itens validados podem descrever a mesma empresa. A segunda dá para executar.
Meu programa de gestão de vulnerabilidades já cobre isso?
Cobre o segundo teste parcialmente, e o primeiro quase nunca. Gestão de vulnerabilidades trabalha sobre o ativo que já está no inventário, então ela nasce cega para o ativo que ninguém registrou. É a diferença entre gestão de vulnerabilidades e gestão de exposição.
Dá para melhorar os dois números sem aumentar o time?
O primeiro sim, porque descoberta é trabalho de máquina e não escala com gente. O segundo depende de automatizar a validação, já que conferir manualmente uma fila de milhares de itens não é viável em nenhum tamanho de equipe.
E se eu não conseguir levantar a primeira data do teste 1?
Esse é o resultado do teste. Não saber quando um ativo ficou exposto significa que ninguém está observando a superfície de fora, e é a lacuna a fechar antes de qualquer outra.
Esses testes servem para medir um fornecedor em POC?
Servem, e são melhores que a contagem de achados. Peça que o fabricante mostre um ativo que você não conhecia, com a data em que ele apareceu, e a prova de exploitabilidade de pelo menos um achado. As duas coisas juntas separam produto de relatório.