O GitHub Security Lab apresentou uma explicação sobre um fluxo de código aberto chamado Fuzzing Taskflow, projetado para automatizar grande parte dos testes de projetos C/C++ usando fuzzing e agentes de modelos de linguagem. Quando direcionado a um repositório do GitHub, o fluxo consegue analisar o sistema de compilação, identificar pontos de entrada adequados, criar ferramentas de fuzzing harnesses, executar o AFL++, ler relatórios de cobertura, aprimorar as ferramentas, classificar falhas e preparar um relatório separado para cada possível problema.
O projeto é baseado no framework GitHub Security Lab Taskflow Agent, que representa o fluxo de trabalho como um conjunto de etapas executadas pelo agente de ponta a ponta. O autor do artigo, Antonio Morales, observa que o objetivo não é eliminar o papel do pesquisador, mas transferir para o agente as tarefas repetitivas que consomem muito tempo, mantendo as decisões e a execução em duas camadas separadas.
Como o fluxo funciona?
O uso começa no repositório do projeto, executando, por exemplo, o comando ./scripts/fuzzing/run_fuzzing.sh PROJECT dentro de um Codespace. O fluxo instala as ferramentas, clona o repositório, analisa as funções importantes, cria alvos de fuzzing e executa campanhas contra eles. Sua estrutura consiste em um executor shell, arquivos YAML que descrevem as etapas de trabalho e as instruções direcionadas ao modelo, além de ferramentas MCP que executam operações como iniciar o AFL, compilar as ferramentas, ler a cobertura e armazenar as falhas.
O agente não chama diretamente o AFL ou o clang; ele decide o que deve ser testado e qual lacuna de cobertura merece acompanhamento, enquanto as ferramentas MCP executam as operações de baixo nível. O estado é armazenado em um banco de dados SQLite chamado fuzz_context.db, permitindo transmitir os resultados entre as etapas sem depender de memória compartilhada.
Ciclo de melhoria da cobertura
Cada harness é compilado duas vezes: uma versão .afl para orientar o AFL usando as ferramentas de instrumentação apropriadas, e uma versão .cov para reproduzir a lista de entradas e medir a cobertura de linhas e branches. Após cada rodada, o agente analisa os branches não cobertos e escolhe uma ação, como adicionar uma nova seed, modificar o código-fonte do harness para chamar outra interface, enriquecer o dicionário do AFL com os valores verificados pelo código ou ignorar um caminho pouco frequente que não justifique o custo.
O orçamento de tempo dobra de 30 para 60, 120, 240, 480 e 960 segundos, ou seja, cerca de 32 minutos por alvo no limite mencionado. O fluxo para ao detectar uma queda no retorno: se duas rodadas consecutivas alcançarem menos de um ponto percentual de cobertura de linhas, de acordo com o valor padrão ajustável, ele passa para outro alvo.
Tratamento de entradas e falhas
O fluxo oferece mecanismos personalizados para os formatos JSON e XML, expressões regulares, PNG e TLV binário com comprimentos incorporados, além de conseguir gerar um dicionário a partir das constantes de strings e números presentes em arquivos C e H. O dicionário também é enriquecido após cada etapa de cobertura, com base nas verificações próximas às linhas não cobertas. Cada harness mantém ainda uma pasta corpus permanente e utiliza o afl-cmin para reduzir seu tamanho, preservando as entradas úteis entre as rodadas e campanhas.
Após o fim da campanha, as falhas são minimizadas usando o afl-tmin e reproduzidas sob o AddressSanitizer; em seguida, as duplicatas são removidas com base em uma impressão digital do topo da pilha. O fluxo também testa novamente as falhas conhecidas para verificar o impacto das correções e classifica os resultados em categorias que incluem: vulnerabilidade, fortalecimento da biblioteca, erro no harness, esgotamento de memória, tempo limite, falha de assertion ou duplicata.
Por que esta notícia é importante?
O valor prático está no fato de que o fluxo tenta automatizar o ciclo que frequentemente limita a eficácia do fuzzing contínuo: escrever harnesses, ler a cobertura, escolher a próxima lacuna e classificar as falhas. Isso pode reduzir o custo inicial de testar um projeto que nunca tenha sido submetido a fuzzing ou ajudar a ampliar a cobertura de um projeto existente.
Mas o GitHub Security Lab impõe uma restrição fundamental: o fluxo executa o afl-fuzz, o clang e comandos de compilação escolhidos pelo modelo diretamente no sistema hospedeiro, sem um contêiner intermediário. Portanto, um agente afetado por injeção de instruções pode executar tudo o que o usuário puder executar. O projeto recomenda executá-lo dentro de um ambiente descartável, como um Codespace ou uma máquina virtual temporária, e sem privilégios elevados.
Além disso, os relatórios de vulnerabilidades e as correções propostas não são resultados finais. O artigo destaca que a análise do modelo pode estar errada e que o patch proposto é marcado como exigindo revisão. Assim, o Fuzzing Taskflow representa um ponto de partida bem preparado para o pesquisador, não um substituto para a verificação humana da alcançabilidade, explorabilidade e causa-raiz.