O software muda continuamente, a validação de segurança não. Isso está criando uma lacuna tão grande que, em setores regulamentados como o bancário, os ciclos de lançamento frequentemente desaceleram não porque a engenharia não consiga avançar mais rápido, mas porque a validação não consegue acompanhar.
No geral, a indústria concorda que o snapshot testing não é suficiente; nossa pesquisa com 200 CISOs e 200 líderes de engenharia descobriu que 79% estão preocupados que problemas passem despercebidos entre os testes de penetração agendados, enquanto 85% dizem que as descobertas estão desatualizadas pelo menos às vezes. Mas ninguém (pelo menos até agora) consegue concordar sobre como o pentest contínuo o substitui na prática.
O que significa pentest contínuo?
Em um tópico recente no Reddit, alguém fez uma pergunta aparentemente direta:
“Alguém está realmente fazendo pentest contínuo em vez de auditorias anuais?”
Ninguém concordou sobre o que “pentest contínuo” realmente significava. Em um único tópico, o pentest contínuo alternou entre significar “varredura automatizada glorificada” e testes manuais completos realizados com mais regularidade. Outras definições incluíam engajamentos regulatórios demorados ou testes por lançamento focados em mudanças. Havia também vários comentaristas insatisfeitos que claramente haviam sido prejudicados por empresas que comercializaram um produto verdadeiramente contínuo, apenas para oferecer algo completamente diferente.
Antes de entrarmos nisso, vamos concordar com a definição que usaremos para pentest neste artigo. Executar varreduras de vulnerabilidades em cada lançamento não é pentest. Testes ofensivos reais exigem raciocínio sobre o comportamento da aplicação, exploração de fluxos de trabalho autenticados, encadeamento de caminhos de ataque e validação da explorabilidade por meio de ataques reais. O pentest contínuo só faz sentido se o próprio teste for significativo.
Onde o pentest humano para de escalar
O instinto correto é que o pentest contínuo deve acompanhar as mudanças. Quando algo muda, valide-o. Isso é frequentemente chamado de “delta testing”.
Mas o contraponto a isso, como o tópico acima aponta, é que nem toda mudança justifica testes, e pode ser difícil decidir quais mudanças importam, como precificar adequadamente, como melhor utilizar as pessoas para estarem disponíveis “sob demanda” e como garantir que você não esteja apenas testando ruído.
Pentesters ou equipes de red team possuem criatividade e julgamento que as ferramentas de pentest podem não ter, mas eles lidam com uma situação difícil, que está ficando ainda mais complicada. O fator limitante não é a qualidade deles, é que eles não conseguem aplicar esse raciocínio em larga escala e na velocidade em que a superfície de ataque está mudando.
Eles são limitados por horas, precisam reconstruir o contexto do sistema toda vez que o testam, e isso sem considerar o planejamento, a coordenação e os relatórios exigidos para cada pentest.
Este é o ponto; um modelo construído apenas na coordenação humana não consegue escalar com a velocidade atual de deployment. É aqui que o pentest contínuo de IA pode ajudá-los.
Mas mesmo com IA, existem nuances. Contínuo não significa testar tudo o tempo todo – isso seria um enorme desperdício de recursos. Só porque você pode, não significa que você deve. O pentest contínuo de IA pode determinar se uma mudança afeta significativamente a superfície de ataque ou a postura de segurança, e só iniciar testes quando isso ocorrer.
O tradeoff forçado entre cobertura e profundidade
Um dos maiores dilemas para testadores experientes é decidir o quanto focar na amplitude versus profundidade. Se eles tentam cobrir uma grande superfície rapidamente, eles se concentram em classes de vulnerabilidades comuns e padrões de ataque conhecidos. Eles podem encontrar vários problemas, mas terão menos tempo para aprofundar em outras interações, onde problemas de maior gravidade podem estar à espreita. Por outro lado, se eles se aprofundam, focando em caminhos de ataque complexos e encadeando comportamentos em toda a aplicação, eles inevitavelmente cobrem menos do sistema como um todo.
Sistemas modernos agravam esse problema porque são maiores, mais interconectados e atualizados com mais frequência.
É por isso que vulnerabilidades mais profundas, como falhas de lógica, controle de acesso quebrado ou cadeias de exploração multi-etapas, são notoriamente difíceis de serem detectadas de forma consistente. Em nossa pesquisa, mais da metade dos líderes de segurança e engenharia dizem que falhas de lógica mais profundas e vulnerabilidades multi-etapas são frequentemente perdidas em engajamentos de pentest tradicionais.
Isso não é uma crítica à capacidade dos pentesters; é um reflexo das restrições sob as quais eles operam.
Mas também reforça a mesma conclusão: a validação contínua não se trata apenas de testar com mais frequência. Trata-se de obter a cobertura certa ao fazê-lo.
O pentest contínuo pode cuidar do desvio da superfície de ataque para que equipes ofensivas experientes possam se concentrar nos ativos mais críticos.
O pentest contínuo tem um problema de arquitetura
Muitas ferramentas focam no pentest automatizado e na geração de ataques. O verdadeiro desafio para o pentest contínuo é construir um sistema capaz de executar testes ofensivos continuamente contra uma aplicação em constante mudança.
Em primeiro lugar, a arquitetura deve permitir contexto de sistema suficiente. Isso significa visibilidade da arquitetura da aplicação, APIs, código-fonte e configuração da infraestrutura, para que caminhos de ataque realistas possam ser explorados. Se uma ferramenta vê apenas endpoints expostos, ela perderá caminhos de ataque que passam pela comunicação interna de serviços.
Em segundo lugar, o sistema precisa entender quando os testes devem ser executados. Isso significa detectar mudanças que realmente afetam a superfície de ataque e acionar os testes quando elas ocorrem. Sem isso, o teste “contínuo” ou é executado constantemente e desperdiça recursos, ou retorna a varreduras agendadas que perdem as mudanças que introduzem risco.
Terceiro, aplicações modernas envolvem milhares de interações entre funções, endpoints e serviços. Esses caminhos precisam ser explorados em paralelo, e não um de cada vez. Um sistema que testa sequencialmente nunca terminará de validar uma aplicação moderna antes do próximo deployment, então componentes importantes ficarão sem teste.
Quarto, os achados devem ser validados por meio de exploração real para garantir que os resultados reflitam vulnerabilidades que são realmente alcançáveis e reproduzíveis; as equipes já lidam com muitos falsos positivos, não precisam de mais.
Quinto, o sistema precisa fechar o ciclo. A descoberta contínua só importa se as vulnerabilidades puderem ser corrigidas e verificadas com a mesma rapidez. Isso significa gerar orientações de remediação, validar as correções uma vez aplicadas e retestar o sistema para garantir que o problema foi realmente resolvido.
E, finalmente, o sistema deve impor limites de execução rigorosos, garantindo que os testes permaneçam dentro do escopo e não possam impactar sistemas não relacionados (veja nosso artigo sobre como garantimos que nossos agentes de pentest de IA não saiam do escopo).
Sem nenhum dos pontos acima, o pentest contínuo se torna pouco mais do que uma varredura automatizada.
O modelo está mudando
A indústria não está confusa sobre se o pentesting precisa evoluir. Mas está um pouco incerto sobre qual é o novo modelo. A hesitação é compreensível. O pentesting tradicional ainda funciona, apenas não foi construído para softwares que mudam constantemente.
Sabemos que executar scanners com mais frequência não resolve o problema. Agendar mais pentests também não. A validação precisa mudar com a mesma frequência que o software.
Mas ele precisa testar as coisas certas quando elas mudam, manter a profundidade esperada de um trabalho ofensivo real e garantir que a superfície de ataque não se desvie silenciosamente entre as avaliações.
Quando isso acontece, as equipes de red team podem se concentrar no trabalho que exige sua expertise: caminhos de ataque complexos, fraquezas sistêmicas e os ativos mais críticos.
O pentest contínuo não substitui as equipes ofensivas, ele lhes dá a cobertura que nunca tiveram.
Quer ver como o pentest contínuo funciona na prática?
Aikido Infinite testa cada mudança significativa em sua aplicação, explora caminhos de ataque reais, valida a explorabilidade e verifica as correções antes que o código chegue à produção.
Comece o pentesting em 5 minutos ou agende uma demonstração para ver como o pentest contínuo realmente funciona.
