Por Que IA Ainda Não Detecta Vulnerabilidades Críticas: Lições do curl e Limitações das Ferramentas Inteligentes

Em março de 2024, Daniel Stenberg fez algo que muitos de nós temos considerado: testou se ChatGPT e GPT-4 conseguiriam encontrar vulnerabilidades de segurança no curl, um dos projetos mais críticos da infraestrutura da internet. O curl processa bilhões de requisições diariamente e acumulou 161+ security advisories documentados ao longo de sua história. Se algum projeto seria ideal para demonstrar o valor de IA em análise de segurança, seria este.

Os resultados foram decepcionantes. Os LLMs geraram muitos falsos positivos e não encontraram vulnerabilidades reais críticas. As duas CVEs mais sérias de 2023 (CVE-2023-38545 e CVE-2023-38546) foram descobertas por pesquisadores humanos usando métodos tradicionais. Quando você lê promessas de vendors sobre IA revolucionando segurança de código, essa história oferece uma perspectiva realista sobre onde estamos de fato.

O Gap Entre Promessa e Realidade

A narrativa dominante sugere que LLMs estão transformando como detectamos vulnerabilidades. A realidade documentada em pesquisas controladas conta história diferente. Um paper de 2023 chamado “Do Language Models Find Security Bugs?” testou LLMs em cenário cego com código contendo 8 CVEs conhecidos. O resultado: zero vulnerabilidades detectadas.

O benchmark SecurityEval, desenvolvido por GitHub e OpenAI, mostrou que Codex detectou apenas 25% de vulnerabilidades conhecidas em código C/C++. Não são números impressionantes quando você considera que ferramentas SAST tradicionais como CodeQL alcançam recall de 70-80% em vulnerabilidades OWASP Top 10, enquanto Semgrep atinge 60-70% na mesma categoria.

Essa diferença de performance importa em produção. Integrar ferramenta com 25% de detecção em pipeline de CI/CD é essencialmente jogar moeda ao ar sobre se vulnerabilidades críticas serão identificadas antes do deploy. A pesquisa de Stanford “Do Users Write More Insecure Code with AI Assistants?” demonstrou problema adicional: código gerado por IA frequentemente contém mais vulnerabilidades que código escrito por desenvolvedores sem assistência.

Onde Ferramentas Tradicionais Ainda Dominam

O curl documenta como encontra vulnerabilidades de verdade: fuzzing via OSS-Fuzz, análise manual por especialistas em segurança, e bug bounty programs via HackerOne. Desde 2016, esse processo identificou mais de 300 vulnerabilidades. O fuzzing é excepcionalmente efetivo para código C/C++ porque opera no nível de execução real, testando comportamentos de runtime que análise estática não consegue prever.

CodeQL encontrou 100+ CVEs em projetos open source precisamente porque opera com queries estruturadas sobre representações semânticas de código. Quando você escreve query CodeQL para detectar buffer overflow, está codificando conhecimento específico sobre padrões de vulnerabilidade que funcionam consistentemente. Semgrep oferece abordagem similar com 2000+ regras de segurança e taxa de falsos positivos documentada entre 10-20% - número gerenciável em pipelines de produção.

A diferença técnica é fundamental. Ferramentas SAST tradicionais usam análise de fluxo de dados, taint analysis, e modelagem de comportamento baseada em regras formais. Quando CodeQL detecta SQL injection, está rastreando como dados não confiáveis fluem através do programa até chegarem em query SQL. Esse rastreamento é determinístico e auditável.

LLMs operam com reconhecimento de padrões probabilístico. Quando GPT-4 analisa código, está usando contexto estatístico de trilhões de tokens vistos durante treinamento para prever se algo “parece” vulnerável. Essa abordagem funciona razoavelmente para vulnerabilidades óbvias que aparecem frequentemente em dados de treinamento. Para vulnerabilidades sutis ou específicas do domínio - exatamente o tipo que projetos maduros como curl ainda contêm - a taxa de detecção cai dramaticamente.

As Limitações Que Ninguém Quer Admitir

Daniel Stenberg descreveu LLMs como “confiantes mas frequentemente errados” em análise de segurança. Essa observação captura problema crítico: não é apenas que IA perde vulnerabilidades, mas que reporta falsos positivos com mesmo nível de confiança que verdadeiros positivos. Em ambiente de produção com centenas de milhares de linhas de código, essa característica torna ferramentas baseadas em LLM praticamente inutilizáveis sem filtro humano substancial.

