A IA Está a Descobrir Vulnerabilidades Críticas Mais Depressa do que as Equipas as Conseguem Corrigir

Nos últimos 90 dias, executámos pentests autónomos em vários sistemas de produção — e os resultados são difíceis de ignorar.
As aplicações modernas não são apenas vulneráveis. São continuamente vulneráveis.
O problema não é as equipas não testarem a segurança. É que os atacantes estão agora a operar à velocidade das máquinas, enquanto os testes e a correção continuam a acontecer nos prazos humanos.
À medida que a IA acelera a descoberta de vulnerabilidades, a janela entre a introdução de um bug e a sua exploração está a diminuir. Se os testes e as correções não se moverem à mesma velocidade, essa distância torna-se a superfície de ataque.

O que estamos a ver no terreno

Em 28 empresas, os nossos agentes identificaram:

• ~2000 vulnerabilidades no total

• 44.6% críticas ou de gravidade alta (829 resultados)

• 21.6 vulnerabilidades por análise, em média (mediana: 15)

• 65.1% das análises descobriram pelo menos um problema crítico

• Pico: 88 vulnerabilidades numa única análise

Isto não são riscos teóricos. Cada descoberta é validada com um exploit proof-of-concept funcional.
Quase metade de todas as vulnerabilidades que encontrámos são graves, e a maioria dos sistemas tem pelo menos um problema crítico.
O que é ainda mais preocupante é o tipo de vulnerabilidades por trás destes números. Não são simples más configurações ou dependências desatualizadas. São problemas mais profundos na forma como as aplicações são desenhadas e se comportam.

Isto não são bugs simples

Os problemas mais comuns que estamos a ver são falhas de lógica.
Uma falha de lógica significa que o sistema se está a comportar exatamente como foi codificado, mas o próprio design é inseguro.
Isto não são erros de configuração nem bibliotecas desatualizadas. São bugs na forma como a aplicação realmente funciona, na forma como os dados fluem, na forma como as permissões são aplicadas e na forma como os sistemas confiam uns nos outros.

Isto é o que isso parece na prática:

• IDOR (Insecure Direct Object Reference) — 177 descobertas
  Os atacantes podem aceder a dados de outros utilizadores ou modificá-los simplesmente ao alterar identificadores (por exemplo, IDs de utilizador, IDs de ficheiro). Isto pode expor dados sensíveis em grande escala ou até permitir a tomada de controlo da conta.

• SSRF (Server-Side Request Forgery) — 122 descobertas
  Os atacantes podem enganar o servidor para que faça pedidos em seu nome, muitas vezes a sistemas internos. Isto pode expor APIs internas, credenciais da cloud ou infraestrutura que nunca deveria estar acessível ao público.

• Falta de autenticação — 105 descobertas
  Endpoints ou ações sensíveis estão acessíveis sem iniciar sessão. Isto significa que qualquer pessoa na internet pode acionar funcionalidades críticas ou aceder a dados protegidos.

Estas vulnerabilidades são particularmente perigosas porque exploram a forma como a aplicação se comporta, e não apenas a forma como está configurada.
Os scanners tradicionais têm dificuldades aqui porque não entendem comportamento. Procuram assinaturas, não lógica.

Porque é que a IA está a encontrar mais

Até há pouco tempo, encontrar e explorar este tipo de vulnerabilidades exigia tempo, perícia e esforço manual.
Isso mudou.

Os agentes de IA conseguem agora interagir com aplicações da mesma forma que um atacante humano, mas a uma escala e velocidade completamente diferentes.
Não se limitam a fazer scan aos endpoints, exploram-nos.

• Testam casos-limite

• Encadeiam vários passos

• Iteram rapidamente entre milhares de possibilidades

Em vez de verificar problemas conhecidos, sondam ativamente a forma como uma aplicação se comporta e procuram formas de a quebrar. Nunca dormem. O seu dia de trabalho nunca acaba. Têm a base de conhecimento do mundo memorizada.
Esta mudança é o que está a impulsionar os resultados que estamos a ver, a descoberta consistente de problemas críticos na maioria das análises.

Porque é que o Open Source Pode Acelerar a Descoberta de Vulnerabilidades

O open source muda a forma como as vulnerabilidades são descobertas.
Imagina tentar abrir uma fechadura. Quando conheces o funcionamento interno da fechadura, é muito mais fácil fazê-lo.
Quando os sistemas de IA têm acesso ao código-fonte, conseguem analisar diretamente todos os caminhos de código em vez de inferirem o comportamento a partir do exterior.
Em testes comparativos controlados usando o XBow validation suite, publicamente disponível, o acesso ao código-fonte aumentou a deteção de vulnerabilidades em aproximadamente 20% em comparação com testes black-box.
Também vemos esta diferença em cenários do mundo real.
Com visibilidade total, os agentes de IA conseguem:

