# Pentest (teste de invasão): quando fazer e o que esperar

> Quando fazer um teste de invasão (pentest), qual tipo escolher, como montar o escopo e o que fazer com o relatório para o teste virar correção, não só PDF.

Fonte: https://pervian.tech/blog/pentest-quando-contratar · Pervian Tech · publicado em 2026-10-01

O pedido costuma chegar de fora. Um cliente grande manda um questionário de segurança com a pergunta "a aplicação passou por teste de invasão nos últimos doze meses?". Um parceiro de integração exige o relatório antes de liberar o acesso à API. Ou, pior, alguém encontrou um dado de cliente onde não deveria estar e a diretoria quer saber o tamanho do buraco.

A empresa contrata um pentest às pressas, recebe um PDF de muitas páginas cheio de termos em inglês, encaminha para a equipe de desenvolvimento e o documento fica parado numa pasta. Seis meses depois, o próximo teste encontra as mesmas falhas. O dinheiro foi gasto, o risco continua o mesmo.

Em resumo: faça um pentest antes de colocar no ar um sistema que guarda dados de clientes ou dinheiro, depois de mudanças grandes, quando um cliente ou parceiro exigir e após um incidente, e repita o teste em ciclos regulares enquanto o sistema continuar mudando. Abaixo está o que um teste de invasão realmente faz, quais tipos existem, **quando faz sentido contratar** e como preparar o escopo e tratar o relatório para que o resultado seja correção, e não papel.

## Quando fazer um pentest: a resposta curta

Um teste de invasão vale a pena quando pelo menos uma destas situações é verdadeira:

- **Um sistema novo vai para produção** e vai expor dados de clientes, pagamentos ou acesso a operações críticas.
- **Uma mudança grande aconteceu**: nova API aberta a parceiros, novo módulo de pagamento, troca de autenticação, migração para a nuvem.
- **Um cliente, parceiro ou contrato exige** evidência de teste independente.
- **Houve um incidente** ou suspeita de acesso indevido e é preciso saber o que mais está exposto.
- **Faz mais de um ano** desde o último teste e o sistema mudou bastante nesse período.

E ele **não** é a primeira coisa a fazer quando o básico ainda não existe. Se a aplicação não tem controle de acesso por perfil, roda com bibliotecas desatualizadas e não tem registro de quem fez o quê, o pentest vai encontrar o óbvio. É mais barato arrumar o óbvio antes e usar o teste para achar o que a equipe não consegue ver sozinha.

## O que um teste de invasão realmente faz

Um pentest é uma tentativa autorizada e controlada de invadir o sistema, feita por especialistas que pensam como um atacante. O objetivo não é listar todo problema teórico, mas responder a uma pergunta prática: **o que alguém mal-intencionado conseguiria fazer com o que está exposto hoje?**

Na prática, o testador:

1. **Reconhece o alvo**: quais endereços, telas, APIs e funcionalidades existem.
2. **Procura pontos fracos**: autenticação frágil, permissões mal verificadas, entradas que aceitam qualquer coisa, configurações expostas.
3. **Tenta explorar**: mostra que a falha é real, por exemplo acessando o pedido de outro cliente trocando um número na URL.
4. **Documenta**: descreve cada achado, como reproduzir, o impacto e a recomendação de correção.

A diferença para uma **varredura automática de vulnerabilidades** é importante. A ferramenta automática encontra versões desatualizadas e configurações conhecidas. Ela não entende que o vendedor da filial de Campinas não deveria ver a carteira de clientes da filial de Curitiba. Falhas de regra de negócio e de autorização, que estão entre as mais graves em sistemas de gestão, quase sempre só aparecem com alguém testando à mão.

## Caixa preta, cinza e branca

O tipo de teste define quanta informação o testador recebe antes de começar. Cada um responde a uma pergunta diferente.

| Tipo | O que o testador recebe | Responde a | Bom para |
|---|---|---|---|
| Caixa preta | Só o endereço do sistema | O que um estranho na internet consegue fazer? | Sites e portais públicos, visão de atacante externo |
| Caixa cinza | Usuários de teste com perfis diferentes e alguma documentação | O que um cliente, fornecedor ou funcionário consegue fazer além do permitido? | Sistemas de gestão, portais de cliente, apps com login |
| Caixa branca | Acesso ao código, arquitetura e configurações | Onde estão as falhas, inclusive as difíceis de alcançar de fora? | Sistemas críticos, antes de lançamento, após incidente |

