A próxima era de AppSec: por que o código gerado por IA precisa de testes dinâmicos ofensivos

Meu colega Manoj Nair escreveu recentemente sobre a crescente diferença entre o que a IA desenvolve e o que as equipes de segurança realmente testam. Ele argumentou que o ritmo do desenvolvimento orientado por IA superou de vez a capacidade de validação, e que a resposta não pode ser desacelerar, mas mudar o significado de testar. Concordo com cada palavra.

Quero aprofundar um pouco mais o assunto. Passei boa parte da última década desenvolvendo mecanismos de testes dinâmicos de segurança. Primeiro na Probely, empresa que cofundiei, e agora na Snyk, onde nossa tecnologia alimenta o Snyk API & Web. Por isso, quando digo que está prestes a mudar tudo o que esse setor pensa sobre testes dinâmicos de segurança, não estou fazendo uma previsão de mercado. Estou descrevendo o que vejo acontecer nas arquiteturas que testamos todos os dias.

A análise de código ficou muito mais inteligente. Mas ainda não é suficiente.

Vamos começar reconhecendo o que merece reconhecimento: a análise estática avançou muito.

Durante anos, essa categoria ficou presa a uma era de correspondência rígida e ruidosa de padrões, com mecanismos baseados em regras que geravam um enorme volume de descobertas, mas poucos resultados úteis.

Depois veio uma primeira onda de aprendizado de máquina e IA simbólica, capaz de rastrear fluxos de dados mais profundos em bases de código: mecanismos como o Snyk Code, baseado no DeepCode AI, que trouxe uma compreensão semântica real para a análise estática.

Agora, estamos vendo surgir uma capacidade realmente diferente: ferramentas agentivas que usam raciocínio semântico para entender a intenção real do código, não apenas sua sintaxe. Esses modelos conseguem sinalizar falhas complexas de lógica de negócios e problemas de autorização diretamente no código-fonte, de formas que seriam inimagináveis há cinco anos.

Esse é um avanço real e significativo. Ele foi tão grande que ainda não se sabe se o setor continuará chamando essa categoria de “SAST” ou se criará um termo totalmente novo.

Mas o ponto é: até o mecanismo de análise de código mais avançado tem um limite: não consegue testar o que não pode executar.

As aplicações modernas não são monolíticas; são ambientes altamente distribuídos, compostos e multicamadas: aplicações de página única que se comunicam com dezenas de microsserviços de backend, cada um com seu próprio contexto de autenticação, padrões de acesso a dados e ciclo de implantação. Um scanner de código sofisticado pode sinalizar com sucesso uma falha de autorização na base de código de um microsserviço. Mas e se a vulnerabilidade só aparecer quando vários componentes interagirem?

Pense em uma situação real: um problema de autorização que só aparece por causa da forma como uma aplicação frontend lida com um token, combinada com a maneira como um gateway de API encaminha a solicitação e como um serviço secundário de backend interpreta a função do usuário. Nenhuma base de código contém a vulnerabilidade. Ela surge da interação entre os componentes. Por mais inteligente que seja, a análise estática tem dificuldade para lidar com estados entre componentes e bases de código, porque fundamentalmente não consegue observar o sistema como um todo.

É exatamente isso que os testes dinâmicos de segurança podem fazer. Eles validam se um invasor consegue realmente explorar um sistema quando todos esses componentes distintos são integrados em um ambiente ativo.

Esse ponto cego da execução se estende diretamente à fronteira descrita por Manoj: agentes de IA que chamam APIs de forma autônoma e em grande escala, de maneiras que seus criadores nunca previram. Riscos como injeção de prompt, desvio de objetivos e envenenamento de contexto não existem no código-fonte. São comportamentos emergentes que só acontecem durante a execução. Assim como as interações complexas entre microsserviços, essas ameaças só podem ser validadas interagindo dinamicamente com o sistema ativo.

A convergência que ninguém está nomeando

Há outra mudança acontecendo no mercado que, na minha opinião, merece mais atenção.

No último ano, surgiu um novo rótulo: “pentester de IA”. E esse rótulo representa algo real, pois essas ferramentas marcam uma verdadeira mudança de abordagem. Em vez de um scanner rígido que envia payloads estáticos a cada entrada identificada, essa nova geração de ferramentas consegue raciocinar sobre o estado da aplicação e decidir os próximos passos com base no contexto, de maneira semelhante à de um pesquisador de segurança humano.

Mas eis o que observei e onde, na minha opinião, o mercado está se equivocando: essas abordagens são fundamentalmente complementares, não concorrentes.

Recentemente, testamos uma aplicação intencionalmente vulnerável usando tanto um mecanismo tradicional de testes dinâmicos de segurança quanto uma abordagem autônoma de pentest orientada por IA. E os resultados foram reveladores.

