Uma avaliação de vulnerabilidades é a análise sistemática de um sistema — código-fonte, aplicações em execução, configurações de nuvem, dependências, infraestrutura — para identificar fraquezas de segurança, classificá-las conforme o risco que representam e reportá-las para que sejam corrigidas. Abrange a varredura automatizada e os testes manuais, e termina em uma lista priorizada de achados, não em um inventário bruto.
Nos sistemas que a Fluid Attacks avaliou durante 2025, os scanners automatizados detectaram 55,8 % da exposição ao risco. Os outros 44,2 % vieram de técnicas manuais, e de lá veio também 87 % dos achados de severidade crítica.
Esta página cobre o que é e o que não é uma avaliação de vulnerabilidades, em que ela difere da varredura de vulnerabilidades e do pentesting, os tipos que existem, os passos que uma avaliação completa segue, o que seu relatório precisa conter para ser útil e o que os nossos próprios dados dizem sobre o que cada método realmente encontra.
O que é uma avaliação de vulnerabilidades?
A avaliação de vulnerabilidades é o processo de examinar um sistema de informação para encontrar, classificar e reportar suas fraquezas de segurança. Uma avaliação completa reporta cada achado com sua categoria, sua localização exata, a evidência que o sustenta e uma classificação de severidade, para que a remediação seja priorizada em vez de adivinhada.
Tanto as ferramentas automatizadas quanto as pessoas realizam avaliações de vulnerabilidades. Os scanners baseados em assinaturas comparam o que veem com um banco de dados de problemas conhecidos, como as entradas da lista Common Vulnerabilities and Exposures (CVE), o que significa que seu alcance é limitado por esse banco. A análise moderna é menos limitada do que isso — o nosso AI SAST gera achados candidatos em repositórios de código aberto que os nossos analistas depois validam, um trabalho que já produziu 12 advisories publicados — mas o ponto geral permanece: uma ferramenta encontra aquilo que foi construída para reconhecer.
O que uma avaliação de vulnerabilidades não é: um teste de penetração, um certificado de conformidade nem um projeto de uma única vez. É a camada de detecção e relato da qual depende o resto da gestão de vulnerabilidades, e a qualidade de tudo o que vem depois fica limitada por ela.
Por que a avaliação de vulnerabilidades importa
A avaliação de vulnerabilidades é a única parte do seu programa de segurança que diz o que um atacante de verdade encontraria. Tudo o que vem depois — priorização, remediação, evidência de conformidade — é construído sobre o que a avaliação reporta, e herda os pontos cegos desse relatório.
Exposição ao risco, não contagem de vulnerabilidades
Uma lista longa de achados não é uma medida de risco. Dez problemas de severidade baixa não equivalem a um crítico, e por isso pontuamos os achados com o CVSSF, uma métrica de exposição ao risco derivada do CVSS em vez de uma contagem simples. A diferença é grande na prática: nos nossos dados de 2025, as vulnerabilidades reportadas por ferramentas automatizadas tiveram média de 15,5 unidades CVSSF, enquanto as reportadas pelos nossos pentesters tiveram média de 93,2, seis vezes mais. Uma avaliação de vulnerabilidades que só reporta quantos problemas existem diz muito pouco sobre o quanto você está exposto.
O que custa detectar tarde
Corrigir uma fraqueza antes de uma publicação é mais barato do que corrigi-la em produção, e muito mais barato do que responder à sua exploração. Entre os sistemas que avaliamos em 2025, os que usaram o nosso CI Gate — que quebra o build quando há uma vulnerabilidade que viola a política — alcançaram uma taxa de remediação de 72,2 % no fim do ano, contra 58 % dos sistemas sem ele, e suas equipes fecharam achados em uma mediana de 22 dias contra 30.
Onde entra a conformidade
Vários padrões esperam que as fraquezas sejam identificadas com regularidade e corrigidas, e esperam que você demonstre isso. O nosso catálogo mapeia requisitos de segurança diretamente para PCI DSS, HIPAA, ISO 27001, GDPR e dezenas de outros padrões e frameworks, de modo que um achado pode ser rastreado até o requisito que ele descumpre. A conformidade é um subproduto de uma avaliação de vulnerabilidades bem-feita, não um motivo para fazê-la.
Avaliação, varredura e testes de penetração não são a mesma coisa
A avaliação de vulnerabilidades, a varredura de vulnerabilidades e os testes de penetração são usados de forma intercambiável, inclusive por fornecedores. Não são equivalentes, e a diferença decide o que você vai encontrar e o que não vai.
Prática | O que é | Quem executa | O que encontra | Confirma explorabilidade? |
Avaliação de vulnerabilidades | O processo completo de encontrar, classificar e reportar fraquezas | Ferramentas, pessoas ou ambas | Depende dos métodos que inclui | Só se incluir testes manuais |
Varredura de vulnerabilidades | Um método dentro da avaliação: detecção automatizada contra padrões conhecidos | Scanners automatizados | Classes de problemas conhecidos, em escala e com velocidade | Não |
Testes de penetração | Uma metodologia, não um alvo: simular um atacante para alcançar um objetivo | Hackers éticos | Falhas lógicas complexas, ataques encadeados, zero-days | Sim, com evidência do impacto |
A varredura é um método; a avaliação de vulnerabilidades é o processo que pode contê-lo. Os testes de penetração são um segundo método que pode ficar dentro do mesmo processo. Os dois se complementam: os scanners dão amplitude e velocidade, os pentesters dão profundidade e prova, e a revisão manual ainda corrige o que o scanner reportou errado, tirando falsos positivos do relatório final.
Avaliação de vulnerabilidades na Fluid Attacks
Executamos a avaliação de vulnerabilidades como um atacante abordaria o seu software: de forma contínua, combinando IA, os nossos próprios scanners e os nossos pentesters. O que segue é como isso funciona e o que os nossos números dizem a respeito, incluindo o ponto em que esses números deixam de ser evidência.
▶️ Vídeo: mostramos como os nossos scanners com IA, os nossos scanners determinísticos e os nossos pentesters certificados trabalham sobre o mesmo sistema, que é o que uma avaliação de vulnerabilidades completa parece na prática.
O que avaliamos, e sob quais regras
Toda avaliação de vulnerabilidades começa pelo escopo, acordado antes dos testes e colocado por escrito: quais aplicações web, aplicações móveis, APIs e microsserviços, infraestrutura de nuvem, contêineres e infraestrutura como código entram, o que fica fora dos limites e qual evidência podemos coletar. A exploração é feita para provar o impacto, nunca para causá-lo: os nossos avaliadores confirmam que uma fraqueza é alcançável e explorável, e param aí.
Como isso se vê na prática
Superfície | Técnica | Evidência que você recebe |
Código-fonte | Arquivo, linha e fluxo de dados, com exemplos de código em conformidade | |
Aplicações em execução | Request, response e uma prova de conceito reproduzível | |
Dependências | Componente afetado, versão e se o código vulnerável é alcançável | |
Nuvem e contêineres | Recurso mal configurado ou credencial exposta, com sua localização | |
Binários e componentes fechados | Lógica recuperada do binário e a fraqueza que ela expõe |
Varredura automatizada e testes manuais nos nossos dados
Entre 1º de janeiro e 31 de dezembro de 2025 registramos 1.119.396 vulnerabilidades nos sistemas que avaliamos, com 27.440.146 unidades CVSSF de exposição ao risco. A divisão por método de detecção:
Método | Parcela da exposição ao risco | Achados de severidade crítica | CVSSF médio por achado |
Automatizado (SAST, AI SAST, SCA, DAST, CSPM) | 55,8 % | 13 % | 15,5 |
Manual (PTaaS, secure code review, reverse engineering) | 44,2 % | 87 % | 93,2 |
Fonte: Fluid Attacks, State of Attacks 2026, sobre todos os sistemas avaliados em 2025. Os números dos pentesters vêm apenas de sistemas do plano Advanced; os das ferramentas incluem os planos Advanced e Essential.
O padrão é consistente: as ferramentas carregam o volume, as pessoas carregam a severidade. Essa é a coisa mais útil a saber quando você decide como alocar pessoal em uma avaliação de vulnerabilidades.
O que o nosso benchmark não prova
No nosso benchmark de ferramentas AppSec e pentesting, executado contra um universo de 1.201 vulnerabilidades distribuídas em 105 categorias CWE, um pentester reportou 1.076 delas: 89,6 % de recall com 100 % de precisão. Desse universo, 743 vulnerabilidades — 61,9 % — foram detectadas pelo pentester e por mais ninguém, diante de 36 ferramentas de terceiros de SAST, DAST ou SCA.
Três limites sobre esse resultado, porque um número sem suas ressalvas não é evidência:
A ferramenta automatizada com maior recall nela é o nosso próprio scanner, com 22,7 %, diante dos 89,6 % do pentester.
O conjunto de dados é curado, não um produto. 1.201 é o tamanho de um conjunto rotulado de vulnerabilidades conhecidas, não uma aplicação em produção. Um número de recall medido contra casos de teste com gabarito não se transfere igual para o software real, onde ninguém sabe o total.
O recall é calculado sobre a parte que o pentester revisou. A nota de rodapé do próprio benchmark diz que os falsos negativos dele são contados como 73 e não 125, porque ele não revisou de novo as seções que o scanner já havia coberto. Mude esse denominador e os 89,6 % se movem.
A ferramenta automatizada com maior recall nesse benchmark é o nosso próprio scanner, com 22,7 %. Publicamos esse número justamente porque ele é baixo. Os scanners não estão perto de substituir as pessoas, e preferimos dizer isso a arredondar para cima.
A mesma cautela se aplica à comparação de 2025: a média de 93,2 CVSSF dos pentesters vem de sistemas do plano Advanced, enquanto a média de 15,5 das ferramentas abrange os dois planos. As bases não são idênticas, e a diferença de seis vezes deve ser lida com isso em mente.
Reavalie cada correção
Uma correção pode falhar, ou introduzir uma fraqueza nova. Na nossa plataforma você pode solicitar um reattack, e o mesmo achado é testado de novo contra o código corrigido antes de ser fechado. Uma avaliação de vulnerabilidades que nunca verifica as próprias remediações reporta intenções, não estado.
Tipos de avaliação de vulnerabilidades
As avaliações de vulnerabilidades costumam ser classificadas pelo que está sendo avaliado, e a maioria das equipes executa mais de um tipo.
Tipo | Alvo | Análise típica |
Host | Servidores, estações de trabalho e outros dispositivos em uma rede | Revisão de configuração, nível de correções, serviços expostos |
Rede | Uma rede inteira, com fio ou sem fio, e seus recursos alcançáveis | Descoberta, identificação de portas e serviços, checagens de segmentação |
Banco de dados | Bancos de dados e ambientes de big data | Controle de acesso, criptografia, caminhos de injeção, dados expostos |
Aplicação | Aplicações web e móveis, APIs e microsserviços | Análise estática do código, análise dinâmica da aplicação em execução |
Nuvem e IaC | Contas de nuvem, contêineres e definições de infraestrutura | Gestão de postura, varredura de imagens, revisão de modelos |
O pentesting não pertence a esta lista de tipos de avaliação de vulnerabilidades. É uma metodologia, definida por como os testes são feitos, não por qual sistema está sob avaliação, e por isso ele se compara à varredura de vulnerabilidades e não à avaliação de rede ou de aplicação.
Como funciona uma avaliação de vulnerabilidades
A SP 800-115 do NIST (2008), o guia técnico para testes e avaliação de segurança da informação, agrupa o trabalho em técnicas de revisão, identificação e análise do alvo — descoberta de rede, identificação de portas e serviços, varredura de vulnerabilidades — e validação de vulnerabilidades do alvo. A sequência abaixo segue esse formato.
Escopo e inventário de ativos
Você não pode avaliar o que não listou. Este passo fixa quais sistemas, repositórios, contas e componentes de terceiros estão no escopo, e quanto cada um vale para o negócio. A maioria das avaliações de vulnerabilidades que deixa algo passar, deixa passar aqui, e não durante a detecção.
Detecção
Os scanners e os analistas trabalham sobre o escopo acordado da avaliação de vulnerabilidades. A amplitude vem da automação que roda a cada commit e a cada implantação; a profundidade vem dos avaliadores que percorrem a lógica de negócio que nenhuma assinatura descreve.
Validação
Uma avaliação de vulnerabilidades que pula a validação envia os próprios erros para os desenvolvedores, então os achados reportados são confirmados antes. É aqui que os falsos positivos são removidos e que um problema suspeito vira um problema documentado, com evidência anexada.
Priorização
A severidade sozinha é uma fila ruim. O CVSS descreve o impacto potencial; o EPSS estima a probabilidade de exploração; o catálogo Known Exploited Vulnerabilities da CISA — 1.734 entradas em outubro de 2026 — registra o que já está sendo explorado na prática, e a CISA recomenda usá-lo como insumo para priorizar a gestão de vulnerabilidades.
A nossa própria pontuação de prioridade funciona assim. Parte de uma base derivada do CVSS e a ajusta com as políticas de priorização da sua organização: a transitividade da dependência afetada, a fase de uso do componente vulnerável, se o problema aparece na lista KEV da CISA, seu valor de EPSS e o tempo estimado de correção. O resultado é um percentil diante de todas as vulnerabilidades identificadas até agora, o que é mais útil para ordenar do que uma pontuação de zero a dez.
Remediação e verificação
Os achados são atribuídos, corrigidos com mudanças de código, mudanças de configuração ou correções, e depois testados de novo. A avaliação de vulnerabilidades não termina quando o relatório é entregue; termina quando a correção é confirmada.
Cada volta alimenta a seguinte: as correções verificadas fecham achados, e os commits novos reabrem o ciclo.
Dentro de um relatório de avaliação de vulnerabilidades
Um relatório de avaliação de vulnerabilidades é acionável quando um desenvolvedor pode abrir um achado e saber o que está errado, onde está, por que importa, o que fazer a respeito e quanto tempo deve levar. Menos do que isso e o relatório vira um exercício de gerar tíquetes. Esta é a parte que os compradores avaliam menos e sofrem mais, então vale a pena ser concreto sobre os campos.
O achado: o quê, onde e a evidência que o sustenta
Todo achado começa com uma categoria de fraqueza — uma classe padronizada, não texto livre — e a instância específica encontrada no seu sistema. Uma categoria pode aparecer muitas vezes; cada instância precisa da própria localização.
Em uma avaliação de vulnerabilidades, localização significa o caminho do arquivo ou a URL do ambiente, mais a linha de código, o número de porta ou o campo de entrada exatos. Para código, a nossa plataforma também registra o hash do commit que introduziu o problema, o e-mail do seu autor e a quantidade de dias entre esse commit e o relatório. Esse último número é o que as equipes subestimam: é uma medida direta de quanto tempo a fraqueza ficou no repositório antes de alguém vê-la.
A descrição pertence à fraqueza, não à instância. O nosso banco de dados público de vulnerabilidades a publica abertamente, e cada entrada traz os mesmos cinco campos: o que é a fraqueza, seu impacto, o agente de ameaça que ela pressupõe, a recomendação para corrigi-la e um tempo esperado de remediação em minutos. A entrada 079, Non-upgradable dependencies, é um exemplo simples: o impacto é a perda de manutenibilidade porque as dependências não são mantidas, a ameaça é um atacante autenticado vindo da internet, a recomendação é declarar cada dependência com um gerenciador de dependências, e o tempo esperado de remediação é de 120 minutos. Cada entrada também liga ao requisito de segurança que ela descumpre, que é como um achado vira evidência de conformidade em vez de um exercício à parte.
A fraqueza 079 no nosso banco de dados aberto. Cada entrada traz os mesmos cinco campos e liga ao requisito de segurança que descumpre, então qualquer pessoa pode conferir sobre o que uma avaliação de vulnerabilidades nossa é construída.
A severidade, e o que a pontuação não diz
A severidade em uma avaliação de vulnerabilidades deve ser uma pontuação e o seu vetor. A pontuação sozinha é uma opinião; o vetor é o raciocínio. A nossa plataforma mostra a cadeia do vetor CVSS v4.0, a pontuação calculada com sua classificação qualitativa e um detalhamento de cada métrica que a produziu, para que quem lê possa discordar de uma métrica específica e não do número.
As faixas qualitativas valem ser ditas com clareza, porque as equipes discutem sobre elas mais do que deveriam: baixa é 0,1 a 3,9; média, 4,0 a 6,9; alta, 7,0 a 8,9; e crítica, 9,0 a 10,0. Um relatório que só dá a faixa jogou fora a parte que você poderia ter conferido.
A aba Severity na nossa plataforma: a pontuação calculada, sua classificação qualitativa e o vetor que a produziu, métrica por métrica. Uma avaliação de vulnerabilidades que só reporta a classificação esconde o raciocínio.
Campo | O que responde | Por que importa |
Fraqueza e descrição | De que classe de problema se trata | Agrupa instâncias e as conecta a uma correção conhecida |
Localização e linha, porta ou campo específico | Onde está exatamente | Um achado sem isso é um boato |
Evidência | Como sabemos que é real | Permite ao desenvolvedor reproduzir em vez de acreditar em você |
Pontuação CVSS e vetor | Quão grave pode ser, e com qual raciocínio | Torna a severidade auditável |
Prioridade | O que corrigir primeiro | Soma dados de exploração e contexto à severidade |
Tempo esperado de remediação | Quanto deve custar corrigir | Transforma um backlog em algo que você pode planejar |
Tratamento e responsável | Quem é o dono e sob qual decisão | Impede que achados fiquem sem dono |
Registro de reattack | Se a correção funcionou | Fecha o ciclo com prova e não com uma mudança de estado |
Requisito associado | Qual padrão isso descumpre | Converte achados em evidência de conformidade |
Tratamento: quem é o dono, e até quando
Um achado sem dono não é corrigido. Um relatório de avaliação de vulnerabilidades deve trazer o tratamento aplicado a cada vulnerabilidade, a pessoa designada, a data em que essa decisão foi tomada e, quando o tratamento é temporário, a data em que ele expira. Um risco aceito sem vencimento não é uma decisão; é um achado que foi abandonado em silêncio.
O mesmo vale para os falsos positivos. A nossa plataforma trata um falso positivo como um tratamento solicitado e registrado, não como uma exclusão silenciosa, o que mantém a discordância visível e revisável. Se o seu relatório de avaliação de vulnerabilidades deixa achados desaparecerem sem rastro, você não tem como auditar os julgamentos feitos em seu nome.
Verificação: o registro de reattacks
O último campo é o que separa uma avaliação de vulnerabilidades de uma alegação. Cada achado deve mostrar o resultado do seu reattack mais recente, a data em que foi solicitado, quem o solicitou, por quantos ciclos de reattack ele passou e a eficiência desses ciclos: a parcela que confirmou uma correção real.
Ciclos e eficiência são o diagnóstico que ninguém pede e todos precisam. Uma vulnerabilidade que passou por quatro reattacks com baixa eficiência não é um problema de remediação; é um sinal de que a equipe está remendando um sintoma e a fraqueza de fundo continua lá.
A avaliação de vulnerabilidades dentro da gestão de vulnerabilidades
A avaliação de vulnerabilidades detecta e reporta; a gestão de vulnerabilidades decide o que é corrigido primeiro, atribui, acompanha e verifica. Uma abordagem baseada em risco para essa segunda metade é o que mantém o tempo limitado de engenharia apontado para os achados que importam.
As duas metades precisam rodar de forma contínua, e por isso a avaliação de vulnerabilidades é um processo e não um projeto. Os sistemas mudam a cada merge, e aparecem fraquezas novas em dependências que você não tocou: o nosso banco de dados rastreia mais de 340.000 vulnerabilidades em 15 ecossistemas de código aberto. Os testes pontuais descrevem um sistema que já não existe quando o relatório é lido, e por isso a avaliação de vulnerabilidades fica dentro do pipeline de CI/CD, como prescreve o DevSecOps, e não ao lado dele.
Conclusões
Trate a avaliação de vulnerabilidades como um problema de medição, não como um exercício de relatório. O método que você escolhe coloca um teto no que você pode chegar a encontrar: nos nossos dados de 2025, a automação produziu a maior parte do volume enquanto 87 % dos achados críticos vieram de pessoas, e no nosso benchmark a melhor ferramenta automatizada alcançou 22,7 % de um conjunto conhecido de vulnerabilidades contra os 89,6 % de um pentester. Escolha um só método e você não terá reduzido o risco: terá reduzido a sua visão dele.
Depois julgue a avaliação de vulnerabilidades pelos seus campos, não pelo número de páginas. Um achado que traz sua localização, sua evidência, seu vetor, sua prioridade, seu responsável e seu histórico de reattacks é um sobre o qual um desenvolvedor pode agir esta semana. Uma faixa de severidade e um parágrafo, não.
A consequência prática de tratar assim a avaliação de vulnerabilidades é uma lista curta. Inventarie o que você tem, rode os dois métodos sobre isso de forma contínua, valide antes de escalar, priorize com dados de exploração e não só com severidade, e teste de novo cada correção.
Perguntas frequentes
A avaliação de vulnerabilidades é a mesma coisa que a varredura de vulnerabilidades?
Não. A varredura de vulnerabilidades é um método dentro de uma avaliação de vulnerabilidades. Uma avaliação de vulnerabilidades é o processo completo de encontrar, classificar e reportar fraquezas, e pode combinar varredura automatizada com testes manuais. Descrever uma avaliação como «rodar um scanner» deixa de fora a parte que encontra os problemas complexos.
Com que frequência uma avaliação de vulnerabilidades deve ser feita?
De forma contínua, não segundo um calendário. O código muda a cada merge e aparecem vulnerabilidades novas em dependências que você nunca editou, então uma avaliação anual ou trimestral reporta sobre um sistema que já mudou. Nos nossos dados de 2025, os sistemas com um portão de CI alcançaram uma taxa de remediação de 72,2 % contra 58 % dos que não tinham.
Os scanners automatizados podem substituir os pentesters?
Por enquanto não. Entre os sistemas que a Fluid Attacks avaliou em 2025, 87 % dos achados de severidade crítica foram identificados por revisão manual, e as vulnerabilidades encontradas por pentesters tiveram média de 93,2 unidades CVSSF contra 15,5 das encontradas por ferramentas. Os scanners dão velocidade e cobertura; as pessoas encontram as falhas lógicas e os ataques encadeados que nenhuma assinatura descreve.
O que um relatório de avaliação de vulnerabilidades deve incluir?
No mínimo: a fraqueza, sua localização exata, a evidência, uma pontuação CVSS com seu vetor, uma prioridade, um tempo esperado de remediação, um responsável e um registro de verificação. Um relatório que dá uma faixa de severidade sem o vetor, ou um achado sem uma localização reproduzível, não pode ser acionado nem auditado.
Uma avaliação de vulnerabilidades ajuda na conformidade com PCI DSS ou ISO 27001?
Sim, quando os achados são mapeados para requisitos. Padrões como PCI DSS, HIPAA, ISO 27001 e GDPR esperam que as fraquezas sejam identificadas e corrigidas. Um achado que pode ser rastreado até o requisito específico que descumpre transforma um relatório de avaliação de vulnerabilidades em evidência de conformidade em vez de um exercício à parte.
A Fluid Attacks realiza avaliações de vulnerabilidades?
Sim. Combinamos IA e os nossos próprios scanners — SAST, AI SAST, SCA, DAST, MAST, CSPM, Secret Scanning — com Pentesting as a Service, Secure Code Review e Reverse Engineering. Cada achado chega à nossa plataforma com sua evidência, sua severidade, sua orientação de remediação e um botão de reattack para verificar a correção.
Avalie o que um atacante realmente alcançaria
Os nossos scanners e pentesters executam a avaliação de vulnerabilidades nos seus sistemas à medida que eles mudam, para que os achados que você prioriza reflitam o que é explorável hoje e não o que uma varredura encontrou no trimestre passado. Start free trial · Contact us