Todas as ferramentas - tradicionais e com IA - enfrentam dificuldade significativa com vulnerabilidades de lógica de negócio, com taxa de detecção abaixo de 30%. Quando vulnerabilidade não é sobre buffer overflow ou SQL injection, mas sobre sequência incorreta de operações que quebra invariante de segurança, análise automatizada de qualquer tipo tem eficácia limitada. Essas vulnerabilidades requerem compreensão profunda de contexto e intenção que nem código-fonte nem patterns estatísticos conseguem expressar completamente.

A pesquisa “Large Language Models for Code Analysis” de 2024 observou que LLMs são melhores em explicar vulnerabilidades conhecidas do que descobrir novas. Essa distinção é crucial: se você já sabe onde está o problema, LLM pode gerar explicação útil ou sugerir fix. O trabalho difícil - encontrar problema desconhecido em codebase complexo - permanece domínio de ferramentas especializadas e análise humana.

Abordagem Pragmática para Projetos em Produção

Dados os benchmarks reais, qual estratégia faz sentido para projetos que rodam em produção? A resposta não é escolher entre IA e ferramentas tradicionais, mas entender onde cada abordagem adiciona valor.

Use ferramentas SAST tradicionais como linha de defesa primária em CI/CD. CodeQL e Semgrep têm performance documentada, falsos positivos gerenciáveis, e integram bem com sistemas de build existentes. O tempo de scan varia - Semgrep opera em segundos a minutos, CodeQL pode levar minutos a horas dependendo do tamanho do projeto - mas esse investimento de tempo compensa pela confiabilidade das detecções.

Fuzzing continua sendo método mais efetivo para encontrar vulnerabilidades de segurança em código que processa input externo. Se seu projeto lida com parsing de protocolos, formatos de arquivo, ou qualquer forma de dados não confiáveis, investimento em fuzzing retorna resultados. OSS-Fuzz encontrou milhares de bugs em projetos críticos porque testa comportamento real de execução, não apenas propriedades estáticas de código.

LLMs podem ter papel como assistentes em análise manual. Investigando potencial vulnerabilidade e precisa entender rapidamente o que código complexo faz? LLM pode gerar explicação útil. Escreveu fix e quer segunda opinião sobre possíveis casos edge? LLM pode sugerir cenários de teste. Essas são aplicações de assistência, não substituição de ferramentas especializadas.

A tendência atual documentada na indústria reflete essa realidade: uso de IA como assistente, não substituto. Empresas como Snowflake e Dropbox usam Semgrep para análise automática enquanto exploram LLMs para casos de uso específicos onde interação conversacional adiciona valor. Não há corrida para substituir pipelines de segurança estabelecidos por ferramentas baseadas em IA, porque os benchmarks não justificam essa mudança.

O Que Vem a Seguir

A eficácia limitada de IA em detectar vulnerabilidades não é statement sobre potencial futuro, mas sobre realidade presente. Quando você toma decisões sobre segurança de código hoje, dados disponíveis sugerem que ferramentas tradicionais oferecem melhor retorno sobre investimento.

Isso pode mudar. Pesquisas em fine-tuning de modelos específicos para análise de segurança, integração de raciocínio simbólico com reconhecimento de padrões probabilístico, e treinamento em datasets de vulnerabilidades reais podem eventualmente produzir ferramentas mais efetivas. Essas melhorias precisam ser demonstradas em benchmarks controlados com código real de produção, não apenas em promessas de vendors.

Até lá, a experiência do curl oferece lição valiosa: projetos críticos não estão descobrindo vulnerabilidades com IA porque as ferramentas ainda não alcançaram eficácia necessária. As 300+ vulnerabilidades encontradas no curl desde 2016 foram identificadas por fuzzing, análise manual, e bug bounties - métodos que continuam sendo mais confiáveis que qualquer ferramenta baseada em LLM disponível hoje.

Se você está construindo pipeline de segurança para projeto em produção, aposte em ferramentas com performance documentada. Use IA onde ela adiciona valor real - explicação, exploração, geração de casos de teste - mas não espere que substitua análise rigorosa de segurança. A infraestrutura crítica da internet roda em código que precisa de garantias que apenas métodos formais e testes exaustivos conseguem fornecer.