Gestão de vulnerabilidades: como priorizar riscos além do CVSS
Corrigir tudo é impossível. Veja como priorizar o que importa combinando severidade, exposição e probabilidade de exploração.
Scanners produzem centenas ou milhares de achados, e tratar todos como urgentes é a receita para não tratar nenhum bem. Gestão de vulnerabilidades é o processo de transformar esse volume em decisões de correção orientadas a risco real. O segredo está na priorização: o CVSS sozinho não basta, porque mede a gravidade teórica da falha, não a probabilidade de ela ser explorada no seu contexto.
Este guia apresenta um modelo prático de priorização que combina severidade, exposição, criticidade do ativo e probabilidade de exploração, além da governança que torna o processo repetível: inventário, SLA, exceções e reteste. O objetivo é corrigir primeiro o que mais reduz risco.
Por que o CVSS não basta
O CVSS dá uma nota de gravidade técnica, mas duas vulnerabilidades com o mesmo CVSS podem ter risco muito diferente. Uma falha crítica em um servidor interno e isolado, sem exposição, é menos urgente que uma falha média em um serviço exposto à internet e que já tem exploração pública circulando. Priorizar só por CVSS faz a equipe gastar energia no lugar errado.
O EPSS complementa o CVSS estimando a probabilidade de uma vulnerabilidade ser explorada num horizonte próximo. Combinar EPSS com o contexto de exposição e a criticidade do ativo aproxima a priorização do risco real, em vez da gravidade teórica.
Fontes de descoberta: cobrir todas as camadas
Um único scanner enxerga só uma parte do problema. Gestão de vulnerabilidades madura combina fontes que olham camadas diferentes: análise de composição (SCA) para as dependências de terceiros, análise estática (SAST) para o código próprio, análise dinâmica (DAST) para a aplicação em execução, varredura de rede e de sistema operacional para a infraestrutura, exame de imagens de contêiner e avaliação de configuração de nuvem (CSPM). Cada uma cobre um ponto cego das outras.
Juntar essas fontes traz um problema prático: a mesma vulnerabilidade aparece em várias ferramentas, com formatos e notas diferentes. Deduplicar e correlacionar os achados em um inventário único evita que a equipe conte o mesmo item várias vezes e perca a real dimensão do risco. Normalizar a severidade em uma escala comum é o que torna a fila de correção confiável.
- SCA: vulnerabilidades em bibliotecas e dependências de terceiros
- SAST: falhas no código próprio, antes de ir para produção
- DAST: comportamento da aplicação em execução
- Varredura de rede e sistema: infraestrutura e serviços expostos
- Imagens de contêiner: pacotes e camadas base desatualizadas
- Configuração de nuvem (CSPM): postura e desvios de boas práticas
Um modelo de priorização
Um modelo simples e eficaz cruza três dimensões: gravidade técnica (CVSS), probabilidade de exploração (EPSS e existência de exploração conhecida) e contexto (o ativo é exposto, é crítico para o negócio, guarda dados sensíveis). Itens que pontuam alto nas três dimensões vão para o topo da fila.
- Gravidade técnica da falha (CVSS)
- Probabilidade de exploração (EPSS, exploração pública conhecida)
- Exposição do ativo (interno, externo, internet)
- Criticidade do ativo para o negócio e sensibilidade dos dados
- Existência de mitigação ou controle compensatório
Valide os achados relevantes antes de priorizar, para descartar falso positivo. Nada desperdiça mais credibilidade do que cobrar a correção de algo que não se aplica ao ambiente.
Inteligência de exploração e o ciclo de correção
O EPSS estima a probabilidade de exploração, mas há um sinal ainda mais direto: saber que a vulnerabilidade já está sendo explorada. O catálogo de vulnerabilidades exploradas conhecidas mantido pela CISA (o KEV) lista falhas com exploração confirmada em campo. Quando um item do seu ambiente aparece nesse catálogo, ele salta para o topo da fila, porque a dúvida sobre se vale a pena atacar já foi respondida na prática.
A diferença entre os dois sinais é útil: o EPSS é probabilístico e olha para a frente, enquanto o KEV é a confirmação de que a exploração existe. Uma regra de priorização que combina os dois com a exposição do ativo separa com clareza o que precisa de ação imediata do que pode seguir o fluxo normal.
SE consta no KEV E ativo exposto: prazo mais curto
SE cvss alto E epss alto E ativo exposto: prazo curto
SE cvss alto E ativo interno sem exposição: prazo padrão
SE baixo risco em ativo isolado: avaliar aceitação registradaDo achado ao patch
Priorizar sem executar não reduz risco. O ciclo se fecha com a correção, que na maioria das vezes é aplicar uma atualização, mas nem sempre. Patches críticos merecem uma janela definida e teste antes de ir para produção, com plano de retorno caso algo quebre. Quando o patch não está disponível ou não pode ser aplicado a tempo, um controle compensatório, como restringir a exposição na borda, reduz o risco enquanto a correção definitiva não chega.
Governança: SLA, exceções e reteste
Defina SLAs de correção por faixa de risco, com prazos realistas, e um processo de exceção para quando a correção não é viável de imediato. Uma exceção deve ter justificativa, dono, prazo e, idealmente, um controle compensatório. Sem governança, exceções viram regra e o risco se acumula em silêncio.
Feche o ciclo com reteste: confirme que a correção realmente eliminou a vulnerabilidade. Acompanhe a evolução com métricas simples, como o tempo médio de correção por faixa de risco, para mostrar que a postura está melhorando de forma mensurável.
Checklist prático
- Manter inventário de ativos atualizado e abrangente
- Validar achados relevantes para descartar falso positivo
- Priorizar combinando CVSS, EPSS, exposição e criticidade
- Considerar exploração pública conhecida na priorização
- Definir SLA de correção por faixa de risco
- Ter processo de exceção com justificativa, dono e prazo
- Registrar controles compensatórios quando a correção é adiada
- Executar reteste para confirmar a correção
- Acompanhar métricas de evolução da postura
- Reavaliar periodicamente em vez de tratar como esforço pontual
- Cobrir várias fontes: SCA, SAST, DAST, infraestrutura, contêiner e nuvem
- Deduplicar e correlacionar achados de ferramentas diferentes
- Elevar a prioridade de itens no catálogo KEV de exploração conhecida
- Definir janela e teste antes de aplicar patches críticos
Boas práticas
- Priorize por risco real, não apenas por severidade nominal
- Use EPSS e contexto para separar o urgente do importante
- Mantenha o inventário em dia para evitar pontos cegos
- Trate exceções como decisão consciente e temporária
- Feche sempre com reteste para validar a correção
- Meça e comunique a evolução com métricas simples
- Combine fontes de descoberta e normalize a severidade em uma escala única
- Trate exploração confirmada (KEV) como sinal de ação imediata
Erros comuns
Priorizar somente por CVSS
Esforço gasto em itens isolados enquanto exposições reais permanecem abertas.
Inventário incompleto
Ativos não inventariados nunca são avaliados e viram pontos cegos.
Tratar todo achado como urgente
A equipe se afoga em alertas e nada é corrigido com qualidade.
Exceções sem prazo nem dono
O risco se acumula de forma permanente e silenciosa.
Não fazer reteste
Correções incompletas passam por resolvidas e a falha continua.
Depender de uma única fonte de descoberta
Camadas não cobertas, como dependências ou configuração de nuvem, viram pontos cegos.
Ignorar exploração confirmada na priorização
Vulnerabilidades já exploradas em campo esperam na fila atrás de itens teóricos.
Quando procurar apoio especializado
Transformar volume de achados em um processo contínuo e priorizado é o foco do serviço de Gestão de Vulnerabilidades da GUARDIASEC, que identifica, prioriza por risco real e acompanha a correção com reteste e métricas de evolução.
Perguntas frequentes
O que é EPSS e como ele ajuda na priorização?
O EPSS é um indicador que estima a probabilidade de uma vulnerabilidade ser explorada em um horizonte próximo. Enquanto o CVSS mede a gravidade técnica, o EPSS aproxima a probabilidade real de exploração. Combinar os dois com o contexto de exposição ajuda a separar o que é urgente do que apenas parece urgente pela nota.
Gestão de vulnerabilidades substitui o pentest?
Não. A gestão de vulnerabilidades dá amplitude e continuidade, identificando e acompanhando falhas conhecidas em escala. O pentest dá profundidade, valida exploração e encontra falhas de lógica que scanners não detectam. Os dois se complementam dentro de um programa de segurança maduro.
Como lidar com vulnerabilidades que não posso corrigir agora?
Use um processo de exceção formal: registre a justificativa, defina um dono e um prazo de reavaliação e, sempre que possível, aplique um controle compensatório que reduza o risco enquanto a correção definitiva não acontece. O importante é que a exceção seja consciente e temporária, não um esquecimento permanente.
Preciso corrigir todas as vulnerabilidades?
Corrigir tudo é inviável e não é o objetivo. A meta é reduzir e controlar o risco de forma contínua, tratando primeiro o que combina gravidade, probabilidade de exploração e exposição. Algumas vulnerabilidades de baixo risco em ativos isolados podem ser aceitas conscientemente, desde que isso seja registrado e revisado.
O que é o catálogo KEV e como usá-lo na priorização?
O KEV é o catálogo de vulnerabilidades exploradas conhecidas mantido pela CISA, que reúne falhas com exploração confirmada em campo. Na priorização, ele funciona como um sinal forte: se um item do seu ambiente consta ali, a exploração deixou de ser hipótese e ele deve subir na fila. Usado junto ao CVSS, ao EPSS e à exposição do ativo, ajuda a separar o que precisa de ação imediata do que pode seguir o fluxo normal.
Qual a diferença entre SCA, SAST e DAST?
São fontes que olham camadas diferentes. O SCA analisa as dependências de terceiros em busca de vulnerabilidades conhecidas. O SAST examina o código próprio de forma estática, antes da execução. O DAST testa a aplicação em execução, observando o comportamento. Nenhuma cobre tudo sozinha, e um programa maduro combina as três com varredura de infraestrutura, imagens de contêiner e configuração de nuvem.
Como evito contar a mesma vulnerabilidade várias vezes?
Ferramentas diferentes relatam o mesmo item com formatos e notas distintas, o que infla o volume. A solução é consolidar os achados em um inventário único, deduplicar por identificador e ativo, e normalizar a severidade em uma escala comum. Sem essa correlação, a fila de correção perde precisão e a equipe trabalha sobre um número que não reflete o risco real.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.