Ordenar a fila de correção apenas pela nota de CVSS desperdiça as horas mais caras da equipe em falhas graves, porém inacessíveis, e adia vulnerabilidades medianas que estão expostas na internet com exploração automatizada. Equipes de defesa que quiserem priorizar por risco contam com um roteiro pronto: a CISA consolidou, na diretiva BOD 26-04, um modelo de quatro variáveis que qualquer organização pode reproduzir com dados que já possui: inventário, inteligência de ameaças e o catálogo de vulnerabilidades exploradas.
Os limites do CVSS puro
A pontuação Base é comunicação técnica, não decisão de fila. A especificação do CVSS mantida pela FIRST delimita o papel da métrica: provedores de análise, como mantenedores de produto e entidades públicas como o National Vulnerability Database (NVD), publicam apenas a pontuação Base, rotulada CVSS-B, calculada sob pior caso razoável e sem qualquer ajuste ao ambiente de quem consome a informação. A nomenclatura existe justamente para expor essa lacuna: uma nota sem as letras T e E ignora exploração ativa e contexto de uso.
A mesma especificação deixa claro que requisitos regulatórios, número de clientes afetados, perdas monetárias e risco à vida ficam fora do escopo do CVSS, e que esses fatores devem entrar no processo de gestão de vulnerabilidades da organização. Ignorar a fronteira produz os dois erros clássicos de fila: semanas de esforço em falhas de nota máxima, sem exploit público nem rota de acesso; e adiamento de nota intermediária em VPN exposta que já figura no catálogo de vulnerabilidades exploradas. Quando a decisão de risco é terceirizada para quem calculou a nota, quem decide não conhece o seu ambiente — e a fila deixa de representar risco.
As quatro variáveis da urgência
A pergunta certa é sobre risco composto. Na diretiva emitida pela CISA em junho de 2026, a urgência de correção passa a ser calculada a partir de exposição do ativo, status no KEV, automação da exploração e impacto técnico. Cada variável responde a uma pergunta fechada, verificável e auditável, com fonte de dados definida:
| Variável | Pergunta | Onde obter |
|---|---|---|
| Exposição do ativo | O sistema é alcançável pela internet sem autenticação? | Inventário, varredura externa, ferramentas de superfície exposta |
| Status no KEV | A CVE tem entrada no catálogo de exploradas? | Catálogo KEV e dados do programa de enriquecimento |
| Automação | O adversário automatiza todos os passos do exploit? | Metadados públicos de enriquecimento e inteligência |
| Impacto técnico | A exploração dá controle parcial ou total? | Análise do advisory, com CVSS como pista inicial |
A orientação prática sobre exposição é deliberadamente prudente: se qualquer método de descoberta apontar que o ativo é alcançável por entidade não autenticada em rede pública, o valor é sim; e quando não houver informação confiável sobre o ativo, ele deve ser tratado como exposto por precaução, nunca como interno por comodidade. O status no KEV traz a evidência de dano real no mundo, e não a facilidade teórica de exploração. A automação pergunta se o adversário consegue executar todos os passos do ataque sem intervenção humana, o que comprime drasticamente o tempo de reação. O impacto técnico separa controle parcial, como negação de serviço ou exposição limitada de informação, de controle total, quando o invasor executa código arbitrário ou obtém credenciais de acesso — a diferença entre um incidente operacional e uma intrusão completa.
Da diretiva ao comitê de risco
Embora vinculante apenas para agências federais dos EUA, o BOD 26-04 substitui o BOD 22-01 e integra o catálogo KEV aos pontos de decisão de prazo de correção, mantendo os critérios de entrada do catálogo e recomendando de forma explícita que estados, municípios e iniciativa privada adotem o mesmo raciocínio nos seus planos de gestão de vulnerabilidades, como resume a página oficial do catálogo KEV. Para quem opera fora do alcance da diretiva, o valor está no desenho: variáveis explícitas, prazo como consequência do risco e não da severidade isolada, e decisão registrada quando a correção precisa esperar. Isso é governança aplicada — o comitê decide com base em perguntas respostáveis, e o registro da decisão vira evidência para auditoria e para a melhoria contínua do processo.
Monte a árvore de decisão
Não é preciso inventar método do zero. O guia Stakeholder-Specific Vulnerability Categorization, publicado pela CISA com o CERT/CC, define pontos de decisão que casam com as variáveis da diretiva: estado de exploração, impacto técnico e automação, além de prevalência para a missão e impacto ao bem-estar público — as duas variáveis que só a organização consegue responder, porque dependem de conhecer o próprio negócio. O resultado da árvore é uma ação, não uma nota: Track, para monitorar; Attend, para priorizar dentro do ciclo normal; Act, para tratamento urgente. Combinações de exploração ativa com impacto técnico total levam a Act mesmo quando a nota de CVSS é discreta, porque risco é composto e a árvore codifica essa composição.
Dois cuidados melhoram a implementação. Primeiro, calibrar missão e bem-estar público com quem entende do negócio: a segurança propõe o mecanismo, mas o dono do sistema diz qual serviço depende daquele ativo e qual dano é intolerável. Segundo, versionar a árvore: quando a diretiva ou o guia mudarem os pontos de decisão, a fila precisa ser recalculada e as exceções reavaliadas, sob pena de a organização operar um modelo defasado com aparência de rigor.
Prazos e operação
A orientação de implementação da CISA transforma o modelo em rotina de resposta: escopo do impacto nas primeiras duas horas após a adição de uma vulnerabilidade crítica ao KEV, preservação de evidência antes do patch quando há suspeita de comprometimento, e relatório de triagem até setenta e duas horas, com decisão explícita entre monitoramento intensificado e escalada para resposta a incidentes. Quando faltam metadados para uma CVE fora do KEV, o prazo padrão assumido é de sessenta dias, até que o enriquecimento chegue — uma regra simples que impede paralisação por falta de dados.
- P1: monitorar o feed do KEV e do programa de enriquecimento; classificar automaticamente as quatro variáveis em cada novo achado de varredura; tratar ativo sem informação de exposição como exposto.
- P2: revisar exceções registradas sempre que uma variável mudar; exercitar o fluxo em tabletop de crise antes do incidente real; medir tempo médio de correção por faixa de decisão, e não por nota de CVSS.
Para quem já acompanha prazos do catálogo, a mudança é de mentalidade: o prazo venceu porque o risco composto mandou, não porque o calendário mandou — como ficou claro no caso do NetScaler no KEV. A fila por risco não é mais trabalho; é o mesmo trabalho na ordem que reduz perda esperada.