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 comunicada e catalogada. Não diz se o produto corre na sua organização, se está acessível, se está a ser explorado nem o que acontece se for.

É exatamente aqui que falham a maioria dos processos de vulnerabilidades. Produzem listas em vez de decisões. Uma lista com 4.000 constatações em aberto não é prova de uma gestão de vulnerabilidades que funciona — é a prova de que não existe nenhuma.

As quatro grandezas que só juntas dizem alguma coisa

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 mantém-se igual durante anos. Sozinho não serve para priorizar: há muito mais vulnerabilidades com CVSS 9 do que capacidade para as 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á a ser exploradaO catálogo de vulnerabilidades exploradas conhecidas lista o que está comprovadamente sob ataque. Se uma vulnerabilidade lá consta e corre na sua organização, a discussão sobre prioridades terminou.
4. 4
   O seu ambiente — chega sequer a afetá-loA grandeza que nenhum serviço externo conhece: se o produto corre na sua organização, em que versão, acessível do exterior ou na rede interna, e que dados estão por trás. Sem um inventário dos seus sistemas, qualquer avaliação de vulnerabilidades é um palpite.

O que os referenciais exigem

A gestão de vulnerabilidades consta de todos os grandes referenciais — com exigência e prova diferentes.

• ISO/IEC 27001:2022, anexo A 8.8 — tem de ser obtida informação sobre vulnerabilidades técnicas dos sistemas utilizados, avaliada a exposição e tomadas medidas adequadas. A prova é o caminho de decisão documentado, não a lista do scan.
• NIS2 / § 30 BSIG, medida 5 — segurança na aquisição, desenvolvimento e 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 do risco das TIC — deteção de atividades anómalas e de vulnerabilidades, mais um programa de testes que inclua avaliações de vulnerabilidades e scans.
• § 75b SGB V, anexos 1 a 5 — sistemas operativos e aplicações atualizados e aplicação de correções de segurança, escalonados pela dimensão do consultório.

Um procedimento que aguenta em auditoria

Quatro passos que, juntos, produzem a prova que um auditor quer ver.

1. 1
   Saber o que 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
   Subscrever fontes em vez de procurarAvisos exatamente sobre os produtos que utiliza — 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 à partida que combinação de gravidade, explorabilidade e acessibilidade desencadeia que prazo. Essa definição é, em si, uma prova — e protege-o no dia em que um prazo falha.
4. 4
   Fundamentar exceções e dar-lhes prazoO que não é fechado precisa de fundamentação, de uma medida compensatória e de uma data de reapreciação. Uma exceção sem prazo é uma não conformidade em auditoria.

Avisos de vulnerabilidades

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