Segurança ofensiva contínua: o caminho que temos percorrido

O pentest com IA está vivendo um momento.

Na verdade, vários momentos. A cada duas semanas, outro fornecedor anuncia uma novidade, ou outra ferramenta de pentest baseada em LLM lidera algum benchmark com um alvo do qual ninguém ouviu falar; mais uma apresentação afirma que um novo “padrão ouro” está sendo revolucionado, finalmente... Tem sido uma correria.

Por trás de todo esse ruído, porém, há um motivo real para isso estar acontecendo em todo lugar, ao mesmo tempo: a mesma capacidade de raciocínio que tornou o pentest com IA comercialmente viável agora está nas mãos dos invasores. Invasores autônomos já sondam as superfícies de aplicações continuamente, na velocidade das máquinas e em um ritmo que as equipes de defesa não conseguem acompanhar.

A corrida agora é para saber se os testes de segurança ofensiva encontram as falhas antes que a IA ofensiva de um invasor. Os anúncios dos fornecedores não são a verdadeira história: são apenas o mercado tentando acompanhar um problema que já chegou.

Trabalho há vários anos no Snyk API & Web, nosso produto de testes dinâmicos de segurança, e me sinto validado com o anúncio da Snyk de Segurança ofensiva contínua. Quero usar esta publicação para fazer mais do que simplesmente anunciá-la: quero explicar por que o caminho dos testes dinâmicos de segurança ao pentest com IA é algo que percorremos há anos e por que, na minha opinião sincera, quem tentar desenvolver o segundo sem uma base no primeiro vai atingir um limite rapidamente.

Detectáveis por heurísticas vs. dependentes de contexto

Esta é a distinção inicial, essencial para entender nosso argumento.

Vulnerabilidades detectáveis por heurísticas são aquelas que se revelam para ferramentas determinísticas. O SAST identifica padrões no próprio código-fonte, enquanto o DAST segue outra abordagem: envia payloads a uma aplicação ou API em execução e observa as respostas — mensagens de erro, atrasos, diferenças de comportamento e coisas do tipo. Sondar, observar, inferir. Injeção de SQL, cross-site scripting, uso indevido de APIs, padrões clássicos de injeção: tudo isso aparece de forma confiável por meio de comportamentos que as heurísticas conseguem reconhecer. Os scanners e as ferramentas DAST ficaram muito bons nisso ao longo dos anos. Hoje, centenas de classes de vulnerabilidade desse tipo são detectadas de forma confiável em todo o SDLC, e isso é uma conquista importante.

Vulnerabilidades dependentes de contexto são outra coisa. BOLA ou IDOR, vazamento de dados entre inquilinos, bypass de autenticação e, especialmente, vulnerabilidades encadeadas, em que algumas falhas médias e altas se combinam para formar um caminho de exploração crítico. Nenhuma delas tem uma assinatura heurística que você possa sondar. Não é possível escrever uma regra, em SAST ou DAST, para “O usuário A não deve conseguir ler a fatura do usuário B”, porque essa regra depende do que sua aplicação DEVERIA fazer. A vulnerabilidade está na diferença entre o comportamento esperado e o comportamento real, e não existe sondagem, payload ou assinatura capaz de inferir a intenção a partir de fora.

É por isso que o pentest sempre foi conduzido por pessoas. Até pouco tempo atrás, só seres humanos conseguiam adquirir o entendimento contextual necessário para encontrar essa segunda classe de vulnerabilidades. As heurísticas encontram assinaturas ou comportamentos; os pentesters encontram o que só se revela no contexto. Por mais interessante que isso pareça, não é um slogan: é assim que essa disciplina funciona desde que existe.

E foi justamente essa fronteira que a IA acabou de cruzar.

A trajetória que realmente importa

Aqui vai um segredo do setor que não é bem segredo: todo mecanismo DAST confiável da última década foi desenvolvido por pessoas com experiência em pentest. O mecanismo do Snyk API & Web não foi exceção. A equipe que o desenvolveu passou anos encontrando falhas manualmente e projetou a ferramenta em torno do que os pentesters realmente fazem: reconhecimento, sondagem, observação, raciocínio, escalonamento, validação... todo o processo. Na época, porém, não conseguíamos reproduzir tudo o que os pentesters fazem. Faltava a capacidade de raciocínio — justamente o que podemos fazer agora, já que os LLMs entendem o contexto e conseguem raciocinar.

Essa experiência é o motivo pelo qual nossa detecção de BOLA, lançada no ano passado, funciona como funciona. Ela não compara padrões com uma lista de assinaturas, porque não existe assinatura para BOLA: é uma cadeia de sondagens de autorização, orientada por raciocínio estrutural sobre a relação entre objetos de API e identidades. É uma busca automatizada por falhas que ultrapassa a barreira entre “O que o código faz?” e “O que ele deveria fazer e como posso subverter essa intenção?”

