Gestão de vulnerabilidades: o que corrigir primeiro

Existe um número no relatório de investigações de vazamento de dados de 2026 que deveria reorganizar prioridade em muita empresa: a exploração de vulnerabilidade ultrapassou o roubo de credencial como vetor inicial número um, chegando a 31% e crescendo 55% em um ano.

Durante muito tempo a mensagem foi que o elo mais fraco era humano — e continua sendo verdade que credencial abusada é a técnica mais presente ao longo das cadeias de ataque, com 39%. Mas a porta de entrada mudou: hoje, mais frequentemente, o invasor não convence ninguém. Ele encontra um sistema desatualizado exposto à internet e entra.

O problema é que "manter tudo atualizado" não é um plano executável. Um parque médio acumula milhares de achados e nenhuma equipe corrige tudo.

A tese em uma frase: gestão de vulnerabilidades não é corrigir tudo — é ter um critério defensável para escolher o que fica sem correção, e revisitá-lo antes que a escolha vire esquecimento.

O vocabulário, em ordem de utilidade

CVE (Common Vulnerabilities and Exposures) é só o identificador — CVE-2026-39987, por exemplo, a falha usada no primeiro ataque agêntico documentado. Serve para que todo mundo fale da mesma coisa. Não carrega julgamento de gravidade.

CVSS é a nota de severidade de 0 a 10, derivada de características técnicas: dá para explorar remotamente? precisa de autenticação? qual o impacto? É útil e é mal usado — porque CVSS mede gravidade em tese, não prioridade no seu ambiente. Uma falha 9,8 num sistema que não existe na sua rede tem prioridade zero.

EPSS (Exploit Prediction Scoring System) corrige parte disso: estima a probabilidade de a falha ser explorada nos próximos 30 dias, a partir de dados observados. É a diferença entre "isso seria grave" e "isso está acontecendo".

KEV (Known Exploited Vulnerabilities) é o catálogo da CISA com vulnerabilidades comprovadamente exploradas em ataques reais. Se algo entrou no KEV, acabou a discussão: é prioridade máxima, independentemente da nota CVSS. É a lista mais acionável que existe no assunto, é pública e é gratuita.

Gestão de vulnerabilidades: o critério de priorização que funciona

Três perguntas, nesta ordem. Elas reduzem milhares de achados a uma lista que cabe numa semana.

1. Está exposto à internet? Vulnerabilidade em serviço publicado é ordem de magnitude mais urgente do que a mesma falha numa máquina interna. O invasor não precisa de nada além de um scanner e um exploit público.

2. Já está sendo explorada? Consulte o KEV e o EPSS. Falha explorada na prática deixou de ser hipótese e passou a ser corrida.

3. O que roda ali importa? Um servidor que guarda dado de cliente ou sustenta faturamento vale mais do que a máquina de teste que ninguém usa. Isso exige inventário — e é onde a maioria dos programas descobre que não sabe o que tem.

Combinando as três, a fila fica assim:

Repare que CVSS não aparece sozinho em nenhuma linha. Ele entra como desempate, nunca como critério principal.

O que trava os programas reais

Quatro obstáculos que aparecem em quase toda empresa.

Não existe inventário. Você não corrige o que não sabe que tem. O servidor esquecido de um projeto encerrado, a VPS que alguém subiu para um teste, o sistema de OT que ninguém mapeou. O levantamento é chato e é pré-requisito de tudo.

A janela de manutenção é disputada. Patch exige parada, e parada disputa espaço com entrega. É por isso que o concentrador de VPN — o equipamento mais exposto de muitas redes — costuma ser o mais atrasado: atualizá-lo derruba o acesso remoto de todo mundo.

Ninguém verifica se aplicou. Esta é a falha mais silenciosa. A ferramenta reporta o patch como aplicado, o serviço não foi reiniciado, e a vulnerabilidade continua ativa com a planilha dizendo que fechou. Sem a etapa de verificação, o ciclo é ficção.

Não há registro do que ficou de fora. Vulnerabilidade que não vai ser corrigida precisa de exceção formal: qual a mitigação, qual o prazo, quem responde. Sem isso, não é risco aceito — é risco esquecido, e a diferença aparece na auditoria e no incidente.

Quando não dá para corrigir

É a situação mais comum, e ela tem saída legítima. Quando o patch não existe, quebra compatibilidade ou exige uma parada inviável, aplica-se mitigação compensatória:

• Tirar da internet. A medida de maior impacto e a mais subestimada. Se aquilo não precisa ser público, deixe de ser.
• Segmentar. Reduzir quem alcança o sistema vulnerável limita o estrago — mecanismo detalhado no post sobre VLAN.
• Restringir e monitorar. Regra de firewall específica, WAF na frente da aplicação, alerta dedicado no SIEM.
• Registrar a exceção com prazo e responsável, e revisitar.

A métrica certa

Programas de vulnerabilidade adoram reportar volume: "escaneamos 4 mil ativos, encontramos 12 mil achados". Isso não diz nada sobre segurança.

Os números que importam são três, e o que vale neles é a tendência:

• Tempo entre a divulgação e a correção, para o que está exposto à internet. É o único número que descreve a sua exposição real.
• Quantidade de itens do KEV em aberto. Deveria ser zero, ou perto disso.
• Idade do achado mais antigo em aberto por criticidade. Denuncia acúmulo silencioso melhor do que qualquer média.

Existe uma expressão que descreve bem o problema atual: enquanto os defensores demoram para corrigir, a exploração acelera. É a assimetria que produziu a alta de 55% — não uma sofisticação nova do atacante, mas a mesma lentidão de sempre encontrando ferramentas de exploração cada vez mais rápidas.

Onde isso se conecta

Gestão de vulnerabilidades é o pré-requisito de quase tudo que já cobri nesta série. A entrada do ataque agêntico documentado foi uma CVE em serviço exposto. O relatório de OT aponta infraestrutura superexposta como uma das quatro fraquezas estruturais que sustentam os ataques industriais. E a cadeia de suprimentos de software é gestão de vulnerabilidade aplicada ao código que você não escreveu — daí o valor do SBOM, que responde "eu uso isso?" em segundos.

Para uma PME, o programa mínimo defensável cabe em quatro linhas: saber o que está publicado na internet, acompanhar o KEV, aplicar atualização automática onde não há risco de quebrar, e registrar formalmente o que ficou de fora. O restante da base está no guia de cibersegurança para PMEs.

O ponto que fica

A promessa implícita de todo programa de vulnerabilidades — "vamos corrigir tudo" — é falsa, e assumir isso melhora o resultado. Nenhuma equipe fecha todos os achados, e boa parte deles nunca seria explorada.

O trabalho real é de triagem: separar o que ameaça você agora do que é apenas grave em tese, e transformar o resto numa decisão registrada em vez de um item que envelhece numa planilha.

Se a sua empresa vai começar por um lugar só, comece pelo que está exposto à internet e aparece no KEV. É uma lista curta, pública, gratuita — e é por onde o invasor também começa.