- **Caixa preta parece mais realista, mas costuma render menos.** Boa parte do tempo vai em descobrir o que poderia ter sido informado. Um atacante real pode ter meses; o testador tem dias.
- **Caixa cinza é o ponto de partida para a maioria das empresas.** Quase todo sistema de gestão tem login, e o risco maior está no que um usuário autenticado consegue fazer além do seu perfil.
- **Caixa branca encontra mais com o mesmo esforço**, porque o testador não precisa adivinhar como as coisas funcionam. Faz sentido quando o sistema é crítico ou quando a empresa quer aproveitar o teste para melhorar o código.

## Quando contratar: lançamentos, clientes exigentes, incidentes

### Antes de um lançamento

O melhor momento é quando o sistema está estável, num ambiente igual ao de produção, mas ainda há tempo para corrigir antes de abrir para o público. Testar uma semana antes do lançamento, sem folga na agenda, garante que as falhas graves vão para produção junto com o sistema.

Reserve na agenda tempo para o teste, a correção e o reteste.

### Quando um cliente ou parceiro exige

Empresas maiores, bancos, operadoras de saúde e plataformas de pagamento costumam pedir evidência de teste independente antes de fechar contrato ou liberar integração. Antes de contratar, pergunte ao cliente **o que exatamente ele espera**: qual sistema, qual tipo de teste, se aceita um resumo executivo ou quer o relatório completo, e se exige reteste comprovando as correções. Isso evita pagar por um teste que não atende à exigência.

### Depois de um incidente

