Reteste de teste de intrusão: o que é, porque o auditor o exige e com que frequência testar

O problema: o relatório saiu, a correção "foi feita" e ninguém a comprovou

Um teste de intrusão termina com uma lista de falhas. O valor real surge depois: a equipa corrige e alguém tem de provar que a correção funciona. É isso que faz o reteste. Sem ele, a organização fica com um relatório que diz "havia um problema" e nenhuma evidência de que deixou de existir.

Pense no que acontece na prática. O relatório chega com doze achados. A equipa abre doze tickets, fecha onze em dois sprints e deixa um "para depois". Seis meses mais tarde, o auditor pergunta: "qual é o estado daqueles achados?". A resposta honesta é "acreditamos que foram corrigidos". Para um auditor, acreditar não é evidência.

Auditores, QSA e áreas de risco sabem-no. Por isso o reteste surge como ponto autónomo nas conversas de conformidade, e é onde mais relatórios ficam incompletos. Neste guia explicamos o que é, o que tem de entregar, que correções costumam falhar, com que frequência testar e o que perguntar ao fornecedor antes de assinar.

O que é um reteste

Um reteste é a repetição dirigida dos testes que originaram cada achado, depois de a equipa aplicar a correção. O pentester reproduz o mesmo ataque, nas mesmas condições, e regista se ainda funciona.

Não é um novo teste de intrusão. O âmbito fica limitado aos achados já reportados: não procura vulnerabilidades novas, não cobre funcionalidades alteradas entretanto e não substitui o teste anual. Esta fronteira ajuda as duas partes: o cliente sabe exatamente o que está a pagar e o fornecedor sabe exatamente o que tem de demonstrar.

	Teste de intrusão	Reteste
Objetivo	Descobrir o que é explorável	Confirmar que o que foi encontrado foi corrigido
Âmbito	Aplicação, rede ou ambiente completo	Apenas os achados do relatório anterior
Resultado	Lista de achados com evidência	Estado por achado com nova evidência
Esforço típico	Dias ou semanas, consoante o âmbito	Uma fração do teste original, proporcional ao número de achados
Quando	Anualmente e após alterações relevantes	Após a correção, numa janela acordada

O ciclo de vida de um achado

O reteste só faz sentido dentro de um ciclo. Cada achado percorre as mesmas etapas, e cada etapa deixa um registo que o auditor pode seguir:

Etapa	O que acontece	Registo que fica
1. Descoberta	O pentester explora a falha e documenta a evidência	Achado no relatório, com severidade e passos de reprodução
2. Triagem	A equipa define responsável, prazo e abordagem de correção	Ticket associado ao ID do achado
3. Correção	O código, a configuração ou o processo é alterado	Commit, pull request ou pedido de alteração
4. Reteste	O pentester repete o ataque original em produção	Pedido, resposta ou registo novos
5. Estado	O achado é fechado, reaberto ou aceite como risco	Relatório atualizado com estado e data

Se faltar qualquer etapa, o ciclo quebra. O erro mais comum é saltar da etapa 3 diretamente para o fecho do ticket, sem a etapa 4: a falha "desaparece" do backlog, mas ninguém verificou o ambiente.

Porque é que auditores e reguladores esperam reteste

No PCI DSS 4.0, o requisito 11.4 trata o teste de intrusão como um ciclo e não como um evento: as vulnerabilidades exploráveis encontradas devem ser corrigidas e o teste repetido para verificar a correção. Veja como isto entra no relatório em Pentest para PCI DSS 4.0.

No setor financeiro europeu, o DORA exige testes de resiliência e o tratamento das falhas detetadas, e a NIS2 pede gestão de vulnerabilidades por parte das entidades abrangidas. Em ambos os casos, um reteste documentado é a forma mais direta de demonstrar o tratamento. Confirme o texto aplicável à sua entidade antes de montar o dossiê de evidências. Para o enquadramento, veja Testes de intrusão na NIS2 e no DORA.

A lógica é igual na ISO 27001 e no SOC 2: o auditor não quer apenas saber que testou, mas que a gestão de vulnerabilidades fechou o ciclo. Vale também para o questionário de segurança de um cliente empresarial: "corrigiram o que o teste encontrou?" é uma pergunta a que o reteste responde com um documento, não com uma promessa.

