Red Flags de um Pentest: 7 Sinais Que o Teste Falhou

Resumo:

• Existem sinais (red flags) que indicam problemas de execução no pentest.
• Um relatório de pentest sem nenhuma vulnerabilidade encontrada quase sempre é um sinal de metodologia insuficiente.
• Um escopo genérico e sem delimitação formal é um dos sinais mais comuns de que o teste foi superficial desde o início.
• A ausência de evidências de exploração indica que o relatório pode ter sido gerado por ferramentas automatizadas.
• Recomendações vagas como “atualizar o sistema” são inúteis para quem precisa corrigir uma vulnerabilidade real.
• Pentest sem reteste não fecha o ciclo: sem verificação das correções, não há como saber se a superfície de ataque foi de fato reduzida.
• Fornecedores que não fazem perguntas antes de propor geralmente não entendem o ambiente, o que pode gerar um teste inconclusivo.
• O prazo e o preço abaixo do mercado costumam refletir exatamente o nível do serviço entregue.

Quando uma empresa recebe um relatório de pentest, a reação costuma ser de alívio se poucas vulnerabilidades forem encontradas, ou de preocupação se a lista for longa. Profissionais de segurança experientes, no entanto, têm uma terceira reação: desconfiança quando o relatório vem vazio.

Ambientes de software modernos são complexos demais para não ter vulnerabilidades, e um profissional certificado com metodologia sólida vai encontrá-las. Se não encontrou, é preciso se perguntar se o teste foi feito corretamente.

A Vantico selecionou uma lista com os sete sinais mais comuns de que um pentest não foi executado com o rigor necessário. Alguns são visíveis antes mesmo do teste começar e outros aparecem só no relatório. 

7 Red Flags de um Pentest

1. O relatório não tem nenhum achado

Existe um mito persistente de que um relatório sem vulnerabilidades é o ideal para um pentest. A ideia de um relatório “limpo” tem origem na era do desenvolvimento Waterfall (com os primeiros registros em 1970), quando o software era estático, atualizações aconteciam uma ou duas vezes por ano, e o pentest era tratado apenas como uma checagem final antes do lançamento. Nesse modelo, passar no teste sem achados era o objetivo.

Agora, os códigos mudam diariamente, novas dependências são adicionadas constantemente e as superfícies de ataque se expandem a cada deploy. Segundo o NIST (National Vulnerability Database), mais de 28.000 novas vulnerabilidades foram catalogadas em 2024, uma média de mais de 70 por dia. Então esperar que um ambiente real não tenha nenhuma delas é estatisticamente improvável.

Quando um relatório volta vazio, as hipóteses mais prováveis são: o escopo foi estreito demais, o tempo de teste foi insuficiente, a metodologia foi superficial, ou o relatório foi gerado por uma ferramenta automatizada sem análise humana. 

Para efeito de comparação: em um ativo testado pela Vantico em 2025, uma ferramenta de inteligência artificial com mais de 1.300 ferramentas integradas não encontrou nenhuma vulnerabilidade. O pentester humano certificado encontrou 21, incluindo duas críticas. O relatório vazio indicava limitação da ferramenta.

Importante: um teste pode ser bem feito e, ainda assim, ter zero achados, como aconteceu neste caso da Vantico. Porém, o teste foi orientado especificamente às exigências do compliance com o PCI DSS 4.0 e a empresa já possuía uma profunda maturidade de segurança.

2. O escopo não foi definido formalmente

Um pentest sem escopo documentado é um dos sinais mais precoces de que o projeto vai ter problemas. O escopo define o que será testado: quais sistemas, quais APIs, quais ambientes e quais tipos de acesso. 

Fornecedores sérios definem o escopo por escrito antes de iniciar qualquer teste, estabelecem regras de engajamento claras (o que pode ser testado, em quais horários e com qual nível de acesso) e documentam qualquer restrição acordada. Isso garante que o teste vai cobrir o que realmente importa.

Quando o escopo é genérico ou mal definido, o risco é duplo: o pentester pode desperdiçar tempo em sistemas irrelevantes e deixar de testar os mais críticos, ou o cliente pode achar que foi testado um ambiente que nunca entrou no escopo. 

