A gestão de vulnerabilidades é o processo contínuo de identificar, avaliar, priorizar, tratar e verificar vulnerabilidades de segurança em todo o software e infraestrutura de uma organização. Seu objetivo não é gerar uma lista de descobertas, mas sim manter a exposição ao risco em um nível baixo, mesmo com as constantes mudanças nos sistemas.
Os números explicam por que a priorização é mais importante do que a simples contagem. No relatório State of Attacks 2026 da Fluid Attacks, falhas de gravidade alta ou crítica representaram apenas 4,5% do total de 1.119.396 vulnerabilidades registradas em 2025; no entanto, elas foram responsáveis por 79,9% da exposição total ao risco. Um programa de gestão de vulnerabilidades que trata todas as falhas da mesma forma acaba concentrando a maior parte de seus esforços nos 95% que são menos relevantes.
Esta página aborda o que constitui (e o que não constitui) a gestão de vulnerabilidades, como ela se diferencia de uma avaliação pontual e do CTEM, como realizar a priorização utilizando CVSS, EPSS e KEV, as seis etapas do ciclo de vida e como essa prática é executada pela Fluid Attacks por meio de IA, ferramentas de varredura e testes de intrusão (pentests).
O que é gestão de vulnerabilidades?
A gestão de vulnerabilidades é o processo contínuo de identificar, avaliar, priorizar, tratar e verificar vulnerabilidades de segurança no software e na infraestrutura de uma organização. O objetivo não é uma lista curta de achados, mas uma exposição ao risco baixa que continue baixa à medida que os sistemas mudam.
Os números explicam por que priorizar importa mais do que contar. No State of Attacks 2026 da Fluid Attacks, as falhas de severidade alta e crítica foram apenas 4,5 % das 1.119.396 vulnerabilidades reportadas em 2025, mas concentraram 79,9 % da exposição ao risco total. Um programa de gestão de vulnerabilidades que trata todos os achados da mesma forma gasta a maior parte do esforço nos 95 % que menos importam.
Esta página explica o que é e o que não é a gestão de vulnerabilidades, como ela se diferencia de uma avaliação pontual e do CTEM, como priorizar com CVSS, EPSS e KEV, as seis etapas do ciclo de vida e como é a prática quando a Fluid Attacks a executa com IA, scanners e pentesters.
O que é gestão de vulnerabilidades?
A gestão de vulnerabilidades é um ciclo recorrente, não uma varredura única. Começa por saber quais ativos estão no escopo, segue com a detecção e a priorização, e só termina quando uma correção é verificada. Depois recomeça, porque o código, as dependências e a infraestrutura mudam toda semana.
Uma vulnerabilidade é uma fraqueza em um sistema, geralmente resultado de um erro de software, uma falha de design ou uma configuração incorreta, que um atacante pode usar para obter acesso não autorizado ou interromper operações. A gestão de vulnerabilidades trata cada uma como uma unidade de trabalho com um responsável, uma prioridade, uma decisão de tratamento e uma etapa de verificação.
O que a gestão de vulnerabilidades não é
A gestão de vulnerabilidades não é um relatório de scanner. O relatório é um insumo; o programa é tudo o que acontece depois: triagem, atribuição, remediação, decisões de aceitação e novos testes. Também não é uma promessa de zero vulnerabilidades. Programas maduros medem a exposição ao risco e o tempo de remediação, não contagens brutas.
Vulnerabilidade, risco e ameaça
Esses três termos se confundem, e a diferença define a priorização:
Vulnerabilidade: a fraqueza em si, por exemplo um endpoint que ignora as verificações de autorização.
Risco: a chance de a fraqueza causar dano, ponderada por probabilidade e impacto.
Ameaça: o agente ou evento que poderia explorá-la, muitas vezes chamado de agente de ameaça.
Se um sistema tem uma vulnerabilidade, existe o risco de um agente de ameaça explorá-la. A gestão de vulnerabilidades atua sobre a única parte dessa frase que uma organização controla por completo: a vulnerabilidade.
Por que a gestão de vulnerabilidades é importante?
A gestão de vulnerabilidades importa porque o volume de falhas cresce mais rápido do que qualquer equipe consegue corrigi-las uma a uma. Sem uma forma de priorizar e verificar, o esforço vai para o que parece mais alarmante no papel, e não para o que os atacantes provavelmente vão usar.
O volume supera a equipe
O número de CVEs publicados continua crescendo a cada ano, e uma grande parte recebe uma pontuação base alta ou crítica. Uma gestão de vulnerabilidades que trata cada pontuação CVSS crítica como emergência não é sustentável. A análise da Fluid Attacks sobre a pontuação de severidade concluiu que fazer isso esgotaria a equipe e o orçamento perseguindo riscos que muitas vezes são teóricos.
Nossos próprios dados apontam na mesma direção. No State of Attacks 2026, 70 % dos sistemas avaliados tinham pelo menos uma vulnerabilidade de severidade alta ou crítica, contra 53,3 % no ano anterior. Mais código, boa parte assistido por IA, significa mais achados para triar.
Falhas conhecidas continuam causando incidentes graves
A maioria dos incidentes danosos não precisa de um dia zero. Eles exploram uma vulnerabilidade que já era pública, tinha pontuação e muitas vezes tinha correção. Dois casos mostram onde a gestão de vulnerabilidades costuma falhar:
Caso | Vulnerabilidade | Onde o ciclo falhou |
|---|---|---|
Log4Shell (2021) | CVE-2021-44228, Apache Log4j | Visibilidade sobre dependências diretas e transitivas, o trabalho da análise de composição de software |
MOVEit Transfer (2023) | CVE-2023-34362, injeção de SQL | Velocidade: a falha foi explorada ativamente e entrou no catálogo KEV da CISA, então era preciso encontrar e corrigir rápido as instâncias expostas |
Gestão de vulnerabilidades, avaliação de vulnerabilidades e CTEM não são alternativas
Uma varredura ou avaliação de vulnerabilidades é uma etapa dentro da gestão de vulnerabilidades, e a gestão contínua da exposição a ameaças (CTEM) é um programa mais amplo que contém as duas. Confundi-las leva as equipes a comprar um scanner e acreditar que já têm um programa.
Uma avaliação identifica, classifica e reporta problemas de segurança em um momento específico, com ferramentas automatizadas, pentesting manual ou ambos. A gestão de vulnerabilidades acrescenta o que vem depois: priorização, tratamento, verificação e repetição. A gestão contínua da exposição a ameaças estende o escopo a toda a superfície de ataque e acrescenta a validação de que as exposições são realmente exploráveis.
Abordagem | Pergunta principal | Resultado | Termina quando |
|---|---|---|---|
Avaliação de vulnerabilidades | Quais fraquezas existem agora? | Uma lista de achados com severidade | O relatório é entregue |
Gestão de vulnerabilidades | Quais fraquezas corrigimos primeiro e elas foram realmente corrigidas? | Remediação priorizada, atribuída e verificada | Nunca: é um ciclo |
Gestão de vulnerabilidades baseada em risco | Quais fraquezas provavelmente serão exploradas aqui? | Uma prioridade que combina severidade, dados de exploração e contexto | Nunca: a prioridade se atualiza com os dados |
CTEM | Onde toda a nossa superfície de ataque está exposta e os atacantes podem usá-la? | Exposições delimitadas e validadas em todos os ativos | Nunca: roda em ciclos repetidos |
Na Fluid Attacks, descrevemos uma versão inicial dessa ideia em 2022 como a passagem da gestão da superfície de ataque para a gestão da resistência a ataques: conhecer os ativos não basta sem testes contínuos e remediação verificada.
Gestão de vulnerabilidades na Fluid Attacks
A Fluid Attacks executa a gestão de vulnerabilidades como um único programa contínuo: IA, scanners próprios e pentesters encontram vulnerabilidades, e uma única plataforma cuida da priorização, da atribuição, do apoio à remediação e dos reataques. A diferença aparece no que é encontrado e na rapidez com que é corrigido.
Mostramos como a Fluid Attacks combina scanners nativos de IA, scanners determinísticos e pentesters certificados para ajudar as equipes a prevenir, detectar, gerenciar e remediar vulnerabilidades.
O que avaliamos e com quais regras
Nosso programa de gestão de vulnerabilidades avalia três alvos de avaliação: código-fonte, aplicações em execução e infraestrutura. Os testes automatizados cobrem Static Application Security Testing (SAST), AI-powered SAST (AI SAST), Software Composition Analysis (SCA), Dynamic Application Security Testing (DAST) e Cloud Security Posture Management (CSPM).
Os testes manuais somam Pentesting as a Service (PTaaS), Secure Code Review e Reverse Engineering. Nossos pentesters têm diversas certificações em segurança ofensiva e anexam evidências de exploração aos seus achados.
Como isso funciona na prática
Cada etapa do ciclo de vida da gestão de vulnerabilidades corresponde a algo que a plataforma registra, então cada decisão deixa evidência:
Etapa | O que a plataforma faz | Evidência que fica |
|---|---|---|
Identificação | Consolida em uma única visão os achados de scanners e pentesters | Localização, tipo, severidade e evidência de exploração de cada vulnerabilidade |
Priorização de vulnerabilidades | Ordena os achados com sete atributos que a organização pode reordenar: transitividade, uso, KEV, EPSS, custo de correção, severidade VLAI e análise de alcançabilidade | Uma posição de prioridade que ajusta a pontuação CVSS v4.0 em até dois pontos |
Atribuição | Atribui cada vulnerabilidade a um desenvolvedor e sincroniza com Jira ou Azure DevOps | Responsável, status de tratamento e trilha de auditoria |
Tratamento | Oferece correções com GenAI (Autofix, Custom Fix), sessões de Talk to a Pentester e políticas de aceitação | Aceitações temporárias ou permanentes justificadas |
Verificação | Executa reataques sob demanda e bloqueia implantações arriscadas com o CI Gate | Status fechado somente após um novo teste bem-sucedido |
As organizações reordenam sete atributos para definir como a plataforma prioriza cada vulnerabilidade.
Os atributos de priorização estão documentados no nosso guia de atributos de priorização. A análise de alcançabilidade se aplica apenas a achados de SCA: ela indica se o seu código realmente chama a função vulnerável de uma dependência.
Testes automatizados versus manuais, em números
Os scanners encontram a maioria das vulnerabilidades; os pentesters encontram a maior parte do risco. Essa divisão é o principal motivo pelo qual a gestão de vulnerabilidades não pode depender só de ferramentas:
Métrica | Ferramentas automatizadas | Testes manuais | Fonte |
|---|---|---|---|
Porcentagem de vulnerabilidades encontradas (2025) | 88,4 % | 11,6 % | State of Attacks 2026 |
Porcentagem da exposição ao risco total encontrada (2025) | 55,8 % | 44,2 % | State of Attacks 2026 |
Porcentagem de achados de severidade crítica (2025) | 13 % | 87 % | State of Attacks 2026 |
Recall em uma aplicação web com 1.201 vulnerabilidades | 22,7 % (melhor ferramenta: nosso scanner) | 89,6 % (um pentester) | Comparação de ferramentas |
Na comparação da Fluid Attacks entre 36 ferramentas AppSec de terceiros e nosso próprio scanner, feita em uma aplicação web com 1.201 vulnerabilidades, um pentester encontrou 1.076: 89,6 % de recall com 100 % de precisão, cobrindo 98,9 % da exposição ao risco. O melhor resultado automatizado, do nosso scanner, chegou a 22,7 % de recall e 8,8 % da exposição ao risco.
Porcentagem da exposição ao risco total que as ferramentas automatizadas e os testes manuais encontraram em 2025. Fonte: Fluid Attacks, State of Attacks 2026.
O limite da remediação automatizada
A automação ajuda mais nas correções mais fáceis, e nossos próprios dados mostram isso. No State of Attacks 2026, o Autofix e o Custom Fix foram usados em 53,6 % dos sistemas, mas principalmente em vulnerabilidades de severidade baixa e média. A GenAI acelera atualizações rotineiras de dependências e mudanças simples de código; ainda não resolve os problemas críticos.
As ferramentas que prometem correções automáticas costumam funcionar com dependências diretas que têm um caminho de atualização claro. Uma dependência transitiva, uma mudança de API que quebra a compatibilidade ou uma falha de lógica ainda precisam de alguém que faça a triagem do achado, confirme que é um verdadeiro positivo e verifique que a correção não quebra a produção. Nosso guia para corrigir vulnerabilidades de SCA traz estratégias para dependências transitivas. A remediação é mais rápida com GenAI, mas uma gestão de vulnerabilidades adequada hoje não pode ser totalmente automatizada.
A prática que decide o resto: verificar a correção
Uma correção que ninguém testa de novo é uma esperança, não uma remediação. Dois controles decidem se a gestão de vulnerabilidades fecha o ciclo: os reataques, que confirmam cada correção, e quebrar o build, que impede que novas vulnerabilidades cheguem à produção.
O State of Attacks 2026 mostra o efeito. Os sistemas que usaram nosso CI Gate chegaram a uma taxa de remediação de 72,2 % no fim de 2025, contra 58 % dos sistemas que não o usaram. A mediana do tempo de remediação foi de 22 dias contra 30, ou seja, 26,7 % mais rápido. Nas vulnerabilidades de severidade crítica, o tempo médio de remediação de todos os clientes caiu 17,5 % em relação a 2024. Os clientes que configuraram critérios de priorização próprios chegaram a uma taxa média de remediação de 64,4 %, contra 34 % de quem manteve a ordem padrão.
Os sistemas que quebraram o build remediaram mais vulnerabilidades, e mais rápido. Fonte: Fluid Attacks, State of Attacks 2026.
Para se aprofundar: como eliminar silos de dados entre equipes de desenvolvimento e segurança explica como uma plataforma compartilhada encurta o caminho do achado até a correção verificada.
Pontuação e priorização: CVSS, EPSS e KEV
Uma priorização de vulnerabilidades eficaz combina três sinais: o CVSS para o impacto potencial, o EPSS para a probabilidade de exploração e o catálogo KEV da CISA para a exploração já observada. Nenhuma pontuação sozinha responde ao mesmo tempo "quão grave isso poderia ser?" e "alguém vai usar isso aqui?".
CVSS: severidade, não risco
O Common Vulnerability Scoring System (CVSS), mantido pelo FIRST, classifica a severidade de 0,0 a 10,0. A versão atual é o CVSS v4.0:
Pontuação CVSS v4.0 | Classificação |
|---|---|
0,0 | Nenhuma |
0,1 – 3,9 | Baixa |
4,0 – 6,9 | Média |
7,0 – 8,9 | Alta |
9,0 – 10,0 | Crítica |
A pontuação base descreve o pior cenário em um ambiente genérico. As métricas ambientais e de ameaça a ajustam ao seu contexto, mas muitas ferramentas reportam apenas o valor base. Por isso duas ferramentas, ou duas bases de dados, podem classificar de forma diferente a mesma falha.
EPSS: probabilidade de exploração
O Exploit Prediction Scoring System (EPSS), também do FIRST, estima a probabilidade de um CVE ser explorado nos próximos 30 dias. O FIRST mediu uma política comum contra a exploração observada em outubro de 2023: priorizar todo CVE com pontuação base CVSS 3.x de 7 ou mais teve uma eficiência de cerca de 4 % (3,96 %), ou seja, só cerca de 4 em cada 100 dessas correções trataram uma vulnerabilidade explorada nos 30 dias seguintes. Na gestão de vulnerabilidades, o EPSS funciona melhor como segundo filtro depois da exploração confirmada, não como o único número que decide uma fila de trabalho. Nosso guia sobre o EPSS aborda limites e percentis.
KEV: exploração já confirmada
O catálogo de Known Exploited Vulnerabilities da CISA lista os CVEs com evidência de exploração ativa. Uma entrada no KEV é o sinal mais forte para subir um achado na fila, independentemente da pontuação CVSS. Pela Binding Operational Directive 22-01, as agências civis federais dos EUA devem remediar as entradas do KEV em prazos definidos, e a CISA recomenda que toda organização inclua o catálogo no seu plano de gestão de vulnerabilidades.
A injeção de SQL do MOVEit Transfer no NVD, marcada como incluída no catálogo KEV da CISA. Fonte: NIST NVD.
CVSSF: comparar o risco entre sistemas
As pontuações CVSS não se somam bem, o que torna enganosos os relatórios de gestão de vulnerabilidades que as somam ou calculam médias: dez vulnerabilidades com 1,0 não são tão arriscadas quanto uma com 10,0. A Fluid Attacks usa o CVSSF, calculado como 4^(CVSS − 4), para agregar e comparar a exposição ao risco. Esses dez achados de severidade baixa somam 0,2 unidade de CVSSF; o único crítico equivale a 4.096.
Explicamos por que o CVSS é insuficiente para dimensionar o risco e como a métrica CVSSF estima a exposição ao risco dos sistemas. (em espanhol)
Como combinar os sinais
A gestão de vulnerabilidades baseada em risco prioriza os achados pela severidade, pelos dados de exploração e pelo contexto de negócio ao mesmo tempo. Na prática, isso significa que uma vulnerabilidade alcançável, exposta à internet e presente no catálogo KEV vem primeiro mesmo que seu CVSS seja 7,5, e que um 9,8 não alcançável em uma dependência de testes pode esperar. Nossa solução de gestão de vulnerabilidades baseada em risco aplica essa priorização automaticamente.
O ciclo de vida da gestão de vulnerabilidades
O ciclo de vida da gestão de vulnerabilidades tem seis etapas que se repetem continuamente. O modelo não é rígido, mas pular uma etapa é onde a maioria dos programas falha.
As seis etapas se repetem continuamente; cada correção é testada de novo antes de o ciclo recomeçar.
1. Escopo, funções e políticas
Defina quais sistemas e componentes estão no escopo e quão crítico é cada um. Um inventário de ativos preciso é a condição prévia da gestão de vulnerabilidades: o que não está no inventário nunca é varrido. Atribua funções para detecção, remediação e aprovação, e defina políticas de frequência de revisão, prazos de remediação e critérios de aceitação.
2. Identificação
A gestão de vulnerabilidades costuma começar a detecção com varredura automatizada, que compara os sistemas com padrões de vulnerabilidades conhecidas e roda cedo e com frequência. Depois vêm os testes manuais para encontrar o que as ferramentas não veem: falhas de lógica de negócio, ataques encadeados e vulnerabilidades até então desconhecidas. Os dois se complementam, não se substituem.
3. Avaliação e priorização
Valide os resultados do scanner para eliminar falsos positivos e acrescentar as vulnerabilidades que as ferramentas não detectaram. Depois classifique cada achado verdadeiro com o CVSS, ajuste-o com EPSS, KEV e contexto, e priorize-o. A explorabilidade é a pergunta-chave: isso pode ser explorado aqui, com que facilidade e com que impacto? Os pentesters respondem com evidências.
4. Relatório
Reporte os achados à medida que são confirmados, não em um grande lote no fim de um teste, para que a gestão de vulnerabilidades mantenha um fluxo de trabalho constante. Cada relatório deve incluir tipo, severidade, localização, data de detecção, status, descrição, evidência e uma recomendação de tratamento. Lotes pequenos e priorizados são mais fáceis de tratar.
5. Tratamento
A remediação de vulnerabilidades, a correção completa, é a opção preferida. A mitigação reduz a probabilidade ou o impacto da exploração enquanto uma correção é preparada. A aceitação, temporária ou permanente, é uma decisão documentada de que o custo de corrigir supera o risco. Em uma gestão de vulnerabilidades madura, a aceitação permanente de problemas de severidade alta fica perto de zero.
6. Verificação e relatório
Faça uma nova varredura e um reataque para confirmar cada correção e verificar que ela não introduziu novas vulnerabilidades. Depois atualize o status e acompanhe métricas de gestão de vulnerabilidades como a taxa de remediação, o tempo médio de remediação e a exposição ao risco ao longo do tempo.
Tipos de vulnerabilidades
A Fluid Attacks agrupa as vulnerabilidades por mecanismo de ataque em nove categorias, uma abordagem semelhante à do MITRE CAPEC. Cada fraqueza do nosso banco de dados público se vincula a requisitos de segurança, e cada requisito é mapeado para padrões como CWE e o OWASP Top 10, o que ajuda as equipes de gestão de vulnerabilidades a agrupar os achados por causa raiz:
Categoria | Fraquezas de exemplo |
|---|---|
Subversão de acesso | Escalonamento de privilégios, falsificação de solicitação entre sites |
Coleta de informações | Uso de software com vulnerabilidades conhecidas, informações sensíveis no código-fonte |
Abuso de funcionalidade | Dependências não atualizáveis, negação de serviço assimétrica |
Interações enganosas | Falsificação de solicitação do lado do servidor, ausência de verificação de integridade de sub-recursos |
Manipulação de protocolos | Cabeçalhos HTTP inseguros, método de autenticação inseguro |
Injeção inesperada | Injeção de SQL, execução remota de comandos, XSS refletido |
Técnicas probabilísticas | Credenciais fracas adivinhadas, falta de proteção contra força bruta |
Manipulação do sistema | Controle inadequado do tamanho de arquivos, injeção de logs |
Manipulação de dados | Validação insuficiente da autenticidade dos dados, inclusão de arquivos locais |
Cada fraqueza do banco de dados público da Fluid Attacks inclui seu vetor CVSS v4.0, seus requisitos e correções por linguagem.
No State of Attacks 2026, "authentication mechanism absence or evasion" representou sozinha 19,1 % da exposição ao risco total, e as 10 principais fraquezas concentraram juntas 68,4 %.
Conclusões
A gestão de vulnerabilidades é um ciclo de encontrar, priorizar, corrigir e verificar, e falha na etapa que for pulada. O CVSS sozinho prioriza pelo dano potencial; a gestão de vulnerabilidades que soma EPSS, KEV e análise de alcançabilidade prioriza pela probabilidade real.
Os scanners encontram a maioria das vulnerabilidades, mas os pentesters encontram a maior parte do risco, e nossos dados de 2025 mostram que 87 % dos achados críticos vieram de testes manuais. Os controles que mais movem a remediação são os menos chamativos: os reataques e quebrar o build. A gestão de vulnerabilidades funciona quando cada achado termina em uma correção verificada ou em uma decisão documentada.
Perguntas frequentes
Qual é a diferença entre gestão de vulnerabilidades e avaliação de vulnerabilidades?
A avaliação é uma etapa da gestão de vulnerabilidades. A avaliação identifica e reporta fraquezas em um momento específico. A gestão de vulnerabilidades também as prioriza, atribui e trata, verifica cada correção e repete o ciclo continuamente. Um programa que só avalia produz relatórios; um que gerencia produz correções verificadas e menos exposição ao risco.
O CVSS basta para priorizar vulnerabilidades?
Não. O CVSS mede a severidade potencial no pior cenário genérico, não a probabilidade de exploração. Na medição do FIRST de outubro de 2023, corrigir todo CVE com pontuação CVSS 3.x de 7 ou mais teve apenas cerca de 4 % de eficiência. Combinar o CVSS com o EPSS, o catálogo KEV da CISA e a análise de alcançabilidade gera uma priorização mais próxima do risco real.
A gestão de vulnerabilidades pode ser totalmente automatizada?
Ainda não. As ferramentas detectam a maioria das vulnerabilidades e conseguem corrigir problemas simples de dependências, mas no State of Attacks 2026 da Fluid Attacks, 87 % dos achados de severidade crítica vieram de testes manuais, e as correções com GenAI foram usadas principalmente em problemas de severidade baixa e média. A automação acelera a detecção e as correções rotineiras, mas a gestão de vulnerabilidades ainda precisa de pessoas para a triagem e a verificação.
Quebrar o build acelera a remediação de vulnerabilidades?
Sim. No State of Attacks 2026, os sistemas que usaram o CI Gate da Fluid Attacks remediaram vulnerabilidades com uma mediana de 22 dias contra 30 dos que não o usaram, e chegaram a uma taxa de remediação de 72,2 % contra 58 %. Essa mediana é 26,7 % mais rápida.
A Fluid Attacks oferece gestão de vulnerabilidades?
Sim. A Fluid Attacks combina IA, scanners próprios e pentesters para encontrar vulnerabilidades, e sua plataforma cuida da priorização com EPSS, KEV e alcançabilidade, da atribuição, do apoio à remediação com GenAI e dos reataques para verificar cada correção. Os pentesters anexam evidências de exploração aos seus achados, e o CI Gate pode quebrar o build para barrar implantações arriscadas.
Feche o ciclo em cada achado
A Fluid Attacks executa a gestão de vulnerabilidades como um único programa contínuo que encontra, prioriza e testa de novo as suas vulnerabilidades, para que cada correção seja verificada antes de contar.
Comece agora com a solução RBVM da Fluid Attacks
