O escaneamento de vulnerabilidades é a inspeção automatizada de um alvo —uma rede, um host, uma aplicação em execução, código-fonte, dependências de código aberto ou uma configuração na nuvem— para encontrar fraquezas que correspondam a padrões conhecidos. O scanner é a ferramenta. O escaneamento é o processo que decide para onde apontá-la, quando executá-la e o que fazer com o resultado.
Nos sistemas que a Fluid Attacks avaliou em 2025, as ferramentas automatizadas identificaram 88,4 % de todas as vulnerabilidades, mas apenas 55,8 % da exposição total ao risco, e 87 % dos achados de severidade crítica vieram de revisão manual. O escaneamento de vulnerabilidades cobre terreno. Não cobre o terreno que mais dói.
Esta página explica o que um scanner de vulnerabilidades realmente procura, como o escaneamento de vulnerabilidades é classificado, com que frequência executá-lo, onde o método para e o que precisa acontecer depois que o relatório chega.
O que é escaneamento de vulnerabilidades?
O escaneamento de vulnerabilidades é um método de detecção: o software compara os componentes, as versões, as configurações e o código de um alvo definido com regras e bases de dados de vulnerabilidades, e reporta cada correspondência. O termo cobre duas coisas diferentes, e a distinção importa quando você escreve uma política em torno dele.
Scanner de vulnerabilidades: a ferramenta. Um programa com um conjunto de regras, uma base de dados e um motor que sonda ou analisa o alvo.
Escaneamento de vulnerabilidades: o processo. Definir o escopo, escolher credenciais, executar o scanner, ler o resultado e decidir o que vem depois.
Um scanner não entende a sua aplicação. Ele reconhece formas que lhe ensinaram: uma versão de biblioteca com um CVE publicado, um cabeçalho que falta, uma consulta construída por concatenação de strings, um bucket de armazenamento que responde a qualquer um. A análise da Fluid Attacks sobre escaneamento de aplicações web descreve a mecânica sem rodeios: um escaneamento revisa os componentes e as configurações dos alvos de avaliação predefinidos e os compara com características de código vulnerável.
Essa única frase contém o valor e o teto do escaneamento de vulnerabilidades. A correspondência de padrões escala para milhares de ativos. Ela não raciocina.
Escaneamento, avaliação e pentesting não são a mesma coisa
O escaneamento de vulnerabilidades é um método. Uma avaliação de vulnerabilidades é o processo que pode contê-lo, e o pentest responde a uma pergunta diferente. Equipes que tratam os três como sinônimos acabam comprando escaneamento de vulnerabilidades e reportando como outra coisa.
Prática | Pergunta que responde | Quem ou o que executa | Resultado |
Escaneamento de vulnerabilidades | Quais fraquezas conhecidas correspondem a este alvo? | Ferramenta automatizada | Uma lista de achados, com severidade e localização |
Avaliação de vulnerabilidades | Quão exposto está este sistema e o que importa primeiro? | Ferramentas mais analistas | Fraquezas classificadas, priorizadas e reportadas |
Pentesting | Um atacante consegue mesmo explorar isto e até onde chega? | Pentesters, apoiados por ferramentas | Prova de exploração, cadeias de ataque e impacto |
Estamos fechando mais rápido do que abrimos? | A organização | Remediação, verificação e métricas ao longo do tempo |
Um relatório de escaneamento de vulnerabilidades é evidência para uma avaliação. Não é a avaliação e nunca é o pentest, nem é red teaming nem uma simulação de violações e ataques, que testam detecção e resposta em vez de enumerar fraquezas.
Escaneamento de vulnerabilidades na Fluid Attacks
A Fluid Attacks executa o escaneamento de vulnerabilidades como uma camada de testes de segurança contínuos, junto com IA e pentesters, e reporta cada achado com a técnica que o produziu. Essa atribuição é o que a maioria dos relatórios de escaneamento omite, e o que permite julgar a sua própria cobertura.
O que escaneamos e com qual técnica
Cada vulnerabilidade na plataforma carrega a técnica que a detectou, então uma equipe consegue ver de relance se um achado veio de uma regra ou de uma pessoa.
Técnica | O que inspeciona |
SAST e AI SAST | Código-fonte |
SCA | Dependências de código aberto e suas vulnerabilidades conhecidas |
Web DAST e API DAST | Aplicações e APIs em execução |
MAST | Aplicações móveis |
CSPM | Configurações na nuvem |
SS | Segredos enviados a repositórios |
SCR, PTaaS e RE | Revisão manual, pentesting e engenharia reversa |
Cada achado indica com qual técnica foi detectado: SAST, DAST, SCA, PTaaS e as demais.
As primeiras seis técnicas são escaneamento de vulnerabilidades. As três últimas não, e a plataforma nunca apaga essa linha.
Como um escaneamento roda em um pipeline real
Static Application Security Testing (SAST), Software Composition Analysis (SCA), Dynamic Application Security Testing (DAST) e um scanner de APK são distribuídos como CLIs independentes e contêineres Docker. Eles reportam os resultados na CLI ou os exportam em CSV ou SARIF, e a opção --strict faz a execução falhar com exit code 1 quando encontra qualquer coisa. Essa opção é o que transforma o escaneamento de vulnerabilidades em um portão de build em vez de um relatório que ninguém abre. O scanner SAST da Fluid Attacks obteve 100 no OWASP Benchmark versão 1.2 em 2021, e em 2022 a App Defense Alliance adicionou sua CLI de escaneamento estático como ferramenta aprovada para validar requisitos de CASA tier 2.
O que as ferramentas encontraram e o que as pessoas encontraram em 2025
Os números abaixo vêm dos sistemas que a Fluid Attacks avaliou durante 2025. Os números de pentesters vêm exclusivamente do plano Advanced; os de ferramentas incluem os planos Advanced e Essential.
Medida | Ferramentas automatizadas | Técnicas manuais |
Percentual da exposição total ao risco identificado | 55,8 % | 44,2 % |
Percentual do número total de vulnerabilidades identificado | 88,4 % | 11,6 % |
Percentual de achados de severidade crítica identificado | 13 % | 87 % |
Leia as duas primeiras linhas juntas. O escaneamento de vulnerabilidades encontrou quase nove de cada dez achados e pouco mais da metade do risco, porque um scanner é bom em volume e fraco nas falhas severas e dependentes de contexto que concentram a exposição. A conclusão do próprio relatório é que a experiência humana continua essencial para avaliações de segurança completas, mesmo depois de implementar múltiplas ferramentas e investir em IA.
Um limite que vale dizer: nosso próprio scanner encontrou 22,7 %
No benchmark da Fluid Attacks com 36 ferramentas AppSec de terceiros contra uma aplicação web construída de propósito com 1.201 vulnerabilidades em 105 categorias CWE, a ferramenta automatizada com melhor recall foi o scanner próprio da Fluid Attacks, com 22,7 % das vulnerabilidades e 8,8 % da exposição total ao risco medida em CVSSF. Um pentester trabalhando na mesma aplicação chegou a 89,6 % de recall com 100 % de precisão.
Esse é um limite do escaneamento de vulnerabilidades como método, não de um produto, e é o número a ter em mente toda vez que um escaneamento volta limpo. O guia da Fluid Attacks para avaliar ferramentas AppSec diz o mesmo em termos mais diretos: o scanner automatizado com o maior número de verdadeiros positivos ainda assim perdeu quase 80 % do universo de vulnerabilidades.
Um escaneamento não termina até a correção ser verificada
Um patch pode falhar, não atacar a causa real ou introduzir algo novo, então a Fluid Attacks fecha o ciclo com reattacks: novos testes executados por suas ferramentas e seus pentesters depois de uma tentativa de correção. Cada um termina em Verified (vulnerable), Verified (safe) ou On hold. Enquanto um achado não chega a Verified (safe), o ciclo de escaneamento de vulnerabilidades em torno dele segue aberto, diga o que disser o ticket.
O que os scanners de vulnerabilidades procuram?
O escaneamento de vulnerabilidades procura mais do que identificadores CVE. Dependências vulneráveis conhecidas são a categoria mais fácil de casar, mas os conjuntos de regras atuais também cobrem padrões de código inseguro, configurações fracas e segredos expostos.
As regras por trás do escaneamento de vulnerabilidades merecem ser inspecionadas antes de você confiar em um relatório. A Fluid Attacks publica sua lógica de detecção de forma aberta: o catálogo de Security Rules tem mais de 1.900 regras automatizadas sobre 43 alvos, descritas como lógica e verificações automatizadas em código, nuvem, aplicações e binários, cada uma mapeada aos padrões que suporta. Um escaneamento de vulnerabilidades que só enumera CVE em dependências faz uma fração do que o método permite.
As regras automatizadas que os scanners executam, com seus alvos e os padrões aos quais se mapeiam.
Tipos de escaneamento de vulnerabilidades
O escaneamento de vulnerabilidades é classificado de duas maneiras: pelo que aponta e por como é executado. As duas classificações mudam o que os resultados significam.
Por alvo
O alvo decide quais fraquezas o escaneamento de vulnerabilidades consegue sequer enxergar.
Tipo de escaneamento | Alvo | Achados típicos |
Escaneamento de vulnerabilidades de rede | Faixas de IP, portas abertas, serviços, sistemas operacionais | Serviços sem patch, portas expostas, versões fracas de protocolo |
Escaneamento de aplicações web | Aplicações web e APIs em execução | Injeção, controle de acesso quebrado, cabeçalhos mal configurados |
Escaneamento de código | Código-fonte no repositório | Padrões inseguros, segredos no código, tratamento inseguro de dados |
Escaneamento de dependências | Componentes de terceiros e de código aberto | Componentes com vulnerabilidades publicadas |
Escaneamento de nuvem e contêineres | Configurações na nuvem e imagens de contêiner | Políticas permissivas, armazenamento público, imagens base vulneráveis |
Por modo
O mesmo alvo produz resultados diferentes conforme de onde o escaneamento de vulnerabilidades roda e se ele tem credenciais.
Modo | O que vê | Quando usar |
Escaneamento externo | A superfície de ataque alcançável pela internet | Checagens de perímetro e evidência de conformidade |
Escaneamento interno | Ativos alcançáveis de dentro da rede | Risco de movimento lateral e falhas de segmentação |
Escaneamento não autenticado | Só o que um visitante anônimo vê: banners, respostas, endpoints expostos | Uma primeira visão da perspectiva do atacante |
Escaneamento autenticado | Versões de pacotes instalados, configuração local, privilégios de usuário, ajustes que só aparecem após o login | Inventário preciso e muito menos erros por adivinhar versões |
Escaneamento integral | Todos os ativos no escopo, todas as verificações | Linhas de base periódicas |
Escaneamento direcionado | Uma aplicação, um branch, um grupo de ativos | Checagens por mudança dentro de um pipeline |
A diferença entre autenticado e não autenticado decide, sem alarde, a taxa de falsos negativos do seu escaneamento de vulnerabilidades. Um scanner não autenticado infere a versão de um serviço a partir do que o serviço anuncia; um escaneamento autenticado a lê. A OWASP alerta que essa inferência leva a falsos positivos e falsos negativos, porque os fornecedores aplicam backport de correções de segurança sem mudar o número da versão.
Quais são as limitações dos scanners de vulnerabilidades?
Os scanners de vulnerabilidades perdem aquilo para o que não têm uma regra, e a lacuna é estrutural, não questão de comprar um produto melhor. Isso inclui falhas de lógica de negócio, erros de autorização que dependem de quem é o usuário, vulnerabilidades que só importam quando encadeadas com outra e qualquer coisa para a qual ninguém publicou um padrão ainda.
O Web Security Testing Guide da OWASP faz a mesma observação sobre as ferramentas automatizadas que executam o escaneamento de vulnerabilidades: elas conseguem encontrar muitos problemas comuns, mas frequentemente lhes falta o contexto específico da aplicação necessário para detectar falhas mais profundas, e os problemas mais sérios costumam estar entrelaçados com a lógica de negócio e o desenho sob medida. A Fluid Attacks chega à mesma conclusão a partir dos seus próprios dados: a relação entre escaneamento de vulnerabilidades e pentesting é de complementação, não de substituição.
Três modos de falha do escaneamento de vulnerabilidades aparecem na prática:
Falsos positivos: achados que não resistem a uma revisão. Custam tempo de analista e, pior, ensinam os desenvolvedores a ignorar a fila.
Falsos negativos: vulnerabilidades reais que o scanner nunca reporta. Ninguém as vê, e por isso o recall merece pelo menos tanto escrutínio quanto a precisão quando você avalia uma ferramenta.
Cegueira de contexto: o escaneamento de vulnerabilidades devolve um achado tecnicamente correto e praticamente irrelevante, ou o contrário: um problema de severidade baixa que se torna crítico por onde está.
Um escaneamento limpo não é um sinal verde: Equifax
Em 2017, os atacantes chegaram ao portal de disputas on-line da Equifax por meio de uma vulnerabilidade crítica do Apache Struts, CVE-2017-5638, sobre a qual o US-CERT havia emitido um alerta público em 8 de março daquele ano. O relatório do Permanent Subcommittee on Investigations do Senado dos EUA concluiu que nenhum dos escaneamentos posteriores da Equifax identificou a versão vulnerável do Apache Struts que rodava na sua rede, e atribuiu a falha ao escopo, não à ferramenta: a empresa "não tinha inventário para determinar onde ou se usava Apache Struts na sua rede", e a ausência de um inventário de ativos de TI limitou a efetividade das suas ferramentas de escaneamento.
A formulação do próprio relatório é a lição: uma organização só pode defender os ativos que identificou. O escaneamento de vulnerabilidades herda a qualidade do inventário de ativos contra o qual roda, e um resultado negativo só cobre o que estava no escopo.
Com que frequência você deve executar escaneamentos de vulnerabilidades?
Execute o escaneamento de vulnerabilidades em uma cadência fixa e a cada mudança significativa, porque os dois pegam coisas diferentes. A cadência pega vulnerabilidades recém-publicadas em código que você não tocou; o gatilho por mudança pega o que você acabou de introduzir.
Gatilho | O que escanear | Referência |
A cada três meses, no mínimo | Superfície de ataque interna e externa | O PCI DSS exige escaneamentos internos e externos pelo menos uma vez a cada três meses para entidades que lidam com dados de portadores de cartão |
A cada três meses, por um Approved Scanning Vendor | Superfície de ataque externa | |
A cada commit, pull request ou release | Código, dependências e a aplicação em execução | Prática própria da Fluid Attacks; o controle 7 do CIS pede identificação e acompanhamento contínuos sem fixar um intervalo |
Depois de cada tentativa de correção | O achado específico | Reattack, para confirmar que a correção se sustentou |
O trimestral é um piso de conformidade, não uma meta de segurança. Para software que muda toda semana, o escaneamento de vulnerabilidades fica no pipeline, onde um escaneamento que falha bloqueia o merge e a janela entre introduzir uma falha e encontrá-la cai de meses para minutos. Executar o escaneamento de vulnerabilidades de forma contínua durante o desenvolvimento é o que mantém o inventário de achados atualizado o suficiente para agir.
O que fazer depois de um escaneamento de vulnerabilidades
Um relatório de escaneamento de vulnerabilidades é um insumo, não um resultado. Quatro passos transformam um no outro.
Validar: confirme que o achado é real e alcançável no seu contexto. É aqui que os falsos positivos são removidos e, mais importante, que cada achado recebe sua severidade real.
Priorizar por risco, não por quantidade: a Fluid Attacks mede a exposição ao risco como a soma das pontuações CVSSF de todas as vulnerabilidades abertas, de modo que fechar um achado crítico move o número mais do que fechar vinte triviais.
Atribuir e remediar: cada achado precisa de um responsável e de um prazo, ou o escaneamento de vulnerabilidades só enche um painel sobre o qual ninguém age.
Reavaliar: verifique que a correção eliminou a vulnerabilidade em vez de movê-la.
Pule o quarto passo e o seu programa de escaneamento de vulnerabilidades mede atividade em vez de resultados.
Conclusões
O escaneamento de vulnerabilidades é a forma mais rápida de encontrar fraquezas conhecidas em escala, e é a ferramenta errada para as falhas que carregam mais risco. Os dados próprios da Fluid Attacks de 2025 dizem as duas coisas ao mesmo tempo: o escaneamento de vulnerabilidades encontrou 88,4 % das vulnerabilidades e 55,8 % da exposição ao risco, enquanto 87 % dos achados críticos precisaram de uma pessoa.
A conclusão prática não é escanear menos. É escanear de forma contínua, com credenciais, contra um inventário de ativos em que você confie, tratar um relatório limpo como o começo da pergunta e não como a resposta, e colocar testes humanos onde as regras do scanner acabam.
Perguntas frequentes
Qual é a diferença entre escaneamento de vulnerabilidades e avaliação de vulnerabilidades?
O escaneamento de vulnerabilidades é um método de detecção automatizado; uma avaliação de vulnerabilidades é o processo mais amplo que pode contê-lo. A avaliação acrescenta definição de escopo, validação, classificação, priorização e relatório, e pode combinar ferramentas automatizadas com técnicas manuais. Um escaneamento produz uma lista. Uma avaliação produz um julgamento sobre a exposição.
Qual é a diferença entre um escaneamento de vulnerabilidades autenticado e um não autenticado?
Um escaneamento não autenticado vê apenas o que um visitante anônimo vê: portas expostas, banners de serviço, respostas públicas. Um escaneamento autenticado faz login e lê diretamente as versões dos pacotes instalados, as configurações locais e os privilégios. O escaneamento de vulnerabilidades autenticado produz menos falsos negativos, porque deixa de inferir versões a partir do que um serviço anuncia.
Com que frequência você deve executar escaneamentos de vulnerabilidades?
No mínimo a cada três meses, que é o que o PCI Security Standards Council estabelece para escaneamentos internos e externos em entidades que lidam com dados de portadores de cartão, mais um escaneamento depois de cada mudança significativa. Para aplicações em desenvolvimento ativo, esse piso é lento demais: execute o escaneamento de vulnerabilidades a cada commit ou pull request, e escaneie de novo depois de cada tentativa de correção para confirmar que ela se sustentou.
Passar em um escaneamento de vulnerabilidades significa que minha organização está em conformidade com o PCI DSS?
Não. O PCI Security Standards Council afirma que um escaneamento externo feito por um Approved Scanning Vendor "não é uma indicação de que qualquer outro requisito do PCI DSS tenha sido revisado ou esteja implementado". Um escaneamento aprovado é evidência de um requisito, não um veredito de conformidade.
A Fluid Attacks usa scanners de vulnerabilidades?
Sim, e publica o que eles deixam passar. No benchmark da Fluid Attacks contra uma aplicação com 1.201 vulnerabilidades, o scanner próprio liderou entre as ferramentas automatizadas com 22,7 % de recall, enquanto um pentester chegou a 89,6 % com 100 % de precisão. Essa lacuna é a razão pela qual o plano Essential funciona com ferramentas automatizadas e IA, enquanto o plano Advanced soma pentest manual, revisão manual de código e engenharia reversa a cargo dos seus especialistas.
Escaneie continuamente e depois olhe onde as regras acabam
Nosso escaneamento de vulnerabilidades roda a cada mudança e nossos pentesters vão atrás do que nenhuma regra consegue casar, para que você descubra o que um relatório limpo escondia antes que um atacante descubra. Teste gratuito · Fale conosco.
Comece agora com a solução RBVM da Fluid Attacks