O mecanismo de testes dinâmicos de segurança encontrou vulnerabilidades que a abordagem orientada por IA não detectou, simplesmente porque os mecanismos tradicionais são feitos para testar tudo de forma incansável e sistemática: eles verificam metodicamente cada parâmetro, cada endpoint e cada caso-limite.

Enquanto isso, a abordagem orientada por IA encontrou falhas complexas de lógica que o mecanismo tradicional não conseguiu compreender, pois era capaz de raciocinar sobre cadeias de autorização e lógica de negócios de maneiras que um scanner determinístico nunca conseguiria.

Nenhuma das abordagens foi suficiente por si só. Juntas, elas ofereceram uma visão muito mais completa.

Isso me mostra que o setor está claramente caminhando para uma convergência. O futuro produto dessa categoria provavelmente combinará as duas capacidades: um modo exaustivo para cobertura abrangente dos pipelines (o que as organizações precisam para garantir segurança continuamente) e um modo direcionado e orientado pelo contexto para explorar falhas de lógica em profundidade (capaz de encontrar problemas de autorização e vulnerabilidades encadeadas que o código gerado por IA introduz em grande escala).

Ainda não se sabe qual será o nome: o mercado continuará usando “DAST”, adotará “pentest com IA” ou inventará algo totalmente novo. Mas a convergência em si parece inevitável.

Para onde estamos caminhando

Se eu tivesse que descrever a mudança arquitetônica mais importante no horizonte, diria que a inteligência no nível do código e os testes dinâmicos de segurança estão se integrando profundamente.

Durante a maior parte de sua história, os testes dinâmicos de segurança funcionaram como uma caixa-preta, sem conhecimento do código-fonte nem compreensão da lógica interna da aplicação. Eles investigavam o sistema externamente e relatavam o que encontravam. Essa era tanto sua força (testavam a realidade, não a teoria) quanto sua limitação (não enxergavam o contexto que poderia torná-los muito mais eficazes).

Isso está mudando. À medida que as plataformas amadurecem, a evolução natural aponta para o que pesquisadores de segurança sempre chamaram de testes “grey-box”: uma abordagem que interage com a aplicação ativa e compreende o código-fonte subjacente. Em uma direção, a análise no nível do código pode levantar hipóteses sobre endpoints ocultos ou falhas de lógica, que os testes dinâmicos de segurança podem então confirmar (ou refutar) no ambiente ativo. Na outra direção — mais próxima da forma como hackers humanos de elite realmente atuam —, os testes dinâmicos de segurança podem observar comportamentos suspeitos em aplicações ou APIs ativas e, em seguida, usar o contexto do código para entender exatamente como uma proteção foi implementada, criando o payload preciso em vez de recorrer à força bruta.

Isso também começa a resolver um dos maiores pontos de atrito históricos dos testes dinâmicos de segurança: a correção. Uma ferramenta dinâmica sempre pôde comprovar a existência de uma exploração mostrando a solicitação e a resposta HTTP maliciosas, além das evidências da exploração. Mas deixava o desenvolvedor tentando adivinhar em que ponto da base de código a falha realmente se originava. Quando as evidências dinâmicas e o contexto no nível do código são correlacionados, você obtém algo muito mais poderoso: uma descoberta que comprova a possibilidade de exploração durante a execução e aponta diretamente para o código que precisa ser corrigido.

Essa é a evolução que vale a pena acompanhar. Não porque algum fornecedor já tenha concretizado tudo isso (embora nós tenhamos), mas porque as condições arquitetônicas necessárias estão se estabelecendo. As equipes que reconhecerem essa convergência primeiro criarão os programas de segurança mais sólidos.

A convicção de quem constrói

Vou concluir com algo em que acredito cada vez mais a cada arquitetura que testamos.

Está ficando para trás a era em que os testes dinâmicos de segurança eram tratados como uma exigência de conformidade: scanners lentos e ruidosos, executados trimestralmente, cujos resultados eram arquivados. Não porque a ideia estivesse errada, mas porque o mundo ao redor mudou.

O código gerado por IA é lançado mais rápido do que qualquer processo humano foi projetado para revisar, e agentes de IA chamam APIs mais rápido do que qualquer inventário foi projetado para acompanhar. Além disso, as vulnerabilidades introduzidas por essas forças — como falhas de autorização, falhas de lógica de negócios e problemas de estado entre componentes — são justamente as que só os testes dinâmicos de segurança conseguem comprovar de forma definitiva.

O que está surgindo não substitui a análise de código: é a outra metade da equação. A análise de código indica o que pode estar vulnerável, mas os testes dinâmicos de segurança revelam o que pode ser explorado. Quando esses dois sinais se encontram, o ruído diminui e o sinal fica mais nítido... os desenvolvedores podem lançar com confiança, em vez de ansiedade.

Se você está criando um programa de segurança para a era da IA, vale a pena investir nessa confiança.