O GitHub Security Lab apresentou em 24 de setembro de 2026 o Fuzzing Taskflow, um pipeline de fuzzing autônomo voltado a projetos escritos em C e C++. O anúncio foi feito pelo pesquisador Antonio Morales, que assina a publicação no blog da companhia.
Ele descreve um fluxo capaz de conduzir boa parte do trabalho que hoje ainda depende de analistas humanos. A ferramenta é construída sobre o GitHub Security Lab Taskflow Agent, framework do próprio laboratório para escrever automações de segurança dirigidas por modelos de linguagem.
O que a pipeline faz sozinha
Basta apontar o sistema para um repositório no formato owner/repo. O exemplo citado no texto é tukaani-project/xz.
O agente assume as etapas seguintes.
Ele instala softwares como o AFL, identifica as funções mais relevantes do código, cria alvos de fuzz, analisa o sistema de build, escreve os harnesses, executa o AFL++, lê os relatórios de cobertura, melhora os harnesses, faz a triagem de cada crash e produz um relatório de vulnerabilidade para cada bug único encontrado. Para quem quer apenas um teste rápido antes de comprometer tempo com uma campanha longa, o autor sugere usar o projeto DaveGamble/cJSON, menor e mais adequado a uma verificação inicial.
A motivação vem de uma limitação conhecida de quem trabalha com fuzzing contínuo. Mesmo projetos que estão há anos no OSS-Fuzz podem esconder falhas críticas.
O motivo costuma ser sempre o mesmo: alguém precisa acompanhar a cobertura, escrever novos harnesses para trechos que ninguém alcança e triar os crashes resultantes. Ou seja, ainda há um humano no meio do processo.
A pergunta que Morales diz ter se feito é justamente quanto desse trabalho poderia ser entregue a um agente baseado em LLM.
Como a arquitetura está organizada
O pipeline se divide em três camadas. A primeira é um driver em shell, o script run_fuzzing.sh, que encadeia os estágios.
A segunda é um conjunto de arquivos YAML de taskflow, um por etapa, funcionando essencialmente como os prompts que orientam o agente sobre o que fazer a cada passo. A terceira reúne as ferramentas MCP que o agente chama para executar o trabalho: rodar o AFL, compilar um harness, armazenar um crash, ler um relatório de cobertura.
A regra de projeto que o autor destaca é a separação clara de responsabilidades: o agente LLM toma as decisões, e as ferramentas MCP executam. O agente decide o que fuzzar, qual harness escrever e qual lacuna de cobertura perseguir em seguida.
As ferramentas expõem primitivas como run_afl_for ou compile_harness. O agente nunca chama AFL ou clang diretamente, apenas compõe o pipeline com esses blocos.
Todo o estado fica em um banco SQLite, o fuzz_context.db, de modo que os estágios não trocam dados em memória, apenas pelo banco.
Um detalhe pequeno mas importante: cada harness é compilado duas vezes. A instrumentação de arestas do AFL é ótima para guiar o fuzzer, mas inútil para relatórios de cobertura legíveis por humanos.
Por isso todo harness vira tanto um binário.afl, construído com afl-clang-lto e sanitizadores de endereço e de comportamento indefinido, quanto um binário.cov, gerado com clang e instrumentação de cobertura. O primeiro fuzza; o segundo reproduz a fila do AFL depois para produzir cobertura real de linhas e ramos do código-fonte.
O ciclo de feedback de cobertura
O coração do sistema é o laço que automatiza o trabalho manual descrito no início. Em cada iteração, para cada harness, o agente executa o AFL por um orçamento de tempo, reproduz a fila contra o binário.cov para obter um relatório de cobertura verdadeiro e lê a lista de ramos não cobertos.
A partir do que encontra, escolhe uma entre algumas ações: adicionar uma nova semente criada para alcançar um ramo específico, editar o código do harness para chamar uma API adicional ou enriquecer automaticamente o dicionário do AFL com as constantes mágicas que determinada verificação compara.
Na escolha do modelo, o texto menciona que alguns modelos de fronteira impõem restrições de segurança às próprias saídas. Para essa tarefa, o padrão adotado é o Claude Sonnet 5, que passou em todos os testes internos sem problemas.
A troca por outro modelo é feita editando o arquivo de configuração model_config.yaml no repositório.
Riscos que acompanham a autonomia
O autor faz um alerta explícito: o taskflow executa afl-fuzz, clang e comandos de build arbitrários escolhidos pelo LLM diretamente no host, sem contêiner intermediário. Um agente vítima de prompt injection poderia, em princípio, fazer qualquer coisa que o usuário possa fazer.
A recomendação é rodar apenas em ambiente descartável, como um Codespace ou uma máquina virtual temporária, e sem privilégios elevados. Para quem está começando, o material aponta ainda o curso Fuzzing 101 como ponto de partida nos fundamentos da técnica.
