CISA está mudando a forma de priorizar vulnerabilidades: por que a PME deve olhar exploração e exposição, não apenas CVSS

O que mudou em 10 de junho de 2026

Em 10 de junho de 2026, a CISA — a agência de cibersegurança dos Estados Unidos — publicou a Diretiva Operacional Vinculante BOD 26-04, "Prioritizing Security Updates Based on Risk" (em tradução livre, "Priorizando atualizações de segurança com base em risco"). O texto revogou a BOD 19-02, a diretiva anterior, que exigia o uso do CVSS como base para priorizar correções nas agências federais civis americanas.

Na prática, o governo dos EUA deixou de usar o CVSS como critério oficial de prioridade de correção. A mudança foi amplamente coberta por veículos de segurança, como Picus Security, Zafran e CyberSecurity Dive — e vale entender o que ela diz sobre o rumo do mercado, mesmo para uma empresa que nunca tratou com o governo americano.

Por que "crítico" deixou de ser critério suficiente

O CVSS foi criado para dar a cada vulnerabilidade uma nota de severidade técnica, de 0 a 10. Serviu por muito tempo como linguagem comum: relatório, scanner e ferramenta de patch falavam a mesma nota. O problema é que a conta deixou de fechar. O número de CVEs publicadas por ano é muito maior do que a capacidade de correção de qualquer equipe — a de uma multinacional ou a de uma PME de Suzano.

Quando dezenas de itens chegam marcados como "crítico" ao mesmo tempo, a nota deixa de ajudar a escolher o primeiro. E ela não responde às perguntas que realmente decidem a ordem: alguém está explorando isso agora? O sistema afetado está aberto para a internet? O que ele faz pela operação da empresa?

O que entra no lugar: uma decisão, não um número

A BOD 26-04 se baseia no SSVC (Stakeholder-Specific Vulnerability Categorization), framework criado pela Carnegie Mellon University (CERT/CC) em conjunto com a CISA. Em vez de uma nota única, o SSVC usa uma árvore de decisão que combina fatores como exploração ativa confirmada, presença no catálogo CISA KEV (a lista de vulnerabilidades já exploradas na prática), exposição do ativo (acessível pela internet ou só pela rede interna?) e criticidade do sistema para a operação daquela organização.

O resultado deixa de ser um número de 0 a 10 e passa a ser uma recomendação de ação: Agir, Atender, Rastrear ou Rastrear com atenção. Fonte: guia oficial do SSVC da CISA, consolidado por Picus Security e riskbasedprioritization.github.io (2026).

As quatro perguntas, traduzidas para o dia a dia

Ninguém precisa decorar a árvore de decisão para aproveitar a lógica dela. Traduzido para o dono de uma PME, o raciocínio do SSVC vira quatro perguntas:

Ressalva: é uma diretiva americana, não uma lei brasileira

O motivo de ela importar para uma PME de Suzano, Mogi das Cruzes ou Itaquaquecetuba é outro: é sinal de direção de mercado. Analistas do setor, citados pela Picus Security e por outros veículos em 2026, apontam que requisitos de seguro cibernético, auditorias de fornecedor e as próprias ferramentas de gestão de vulnerabilidades devem seguir a mesma lógica de priorização nos próximos anos.

Trate como tendência, não como certeza. Quem já organiza a fila de correção por exploração, exposição e criticidade chega mais preparado ao questionário da seguradora, à auditoria de um cliente grande — ou simplesmente gasta melhor as horas da equipe.

Complemento: de CVSS vs. EPSS para um conjunto mais amplo de sinais

Já publicamos aqui um artigo sobre por que vulnerabilidade crítica não é a mesma coisa que prioridade crítica, que explica a diferença entre o CVSS (o estrago possível) e o EPSS (a probabilidade real de exploração). Este texto complementa aquele com uma notícia mais recente e amplia o argumento: a discussão já não é só "CVSS versus EPSS", é "CVSS versus um conjunto de sinais" — exploração, exposição do ativo e criticidade para o negócio.

A probabilidade de exploração continua sendo um sinal útil. Já a exposição e a criticidade são justamente o que nenhum relatório automático sabe por você: só a própria empresa sabe quais sistemas estão abertos para a internet e quais deles não podem parar.

Checklist: como aplicar sem ferramenta de SSVC automatizada

Não é preciso uma plataforma de SSVC para começar. O ponto de partida é processo: organizar a fila de correção com cinco checagens.

• Separe o que está exposto à internet do que é só interno. Faça essa lista uma vez e mantenha atualizada — ela vale para todas as próximas rodadas de correção.
• Confira cada item crítico no catálogo CISA KEV. É uma lista pública de vulnerabilidades já exploradas na prática; estar nela move o item para o topo da fila.
• Classifique os sistemas por criticidade para a operação. Quem decide o que "não pode parar" é a gestão do negócio, não apenas a TI.
• Registre a decisão e o motivo — agir agora, corrigir na próxima janela ou acompanhar — e anote qualquer mitigação temporária que esteja em vigor.
• Reveja a fila periodicamente. Exposição e exploração mudam: um item que era "acompanhar" pode virar "agir" quando entra no KEV ou quando o sistema passa a ficar acessível de fora.

Vale registrar: essa adaptação para cinco checagens de processo é uma simplificação nossa para o contexto de PME e indústria de médio porte — não uma implementação oficial do SSVC.