O que mostra um relatório de reteste

Um bom reteste devolve, para cada achado original:

1. Identificador e severidade originais, para rastrear face ao relatório anterior.
2. Estado: corrigido, parcialmente corrigido, não corrigido ou risco aceite (este último com justificação escrita e aprovação formal da organização).
3. Evidência nova: o pedido e a resposta, a captura de ecrã ou o registo que mostram que o ataque original falha (ou continua a funcionar).
4. Data e responsável pelo teste, para a pista de auditoria.
5. Novos achados introduzidos pela correção, quando evidentes, registados à parte.

Um reteste que diz apenas "todas as falhas foram corrigidas" não serve de evidência. Quem lê precisa de ver o que foi tentado. O quadro seguinte resume o que cada estado exige para ser aceite por um auditor:

Estado	Significado	Evidência necessária
Corrigido	O ataque original e as variações razoáveis falham	Pedido e resposta que mostram a falha do ataque, data e ambiente testado
Parcialmente corrigido	O vetor original falha, mas uma variação ou instância ainda funciona	Evidência do que passou a falhar e do que continua explorável
Não corrigido	O ataque original continua a funcionar	Evidência da exploração repetida e do impacto atual
Risco aceite	A organização decidiu conviver com a falha	Justificação, controlo compensatório, aprovação formal e data de revisão
Não aplicável	O componente foi desativado ou removido	Prova da remoção, e não apenas retirar o achado do âmbito

Quando fazer o reteste

O melhor momento é logo a seguir a a equipa marcar as correções como implementadas em produção (ou no ambiente equivalente). Retestar em pré-produção pode ser uma verificação prévia útil, mas só a verificação no ambiente real comprova o resultado final.

Acorde uma janela com o fornecedor: por exemplo, que aceite pedidos de reteste durante um período após a entrega do relatório. Pergunte-o na contratação. Uma janela demasiado curta obriga a correções apressadas; sem janela, o reteste torna-se um novo orçamento.

Duas dicas de calendário ajudam bastante. Primeiro, agrupe as correções em lotes em vez de pedir um reteste por achado: o fornecedor trabalha com mais eficiência e passa por menos rondas. Segundo, trabalhe a partir do prazo da sua auditoria ou supervisão, para trás: se o relatório final atualizado tem de estar pronto em março, a janela de correção termina bastante antes.

Erros comuns na correção

São os padrões que mais vezes fazem um achado regressar como "não corrigido":

• Corrigir o sintoma e não a causa. Bloquear o payload do teste em vez de corrigir a validação. O pentester altera um carácter e a falha regressa.
• Resolver só com WAF. Uma regra no WAF reduz o risco imediato, mas não elimina a vulnerabilidade da aplicação. Vale como mitigação temporária e deve ser registada como tal.
• Validar apenas no cliente. Esconder um botão ou verificar um campo no navegador não impede quem chama a API diretamente. A regra tem de existir no servidor.
• Corrigir uma instância e esquecer a classe. A mesma falha de autorização em cinco endpoints, corrigida num. A falha de autorização em APIs (BOLA) é o exemplo clássico: a correção certa é um controlo central, não cinco remendos.
• Introduzir uma regressão. A correção quebra outra proteção, ou uma versão futura reintroduz a falha. Um teste automatizado para o caso corrigido evita que o achado regresse.
• Alterar o âmbito para o achado desaparecer. Retirar um sistema do relatório não é corrigir, e o auditor nota-o pelo diagrama de rede.
• Corrigir sem registar. Sem ticket, commit ou changelog, a equipa não consegue explicar o que mudou.

Com que frequência fazer um teste de intrusão

A regra de mercado, e o que o PCI DSS e a maioria dos auditores esperam, é pelo menos uma vez por ano e após qualquer alteração significativa: nova funcionalidade crítica, migração de cloud, mudança de fornecedor de autenticação, integração com terceiros, alteração de arquitetura. Para entidades abrangidas pelo DORA ou pela NIS2, a periodicidade exigida vem do texto aplicável; confirme-a e trate o anual como um mínimo, não como um teto.