Fique atento(a): fornecedores que enviam a proposta comercial antes mesmo de fazer perguntas sobre o seu ambiente são um sinal de alerta. Quem não entende o que vai testar não consegue calibrar o teste corretamente.

3. O relatório não tem evidências de exploração

Todo achado de um pentest profissional precisa de evidência: a requisição utilizada, a resposta obtida, um print mostrando o ataque em execução ou a captura do tráfego. Sem evidência, a vulnerabilidade foi apenas identificada por uma ferramenta e reproduzida no relatório.

A existência de evidência é fundamental por três motivos: prova que a falha é real e reproduzível naquele ambiente, permite que os desenvolvedores repliquem o erro para encontrar a causa raiz e atende à exigência dos auditores em processos de compliance.

Relatórios sem evidências técnicas por achado são um dos principais indicadores de que o trabalho foi feito por ferramenta automatizada. 

4. As recomendações de correção são vagas

“Atualizar o sistema”, “aplicar boas práticas de segurança”, ou “revisar as configurações”: esse tipo de recomendação aparece com frequência em relatórios de baixa qualidade e é inútil para quem precisa corrigir problemas reais.

Uma recomendação de correção útil é específica: qual biblioteca atualizar, qual parâmetro corrigir e qual configuração alterar, com exemplo de código ou configuração correta quando possível. Ela também indica a prioridade da correção em relação a outros achados e a referência à origem da vulnerabilidade (CVE, CWE, OWASP) para que o desenvolvedor possa entender o contexto completo.

O nível de detalhe das recomendações é um bom indicador do nível de análise que aconteceu antes delas. Recomendações genéricas revelam que o profissional não foi a fundo o suficiente para entender a causa raiz,  o que pode gerar a correção apenas do sintoma e não resolver o problema.

5. Não há previsão de reteste

O reteste é a etapa em que o pentester verifica, após as correções feitas pelo cliente, se as vulnerabilidades foram de fato resolvidas. Sem essa etapa, o ciclo do pentest não fecha: sabe-se que havia falhas, mas não se sabe se as correções funcionaram.

Muitos fornecedores não incluem reteste no contrato padrão ou o oferecem com prazo muito curto. Isso tem um efeito importante: o cliente corrige as vulnerabilidades, mas não tem confirmação técnica de que a correção foi eficaz. 

Para fins de compliance, essa ausência pode ser um problema. Frameworks como PCI DSS 4.0 e as resoluções BCB 538/2025 e CMN 5.274/2025 exigem evidências rastreáveis de remediação, e o laudo de reteste é o documento que fornece essa evidência.

Um pentest sem reteste previsto é um serviço incompleto. Pergunte ao fornecedor antes de contratar se o reteste está incluso, por quanto tempo e se gera documentação formal.

6. A criticidade dos achados não tem critério documentado

Como o fornecedor decidiu que uma vulnerabilidade é crítica, alta, média ou baixa? Se o relatório não explica, a classificação é arbitrária e sem critério documentado.

Relatórios profissionais documentam a metodologia de classificação de criticidade, geralmente baseada no CVSS (Common Vulnerability Scoring System), e explicam como fatores do ambiente, como exposição à internet, tipo de dado processado e contexto regulatório, foram considerados na ponderação.

O mesmo tipo de vulnerabilidade pode ser crítica em um sistema exposto à internet e média em um sistema interno com acesso restrito. Esse contexto precisa aparecer no relatório e, se não aparecer, você não tem como tomar decisões de priorização de correção com base nele.

7. O prazo e o preço estão muito abaixo do mercado

Um pentest profissional leva tempo. O reconhecimento do ambiente, a exploração manual das vulnerabilidades, a documentação de cada achado com evidência, a análise de impacto de negócio e a elaboração de recomendações específicas são atividades que não podem ser comprimidas indefinidamente sem comprometer a qualidade.

O tempo e o preço praticados revelam o nível de profundidade do serviço. Um teste muito rápido e barato quase sempre é um scan automatizado com relatório formatado.

Isso não significa que o pentest precisa ser caro para ser bom. Mas significa que preço e prazo muito abaixo da média do mercado são sinais de que a entrega será proporcional ao investimento.

Como é um pentest bem-feito

