Sua fintech faz deploy toda semana. Talvez todo dia. Na maioria das empresas, o pentest (também conhecido como teste de intrusão) acontece uma vez por ano.
A conta não fecha.
A Resolução BCB 538, do Banco Central do Brasil, publicada em dezembro de 2025, passou a exigir que instituições de pagamento façam testes de intrusão anuais com profissionais independentes. Isso é o mínimo exigido, não o ideal. Um teste anual não garante que o código que foi para produção ontem passou por um teste de segurança.
O pentest contínuo é uma abordagem de testes de intrusão recorrentes, orientados pelas mudanças no produto e pelos riscos de cada entrega. Em vez de avaliar a segurança apenas em datas específicas, os testes acompanham a evolução da aplicação.
Neste artigo, mostramos a diferença prática entre os dois modelos e por que o contínuo contribui para amadurecer a segurança, tanto do produto quanto do time que desenvolve.
Por que o pentest anual não acompanha os ciclos de deploy?
Um pentest tradicional avalia a aplicação em um momento específico. Tudo que muda depois fica de fora. Isso funciona para um produto que evolui devagar. Fintech não é esse produto.
Pense no cenário. O pentest acontece em março. Em abril, o time lança um novo fluxo de saque via Pix. Em junho, muda a autenticação. Em agosto, integra um parceiro de cartão. Nenhuma dessas mudanças passa por um teste de segurança até o março seguinte.
Qualquer falha introduzida nesse intervalo fica exposta por meses. E as falhas que mais doem em fintech são justamente as mais difíceis de detectar:
- IDOR (Insecure Direct Object Reference, ou referência direta insegura a objeto) em extrato ou comprovante: trocar o identificador (ID) da transação na requisição e ver a de outro cliente.
- Race condition (condição de corrida) em saque ou transferência: duas requisições simultâneas passam pela mesma checagem de saldo e o dinheiro sai duas vezes.
- Manipulação de limite: o limite diário é validado só na interface do app (o front-end), ou o valor é alterado no conteúdo da requisição (o payload) depois da validação.
- Webhook sem validação de origem: o webhook é a notificação automática que o provedor de pagamento envia avisando que uma cobrança foi paga. Se a origem não é validada, alguém forja o "pago" e o crédito é liberado.
São falhas de lógica de negócio: o sistema faz exatamente o que foi programado, só que o programado permite abuso. Ferramentas automatizadas dificilmente pegam esse tipo de falha. Um especialista, sim.
Pentest tradicional vs. pentest contínuo: quais são as diferenças?
Periodicidade
- Pentest tradicional: segue um calendário, geralmente anual ou semestral.
- Pentest contínuo: acompanha cada release (nova versão) ou pacote relevante de entregas.
Escopo
- Pentest tradicional: avalia a aplicação inteira de uma vez.
- Pentest contínuo: concentra os testes no que mudou e no reteste de achados anteriores.
Abordagem
- Pentest tradicional: geralmente black box (sem acesso interno) ou gray box (com logins de usuário).
- Pentest contínuo: white box (com acesso ao código-fonte, às mudanças da versão e à arquitetura), a abordagem mais recomendada, ou gray box.
Janela de exposição
- Pentest tradicional: até 12 meses.
- Pentest contínuo: um ciclo de release.
Conhecimento do produto
- Pentest tradicional: recomeça quase do zero a cada teste.
- Pentest contínuo: acumula conhecimento a cada ciclo.
Entrega
- Pentest tradicional: relatório ao final do projeto.
- Pentest contínuo: achados na fila de tarefas do time (o backlog), com dono e prazo.
Reteste
- Pentest tradicional: pontual, depois das correções.
- Pentest contínuo: faz parte do ciclo, antes de fechá-lo.
Um modelo não exclui o outro. O teste amplo anual continua útil para ter visão geral, atender à conformidade e testar de fato o cenário de um atacante externo. O contínuo cobre o intervalo entre um teste e outro, que é onde nasce a maior parte do código novo.
Como funciona o pentest contínuo na prática?
Nos nossos clientes, o ciclo tem cinco passos:
- Organização por entrega. Cada release ou pacote grande abre um ciclo de teste. Exemplos: uma funcionalidade nova de pagamento, uma mudança em autenticação, uma integração com parceiro.
- Leitura do que mudou. Com acesso ao código e à comparação entre a versão nova e a anterior (o diff), o pentester vai direto aonde o risco mudou e não gasta dias reconhecendo um ambiente que já conhece.
- Teste manual direcionado. O foco está nos fluxos alterados, na lógica de negócio e na autorização. Também refazemos os testes de tudo que já foi encontrado antes.
- Achado crítico vira alerta. Avisamos o time na hora, sem esperar o relatório final, para que o risco seja mitigado o quanto antes. Os demais achados entram no backlog com evidência, contexto e recomendação.
- Reteste e fechamento. Validamos a correção e encerramos o ciclo. O próximo começa na próxima entrega.
O white box faz muita diferença aqui. Lendo o código, gaps de segurança são identificados com muito mais facilidade, inclusive os invisíveis de fora: uma checagem de autorização ausente, um log gravando dados sensíveis em texto plano, uma criptografia fraca. Num teste externo, essas falhas podem levar dias para aparecer, ou nunca aparecer.
O que pentest contínuo não é
- Não é ferramenta rodando no pipeline. A esteira automática que compila e testa o código a cada mudança (o CI, de Continuous Integration) deve ter suas ferramentas: SAST (análise do código-fonte), DAST (testes automatizados na aplicação em execução) e SCA (verificação das bibliotecas de terceiros). Elas são essenciais e pegam padrões conhecidos: código inseguro, configurações erradas, bibliotecas com vulnerabilidades já publicadas, senhas e chaves esquecidas no código etc. Lógica de negócio exige alguém pensando como atacante.
- Não é testar tudo a cada deploy. É testar o que importa: mudanças que mexem com dinheiro, dados sensíveis, autenticação, controle de acesso, integrações com parceiros etc., ou seja, o que de fato pode impactar o negócio.
O que muda na maturidade
No produto
O tempo entre uma falha entrar em produção e ser encontrada cai de meses para um ciclo. A cobertura também é cumulativa. A cada rodada, o pentester entende melhor o domínio, os fluxos de dinheiro e as regras de negócio, e assim consegue aprofundar testes direcionados. Se uma vulnerabilidade corrigida volta três releases depois, o ciclo seguinte pega.
No time que desenvolve
Esse é o ganho mais subestimado.
Se o achado chega poucas semanas depois de o código ser escrito, o desenvolvedor ainda lembra por que fez daquele jeito, e a correção é rápida. Se chega onze meses depois, o autor pode nem estar mais na empresa.
Os achados também seguem padrões. O mesmo tipo de IDOR aparecendo em três ciclos não é um bug isolado, é um gap de conhecimento. Esse gap vira treinamento focado, um item no checklist de revisão de código ou uma regra no SAST. Assim a classe de vulnerabilidade para de aparecer, e o time passa a escrever código mais seguro por conta própria.
Vimos isso acontecer num cliente: nos primeiros ciclos, IDOR aparecia em quase toda release. Seis meses depois, deixou de aparecer.
Em outro cliente, depois de cerca de um ano nesse modelo, a maioria dos ciclos termina com uma ou duas vulnerabilidades de criticidade média ou baixa, e alguns terminam sem nenhuma. Faz meses que nenhum teste encontra uma falha crítica.
O pentest deixa de ser auditoria e passa a ser feedback.
No negócio
Fintech vive de confiança: a do cliente, a do parceiro bancário, a do investidor e a do regulador. O modelo contínuo gera evidência recorrente de que os controles funcionam na prática, e não só no papel. Isso pesa em auditoria e em due diligence (a avaliação que investidores e parceiros fazem antes de fechar negócio). E é exatamente para essa direção que a regulação aponta.
Como saber se está funcionando
Quatro indicadores bastam:
- Tempo de correção por severidade: quanto tempo um achado crítico ou alto fica aberto.
- Reincidência por categoria: se a mesma categoria de vulnerabilidade continua aparecendo.
- Críticos e altos por release: a curva precisa cair ao longo dos ciclos.
- Onde o achado aparece: quanto mais deles surgem em homologação (o ambiente de testes), antes do deploy, melhor.
Conclusão
Em fintech, velocidade de deploy é vantagem competitiva, mas cada release também cria novos pontos por onde um atacante pode tentar entrar. O pentest anual mostra como estava a segurança da aplicação no momento do teste. O contínuo acompanha as mudanças e ajuda o time a evoluir a cada ciclo.
E esse cenário não é exclusivo das fintechs. Empresas de tecnologia, plataformas SaaS, varejistas digitais e e-commerces também lançam funcionalidades, integram sistemas e alteram fluxos críticos constantemente. Quando a segurança não acompanha esse ritmo, novas vulnerabilidades podem permanecer expostas até o próximo teste.
Se sua empresa entrega novas versões com frequência, mas ainda depende de testes pontuais, vale repensar essa abordagem. Converse com o time da Taura e entenda como incorporar o pentest contínuo ao ciclo de desenvolvimento.
