Priorizar vulnerabilidades no SOC exige combinar três sinais que medem coisas diferentes: o KEV da CISA confirma exploração ativa, o EPSS estima a probabilidade de exploração nos próximos 30 dias e o CVSS mede apenas a severidade técnica. A fila de correção não deve ser ordenada por um único score: o CVSS Base Score não é preditor de exploração, o EPSS frequentemente sobe depois da exploração já ocorrer e o KEV, sozinho, chega tarde para o primeiro ataque. O modelo prático é uma fila em camadas que cruza os três sinais com a exposição real do ativo.
O ponto de partida conceitual é simples e frequentemente esquecido: severidade não é probabilidade. Uma falha crítica num componente sem exposição à internet compete na fila com uma falha média num gateway exposto, e o CVSS sozinho não oferece critério para desempatar. É essa lacuna que o EPSS e o KEV preenchem, cada um com uma limitação própria que o time precisa conhecer antes de automatizar decisões.
O que cada sinal realmente mede
O EPSS estima a probabilidade de exploração em 30 dias para cada CVE, com score entre 0 e 1 publicado diariamente pela FIRST via CSV e API. Já o KEV funciona como registro histórico: para entrar no catálogo, a CISA exige exploração ativa observada e orientação de remediação clara disponível. O CVSS, por sua vez, pontua de 0 a 10 o dano potencial se a falha for explorada, sem qualquer informação sobre a chance de isso acontecer.
A tabela abaixo resume o papel de cada sinal na fila:
| Sinal | O que mede | Atualização | Uso correto no SOC |
|---|---|---|---|
| KEV | Exploração confirmada na natureza | Sob demanda (novas entradas quase diárias) | Camada mais alta da fila, prazo curto |
| EPSS | Probabilidade de exploração em 30 dias | Diária | Desempate entre CVEs fora do KEV |
| CVSS | Severidade técnica do impacto | Estático por versão | Contexto de impacto, nunca ordem de fila isolada |
Onde o EPSS falha como preditor
Pesquisa independente sobre CVEs que entraram no KEV mostra por que o EPSS não pode ser o único gatilho. O estudo conclui que mais de dois terços dos CVEs analisados tinham EPSS abaixo de 36% pouco antes de entrarem no KEV, ou seja, a pontuação só subiu depois que a exploração já tinha sido detectada e catalogada. O mesmo trabalho caracteriza o EPSS como mais um indicador atrasado de exploração do que um sistema preditivo, recomendando uso combinado com CVSS e KEV em vez de isolado.
Isso muda a leitura operacional: um score EPSS baixo não significa que a falha é segura, apenas que ela ainda não se parece, nos dados de telemetria, com falhas rotineiramente exploradas. Quando a evidência de exploração existe — por exemplo, entrada no KEV ou telemetria própria do ambiente — ela deve se sobrepor ao score, porque o EPSS foi desenhado para o cenário sem evidência prévia.
Fila em quatro camadas para o SOC
Um modelo funcional de priorização separa a demanda em camadas com prazos distintos, aplicando os sinais em ordem de confiabilidade:
- Camada 1 — KEV em ativo exposto: correção em até 7 dias, com verificação de compensação imediata quando o patch não é viável.
- Camada 2 — EPSS alto sem KEV: score acima de 0,5 em ativo exposto entra na janela seguinte de mudança, com reavaliação diária porque o score muda.
- Camada 3 — CVSS crítico com exposição: severidade 9,0 ou superior em ativo de produção aguarda janela agendada, monitorada por detecção.
- Camada 4 — resto do backlog: correção por ciclo normal de manutenção, reclassificada a cada atualização de score.
O gargalo típico aparece entre as camadas 1 e 2: equipes que só enxergam o KEV descobrem a falha tarde, e equipes que só enxergam EPSS gastam janela de mudança em CVEs que nunca serão explorados no seu contexto. O cruzamento com exposição do ativo é o que torna a fila executável — nenhum score substitui saber se o ativo tem interface na internet.
Automatizando a fila no dia a dia
Como o EPSS publica CSV diário e API gratuitos, sem registro, atualizados por volta das 13:30 UTC, a ingestão cabe num job simples do pipeline de telemetria do SOC. O fluxo recomendado: baixar o CSV do dia, enriquecer o inventário com KEV em JSON, calcular a camada de cada CVE e publicar a fila no repositório de regras onde o time já trabalha. O mesmo enriquecimento alimenta detecção: a lista da camada 1 vira insumo para regras de alerta específicas, aproximando gestão de vulnerabilidades e monitoramento contínuo — a mesma disciplina de validação aplicada na construção de regras de detecção validadas.
A revisão semanal deve checar três pontos: CVEs da camada 2 com score em queda, entradas novas do KEV que ainda não têm ticket e falhas cuja exploração apareceu na telemetria antes de qualquer sinal público. Esse terceiro ponto é o mais valioso: sinal interno de exploração antecede catálogo público com frequência, e o procedimento formalizado evita que a descoberta morra num alerta ignorado — problema clássico de fadiga de alertas.