Se vende a clientes empresariais, o relatório tem de ser recente. Um teste de 2023 apresentado em 2026 depois de duas migrações costuma ser recusado.

Uma cadência baseada no risco costuma funcionar melhor do que uma data fixa no calendário:

Situação	Cadência sugerida
Base	Teste completo anual, com reteste após as correções
Alteração significativa (autenticação, pagamentos, exposição de dados, nova arquitetura)	Teste focado na alteração, antes ou logo após o lançamento
Ativos de risco elevado (APIs públicas, ambiente de cartões, dados sensíveis)	Ciclos mais curtos, definidos pela análise de risco da organização
Entre testes	Análise contínua e testes automatizados em CI para detetar regressões

Ferramentas automatizadas no pipeline complementam o teste de intrusão, mas não o substituem. Encontram rapidamente classes conhecidas de falhas; o teste manual encontra falhas de lógica de negócio e encadeamentos que nenhum scanner vê. A diferença está em Scanner, pentest ou bug bounty.

O que perguntar ao fornecedor

Antes de assinar, obtenha por escrito:

• O reteste está incluído no preço ou é faturado à parte?
• Quantas rondas de reteste estão incluídas? Uma costuma bastar se as correções forem bem feitas; duas dão margem real.
• Qual é a janela para pedir o reteste e o que acontece depois de ela fechar?
• O relatório final é atualizado com o estado de cada achado, ou o reteste vem em documento separado?
• O reteste é feito em produção e entrega evidência nova para cada achado?
• Quem o executa: a mesma equipa do teste original?
• Como são tratados os achados que a correção deixou parcialmente em aberto?

O que faz variar o custo de um reteste é, em regra, o número de achados, a dificuldade de reproduzir cada um e o número de rondas, e não um valor fixo universal. Por isso compensa pedir a política por escrito em vez de comparar apenas o preço do teste inicial. Mais perguntas para comparar propostas estão em 10 perguntas a fazer antes de contratar um pentest, e o efeito do reteste no preço em Quanto custa um teste de intrusão.

Como a Pentest Machine trata o reteste

O reteste está incluído nos nossos pacotes. Cada achado regressa com estado e evidência nova, e o relatório final é atualizado para refletir o estado após a correção. Se a sua auditoria ou supervisão está no calendário, o ideal é fechar âmbito e janela de reteste antes de o teste começar. Peça um orçamento e indique o seu prazo de conformidade.

Perguntas frequentes

Um reteste é o mesmo que um novo teste de intrusão?

Não. O reteste verifica apenas os achados já reportados, com o mesmo método. Um novo teste procura falhas novas em todo o âmbito. Complementam-se: o teste descobre, o reteste prova a correção.

Quanto tempo depois da correção devo fazer o reteste?

Logo que as correções estejam em produção. Acorde com o fornecedor uma janela de pedido para não perder o prazo e agrupe as correções em lotes para reduzir o número de rondas.

Quantas rondas de reteste preciso?

Depende do número de achados e da qualidade das correções. Pergunte quantas rondas estão incluídas e o que acontece se uma correção falhar. Uma ronda costuma bastar para correções bem feitas; uma segunda dá margem para ajustes.

Um WAF chega para considerar o achado corrigido?

Em regra, não. O WAF mitiga, mas a vulnerabilidade continua na aplicação. O relatório deve registá-lo como mitigação, não como correção, e o achado fica em aberto até a causa ser tratada.

Posso fazer o reteste com a minha equipa interna?

Pode, como verificação prévia. Para auditoria e conformidade, porém, o que conta é o reteste executado por quem fez o teste original ou por um terceiro independente, com evidência documentada. Quem corrigiu não deve ser o único a validar.

O que acontece a um achado que a organização decide não corrigir?

Passa a risco aceite, com justificação, controlo compensatório, aprovação formal da gestão e data de revisão. O reteste regista esse estado em vez de fingir que o achado foi resolvido.

Com que frequência devo fazer um teste de intrusão?

Pelo menos uma vez por ano e após alterações significativas na aplicação ou na infraestrutura, com reteste após cada ronda de correções. Os ambientes regulados devem confirmar a periodicidade no texto aplicável.