A solução está em produção para nossos clientes há meses. É a prova de que é possível percorrer o caminho do DAST aos testes baseados em raciocínio. E não é por acaso que pensávamos em criar a versão com IA disso muito antes de “pentest com IA” se tornar uma categoria capaz de atrair investimentos.

O que mudou e por que agora

O que mudou não foi o objetivo, mas o custo.

Antes, o raciocínio em escala exigia um pentester humano. De US$ 20 mil a US$ 50 mil por trabalho. Em média, duas semanas no calendário. E uma janela de cobertura que se fechava assim que o relatório era entregue — quando a aplicação já tinha recebido mais três versões.

Essa era a realidade econômica do pentest manual: insubstituível, mas limitado pelo mesmo fator que limita todo trabalho artesanal — o tempo das pessoas. Seu pentest cobre quinze dias por ano. O que acontece nos outros trezentos e cinquenta?

A IA muda essa realidade econômica, mas não a disciplina. A etapa de raciocínio, que antes só um pentester conseguia executar, agora também pode ser realizada por um modelo suficientemente capaz, de forma repetível e por uma fração do custo.

E há uma terceira superfície de ataque, criada pela própria IA

Tudo o que foi dito até aqui se refere a uma superfície de ataque que existe desde que existem aplicações web: as vulnerabilidades detectáveis por heurísticas e as dependentes de contexto em códigos, APIs e arquiteturas tradicionais. A IA muda o modelo de teste, mas não muda os alvos: eles são objeto de pentest há duas décadas.

Também existe uma superfície de ataque totalmente nova, criada pela própria IA e que não existia há apenas cinco anos.

Aplicações integradas a LLMs, agentes de IA que chamam ferramentas e chatbots conectados a dados de clientes. Pipelines de recuperação que buscam informações em fontes que um invasor pode envenenar, injeção de prompt ou uso indevido. Exfiltração de dados por meio das respostas do modelo ou jailbreaks que transformam um agente de atendimento ao cliente em um ator privilegiado, com acesso que nunca deveria ter. O artigo de Manoj apresentou um exemplo: um agente de IA que chama uma API que nunca tinha sido submetida a testes de estresse, acionado por algo tão simples quanto um endereço de e-mail.

Não dá para procurar esses ataques com um scanner, e eles não são falhas no sentido arquitetural tradicional. Eles surgem na diferença entre o que um LLM foi orientado por um prompt a fazer e o que um invasor consegue convencê-lo a fazer. A única maneira de encontrá-los é fazer, na camada integrada a LLMs, o que um invasor faria: sondar, escalar, exfiltrar, abusar.

Essa é a terceira capacidade da Segurança ofensiva contínua: Red Teaming de agentes. Simulação adversarial em várias etapas contra LLMs, agentes de IA e as ferramentas que eles chamam. Uma ferramenta desenvolvida especificamente para a superfície de ataque criada pela própria IA.

O que mais gosto na forma como isso funciona é que não se trata de um scanner separado que você precisa agendar nem de outro produto que precisa comprar. Durante uma avaliação, o agente de reconhecimento detecta se o alvo inclui componentes integrados a LLMs e, se incluir, o módulo de Red Teaming é acionado automaticamente. Você não precisa saber de antemão que tipo de superfície de ataque sua aplicação apresenta; o sistema identifica e executa os testes certos na camada certa.

Isso é mais importante do que parece à primeira vista. Hoje, a maioria das organizações tem IA em algum lugar do portfólio de aplicações, mas as equipes de segurança não têm um inventário claro de onde ela está. Começar pelo reconhecimento e testar o que for encontrado é o único modelo escalável quando “Onde há IA em produção?” é uma pergunta cuja resposta muda constantemente.

Essa é a superfície de ataque: falhas nas arquiteturas tradicionais e o novo território que a IA acabou de criar sobre elas. A pergunta mais difícil é o que realmente é necessário para realizar testes ofensivos eficazes contra ambas, de forma contínua e em escala empresarial. Apontar um LLM para a URL de um alvo e deixá-lo descobrir tudo sozinho não é a resposta. Quatro fatores diferenciam essa abordagem de trabalhar às cegas.

Contexto da plataforma

A abordagem ingênua ao pentest com IA é começar do zero. Apontar o LLM para uma URL, deixá-lo navegar, fazer suposições, gastar poder computacional com enumerações irrelevantes e torcer para que eventualmente encontre algo. E pior: ele não tem como distinguir uma descoberta teórica de algo realmente explorável na sua pilha, porque não consegue ver seu código, suas dependências, os resultados de scans anteriores, seu ambiente de implantação ou seus limites de confiança. Esse é o ciclo de uma demonstração, mas não é assim que testes de segurança em produção devem funcionar.

