Um número ainda não é um risco.

O que é realmente uma CVE

CVE significa Common Vulnerabilities and Exposures. Um número como CVE-2026-12345 é um identificador e nada mais: diz que uma vulnerabilidade foi reportada e catalogada. Não diz se o produto roda na sua organização, se está acessível, se está sendo explorado nem o que acontece se for.

É exatamente aí que falha a maioria dos processos de vulnerabilidades. Eles produzem listas em vez de decisões. Uma lista com 4.000 achados em aberto não é evidência de uma gestão de vulnerabilidades que funciona — é a evidência de que não existe nenhuma.

As quatro medidas que só juntas dizem algo

1. 1
   CVSS — quão grave seriaO valor de 0 a 10 descreve a gravidade técnica em condições de laboratório. É independente do seu ambiente e permanece igual por anos. Sozinho não serve para priorizar: há muito mais vulnerabilidades com CVSS 9 do que capacidade para fechar todas de uma vez.
2. 2
   EPSS — qual a probabilidadeO Exploit Prediction Scoring System estima a probabilidade de uma vulnerabilidade ser realmente explorada nos próximos 30 dias. O valor muda diariamente. A grande maioria das CVE nunca é explorada — o EPSS torna visível a pequena minoria.
3. 3
   KEV — já está sendo exploradaO catálogo de vulnerabilidades exploradas conhecidas lista o que está comprovadamente sob ataque. Se uma vulnerabilidade está lá e roda na sua organização, a discussão sobre prioridade acabou.
4. 4
   Seu ambiente — isso chega a afetar vocêA medida que nenhum serviço externo conhece: se o produto roda na sua organização, em qual versão, acessível de fora ou na rede interna, e quais dados estão por trás. Sem um inventário dos seus sistemas, toda avaliação de vulnerabilidade é um palpite.

O que os frameworks exigem

A gestão de vulnerabilidades está em todos os grandes frameworks — com rigor e evidência diferentes.

• ISO/IEC 27001:2022, anexo A 8.8 — é preciso obter informações sobre vulnerabilidades técnicas dos sistemas utilizados, avaliar a exposição e tomar medidas adequadas. A evidência é o caminho de decisão documentado, não a lista do scan.
• NIS2 / § 30 BSIG, medida 5 — segurança na aquisição, no desenvolvimento e na manutenção, incluindo expressamente o tratamento e a divulgação de vulnerabilidades. O que se exige é um procedimento, não uma ferramenta.
• DORA, gestão de risco de TIC — detecção de atividades anômalas e de vulnerabilidades, além de um programa de testes que inclua avaliações de vulnerabilidades e scans.
• § 75b SGB V, anexos 1 a 5 — sistemas operacionais e aplicações atualizados e aplicação de correções de segurança, escalonados pelo porte do consultório.

Um procedimento que se sustenta na auditoria

Quatro passos que, juntos, produzem a evidência que um auditor quer ver.

1. 1
   Saber o que você operaUm inventário mantido de sistemas, versões e responsáveis. Sem ele, todo o resto é ocupação. É a primeira coisa que o auditor pede.
2. 2
   Assinar fontes em vez de procurarAvisos exatamente sobre os produtos que você usa — não o fluxo completo de todas as publicações. Quem lê tudo não lê nada.
3. 3
   Avaliar com prazo, não por intuiçãoDefina de antemão qual combinação de gravidade, explorabilidade e acessibilidade dispara qual prazo. Essa definição é, em si, uma evidência — e protege você no dia em que um prazo estoura.
4. 4
   Justificar exceções e dar prazo a elasO que não é fechado precisa de justificativa, de uma medida compensatória e de uma data de reanálise. Uma exceção sem prazo é uma não conformidade na auditoria.

Avisos de vulnerabilidades

Acompanhamos os avisos de qualquer forma e os classificamos: o que é relevante, quem é afetado e o que fazer. Avise-nos se quiser receber essa classificação. O catálogo em si é de consulta pública em cvedetails.com.