Uma análise de vulnerabilidades tenta encontrar e priorizar o máximo possível de fraquezas. Um pentest tenta provar o que um atacante consegue fazer de verdade com algumas delas. Um é amplitude, o outro é profundidade. Quase toda a confusão entre análise de vulnerabilidades vs pentest vem de fornecedores que usam os dois termos como sinônimos, e de equipes que contratam uma coisa quando precisavam da outra.
Neste guia explicamos os dois, comparamos lado a lado (objetivo, profundidade, exploração, frequência, automação, custo e entregável), mostramos quando usar cada um e onde entra a avaliação contínua no nível do código.
O que é uma análise de vulnerabilidades
Uma análise de vulnerabilidades (em inglês, vulnerability assessment) é um processo sistemático para identificar, validar, priorizar e reportar fraquezas de segurança. É majoritariamente automatizada e feita para ser repetida. Um ciclo típico:
- Escopo e inventário: quais hosts, aplicações, repositórios, contas de cloud e dependências estão em jogo.
- Descoberta: scanners e analisadores procuram problemas conhecidos: patches faltando, versões vulneráveis de bibliotecas, configurações inseguras, padrões de código arriscados, segredos expostos.
- Validação: remover falsos positivos e duplicados.
- Priorização: ordenar por severidade (CVSS), probabilidade de exploração (sinais como o EPSS da FIRST ou o catálogo Known Exploited Vulnerabilities da CISA) e contexto de negócio: está exposto à internet? mexe com dados de clientes?
- Relatório e remediação: responsáveis, correções, prazos, e um novo scan para confirmar.
Existem tipos diferentes conforme o alvo: análise de rede e hosts, de aplicações web, revisões de configuração de cloud e avaliações no nível do código que analisam código fonte, dependências e infraestrutura como código. Uma auditoria de segurança de código é, na prática, uma análise de vulnerabilidades profunda no nível do código.
O que é um pentest
Um pentest (teste de intrusão, ou penetration test) é um ataque simulado e autorizado. Os testers trabalham dentro de um escopo e de regras de engajamento definidos, e não param em "isso parece vulnerável": tentam explorar, encadear com outras fraquezas e demonstrar o impacto. Costuma seguir fases como reconhecimento, mapeamento, exploração, pós-exploração e relatório, e pode ser caixa preta (sem informação), caixa cinza (com algumas credenciais ou documentação) ou caixa branca (com acesso ao código). Para o panorama completo, leia o que é pentest.
O valor de um pentest é o julgamento. Um tester humano percebe que um token de redefinição de senha é previsível, que um vazamento de informação de baixa severidade expõe IDs internos, e que esses IDs somados a uma verificação de autorização ausente permitem ler as faturas de todos os clientes. Nenhum achado isolado era crítico; a cadeia é.
Análise de vulnerabilidades vs pentest: tabela comparativa
| Dimensão | Análise de vulnerabilidades | Pentest |
|---|---|---|
| Objetivo | Encontrar e priorizar o máximo possível de fraquezas | Provar o impacto real explorando fraquezas |
| Profundidade | Ampla e superficial: muitos ativos, muitas verificações | Restrita e profunda: alvos selecionados, caminhos de ataque criativos |
| Exploração | Normalmente nenhuma, ou verificação segura limitada | Sim, sob regras de engajamento, incluindo encadeamento |
| Frequência | Contínua, por mudança, semanal ou mensal | Tipicamente anual, por grande release ou após mudanças significativas |
| Automação | Majoritariamente automatizada, com triagem humana | Majoritariamente manual, apoiado por ferramentas |
| Custo | Menor por execução; escala com ativos e frequência | Maior por projeto; depende de horas de tester e escopo |
| Entregável | Lista priorizada de achados com orientação de correção | Relatório narrativo com caminhos de ataque, evidências e impacto de negócio |
| Ponto fraco | Perde falhas de lógica e cadeias; pode ser ruidosa | Foto de um momento; limitado por escopo e horas |
A mesma aplicação, dois relatórios diferentes
Imagine uma API SaaS com três problemas: uma dependência com um CVE conhecido, mensagens de erro verbosas que vazam IDs internos de usuários, e um endpoint que carrega um registro pelo ID sem verificar de quem ele é.
- A análise de vulnerabilidades reporta o CVE como alto, os erros verbosos como baixo e, se a ferramenta raciocina sobre autorização, a verificação de ownership ausente como alta. Cada achado aparece isolado, com sua correção.
- O pentest talvez ignore o CVE se ele não for alcançável, mas usa os IDs vazados para enumerar contas e a verificação ausente para baixar dados de outros tenants. O relatório diz: "Um usuário autenticado consegue ler os registros de qualquer cliente". É essa frase que consegue orçamento e atenção.
Os dois relatórios estão certos. Eles respondem perguntas diferentes.
Quando usar cada um
Use uma análise de vulnerabilidades quando
- Você faz deploy todos os dias e precisa detectar fraquezas novas assim que aparecem.
- Nunca olhou para segurança de forma sistemática e precisa de uma linha de base.
- Quer limpar os problemas conhecidos antes de pagar um pentest.
- Precisa de evidência contínua de gestão de vulnerabilidades. A ISO/IEC 27001:2022, por exemplo, inclui no Anexo A um controle de gestão de vulnerabilidades técnicas.
Use um pentest quando
- Está prestes a lançar um produto ou feature grande que lida com dados sensíveis.
- Um cliente, investidor ou regulador pede um relatório de pentest independente.
- Fez mudanças significativas de arquitetura: nova autenticação, novo modelo multi-tenant, nova API pública.
- O compliance exige. O PCI DSS v4.0, por exemplo, pede scans externos de vulnerabilidades feitos por um Approved Scanning Vendor pelo menos a cada três meses (requisito 11.3.2) e pentests internos e externos pelo menos a cada 12 meses e após mudanças significativas (requisito 11.4).
Se você está avaliando fornecedores, nosso guia de ferramentas de pentest explica o que a automação consegue substituir e o que não.
O que perguntar antes de contratar qualquer um dos dois
Seja uma análise de vulnerabilidades, um pentest ou os dois, estas perguntas separam trabalho útil de ruído caro:
- O que exatamente está no escopo? Domínios, APIs, apps mobile, contas de cloud, código fonte. O que não estiver na lista não será testado.
- Quanto é manual? Em um pentest, peça o número de dias de tester e quem são os testers. Em uma análise, pergunte como os achados são validados antes de chegar até você.
- Autenticado ou não? A maioria dos bugs sérios de um SaaS fica atrás do login. Testar só a superfície pública deixa esses bugs de fora.
- Como os achados são priorizados? O rótulo de severidade sozinho não basta. Você quer explorabilidade e contexto de negócio.
- Como é um achado? Peça um relatório de exemplo. Um bom achado traz evidência, passos para reproduzir e uma correção concreta.
- O reteste está incluído? Confirmar que as correções funcionam faz parte do trabalho, não é um extra.
Erros comuns
- Comprar um scan com rótulo de pentest. Se o entregável é um export do scanner sem edição e sem evidência de exploração, é uma análise de vulnerabilidades. Pergunte quantas horas de teste manual estão incluídas.
- Fazer pentest em um código cheio de problemas conhecidos. Os testers vão gastar seu orçamento reportando bibliotecas desatualizadas e headers faltando em vez de encontrar falhas de lógica.
- Tratar o pentest como o programa de segurança. Um pentest é uma foto. Duas semanas depois sai código novo e o relatório já está envelhecendo.
- Não priorizar. Uma análise de vulnerabilidades com 900 achados sem ordem gera paralisia, não remediação.
Onde entra a avaliação contínua no nível do código
Em uma empresa de software, a maior parte do risco novo entra por mudanças de código: um endpoint novo, um upgrade de dependência, uma alteração em um workflow de CI. Um pentest anual não acompanha esse ritmo. A resposta prática é fazer análise de vulnerabilidades no nível do código a cada mudança e reservar os pentests para o que pessoas fazem melhor.
A avaliação no nível do código combina várias técnicas estáticas:
- SAST no seu próprio código, idealmente AI SAST que raciocine sobre autorização e fluxo de dados, não só sobre padrões fixos. Em SAST e DAST mostramos como ele se complementa com testes em runtime.
- Software composition analysis para CVEs conhecidos em dependências, explicado em SAST vs SCA.
- Detecção de segredos em todo o histórico do git.
- Verificações de infraestrutura como código e CI para GitHub Actions, Dockerfiles, Terraform e Kubernetes.
É aí que o Nurbak se encaixa. Você conecta o GitHub e escaneia um repositório; o próprio modelo de IA self-hosted analisa o código (a análise não envia seu código para a OpenAI nem para a Anthropic) e reporta vulnerabilidades exploráveis com arquivo e linha, CVEs de dependências via OSV com versões corrigidas, configurações inseguras de GitHub Actions, Docker, Terraform e Kubernetes e segredos no histórico do git, tudo resumido em um score de 0 a 100 com explicações em linguagem simples. Para deixar o escopo claro: o Nurbak analisa código e configuração. Ele não faz DAST, nem scan de rede, nem exploração ao vivo contra seus sistemas, então complementa um pentest em vez de substituí-lo. Você pode começar com uma avaliação contínua do seu código; o scan gratuito mostra completos os 3 achados mais importantes.
Um programa prático para uma empresa de software
- Em cada pull request: avaliação no nível do código (SAST, SCA, segredos, IaC), com achados exploráveis resolvidos antes do merge.
- Semanal ou mensal: novo scan completo do repositório e revisão do backlog pendente; scans externos dos ativos expostos à internet.
- Uma vez por ano e após grandes mudanças: um pentest manual focado em lógica de negócio, autenticação, multi-tenancy e cadeias de ataque.
- Depois de cada pentest: transformar cada achado em um teste de regressão e, quando possível, em uma verificação que rode a cada mudança, para que a mesma classe de bug não volte.
Para uma visão mais ampla de prioridades além dos testes, veja nosso guia de cibersegurança para empresas de software.
Conclusão
Análise de vulnerabilidades vs pentest não é uma competição. A análise dá cobertura e continuidade; o pentest dá profundidade e prova. Rode análises continuamente, principalmente no nível do código, onde o seu risco muda todos os dias, e traga pentesters quando precisar de uma visão independente e adversarial. Se quiser colocar a parte contínua para rodar hoje, comece com uma avaliação automatizada do seu repositório.