Depois de listar o que não deve estar em um pentest, vale deixar claro o que deve. Um pentest bem executado tem:

• Escopo e regras de engajamento documentados formalmente antes do início.
• Metodologia baseada em frameworks reconhecidos como OWASP, PTES ou NIST SP 800-115.
• Achados com evidência técnica de exploração real por profissional certificado.
• Classificação de criticidade com critério documentado e contextualizado para o ambiente.
• Recomendações de correção específicas, acionáveis e com referências externas.
• Reteste previsto em contrato, com laudo formal de status de cada achado após as correções.
• Relatório executivo para lideranças e relatório técnico para o time de desenvolvimento.

Se o relatório que você recebeu não tem essas características, vale questionar se o investimento gerou o resultado esperado e se o ambiente está tão seguro quanto o relatório sugere.

Quer entender como a Vantico estrutura seus projetos de pentest? Agende uma demonstração aqui.

Siga a Vantico nas redes sociais e fique atualizado sobre cibersegurança, tecnologia e insights.

FAQ: Perguntas frequentes

Um relatório de pentest sem nenhum achado pode ser legítimo?

É raro. Para que um ambiente real não tenha nenhuma vulnerabilidade identificável, o escopo precisaria ser mínimo, o sistema muito simples e a metodologia muito rigorosa. Quando um relatório volta vazio, quase sempre é sinal de que o escopo foi estreito, o tempo insuficiente ou a metodologia superficial. 

Como saber se um relatório de pentest foi gerado por uma ferramenta ou por um profissional humano?

O principal indicador é a presença de evidências de exploração: capturas de tela mostrando o ataque em execução, requisições e respostas reais, descrição do raciocínio do pentester durante a exploração e impacto contextualizado para o negócio da empresa. Relatórios de ferramentas automatizadas listam vulnerabilidades com base em padrões, sem evidência de que a falha foi explorada naquele ambiente específico. Recomendações genéricas e ausência de análise de impacto de negócio são outros indicadores.

O que devo perguntar a um fornecedor de pentest antes de contratar?

As perguntas mais importantes são: qual metodologia utilizam (OWASP, PTES, NIST)? Os profissionais têm certificações como OSCP ou eWPTX? O reteste está incluso e por quanto tempo? O relatório inclui sumário executivo e relatório técnico? Como a criticidade dos achados é calculada? Você pode compartilhar um exemplo de relatório anônimo? 

Um pentest com muitos achados é sinal de um sistema fraco?

Não necessariamente. Encontrar muitas vulnerabilidades indica que o teste foi rigoroso e que o ambiente foi bem coberto. O importante é o trabalho acerca destes achados: se as vulnerabilidades são documentadas com evidência, priorizadas por criticidade e corrigidas com processo documentado, o pentest cumpriu seu papel. 

Qual a diferença entre pentest e scan automatizado?

Um scan automatizado identifica padrões de vulnerabilidades conhecidas com base em assinaturas, é rápido e útil como triagem, mas não entende contexto, não encadeia falhas e não consegue validar se uma vulnerabilidade é de fato explorável naquele ambiente específico. Um pentest manual é conduzido por um profissional que raciocina sobre o sistema, combina falhas pequenas em vetores de ataque críticos e contextualiza o impacto para o negócio. São complementares, mas não equivalentes. 

O reteste é obrigatório em processos de compliance?

Depende do framework. O PCI DSS 4.0, por exemplo, exige evidências rastreáveis de remediação das vulnerabilidades encontradas no pentest, e o laudo de reteste é o documento que fornece essa evidência. As resoluções BCB 538/2025 e CMN 5.274/2025 do Banco Central também exigem documentação das correções, com retenção por 5 anos. Para ISO 27001 e SOC 2, o reteste não é obrigatório, mas fortalece as evidências de controle apresentadas aos auditores.

Como um relatório com achados pode ser usado como argumento de vendas?

Um relatório que mostra vulnerabilidades encontradas e corrigidas com processo documentado é mais convincente para compradores do que um relatório vazio. Ele prova que a empresa tem metodologia para encontrar problemas reais e processo para resolvê-los. Você pode saber mais sobre isso neste artigo: Como usar o Pentest como Ferramenta de Vendas.