Vulnerabilidade, ameaça e risco: qual é a diferença
A diferença entre vulnerabilidade, ameaça e risco, por que a lista do scanner não é uma lista de riscos e o que a empresa decide com cada um.

A reunião de orçamento trava no mesmo ponto todo trimestre. O analista abre a tela do scanner, mostra a lista cheia de itens em vermelho e pede verba. O diretor pergunta quanto a empresa perde se nada for feito, e ninguém responde.
A lista é de vulnerabilidades. A pergunta é sobre risco. Entre os dois existe um terceiro termo, ameaça, que boa parte das reuniões trata como sinônimo dos outros dois. Enquanto vulnerabilidade, ameaça e risco ocuparem a mesma caixa na cabeça de quem decide, a verba continua parada.
Os três têm definição própria em qualquer norma séria de gestão de risco, e a diferença entre eles decide quem trata o problema, com qual dinheiro e em qual prazo.
Vulnerabilidade é a fraqueza que existe no ativo. Ameaça é o agente ou o evento capaz de explorar essa fraqueza. Risco é o efeito combinado dos dois sobre um objetivo da empresa, com impacto e probabilidade, e é a única das três coisas que alguém aceita, transfere, mitiga ou evita.
A falha, o agente e o efeito
O vocabulário aqui já está fechado há anos, e vale usar o dos glossários em vez do improvisado na reunião. O glossário do NIST define vulnerabilidade como fraqueza num sistema de informação, em procedimentos de segurança, em controles internos ou na implementação, que possa ser explorada ou acionada por uma fonte de ameaça. Repare em duas palavras: fraqueza e possa. A vulnerabilidade é um estado do seu ativo, e ela existe mesmo que ninguém nunca tente usá-la.
Ameaça é a outra ponta. O mesmo glossário trata ameaça como qualquer circunstância ou evento com potencial de afetar negativamente as operações da organização, seus ativos ou pessoas. Ameaça não está dentro do seu parque. Ela é o grupo que vende acesso inicial, o funcionário demitido com credencial ativa, a enchente, a falha de energia. Você não aplica patch em nenhum deles.
Risco é o encontro dos dois com o seu negócio no meio. O NIST descreve risco como a medida de quanto uma entidade está ameaçada por uma circunstância potencial, em função do impacto adverso caso ela ocorra e da probabilidade de ocorrência. A ISO 31000 chega no mesmo lugar por outro caminho e define risco como o efeito da incerteza sobre objetivos, o que amarra a conversa de ameaça e risco ao que a empresa quer alcançar, e não ao inventário técnico.
Onde ameaça e risco deixam de ser a mesma coisa
A confusão entre os três termos custa caro de um jeito específico. Quando a empresa trata ameaça e risco como a mesma coisa, ela compra ferramenta de detecção achando que comprou redução de risco, e descobre no incidente que só comprou visibilidade.
Ameaça e risco também têm donos diferentes. Ameaça é assunto de monitoramento e inteligência: você acompanha quem está ativo no seu setor, quais técnicas aparecem, qual falha ganhou exploit público nesta semana. Risco é assunto de quem responde pelo objetivo afetado e pelo orçamento. O time de segurança informa, o dono do processo decide.
Essa separação é o que sustenta uma estrutura de governança, risco e conformidade funcional. Sem ela, o comitê discute lista técnica por duas horas e sai sem nenhuma decisão registrada, porque lista técnica não é objeto de decisão executiva.
A tabela que resolve a discussão
Quando a discussão de ameaça e risco empaca, esta tabela costuma destravar em cinco minutos.
| Vulnerabilidade | Ameaça | Risco | |
|---|---|---|---|
| O que é | fraqueza no ativo, no processo ou no controle | agente ou evento capaz de explorar a fraqueza | efeito sobre o objetivo, com impacto e probabilidade |
| Exemplo | biblioteca desatualizada no servidor de faturamento | grupo de ransomware que varre a internet atrás dessa versão | parar de faturar por dias, com multa contratual |
| Quem trata | operação de TI e segurança | inteligência e monitoramento | dono do processo e quem responde pelo orçamento |
| O que se faz | corrigir, isolar ou aplicar controle compensatório | detectar, acompanhar e antecipar | aceitar, transferir, mitigar ou evitar |
| Onde fica registrado | inventário e fila de correção | relatório de inteligência e regras de detecção | matriz de risco, com nome e data da decisão |
A última linha é a que mais falta nas empresas. Vulnerabilidade tem fila, ameaça tem painel, e risco fica sem lugar nenhum, o que significa que ninguém assinou por ele.
Um exemplo único, do começo ao fim
Pegue o servidor que emite as notas fiscais da operação. Ele é o ativo, e o objetivo associado a ele é faturar todo dia útil.
O scanner encontra nele uma falha de execução remota numa biblioteca de upload. Essa é a vulnerabilidade: um estado do ativo, com identificador, versão afetada e correção disponível. Até aqui, nenhuma decisão de negócio foi tomada.
Agora entra a ameaça. Existem grupos que varrem a internet procurando exatamente aquela versão, porque ela dá acesso barato e rápido. Se o seu servidor está publicado na internet, esses grupos chegam nele sem alvo escolhido, por varredura. A ameaça é real e você não a controla.
A probabilidade nasce do encontro: ativo exposto, exploit disponível, correção não aplicada, e a detecção que você tem no perímetro. Se o mesmo servidor estivesse numa rede isolada de laboratório, sem rota para fora, a mesma vulnerabilidade com a mesma nota teria probabilidade muito menor.
O risco é a frase completa, e ela só aparece quando você junta tudo: a empresa pode ficar sem emitir nota fiscal por vários dias, com custo de parada, multa de contrato e notificação de dados pessoais, porque um servidor exposto tem falha explorável por grupos que estão ativos agora. Essa é a frase que cabe numa pauta de diretoria, e é a partir dela que se discute orçamento de segurança com número em cima da mesa.
Por que a lista do scanner não é uma lista de riscos
O scanner enxerga dois dos quatro elementos, o ativo e a falha, e deixa ameaça e risco de fora. Ele não sabe quanto vale a operação que roda naquele servidor, não sabe se existe exploit em uso e não sabe qual o seu tempo de parada aceitável. Entregar a saída bruta dele como mapa de risco transfere para quem decide um trabalho que era da área técnica.
Uma operação madura de gestão de vulnerabilidades faz essa tradução antes da reunião. Ela cruza cada achado com criticidade do ativo, exposição de rede e evidência de exploração, e chega com uma lista curta de riscos nomeados, em vez de uma planilha longa de achados.
O mesmo vale para o resultado de um teste de intrusão. O relatório mostra caminhos de ataque que funcionaram, o que é informação muito melhor que a do scanner, mas continua sendo insumo. Vira risco quando alguém escreve qual objetivo do negócio aquele caminho derruba e com qual probabilidade.
A pontuação Base do CVSS descreve características intrínsecas da falha, e a própria especificação da versão 4.0 diz que consumidores devem usar a informação do CVSS como entrada de um processo de gestão de vulnerabilidades que também considera fatores fora do escopo do CVSS para ordenar as ameaças à sua infraestrutura. O texto cita exigência regulatória, número de clientes afetados, perda financeira e impacto reputacional.
Ou seja: a nota mede a gravidade da falha em abstrato, e o seu problema é concreto. Duas falhas com a mesma pontuação alta, uma no servidor de faturamento publicado e outra numa máquina de teste sem rota externa, produzem riscos que não se parecem em nada.
Ordenar a fila só pela nota tem dois efeitos previsíveis. O time gasta as semanas mais caras do trimestre corrigindo notas altas em ativos irrelevantes, e a falha de nota média no sistema que sustenta a receita fica esperando. Quando o incidente chega, o relatório mostra que o item estava na fila, bem longe do topo.
O que fazer na segunda-feira
- Separe os três nas planilhas. Fila de correção, painel de ameaça e matriz de risco são documentos distintos, com donos distintos. Tratar ameaça e risco no mesmo arquivo da fila de correção é a origem da confusão.
- Escreva o risco em forma de frase. Ativo, falha, quem explora, o que a empresa perde e em qual prazo. Se a frase não couber em duas linhas, o risco ainda não foi entendido.
- Classifique o ativo antes de classificar a falha. Sem saber qual ativo sustenta receita, contrato ou obrigação legal, qualquer priorização vira ordenação por nota técnica.
- Use evidência de exploração como filtro. Falha com exploração observada muda a probabilidade de imediato e sobe na fila mesmo com nota menor.
- Registre a decisão, inclusive a de aceitar. Risco aceito precisa de nome, data e prazo de revisão. Aceitação sem registro é só esquecimento com outro nome.
- Ligue o risco ao plano de resposta. O risco que você decidiu aceitar é exatamente o que o plano de resposta a incidentes precisa saber tratar quando acontecer.
O ponto que fica
A separação entre vulnerabilidade, ameaça e risco não é preciosismo de norma. Ela existe porque cada um dos três é tratado por uma pessoa diferente, com um instrumento diferente e num prazo diferente.
Quem leva a lista do scanner para a diretoria pede dinheiro para uma coisa que a diretoria não decide. Quem leva três frases de risco, com ativo, efeito e probabilidade, sai da sala com prioridade definida. A definição do NIST já diz isso desde a primeira linha: risco é função de impacto e probabilidade, e o scanner não mede nem um nem outro.


