KEV, EPSS e CVSS: uma fila de vulnerabilidades que não confunde sinais
Exploração conhecida, probabilidade de exploração e severidade técnica não são sinónimos de risco local. A remediação começa por confirmar produto e versão, exposição, impacto, controlos, solução do fornecedor e capacidade de validar a correção.
- Natureza
- Guia operacional baseado em CISA, NVD e FIRST
- Âmbito
- Gestão de vulnerabilidades e exposição em ambientes próprios e fornecedores
- Publicado e verificado
- 4 de agosto de 2026
- Limite
- A prioridade final depende do inventário, arquitetura, risco e obrigações da organização
Em resumo
O catálogo KEV da CISA contém vulnerabilidades com evidência de exploração conhecida e é um sinal forte de ameaça. O EPSS estima diariamente a probabilidade de observar exploração nos 30 dias seguintes e não inclui o impacto nem os controlos da organização. O CVSS Base descreve severidade intrínseca e deve ser enriquecido com métricas de ameaça e ambiente. Nenhum destes sinais prova que um ativo local está vulnerável. Uma fila defensável liga cada CVE a um ativo identificado, reachability, exposição, criticidade, orientação do fornecedor, medida temporária, dono, prazo e prova de remediação.
- KEV deve acelerar a verificação, mas a data BOD vincula agências federais abrangidas dos EUA — não é prazo legal português.
- EPSS é probabilidade de exploração, não score de risco; guarde data e versão do modelo.
- CVSS-B mede severidade, não risco; ambiente e ameaça alteram a leitura.
- Fechar um ticket exige provar versão/estado e funcionamento, não apenas marcar patch instalado.
Quatro sinais, quatro perguntas
KEV pergunta se existe evidência credível de exploração conhecida. EPSS estima atividade futura agregada em campo. CVSS descreve características e severidade técnica. O contexto local pergunta se o ativo existe, é alcançável, suporta um processo material e tem controlos que alteram probabilidade ou consequência.
Quando já existe evidência de exploração, essa evidência supera uma estimativa EPSS baixa. Quando a vulnerabilidade não está em KEV, EPSS e inteligência do fornecedor ajudam a ordenar verificação — sem transformar ausência do catálogo em ausência de risco.
Da entrada do sinal ao encerramento
- 0–2HConfirmar aplicabilidade
Resolver produto, componente, versão, configuração e ativos afetados.
- 2–6HDeterminar exposição
Verificar internet, autenticação, reachability, privilégio e caminhos laterais.
- MESMO DIAConter quando necessário
Aplicar mitigação suportada, isolar ou desativar com aprovação e observabilidade.
- PRAZO LOCALRemediar por risco
Fixar dono e deadline com base em exploração, impacto, exposição e alternativa.
- DEPOISValidar e procurar sinais
Provar estado, testar regressão e executar hunting quando a exposição o justificar.
A prioridade precisa de campos que possam ser auditados
Calcule ou ordene só depois de guardar os sinais originais. Uma pontuação composta sem componentes visíveis cria falsa precisão e impede perceber por que um item subiu. Use regras de escalada explícitas e permita override humano com fundamento e expiração.
Registo mínimo por vulnerabilidade aplicável
| Campo | Pergunta | Fonte | Decisão |
|---|---|---|---|
| Ativo | Produto e versão existem onde? | Inventário + descoberta | Aplicável ou falso positivo |
| Exploração | Há evidência conhecida? | KEV + fornecedor | Escalada imediata |
| Probabilidade | Qual EPSS, data e percentil? | FIRST | Ordenação entre desconhecidos |
| Severidade | Qual vetor CVSS e ambiente? | NVD/fornecedor + análise local | Impacto técnico contextual |
| Exposição | O caminho de ataque é alcançável? | Configuração + teste | Urgência e contenção |
| Negócio | Que serviço, dados e pessoas dependem? | BIA + dono | Tolerância e janela |
| Correção | Que patch/mitigação e como validar? | Fornecedor + teste | Fecho ou risco aceite |
Definir regras antes da próxima urgência
Uma regra simples pode colocar no topo KEV aplicável e exposto, vulnerabilidade com evidência interna, ou falha crítica num ativo de alto impacto sem controlo. EPSS e CVSS refinam o restante backlog, nunca substituem estes factos.
Para fornecedores, exija lista de ativos afetados, versão corrigida, mitigação, indicadores de compromisso e confirmação de validação. «Estamos a investigar» precisa de próxima atualização e medida temporária.
- Atualizar KEV e EPSS diariamente, preservando o snapshot usado na decisão.
- Medir tempo até aplicabilidade confirmada, não apenas tempo até fechar ticket.
- Separar aceitação temporária de falso positivo e de risco permanentemente aceito.
- Reabrir quando muda evidência de exploração, exposição, versão ou orientação do fornecedor.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01Known Exploited Vulnerabilities CatalogCISA · CY-CISA
- 02BOD 22-01 — Reducing the Significant Risk of KEVsCISA · CY-CISA
- 03NVD vulnerability detail pagesNational Vulnerability Database · CY-NVD
- 04Using EPSSFIRST · CY-FIRST
- 05Get the DataFIRST · CY-FIRST
- 06EPSS frequently asked questionsFIRST · CY-FIRST
- 07CVSS v4.0 User GuideFIRST · CY-FIRST
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.