Se houve vazamento ou acesso indevido, o primeiro passo é [conter o problema e entender o que aconteceu](https://pervian.tech/blog/plano-de-resposta-a-incidentes), não contratar um pentest. Depois da contenção, o teste ajuda a responder se existem outras portas abertas parecidas com a que foi usada. Nesse momento, caixa branca costuma ser a melhor escolha, porque o tempo importa mais do que simular um atacante sem informação.

Incidentes com dados pessoais também têm obrigações próprias de comunicação previstas na LGPD. Essa parte deve ser conduzida com o jurídico e o encarregado de dados da empresa; o que o sistema precisa suportar para isso está em [LGPD no desenvolvimento de sistemas](https://pervian.tech/blog/lgpd-no-desenvolvimento-de-sistemas).

## Escopo: o que testar e o que deixar fora

Escopo mal definido faz o teste passar por tudo superficialmente ou deixar de fora justamente a parte que mais importa.

### Checklist para montar o escopo

- **Liste os sistemas e endereços** que entram no teste: site, painel administrativo, API, app.
- **Marque o que é mais sensível**: telas e rotas da API que mexem com dados pessoais, financeiro, pagamentos, emissão de documentos fiscais, cadastro de usuários e permissões.
- **Defina os perfis de usuário** que o testador vai receber: cliente, vendedor, gerente de filial, administrador. Cada perfil a mais permite testar se um consegue fazer o que é do outro.
- **Inclua as APIs**, não só as telas. Muitos sistemas protegem bem a interface e deixam a API aceitar qualquer requisição. Os erros mais frequentes nessa camada estão em [segurança de APIs: erros comuns](https://pervian.tech/blog/seguranca-de-apis-erros-comuns).
- **Escolha o ambiente**: homologação idêntica à produção é o mais seguro. Testar em produção é possível, mas exige combinar horários, limites e o que não pode ser feito.
- **Liste o que fica fora**: sistemas de terceiros que a empresa não controla (ERP em nuvem do fornecedor, gateway de pagamento), ataques de negação de serviço, engenharia social, se não forem o objetivo.
- **Combine as regras do jogo**: datas, horários, contatos de emergência, o que fazer se o testador encontrar algo crítico no meio do teste.

### Autorização por escrito

Sem autorização formal, um pentest não se distingue de uma invasão, inclusive perante a lei. O contrato precisa deixar claro quem autoriza, quais sistemas, em que período e com quais limites. Se parte da infraestrutura é de um provedor de nuvem ou de um fornecedor de software, confira se as regras desse terceiro permitem o teste e se é preciso avisá-lo.

## Lendo o relatório: severidades e prioridades

Um bom relatório tem duas partes: um **resumo executivo**, para a diretoria, e os **achados técnicos**, para a equipe que vai corrigir. Se o relatório só tem a segunda parte, peça a primeira.

Cada achado costuma vir com uma severidade. As escalas variam, mas em geral seguem esta lógica:

| Severidade | O que costuma significar | Exemplo típico |
|---|---|---|
| Crítica | Acesso amplo a dados ou controle do sistema, com pouca dificuldade | Ver e alterar pedidos de qualquer cliente trocando um identificador |
| Alta | Impacto sério, mas com alguma condição ou limite | Usuário comum consegue acessar função de administrador |
| Média | Impacto real, porém mais difícil de explorar ou mais restrito | Sessão que não expira depois de muito tempo parado |
| Baixa | Pouco impacto isolado, mas facilita outros ataques | Mensagem de erro que revela a versão do servidor |
| Informativa | Boa prática não seguida, sem risco direto demonstrado | Cabeçalho de segurança ausente |

### Severidade não é prioridade

A severidade do relatório é técnica. A prioridade é decisão do negócio, e considera o contexto que o testador não conhece:

- **O que está exposto**: uma falha média no portal de clientes, aberto a todos, pode ser mais urgente que uma alta num painel interno acessível só pela rede da empresa.
- **Quais dados estão envolvidos**: dados pessoais sensíveis, dados financeiros e credenciais pesam mais.
- **Esforço de correção**: algumas falhas se resolvem com uma configuração; outras exigem mudar a forma como o sistema verifica permissões em dezenas de telas.

Muitos achados graves em sistemas de gestão são de autorização: o sistema confere se o usuário está logado, mas não se ele pode ver aquele registro específico. Se o relatório aponta vários achados desse tipo, o problema é de desenho, e corrigir tela por tela não resolve. A forma de estruturar isso está em [controle de acesso e trilha de auditoria](https://pervian.tech/blog/controle-de-acesso-e-trilha-de-auditoria).

## Corrigir e retestar

O relatório só tem valor quando vira lista de trabalho:

1. **Reunião de leitura** com quem fez o teste, a equipe técnica e alguém do negócio.
2. **Transformar cada achado em tarefa** na mesma fila de trabalho das funcionalidades, com responsável e prazo proporcional à prioridade.
3. **Tratar a causa, não o sintoma.** Se a falha é "o pedido 123 aparece para outro cliente", a correção não é bloquear o pedido 123, é garantir que toda consulta filtre pelo dono do registro.
4. **Procurar o mesmo padrão em outras partes do sistema.** O testador encontrou a falha em uma tela; é provável que ela se repita em outras que ele não teve tempo de testar.
5. **Criar um [teste automatizado](https://pervian.tech/blog/testes-automatizados-para-gestores)** para cada falha corrigida, para que ela não volte numa versão futura.
6. **Pedir o reteste.** O testador verifica se as correções funcionam e emite uma confirmação. É isso que clientes e parceiros costumam querer ver.
7. **Registrar riscos aceitos.** Se a empresa decide não corrigir algo agora, a decisão fica escrita, com motivo e responsável.

Inclua o reteste na contratação desde o início. Sem ele, a empresa tem um documento dizendo que estava vulnerável e nenhum dizendo que deixou de estar.

## Segurança contínua além do pentest anual

Um pentest é uma fotografia do sistema nas datas do teste. Na semana seguinte, sai uma versão nova e a fotografia já está desatualizada.

Por isso o teste anual funciona melhor como **auditoria de um processo que já existe**, e não como o processo inteiro. O que deveria acontecer entre um teste e outro:

- **Atualização de dependências** com rotina definida, e alerta quando uma biblioteca usada recebe correção de segurança.
- **Análise automática no [processo de publicação](https://pervian.tech/blog/ci-cd-para-gestores)**: ferramentas que verificam código e dependências a cada versão, antes de ir para produção.
- **Revisão de código** com atenção a permissões e validação de entradas, principalmente em telas e APIs novas.
- **[Requisitos de segurança desde o desenho](https://pervian.tech/blog/desenvolvimento-seguro-o-que-exigir)**: quem pode ver, quem pode alterar, o que fica registrado. Corrigir no desenho é muito mais simples que corrigir depois de um pentest.
- **Registro e monitoramento**: registros de acesso e alertas para comportamento estranho, como um usuário consultando centenas de cadastros em minutos.
- **Teste focado a cada mudança grande**, sem esperar o ciclo anual.

Quando esse processo existe, o pentest encontra menos coisas, e as que encontra são as realmente difíceis.

## Erros comuns ao contratar um pentest

- **Não dar usuários de teste.** O testador passa o tempo tentando entrar, e a parte mais arriscada, o que acontece depois do login, fica sem teste.
- **Não planejar tempo de correção.** O teste termina, a agenda já está tomada por funcionalidades e as falhas ficam para depois.
- **Comprar varredura automática com nome de pentest.** Se a proposta não fala em testes manuais, perfis de usuário nem exploração dos achados, provavelmente é só uma ferramenta rodando sozinha. Pergunte como o teste é feito e peça um relatório de exemplo, com os dados de outro cliente ocultados.
- **Testar uma versão diferente da que vai para produção.** Se o ambiente de teste não reflete a configuração real, o relatório descreve outro sistema.
- **Confundir pentest com certificação.** Um teste sem achados graves mostra que, naquelas datas e naquele escopo, o testador não conseguiu explorar nada sério. Não garante que o sistema é invulnerável.

## Perguntas frequentes

### Quanto tempo dura um pentest?

Depende do escopo: número de sistemas, APIs e perfis de usuário a testar. O teste de invasão em si costuma levar de alguns dias a algumas semanas, mas a agenda precisa incluir também a correção dos achados e o reteste. Por isso, antes de um lançamento, o pentest deve acontecer com folga, não na última semana.

### Qual a diferença entre pentest e varredura de vulnerabilidades?

A varredura de vulnerabilidades é automática e encontra versões desatualizadas e configurações conhecidas. O pentest é feito por especialistas que tentam explorar as falhas à mão, inclusive de regra de negócio e de autorização, como um usuário vendo dados de outro cliente. Proposta que não fala em testes manuais nem em perfis de usuário provavelmente é só varredura.

### O pentest pode derrubar o sistema em produção?

Pode haver impacto, e por isso o teste de invasão costuma ser feito num ambiente de homologação idêntico à produção. Quando é preciso testar em produção, a empresa combina com o testador horários, limites, o que não pode ser feito e contatos de emergência, e ataques de negação de serviço ficam fora do escopo, salvo quando são o objetivo.

### O pentest é obrigatório pela LGPD?

A LGPD não cita o pentest pelo nome, mas exige que quem trata dados pessoais adote medidas de segurança técnicas e administrativas para protegê-los. O teste de invasão é uma das formas de demonstrar esse cuidado, e contratos com clientes ou parceiros podem exigi-lo. A necessidade no caso da sua empresa deve ser avaliada com o jurídico.

## Como a Pervian Tech trabalha segurança de aplicações

Na Pervian Tech, segurança entra como requisito desde o desenho, dentro do trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software): definimos perfis e regras de acesso, validação de entradas, registro de ações e rotina de atualização antes de escrever a primeira tela. Quando a empresa já tem um sistema em produção, começamos por um diagnóstico das áreas mais expostas e ajudamos a montar o escopo do teste de invasão.

Depois do teste, atuamos onde o PDF costuma parar: leitura do relatório em linguagem de negócio, priorização, correção da causa de cada achado, testes automatizados para que a falha não volte e acompanhamento até o reteste. Tudo é sob medida, porque o risco de cada sistema está em lugares diferentes.

O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se um cliente pediu um pentest ou você recebeu um relatório e não sabe por onde começar, [fale com a gente](https://pervian.tech/#contato). Mais conteúdo sobre o tema em [Segurança e LGPD](https://pervian.tech/blog/categoria/seguranca-e-lgpd).