A IA está a encontrar vulnerabilidades críticas mais depressa do que Teams as consegue corrigir

Nos últimos 90 dias, executámos pentests autónomos contra 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 é que as equipas não testem a segurança. É que os atacantes operam agora à velocidade da máquina, enquanto os testes e a correção continuam a acontecer ao ritmo humano.
À medida que a IA acelera a descoberta de vulnerabilidades, a janela entre um bug ser introduzido e ser explorado está a diminuir. Se os testes e as correções não acompanharem a mesma velocidade, esse fosso 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 alta gravidade (829 achados)

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

• 65,1% das análises revelaram pelo menos um problema crítico

• Pico: 88 vulnerabilidades numa única análise

Isto não são riscos teóricos. Cada achado é validado com um exploit funcional de prova de conceito.
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 detrás destes números. Não são simples más configurações nem 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 está a comportar-se exatamente como foi programado, mas o próprio design é inseguro.
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, como as permissões são aplicadas e como os sistemas confiam uns nos outros.

Eis o que isso significa na prática:

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

• SSRF (Server-Side Request Forgery) — 122 achados
  Os atacantes podem levar o servidor a fazer pedidos em seu nome, muitas vezes para sistemas internos. Isto pode expor APIs internas, credenciais de cloud ou infraestrutura que nunca deveria estar acessível publicamente.

• Autenticação em falta — 105 achados
  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 como está configurada.
Os scanners tradicionais têm dificuldade aqui porque não compreendem o 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, competência e esforço manual.
Isso mudou.

Os agentes de IA conseguem agora interagir com as aplicações como um atacante humano faria, mas numa escala e velocidade completamente diferentes.
Não se limitam a verificar endpoints, exploram-nos.

• Testam casos extremos

• Encadeiam vários passos

• Iteram rapidamente por milhares de possibilidades

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

Porque o open source pode acelerar a descoberta de vulnerabilidades

O open source muda a forma como as vulnerabilidades são descobertas.
Imagina escolher uma fechadura. Quando conheces o funcionamento interno da fechadura, é muito mais fácil abri-la.
Quando os sistemas de IA têm acesso ao código-fonte, conseguem analisar diretamente cada caminho de código, em vez de inferir o comportamento a partir do exterior.
Em testes controlados de benchmark 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 do início ao fim

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

• Explorar casos extremos 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.
Dito isto, ser closed source não te torna seguro por defeito.
A segurança por obscuridade nunca foi uma defesa real. Um atacante determinado, com 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 é escolher entre open ou closed source. É adaptar a forma como testas e proteges os sistemas.
Independentemente da arquitetura, as avaliações tradicionais pontuais falham o alvo. As bases de código evoluem à velocidade da máquina, e as superfícies de ataque também.

O verdadeiro problema: maior velocidade = menor custo

Há poucos anos, encontrar e explorar vulnerabilidades exigia tempo, competência e paciência.
Hoje, esse prazo 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 avança muitas vezes ainda mais devagar, à espera de priorização, capacidade de engenharia e ciclos de lançamento. Até o tempo necessário para levar código para produção cria lacunas que sistemas mais rápidos podem explorar.
Isto cria um fosso cada vez maior:

• As vulnerabilidades são descobertas à velocidade da máquina

• As correções são implementadas ao ritmo humano

Esse fosso é a verdadeira superfície de ataque.
Se uma vulnerabilidade crítica existir durante dias ou semanas antes de ser corrigida, não interessa a forma 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 funcionar continuamente.
Esse modelo já está ultrapassado.

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 ferramentas.
Exige repensar como a segurança se encaixa no ciclo de desenvolvimento.
Os testes contínuos normalmente combinam:

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

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

• Programadores a assumir e corrigir problemas como parte dos fluxos de trabalho normais

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

Isto não é algo que a maioria das equipas consiga resolver só com mais pessoal.
Os testes manuais não escalam para acompanhar a velocidade do desenvolvimento moderno ou dos atacantes modernos.
É por isso que estamos a ver uma mudança para a automação e, em muitos casos, para a externalização de testes contínuos para sistemas que conseguem operar à velocidade da máquina.
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 muda 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 bases de código evoluem à velocidade da máquina, 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.
O fosso 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 corresponder à 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 do mundo real de sistemas de produção em toda a nossa plataforma.