A abordagem da Snyk é diferente. A Segurança ofensiva contínua começa com tudo o que a plataforma já sabe sobre sua aplicação: descobertas de SAST, dependências de SCA, inventários de ativos, scans DAST anteriores e sinais de risco de toda a plataforma. Tudo isso alimenta o pentester com IA antes que ele envie uma única solicitação.

Isso muda o que a IA faz desde o primeiro dia. Em vez de “Descubra o que é esta aplicação e encontre vulnerabilidades,”, as instruções passam a ser “Esta aplicação tem estes componentes, estas dependências, estas descobertas anteriores, estes endpoints acessíveis e este perfil de risco. Agora, investigue o que ainda não foi coberto”. O LLM deixa de fazer suposições e começa a trabalhar.

Nas palavras do anúncio desta semana: “A Snyk é diferente porque já conhece seu código”. Esse é o argumento da plataforma em sete palavras. Todas as outras ferramentas de pentest com IA começam do zero; nós começamos de onde suas ferramentas atuais pararam.

É também por isso que não acredito que soluções pontuais puras nessa categoria tenham muito futuro: não dá para simplesmente adicionar essa camada a um produto recém-criado. Ela exige uma década de contexto acumulado, fornecido por mecanismos que vêm encontrando vulnerabilidades reais em clientes reais.

Testes dinâmicos híbridos e detecção com LLM

Este é o ponto de engenharia que a maioria dos novos participantes ignora e onde acredito que muitos vão ter dificuldades quando seus prazos de financiamento e suas contas de tokens se encontrarem.

A abordagem ingênua, mais uma vez, para criar um pentest com IA é usar apenas um LLM: apontá-lo para o alvo e deixar que descubra tudo. Isso funciona em demonstrações, mas não é economicamente sustentável.

Cada payload que um LLM testa em um endpoint de XSS custa tokens. Cada parâmetro submetido a força bruta, cada variação, cada nova tentativa? Tokens, tokens, tokens. Os testes dinâmicos fazem tudo isso de forma exaustiva e determinística, por centavos. Queimar tokens de modelos de ponta para percorrer o catálogo de bugs é o que significa “subsidiar com margens negativas”, e os fornecedores que apostam nisso hoje vão descobrir o que são custos unitários no dia em que precisarem dar lucro.

O modelo arquiteturalmente correto não tem duas camadas trabalhando em paralelo, mas sim um LLM atuando como o cérebro por trás da avaliação, com os testes dinâmicos como uma das ferramentas à sua disposição. Quando é necessário verificar XSS, injeção de SQL ou configurações incorretas, o LLM não enumera os payloads por conta própria: ele aciona os testes dinâmicos, que vêm fazendo exatamente isso de forma exaustiva, determinística e por centavos há anos.

Assim, o LLM pode usar seus tokens naquilo que só um LLM consegue fazer: raciocinar sobre a lógica de negócio, encontrar falhas de autorização e conectar descobertas individuais em caminhos reais de exploração. É aí que fica a maior parte do processamento. O terreno já conhecido continua sendo percorrido de forma determinística, enquanto a capacidade de raciocínio recebe todo o poder computacional que merece.

Essa arquitetura existe desde o primeiro dia; não é algo que estamos planejando desenvolver. Por isso, na minha opinião, construir isso sem um mecanismo de Teste Dinâmico de Segurança por baixo é um problema muito mais difícil do que parece para quem vê de fora.

Narrativas de ataque, não listas de alertas

O resultado de um scanner tradicional é uma lista de vulnerabilidades classificadas por pontuação de gravidade, com rastreamentos de pilha ou solicitações HTTP anexados. Há vários anos, as equipes de segurança estão afogadas nessas listas. CVSS 9,8 ao lado de CVSS 9,6, ao lado de CVSS 9,4... e, em algum lugar ali, um caminho de exploração real que combina duas delas com uma terceira descoberta de baixa gravidade que a equipe descartou na triagem meses atrás.

As vulnerabilidades de contexto que descrevi antes quase nunca aparecem como descobertas isoladas; aparecem em combinações: uma brecha de autorização em um endpoint, uma falha lógica na forma como a API emite identificadores e uma sessão antiga que o processo de limpeza não encerrou. São três descobertas que parecem corriqueiras quando analisadas isoladamente, mas que, em conjunto, funcionam como uma violação de dados.

O Continuous Offensive Security não apresenta as descobertas em uma lista. Ele as apresenta como cadeias de exploração: o caminho real do acesso inicial ao impacto, com o histórico de solicitações e respostas como evidência. Tudo pode ser reproduzido e auditado. É uma narrativa do que um invasor poderia realmente fazer com essa aplicação, e não uma planilha com 400 linhas que alguém precisa triar numa tarde de sexta-feira.

