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

Nos últimos 90 dias, realizámos testes de intrusão (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 estão apenas vulneráveis. Estão continuamente vulneráveis.
O problema não é o facto de as equipas não testarem a segurança. É o facto de os atacantes operarem agora à velocidade das máquinas, enquanto os testes e a correção ainda acontecem em tempos 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 encolher. Se os testes e as correções não se moverem à mesma velocidade, essa lacuna 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% de severidade crítica ou alta (829 descobertas)

• 21,6 vulnerabilidades por scan, em média (mediana: 15)

• 65,1% dos scans revelaram pelo menos um problema crítico

• Pico: 88 vulnerabilidades num único scan

Estes não são riscos teóricos. Cada descoberta é validada com um exploit de prova de conceito 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 é mais preocupante é o tipo de vulnerabilidades por trás destes números. Não se trata de simples configurações incorretas ou de dependências desatualizadas. São problemas mais profundos na forma como as aplicações são concebidas e se comportam.

Estes 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 codificado, mas o design em si é inseguro.
Não se trata de erros de configuração ou de bibliotecas desatualizadas. São bugs na forma como a aplicação realmente funciona, como os dados fluem, como as permissões são aplicadas e como os sistemas confiam uns nos outros.

Eis como isso se parece na prática:

• IDOR (Insecure Direct Object Reference) — 177 descobertas
  Os atacantes podem aceder ou modificar dados de outros utilizadores simplesmente alterando identificadores (por exemplo, IDs de utilizador, IDs de ficheiro). Isto pode expor dados sensíveis em grande escala ou até mesmo permitir a apropriação de contas.

• SSRF (Server-Side Request Forgery) — 122 descobertas
  Os atacantes podem induzir o servidor a fazer pedidos em seu nome, frequentemente para sistemas internos. Isto pode expor APIs internas, credenciais de cloud ou infraestruturas que nunca deveriam estar acessíveis publicamente.

• Falta de autenticação — 105 descobertas
  Endpoints ou ações sensíveis estão acessíveis sem necessidade de início de 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 o comportamento da aplicação, e não apenas a forma como está configurada.
Os scanners tradicionais têm dificuldades neste aspeto porque não compreendem o comportamento. Procuram assinaturas, não lógica.

Porque é que a IA está a encontrar mais

Até há bem 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 da mesma forma que um atacante humano o faria, mas a uma escala e velocidade completamente diferentes.
Eles não se limitam a fazer o scan de endpoints, eles exploram-nos.

• Testam casos limite

• Encadeiam vários passos

• Iteram rapidamente através de milhares de possibilidades

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

Porque é que o Código Aberto pode Acelerar a Descoberta de Vulnerabilidades

O código aberto muda a forma como as vulnerabilidades são descobertas.
Imagine forçar uma fechadura. Quando conhece o funcionamento interno da fechadura, é muito mais fácil forçá-la.
Quando os sistemas de IA têm acesso ao código-fonte, podem analisar diretamente cada caminho do código em vez de deduzirem o comportamento a partir do exterior.
Em testes de benchmark controlados, utilizando a suite de validação XBow disponível publicamente, o acesso ao código-fonte aumentou a deteção de vulnerabilidades em aproximadamente 20% em comparação com os testes de caixa preta (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 incorretos 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 desenvolvidas abertamente e os sistemas de IA melhoram, a velocidade de descoberta de vulnerabilidades continua a aumentar.
Dito isto, ter um código fechado não o torna seguro por padrão.
A segurança através da obscuridade nunca foi uma defesa real. Um atacante determinado, com capacidade de computação suficiente e tokens para gastar, continuará a conseguir enumerar, realizar fuzzing e, eventualmente, descobrir caminhos exploráveis, mesmo sem acesso direto ao código.
O que significa que a lição a tirar não é sobre escolher código aberto ou fechado. É sobre adaptar a forma como testa e protege os sistemas.
Independentemente da arquitetura, as avaliações pontuais tradicionais falham o alvo. As bases de código estão a evoluir à velocidade das máquinas, e o mesmo acontece com as superfícies de ataque.

O verdadeiro problema: maior velocidade = menor custo

Há alguns anos, encontrar e explorar vulnerabilidades exigia tempo, perícia e paciência.
Hoje, esse cronograma 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 rapidamente do que nunca, muitas vezes poucas horas ou dias após terem sido introduzidas.
Mas a maioria das organizações ainda não se adaptou a esta mudança.
Os testes de segurança ainda são tratados como um evento periódico:

• Uma vez por ano

• Talvez uma vez por trimestre

E a correção costuma ser ainda mais lenta, dependendo de priorizações, disponibilidade da engenharia e ciclos de lançamento. Até o tempo necessário para colocar o código em produção cria lacunas que sistemas mais rápidos podem explorar.
Isto cria um fosso crescente:

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

• As correções são implementadas em tempos humanos

Esse fosso é a verdadeira superfície de ataque.
Se existir uma vulnerabilidade crítica durante dias ou semanas antes de ser corrigida, não importa como foi encontrada. É explorável.
O modelo tradicional de "testar, reportar, corrigir mais tarde" simplesmente não se sustenta quando tanto os atacantes como os sistemas de descoberta operam continuamente.
Esse modelo já está obsoleto.

O que realmente funciona

A mudança não tem a ver com ferramentas. Tem a ver com a 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.
Requer repensar como a segurança se integra no ciclo de vida do desenvolvimento.
O teste contínuo normalmente combina:

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

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

• Desenvolvedores a assumirem e a corrigirem 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 apenas com mais pessoal.
Os testes manuais não têm escala para acompanhar a velocidade do desenvolvimento moderno ou dos atacantes modernos.
É por isso que estamos a ver uma transição para a automação e, em muitos casos, a subcontratação de testes contínuos para sistemas que conseguem operar à velocidade das máquinas.
A urgência aqui é real.

E a seguir?

A IA já está a acelerar a descoberta de vulnerabilidades. Os atacantes não estão à espera do seu próximo pentest agendado.
Se a sua aplicação muda diariamente, os seus testes de segurança e a sua capacidade de corrigir problemas têm de acompanhar esse ritmo.
Independentemente da arquitetura, as avaliações pontuais tradicionais falham o alvo. As bases de código estão a evoluir à velocidade das máquinas, e o mesmo acontece com as superfícies de ataque.
Os sistemas de código aberto precisam de reconhecer e assumir a exposição adicional que surge com a visibilidade do código. Entretanto, os sistemas de código fechado não podem confiar na obscuridade e precisarão também de melhorar a sua postura de segurança.
O fosso entre a rapidez com que desenvolvemos 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 a vantagem.
Se não estiver a escalar ativamente a segurança para fazer frente à ameaça, os seus sistemas vão falhar.

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