• Rastrear fluxos de dados de ponta a ponta

• Identificar pressupostos errados na lógica de negócio

• Explorar casos-limite de forma muito mais eficiente

Isto torna as falhas de lógica significativamente mais fáceis de encontrar e explorar.
À medida que mais aplicações são construídas em aberto e os sistemas de IA melhoram, a velocidade de descoberta de vulnerabilidades continua a aumentar.
Ainda assim, ser closed source não te torna seguro por defeito.
Security through obscurity nunca foi uma verdadeira defesa. Um atacante determinado, com poder de computação suficiente e tokens suficientes para gastar, ainda pode enumerar, fazer fuzzing e, eventualmente, descobrir caminhos exploráveis, mesmo sem acesso direto ao código.
O que significa que a conclusão não passa por escolher open source ou closed source. Passa por adaptar a forma como testas e proteges sistemas.
Independentemente da arquitetura, as avaliações tradicionais pontuais falham o alvo. As codebases estão a evoluir à velocidade das máquinas, e as superfícies de ataque também.

O problema real: maior velocidade = menor custo

Há alguns anos, encontrar e explorar vulnerabilidades exigia tempo, perícia e paciência.
Hoje, essa linha temporal colapsou.
Os sistemas de IA conseguem:

• Executar milhares de testes em paralelo

• Explorar continuamente novos caminhos de código

• Encadear exploits automaticamente

Isto significa que as vulnerabilidades estão a ser descobertas mais depressa do que nunca, muitas vezes em horas ou dias após serem introduzidas.
Mas a maioria das organizações ainda não se adaptou a esta mudança.
Os testes de segurança continuam a ser tratados como um evento periódico:

• Uma vez por ano

• Talvez uma vez por trimestre

E a correção muitas vezes avança ainda mais devagar, à espera de priorização, capacidade da engenharia e ciclos de release. Até o tempo que leva a colocar código em produção cria falhas que sistemas mais rápidos conseguem explorar.
Isto cria uma distância cada vez maior:

• As vulnerabilidades são descobertas à velocidade das máquinas

• As correções são implementadas nos prazos humanos

Essa distância é a verdadeira superfície de ataque.
Se existir uma vulnerabilidade crítica durante dias ou semanas antes de ser corrigida, não interessa como foi descoberta. É explorável.
O modelo tradicional de “testar, reportar, corrigir mais tarde” simplesmente não se aguenta quando tanto os atacantes como os sistemas de descoberta estão a operar continuamente.
Esse modelo já está desatualizado.

O que realmente funciona

A mudança não é sobre ferramentas. É sobre abordagem.
A segurança precisa de passar de:

• testes pontuais → testes contínuos

Na prática, isto não é apenas uma mudança de tooling.
Exige repensar a forma como a segurança se encaixa no ciclo de vida do desenvolvimento.
Os testes contínuos normalmente combinam:

• Sistemas automatizados que executam testes continuamente, não apenas uma vez por ano

• Segurança integrada diretamente nos pipelines de CI/CD

• Os developers a assumir e corrigir problemas como parte dos workflows normais

• Testes humanos periódicos para caminhos de ataque mais profundos e complexos

Isto não é algo que a maioria das equipas consiga resolver apenas com mais pessoas.
Os testes manuais não escalam para acompanhar a velocidade do desenvolvimento moderno nem dos atacantes modernos.
É por isso que estamos a ver uma mudança para a automação e, em muitos casos, para o outsourcing dos testes contínuos para sistemas que conseguem operar à velocidade das máquinas.
A urgência aqui é real.

E agora?

A IA já está a acelerar a descoberta de vulnerabilidades. Os atacantes não estão à espera do teu próximo pentest agendado.
Se a tua aplicação está a mudar todos os dias, os teus testes de segurança e a tua capacidade de corrigir problemas precisam de acompanhar.
Independentemente da arquitetura, as avaliações tradicionais pontuais falham o alvo. As codebases estão a evoluir à velocidade das máquinas, e as superfícies de ataque também.
Os sistemas open source precisam de reconhecer e assumir a exposição adicional que vem com a visibilidade do código. Os sistemas closed source, por outro lado, não podem confiar na obscuridade e também terão de melhorar a sua postura de segurança.
A distância entre a velocidade a que construímos software e a frequência com que o testamos está a aumentar.
A IA está a acelerar ambos os lados, mas neste momento os atacantes têm vantagem.
Se não estiveres a escalar ativamente a segurança para acompanhar a ameaça, os teus sistemas vão falhar.

O benchmark referido acima (XBow) está publicamente disponível no GitHub. Os nossos resultados combinam testes controlados de benchmark com dados reais de sistemas de produção em toda a nossa plataforma.