Key points are not available for this paper at this time.
Ferramentas e análises que encontram bugs em software estão se tornando cada vez mais prevalentes. No entanto, mesmo após lidar com os potenciais alarmes falsos levantados por tais ferramentas, muitos erros reportados reais podem permanecer sem solução. Nesses casos, os programadores julgaram que o benefício de corrigir o bug era menor do que o custo de tempo para entendê-lo e corrigi-lo. A verdadeira utilidade de uma ferramenta de detecção de bugs não reside no número de bugs que ela encontra, mas no número de bugs que leva a serem corrigidos. Análises que encontram violações de políticas de segurança geralmente fornecem relatórios de erros como backtraces anotados ou contraexemplos. Propomos que os relatórios de bugs contenham também um patch especialmente construído, descrevendo uma maneira exemplo pela qual o programa poderia ser modificado para evitar a violação de política reportada. Programadores que visualizam a saída da análise podem usar tais patches como guias, pontos de partida, ou como uma maneira adicional de entender o que deu errado. Apresentamos um algoritmo para construir automaticamente tais patches, dado informações de verificação de modelos e políticas normalmente já produzidas pela maioria dessas análises. Não temos conhecimento de quaisquer técnicas automáticas anteriores para gerar patches em resposta a violações de políticas de segurança. Nossos patches podem sugerir código adicional não presente no programa original e, assim, ajudar a explicar bugs relacionados a elementos ausentes do programa. Além disso, nossos patches não introduzem novas violações da política de segurança dada. Para avaliar nosso método, realizamos um experimento de engenharia de software, aplicando nosso algoritmo a mais de 70 relatórios de bugs produzidos por duas ferramentas de detecção de bugs convencionais rodando em grandes programas Java. Relatórios de bugs acompanhados de patches foram três vezes mais propensos a serem abordados do que relatórios de bugs padrão. Este trabalho representa um passo inicial no desenvolvimento de novas maneiras de relatar bugs e facilitar para os programadores corrigi-los. Mesmo um pequeno aumento em nossa capacidade de corrigir bugs seria um grande avanço para a qualidade do software.
Westley Weimer (Sun,) estudou esta questão.