Antonio Morales, pesquisador do GitHub Security Lab, publicou em 24 de setembro uma pipeline de fuzzing (teste de robustez) guiada por um modelo de linguagem grande, voltada a projetos C/C++. O código está no repositório seclab-taskflows-fuzzing do GitHub, e o modelo padrão é o Claude Sonnet 5.
O sistema é construído sobre o Taskflow Agent, framework próprio do GitHub, descrito oficialmente como "um framework para escrever automação de segurança orientada por LLM". O usuário abre um Codespace dentro do repositório, executa uma linha de comando seguida do nome do projeto-alvo, como tukaani-project/xz, e o restante fica por conta do agente.
Do ponto de entrada ao relatório final
Segundo a descrição, a pipeline executa as etapas nesta ordem: identificar pontos de entrada no código, escrever automaticamente um harness de teste, acionar o AFL++ para rodar o fuzzing, ler o relatório de cobertura, reescrever o harness com base na cobertura obtida, classificar cada falha (crash) individualmente e, por fim, gerar um relatório de vulnerabilidade com sugestão de patch em formato diff unificado.
O retorno de cobertura usa um esquema de orçamento de tempo que dobra a cada rodada: começa em 30 segundos e segue para 60, 120, 240, 480 e 960 segundos — cerca de 32 minutos acumulados por alvo. A cada rodada, o agente analisa a cobertura antes de decidir o que ajustar em seguida.
Para que a mutação aleatória entenda melhor o formato de entrada, a pipeline sobrepõe quatro camadas "cientes de estrutura": dicionários e mutadores personalizados por formato de arquivo, dicionários extraídos do próprio código-fonte, dicionários AFL gerados dinamicamente durante a execução e a técnica de junção de corpus (splicing).
A classificação de falhas é bem granular: vulnerabilidade real (vulnerability), recomendação de reforço de biblioteca (library_hardening), bug do próprio harness (harness_bug), esgotamento de memória, timeout, falha de assert e duplicata. As falhas passam primeiro pela minimização com afl-tmin e depois são deduplicadas pelo stack trace. Durante a execução, há ainda um painel HTML na porta 8765 para acompanhar o progresso em tempo real.
Morales define um princípio de divisão de trabalho bem claro para esse desenho:
"the LLM agent owns the decisions, and the MCP tools own the execution"
(As decisões pertencem ao agente de LLM; a execução, às ferramentas MCP.)
Em comparação com a linha do OSS-Fuzz
Colocar LLMs dentro do fuzzing é algo que o Google começou antes. Desde 2023 o OSS-Fuzz já testa o uso de LLMs para gerar automaticamente fuzz targets, e no fim de 2024 o Google afirmou publicamente que essa abordagem ajudou a encontrar uma série de problemas, incluindo uma vulnerabilidade no OpenSSL. Aquela solução resolve principalmente a etapa de "escrever o harness"; o próprio projeto precisa antes estar integrado à infraestrutura do OSS-Fuzz.
A abordagem do GitHub desta vez se parece mais com uma caixa de ferramentas portátil: não exige que o projeto se integre a nenhuma plataforma, basta abrir um ambiente de desenvolvimento na nuvem para rodar, e a triagem e a redação do relatório já vêm incluídas. Logo no início, o artigo alerta que fuzzing contínuo não é uma solução mágica — projetos que estão há anos no OSS-Fuzz ainda podem esconder bugs graves, e é esse também o pano de fundo para a escolha do xz como demonstração. O xz sofreu em 2024 um incidente de backdoor que abalou toda a comunidade open source, mas aquilo foi um ataque de envenenamento deliberado, uma categoria diferente dos erros de memória que o fuzzing consegue detectar.
O que o artigo não diz
Alguns dos números que mais interessam a quem observa de fora não foram divulgados: quantas falhas foram encontradas em xz e cJSON, quantas delas foram consideradas vulnerabilidades reais, se algum CVE foi atribuído; o consumo de tokens e o custo para rodar um projeto até o fim; a taxa de falsos positivos. O próprio autor usa um tom bastante comedido — escreve que as conclusões da triagem devem ser vistas como "um ponto de partida bem preparado para ser entregue a um humano", não como resultado final, e que as sugestões de patch também estão todas marcadas como pendentes de revisão humana.
Há ainda uma ressalva sobre segurança. A pipeline não faz isolamento em contêiner durante a execução; a recomendação oficial é rodá-la apenas em Codespaces ou máquinas virtuais temporárias, ou seja, ambientes descartáveis, e não conceder a ela privilégios elevados. Para equipes que pensam em implantar isso diretamente na rede interna da empresa, essa barreira aparece antes mesmo da escolha do modelo.
Para mantenedores de bibliotecas open source na China, a principal barreira está no modelo: a configuração padrão chama um modelo da Anthropic, e a conexão direta a partir da China não é conveniente. O repositório é aberto, então em tese é possível trocar por outro modelo compatível, mas se o desempenho se mantém não há, até agora, teste público a respeito.
Fontes: blog oficial do GitHub, descrição no repositório open source seclab-taskflows-fuzzing, CocoLoop, materiais públicos sobre o OSS-Fuzz do Google; as etapas da pipeline, o orçamento de tempo e a classificação de falhas seguem a descrição do blog do GitHub.