Pipeline LLM OpenAnt Identifica 28 Vulnerabilidades Exploráveis no OpenSSL

A Knostic lançou a OpenAnt esta semana — um pipeline LLM open-source de seis estágios que varre bases de código em escala de repositório buscando vulnerabilidades exploráveis e valida cada descoberta com um exploit ao vivo em um contêiner isolado antes de exibi-la. No OpenSSL, o sistema reduziu 15.232 funções analisadas em 1.769 arquivos para 49 candidatos para análise LLM, depois sinalizou 28 desses 49 como potencialmente vulneráveis. O artigo e ferramentas foram lançados em conjunto em 17 de junho sob a licença Apache 2.0.

Os dois primeiros estágios não custam nada. O Estágio 1 analisa cada função e constrói um gráfico de chamadas. O Estágio 2 executa travessia de gráfico a partir de pontos de entrada externos — manipuladores CLI, callbacks, funções main — e descarta qualquer código inacessível a partir de entrada controlada pelo atacante. No OpenSSL esse filtro sozinho reduz a superfície de análise em 97%, de 15.232 unidades para 390. Nenhum LLM é invocado até o Estágio 3.

O Estágio 3 é onde os custos começam. Um agente Sonnet 4 itera sobre cada unidade alcançável, classificando-a por nível de exposição: externamente exposta, internamente exposta, controle de segurança ou neutra. O loop é executado até que a classificação seja confiante ou atinja um limite de 20 iterações. O custo escala com a complexidade da função. Um utilitário simples termina em aproximadamente uma iteração a $0,13; uma cadeia de chamadas profunda pode atingir o limite a $10,92 por unidade. No OpenSSL a mediana foi de 9 iterações por unidade. Após o Estágio 3, as 390 unidades alcançáveis desabam para 49 expostas externamente — uma redução de 99,6% da contagem de funções original.

O Estágio 4 entrega essas 49 unidades ao Claude Opus 4.6, que analisa cada um em busca de padrões de vulnerabilidade. Sinalizou 28. O Estágio 5 é o verificador adversarial, onde a arquitetura diverge da maioria das ferramentas de segurança baseadas em LLM. Uma persona de atacante restrita avalia se cada candidato sinalizado é realmente explorável sob condições realistas: sem acesso ao servidor presumido, sem credenciais de banco de dados, sem leitura de arquivo local, sem comandos CLI. O modelo deve rastrear um caminho de exploit passo a passo. Se o único caminho de ataque viável requer acesso ao shell local, a descoberta é classificada como NÃO EXPLORÁVEL e descartada. Prompts "atue como um atacante" irrestritos são a causa raiz de altas taxas de falsos positivos em scanners baseados em LLM — os modelos são agradáveis por padrão e constroem ataques plausíveis que assumem capacidades do atacante que não existem em produção.

O Estágio 6 converte candidatos sobreviventes em ambientes de exploit reais, executa-os em contêineres isolados de vida útil curta e destrói o ambiente depois. Apenas descobertas que sobrevivem à execução chegam ao relatório final. A Knostic está atualmente no processo de divulgação de vulnerabilidade para descobertas que o sistema produziu contra OpenSSL, WordPress e Flowise.

A configuração de modelo padrão usa Claude Opus 4.6 para revisão de acessibilidade, análise e verificação adversarial, e Sonnet 4 para contexto mais leve, aprimoramento e fases de relatório. A config é um arquivo JSON com todas as fases do pipeline atribuíveis independentemente a qualquer par provedor-modelo. Adaptadores Anthropic, OpenAI e Google são fornecidos prontos para usar. Qualquer endpoint proxy compatível com OpenAI ou Anthropic — OpenRouter, vLLM, Bedrock, gateways internos — funciona via base_url customizada. Adicionar um novo adaptador requer um arquivo Python implementando o protocolo LLMAdapter mais alguns pontos de contato Go para o assistente CLI; 12 testes de contrato executam automaticamente. O suporte de idioma é estável para Go, Python e JavaScript/TypeScript; C/C++, PHP e Ruby estão em beta.

A restrição prática para adotar isso é a curva de custo do Estágio 3. Com 9 iterações medianas e $0,13 por iteração, um projeto que resulta em 390 unidades alcançáveis gasta aproximadamente $450 apenas em classificação de exposição antes de qualquer análise de vulnerabilidade executar. Monorepos maiores ou idiomas sem parsers estáticos maduros empurrarão isso para cima. O filtro de acessibilidade é a otimização crítica — sem ele o custo por projeto se torna proibitivo em qualquer escala. Para equipes de segurança já executando revisão de código manual ou pagando por SAST comercial, a economia provavelmente fecha. Para equipes executando isso ad hoc, o custo por varredura precisa de modelagem contra o tamanho do repositório antes da implantação.

A aposta central da arquitetura: fechar o loop entre raciocínio semântico e execução de exploit, e definir "vulnerável" como "demonstravelmente explorável sob restrições realistas do atacante." O número que importa não é quantas descobertas o scanner produz — é quantas sobrevivem ao Estágio 5.