Colleen Carroll, diretora sênior e responsável pela segurança da informação na Emburse, apresentou o ponto de vista de quem compra na nossa publicação de lançamento:

“As equipes de segurança buscam soluções que as ajudem a priorizar riscos reais, e não apenas a gerenciar mais alertas. O Continuous Offensive Security da Snyk dá às equipes mais visibilidade sobre vulnerabilidades exploráveis e sobre como elas se conectam, permitindo agir mais rápido, reduzir a exposição e apoiar a inovação com confiança.”

Essa é a diferença entre “Aqui está o que encontramos” e “Aqui está como isso pode ser usado contra você”.

Estrutura de segurança para IA empresarial

A parte que exige um trabalho sério de engenharia e quase nunca vira manchete é executar agentes de IA com responsabilidade em sistemas a apenas um salto de rede da produção.

Governança, aplicação de limites de escopo, contexto persistente em operações de longa duração e reprodutibilidade, para que uma descoberta possa ser validada e reexaminada. Rastros de raciocínio, para que uma equipe de segurança possa auditar como uma conclusão foi alcançada. Toda a camada que transforma “um LLM fazendo tentativas” em algo que uma equipe de segurança empresarial realmente executaria contra uma aplicação.

Chamamos isso de AI Security Harness. É a parte do Continuous Offensive Security que fica por trás da manchete. E também é onde está a maior parte da dificuldade real. Mais uma vez, é aí que a experiência acumulada faz diferença. Construir essa camada é mais difícil do que criar a IA que fica acima dela, e as organizações que há anos executam testes de intrusão e Teste Dinâmico de Segurança em escala empresarial têm uma vantagem considerável sobre quem está chegando agora.

Também foi nessa camada que fizemos uma escolha deliberada de arquitetura, difícil de replicar com outras soluções: o Continuous Offensive Security não opera com um único modelo de fronteira. O AI Security Harness orquestra vários modelos de ponta, modelos da categoria de defesa e outros modelos abertos e proprietários, aprimorados ao longo do tempo. Para nós, isso representa uma decisão arquitetônica sobre como um sistema de IA de nível empresarial deve ser desenvolvido.

O Continuous Offensive Security executa um sistema de segurança ofensiva com vários modelos, desenvolvido especificamente para testes de intrusão em ambientes empresariais. Modelos de fronteira realizam a avaliação sob a coordenação do harness ofensivo da Snyk; um modelo de validação dedicado atua como avaliador independente e confirma a possibilidade de exploração antes que qualquer descoberta seja apresentada; e a inteligência da plataforma da Snyk fundamenta cada ataque no contexto real da aplicação. O resultado é um sistema projetado para oferecer precisão, sem ruído.

O impacto na prática

Gabriel Brolo, engenheiro de segurança sênior na Yalo, explicou isso recentemente com mais clareza do que eu conseguiria:

“O volume e a velocidade do código gerado por IA superaram radicalmente o modelo de testes de intrusão que a maioria de nós vem usando há anos. Não dá para resolver uma superfície de risco contínua apenas agendando testes. Precisamos de testes ofensivos que acompanhem a forma como desenvolvemos software hoje — com contexto suficiente para se concentrar no que é realmente explorável, e não apenas no que é teoricamente possível. Esse tipo de capacidade permitirá que as equipes compreendam melhor seu cenário de ameaças e os riscos reais, para mitigá-los com mais eficácia.”

Para os clientes de Snyk API & Web, o Continuous Offensive Security não é uma compra separada; é a próxima camada no mesmo caminho de testes externos que o Teste Dinâmico de Segurança já percorre. O scanner cobre os problemas detectáveis por heurística, a IA cobre os que dependem de contexto e o Red Teaming cobre a superfície de ataque específica de IA assim que o reconhecimento detecta um LLM na pilha. A mesma abordagem de segurança, ampliada para abranger aquilo de que suas aplicações são realmente feitas hoje.

Para o mercado, a pergunta deixa de ser “Você precisa de testes de intrusão com IA?” (e, bem, acreditamos que sim) e passa a ser “Qual solução de testes de intrusão com IA devo escolher?”

Ao anunciarmos finalmente o Continuous Offensive Security esta semana, nossa intenção é que o cliente que está avaliando soluções de testes de intrusão com IA hoje — comparando opções, assistindo a demonstrações e tentando descobrir em quem confiar — saiba que uma das respostas vem das mesmas pessoas que já estavam nessa área muito antes de ela sequer existir como área.

Se você acompanhou a publicação de Manoj sobre a superfície de ataque que a IA está criando e meu artigo anterior sobre como os testes dinâmicos precisam evoluir para acompanhar essa mudança, este é o terceiro capítulo — e a conexão entre eles está bem clara. Ela sempre esteve ali, e fomos dando pistas disso o tempo todo.

Teremos mais novidades na Black Hat. Espero encontrar vocês por lá!