Campanha de busca de bugs
Escolha um experimento que possa expor uma nova garantia violada e então gaste computação de acordo com o que o experimento realmente observa. Mantenha os custos de descoberta, reprodução e triagem visíveis. Velocidade é um fator de desempenho listado, junto com "A cobertura de código deve crescer ao longo do tempo" e a resolução de problemas bloqueantes, e um alvo útil "deve ter boa cobertura no código que está testando"; contagens de execução sozinhas não estabelecem alcance útil (Integração OSS-Fuzz, Cobertura, Desempenho ClusterFuzz, Fatores de desempenho).
Estabeleça a capacidade presente
Leia a revisão alvo real, o build habilitado, os produtores de harness e os corpos de asserção. Registre quais entradas, estados iniciais, operações, efeitos, agendamentos, falhas e configurações cada lane existente pode exercitar e observar. Inspecione exclusões e casos rejeitados. Use ferramentas de cobertura ou alcançabilidade apenas onde sua documentação de build/runtime se aplica; o Fuzz Introspector documenta relatórios "Para projetos escritos em C/C++, Python e Java", cada um com suas próprias ferramentas de build, portanto não é um backend universal (Fuzz Introspector, visão geral e Diferenças nas ferramentas de build). Para um projeto JavaScript ou TypeScript, leia o inventário de lane JS.
Conte uma capacidade como existente quando a implementação inspecionada a fornece. Para um alvo que já usa geração de programas válidos, comparação de resultados entre motores e históricos de transações, adicionar os mesmos mecanismos sob novos nomes não é o avanço proposto. Escolha uma interação ou observação descoberta: o dbsqlfuzz do SQLite "muta tanto a entrada SQL quanto o arquivo de banco de dados ao mesmo tempo" e encontrou falhas "perdidas por fuzzers anteriores", um precedente concreto para buscar dimensões juntas. Ele é "um testador de fuzz proprietário": tome emprestado o mecanismo, não uma ferramenta pública assumida (Teste SQLite, §2 e §4.1.3).
Torne um candidato executável
Descreva o candidato na nota de experimento existente do projeto; não introduza um serviço ou esquema obrigatório. Mantenha essas decisões juntas, com caminhos de evidência. O OSS-Fuzz pede que um alvo "faça pelo menos algum progresso" em uma execução local curta, e a reprodução precisa do build que corresponde ao relatório (Integração OSS-Fuzz, Alvo de Fuzz, reprodução, Construa a imagem e os fuzzers):
- Produtor e lacuna: ponto de entrada real mais o espaço de falha omitido pela linha de base.
- Garantia e oráculo: contrato regente, observação executável e resultados legais/não suportados/inconclusivos.
- Busca: valores/estados/operações gerados e quaisquer escolhas controladas de agendamento, falha ou configuração.
- Piloto: envelope autorizado de tempo decorrido/trabalhador/recurso, material de repetição e a evidência que justificará a próxima alocação.
Projete observações antes de multiplicar cargas de trabalho. Os objetos rastreáveis do Elle revelam dependências que sobrescritas comuns escondem, porque escritas cegas a um registro "destroem a história". Sua inferência também tem limites explícitos: o verificador é sólido e "chega perto de garantir completude", e "Nossa abordagem ignora predicados e lida apenas com objetos individuais". Um gerador que produz mais histórias não informativas não repara esses limites (Elle, §§3, 4.3 e 9). Use oraculos-de-corretude para o contrato geral e um especialista abaixo para seu modelo particular.
| Dimensão ou observação ausente | Especialista relevante |
|---|---|
| Objetos de API dependentes e sequências de operação legais | teste-de-propriedade-stateful |
| Estados de UI React ou navegador alcançáveis sem um modelo de operação, com oráculos por estado e repetição de caminho | exploracao-de-estado-ui |
| Programas válidos em tempo de execução com estado/efeitos necessários | geracao-semantica-de-programas |
| Comparação independente de execução ou relação justificada entre execuções | teste-diferencial-semantico, teste-morfologico |
| Mecanismos de instrumentação/busca ou material de busca retido | fuzzing-guiado-por-cobertura, evolucao-de-corpus |
| Diagnósticos de acesso à memória ou escolhas controladas de agendamento | instrumentacao-de-memoria-nativa, campanhas-de-deteccao-de-condicoes-de-corrida, exploracao-de-agendamento |
| Garantias de objetos concorrentes ou transações | verificacao-de-linearizabilidade, teste-de-historio-transacional |
| Falhas de implantação, ambiente controlado ou limites de recuperação | teste-de-falhas-distribuidas, simulacao-deterministica, teste-de-consistencia-de-crash |
| Restrições de caminho difíceis ou invariantes limitadas | execucao-simbolica-concolica, verificacao-de-modelo-limitado |
| Crescimento de recursos, progresso, interações de build ou precisão numérica | teste-de-complexidade-de-recursos, teste-de-vitalidade, teste-diferencial-de-configuracao, oraculos-numericos |
A tabela roteia as responsabilidades deste pacote; ela não estabelece que uma ferramenta nomeada suporta o alvo. Leia apenas o especialista selecionado e suas referências aplicáveis. Use sensibilidade-de-harness para obter evidências de que um novo oráculo alcança e rejeita violações representativas, preferencialmente através de regressões ou controles existentes; o teste de mutação do SQLite "verifica que a suíte de testes captura a mutação" (Teste SQLite, §7.6). Mantenha isso proporcional ao experimento, não uma rodada de aprovação recorrente.
Aloque a partir de evidências piloto
Execute dentro do envelope autorizado. Verifique se o código alvo e a propriedade pretendida são exercitados; distinga caminhos indisponíveis de caminhos alcançáveis que a mutação não resolveu. O Fuzz Introspector compara o "potencial de alcançabilidade estática" de cada fuzzer com a cobertura dinâmica para essa distinção. Mude o experimento quando um produtor ausente, pré-requisito semântico ou observação for o fator limitante (Fuzz Introspector, visão geral). Para diagnósticos, leia diagnóstico piloto.
Estenda uma lane informativa quando suas evidências justificarem mais busca. Compare lanes complementares onde seus mecanismos de busca diferem; AFL++ diz "Para cada fuzzer secundário deve haver uma variação" (AFL++ profundidade, §3.c Usando múltiplos núcleos). Use tempo real, trabalhadores e limites de recursos, não uma duração ou contagem de núcleos universal. Mantenha flags de tempo de execução no especialista; timeout por entrada, duração da campanha e limites de memória são controles diferentes (opções libFuzzer 23.1.0).
Mantenha contadores brutos para avaliações de propriedade e alcance semântico/código, candidatos brutos e descobertas reproduzidas, duplicatas e desconhecidos, e custo de configuração/execução/redução/triagem. Não os colapse em uma pontuação de produtividade inventada. Onde alegações comparativas importam, use condições combinadas e tentativas repetidas com variabilidade; FuzzBench relata "o número de tentativas, média, mediana, desvio padrão" e a "distribuição das coberturas alcançadas" em vez de uma única execução sortuda (Relatório FuzzBench, Resumo por benchmark).
Preserve entradas originais, estado inicial, fonte/build/configuração, instrumentação, saídas brutas e escolhas de repetição antes de resumir. Um caso de teste OSS-Fuzz "contém os bytes que foram fornecidos ao" alvo, e alguns bugs "são reproduzíveis apenas em modo 32 bits ou apenas em modo 64 bits" sob o sanitizador relatado; uma semente sozinha não é esse artefato completo (Reprodução OSS-Fuzz, Bugs do alvo de fuzz e Construa a imagem e os fuzzers). Encaminhe candidatos para reducao-de-falhas e triagem-baseada-em-evidencia; deixe descobertas não confiáveis ou não resolvidas visíveis em vez de contar ou descartá-las silenciosamente. O ClusterFuzz filtra pela confiabilidade da reprodução e mantém estatísticas "sobre com que frequência os problemas ocorrem, e sob quais condições" (Triagem ClusterFuzz, Filtrando casos de teste e Estatísticas de crash).
Finalize a decisão de alocação
Registre continuar, mudar de dimensão, reproduzir/reduzir/triar ou parar, com a razão observada e o espaço restante. Um platô motiva diagnóstico; ele não prova nem corretude nem que outra ferramenta ajudará. Preserve zero descobertas como um resultado limitado. Uma fila de candidatos não processados pode justificar gastar a próxima parcela em evidência em vez de geração. Para alvos libFuzzer ou AFL guiados por cobertura, o ClusterFuzz aconselha que quando um alvo encontra muitos novos crashes, "corrigi-los é provavelmente mais importante do que analisar desempenho" (Desempenho ClusterFuzz, Quando analisar o desempenho do alvo de fuzz).
Retorne a garantia testada, orçamento real, comportamento alcançado, caminhos de evidência, descobertas classificadas e próxima decisão. Descreva efeitos visíveis ao usuário onde estabelecidos; mantenha uma causa possível separada de uma violação demonstrada. Para um exemplo trabalhado de alocação e registro, leia exemplo de campanha; para atalhos enganosos, leia erros comuns.
A invocação preserva o escopo existente do usuário e as regras de execução. Ela não autoriza, por si só, alterações no alvo, instalações, gastos em nuvem, injeção de falhas de produção ou publicação externa.