Monitoramento CVE que leva à ação.

Atualizado em 16 de setembro de 2026

A CVE (Vulnerabilidades e exposições comuns) é o identificador público de uma vulnerabilidade. Mais do que 40 000 foram publicados em 2024, e a curva não se achatou desde 2016 (Métricas do programa CVE). Uma equipe executando cerca de trinta componentes verá algumas dezenas ao longo do ano que realmente lhe dizem respeito. Todo o problema reside nessa proporção.

O verdadeiro custo do ruído

Ler cada CVE publicado representaria mais de duas horas por dia útil, para uma taxa de relevância inferior a um por cento. Ninguém aguenta esse ritmo. O que acontece na prática é pior do que desistir: a equipa lê durante duas semanas, depois passa os olhos, depois filtra por «crítico» e acaba por deixar de abrir. No dia em que uma falha lhe diz realmente respeito, a notificação chega a um canal que já ninguém vê.

Portanto, o risco real é o desligamento, não o volume. Uma configuração de monitoramento é julgada com base em uma questão: alguém ainda estará lendo isso daqui a seis meses?

Construindo um escopo e mantendo-o atualizado

Um escopo de monitoramento é a lista do que você executa, com versões. Existem três maneiras de construí-lo: inseri-lo manualmente, importar um SBOM (Lista de materiais de software, o inventário de componentes produzido pelo pipeline de construção de software) ou permitir que as tecnologias por trás de um URL público sejam detectadas. Aguarde dois minutos para cerca de dez componentes.

O difícil não é criá-lo, é mantê-lo atualizado. Uma atualização de versão, uma biblioteca adicional, um servidor assumido de um cliente: cada alteração não registrada é um ponto cego. Importar um SBOM a cada lançamento é o único mecanismo que se mantém ao longo do tempo, porque não depende da memória de ninguém.

Três sinais para priorizar e quando cada um erra

Depois que a lista for reduzida, você ainda precisará escolher o pedido. Três referências públicas respondem a isso e devem ser lidas exatamente nesta ordem.

KEV primeiro: o catálogo de vulnerabilidades exploradas ativamente, publicado pela agência de segurança cibernética dos EUA. Não é uma previsão, é uma constatação: a lista dos incêndios já ardendo. Um CVE que está no KEV e presente no seu ambiente é consertado, sem discussão. Sua limitação: lista apenas o que foi observado e relatado, por isso às vezes chega após a exploração. Como ler o catálogo KEV.

EPSS próximo: probabilidade de exploração observada nos próximos trinta dias, recalculada todas as manhãs. É a previsão do tempo: não se discute com possibilidade de chuva, leva-se guarda-chuva. Sua limitação: descreve o mundo, não você. Uma falha de alta probabilidade em um serviço que você não expõe dificilmente o preocupa. O que o EPSS prevê e o que não prevê.

CVSS último: a gravidade intrínseca, de 0 a 10. É a magnitude de um terremoto: a força do evento, independentemente de haver uma cidade acima dele. Sua limitação é a mais importante a saber: a maioria dos CVEs classificados como críticos nunca são explorados. Como ler um vetor CVSSe a calculadora para construir um.

Uma regra que você pode usar como está: qualquer coisa no KEV e presente em seu ambiente é tratada em 48 horas; a seguir, qualquer coisa com um EPSS acima de 0,1; CVSS serve apenas para desempatar entre dois candidatos.

O que acontece após o alerta

Um alerta que não leva a lugar nenhum é um custo sem retorno. O caminho completo possui quatro estados: recebido, analisado, sendo corrigido, resolvido. Cada alerta tem um proprietário nomeado; cada mudança de estado deixa um registro datado, que é tão útil para a equipe quanto para um auditor seis meses depois.

Dois atrasos que não devem ser confundidos, porque se confundem por toda parte. O sincronização: com que frequência os feeds são relidos. O processamento: o tempo entre a leitura de um CVE e o envio da notificação, que conosco fica abaixo de 30 segundos. Nenhuma ferramenta pode ser mais rápida do que sua frequência de sincronização, e qualquer fornecedor que anuncie apenas um número está ocultando o outro.

Fim do suporte, o ponto cego

Uma versão em fim de vida nunca receberá outro patch. Não é mais uma vulnerabilidade: é a garantia de que todas as futuras permanecerão abertas. Portanto, um monitoramento sério rastreia datas de fim de suporte tão próximas quanto CVEs, com antecedência suficiente para planejar uma migração em vez de descobri-la no dia.

Nove feeds, verificados

Nenhuma fonte é completa por si só. Desde fevereiro de 2024, o enriquecimento CVE pelo NVD diminuiu drasticamente: muitas vulnerabilidades passaram meses sem pontuação ou referência de produto. Verificamos nove feeds (Lista CVE, NVD, o catálogo KEV, pontuações EPSS, provas de conceito publicadas, avisos GitHub, OSV, publicações CERT-FR e o banco de dados europeu EUVD) para permanecer utilizáveis ​​quando um deles fica para trás. Fontes e suas licenças em detalhes.

Na prática, na manhã de segunda-feira

Quatro passos, nesta ordem, para uma equipe que começa do nada.

1. Declare vinte componentes, versões incluídas. Não cem: os expostos à Internet e os que possuem dados.
2. Defina o limite. Tudo no KEV, qualquer que seja a pontuação, mais qualquer coisa acima de 7 no CVSS. Isso leva você de vários milhares de CVEs por mês a um punhado de alertas.
3. Separe os canais. Itens críticos para Slack ou Teams, o restante em um resumo diário. Enviar tudo para o Slack é o mesmo que silenciar o Slack.
4. Revise o volume após uma semana. Mais de dez alertas? Aumente o limite. Zero? Seu escopo provavelmente está incompleto.

Qual ferramenta para lidar com tudo isso

O método acima não depende de nenhum produto. Para escolher aquele que o realiza, duas páginas: a Classificação de 2026 de seis ferramentas de monitoramento CVE se você está começando do zero, e o comparações cara a cara se você já usa OpenCVE, Cyberwatch ou CVEDetails. O TechWatchAlert aplica este método, em francês, hospedado na França, com um plano gratuito para testá-lo em seu próprio escopo.