Identificação de relatórios de bugs de segurança com base em títulos de relatórios e dados barulhentos

Mayana Pereira	Scott Christiansen
CELA Ciência de Dados	Segurança e Confiança do Cliente
Microsoft	Microsoft

Resumo — Identificar relatórios de bugs de segurança (SBRs) é uma etapa vital no ciclo de vida de desenvolvimento de software. Em abordagens supervisionadas baseadas em aprendizado de máquina, é comum assumir que relatórios de bugs inteiros estão disponíveis para treinamento e que seus rótulos são livres de ruído. Pelo que sabemos, este é o primeiro estudo a demonstrar que é possível prever com precisão os rótulos para SBRs, mesmo quando apenas o título está disponível e na presença de ruído nos rótulos.

pt-PT: Termos de Índice — Aprendizagem Automática, Rotulagem Incorreta, Ruído, Relatório de Erro de Segurança, Repositórios de Erros

I. INTRODUÇÃO

Identificar problemas relacionados à segurança entre os bugs relatados é uma necessidade premente entre as equipes de desenvolvimento de software, pois tais problemas exigem correções mais rápidas para atender aos requisitos de conformidade e garantir a integridade do software e dos dados do cliente.

As ferramentas de machine learning e inteligência artificial prometem tornar o desenvolvimento de software mais rápido, ágil e correto. Vários investigadores aplicaram a aprendizagem automática ao problema da identificação de bugs de segurança [2], [7], [8], [18]. Estudos publicados anteriormente assumiram que todo o relatório de bug está disponível para treinamento e pontuação de um modelo de aprendizado de máquina. Não é necessariamente o caso. Há situações em que todo o relatório de bug não pode ser disponibilizado. Por exemplo, o relatório de bug pode conter senhas, informações de identificação pessoal (PII) ou outros tipos de dados confidenciais - um caso que estamos enfrentando atualmente na Microsoft. Portanto, é importante estabelecer quão bem a identificação de bugs de segurança pode ser realizada usando menos informações, como quando apenas o título do relatório de bug está disponível.

Além disso, os repositórios de bugs geralmente contêm entradas rotuladas incorretamente [7]: relatórios de bugs não relacionados à segurança classificados como relacionados à segurança e vice-versa. Existem várias razões para a ocorrência de erros de rotulagem, que vão desde a falta de experiência da equipe de desenvolvimento em segurança, até a imprecisão de certos problemas, por exemplo, é possível que bugs não relacionados à segurança sejam explorados de forma indireta para causar uma implicação de segurança. Este é um problema sério, uma vez que a rotulagem incorreta de SBRs resulta em especialistas em segurança tendo que revisar manualmente o banco de dados de bugs em um esforço caro e demorado. Entender como o ruído afeta diferentes classificadores e quão robustas (ou frágeis) são diferentes técnicas de aprendizado de máquina na presença de conjuntos de dados contaminados com diferentes tipos de ruído é um problema que deve ser abordado para trazer a classificação automática para a prática da engenharia de software.

O trabalho preliminar argumenta que os repositórios de bugs são intrinsecamente barulhentos e que o ruído pode ter um efeito adverso sobre os classificadores de aprendizado de máquina de desempenho [7]. Falta, no entanto, qualquer estudo sistemático e quantitativo sobre como diferentes níveis e tipos de ruído afetam o desempenho de diferentes algoritmos supervisionados de aprendizado de máquina para o problema de identificação de relatórios de bugs de segurança (RBS).

Neste estudo, mostramos que a classificação de relatórios de bugs pode ser realizada mesmo quando apenas o título está disponível para treinamento e pontuação. Tanto quanto sabemos, este é o primeiro trabalho a fazê-lo. Além disso, fornecemos o primeiro estudo sistemático do efeito do ruído na classificação de relatórios de bugs. Fazemos um estudo comparativo da robustez de três técnicas de aprendizagem automática (regressão logística, Bayes ingénuo e AdaBoost) contra ruído independente da classe.

Embora existam alguns modelos analíticos que capturam a influência geral do ruído para alguns classificadores simples [5], [6], esses resultados não fornecem limites apertados sobre o efeito do ruído na precisão e são válidos apenas para uma técnica específica de aprendizado de máquina. Uma análise precisa do efeito do ruído em modelos de aprendizado de máquina geralmente é realizada executando experimentos computacionais. Estas análises foram efetuadas para vários cenários, desde dados de medição de software [4] até à classificação de imagens de satélite [13] e dados médicos [12]. No entanto, estes resultados não podem ser traduzidos para o nosso problema específico, devido à sua elevada dependência da natureza dos conjuntos de dados e do problema de classificação subjacente. Até onde sabemos, não há resultados publicados sobre o problema do efeito de conjuntos de dados barulhentos na classificação de relatórios de bugs de segurança em particular.

AS NOSSAS CONTRIBUIÇÕES DE INVESTIGAÇÃO:

• Treinamos classificadores para a identificação de relatórios de bugs de segurança (SBRs) com base apenas no título dos relatórios. Pelo que sabemos, este é o primeiro estudo a fazê-lo. Os trabalhos anteriores usavam o relatório de bug completo ou aprimoravam o relatório de bug com recursos complementares adicionais. Classificar erros com base apenas no título é particularmente relevante quando os relatórios completos dos erros não podem ser disponibilizados devido a preocupações de privacidade. Por exemplo, é notório o caso de relatórios de bugs que contêm senhas e outros dados sensíveis.

• Também fornecemos o primeiro estudo sistemático da tolerância ao ruído do rótulo de diferentes modelos e técnicas de aprendizado de máquina usados para a classificação automática de SBRs. Fazemos um estudo comparativo da robustez de três técnicas distintas de aprendizagem automática (regressão logística, Bayes ingénuo e AdaBoost) contra ruído dependente e independente de classe.

O restante do artigo é apresentado da seguinte forma: Na seção II apresentamos alguns dos trabalhos anteriores da literatura. Na seção III, descrevemos o conjunto de dados e como os dados são pré-processados. A metodologia é descrita na seção IV e os resultados de nossos experimentos analisados na seção V. Finalmente, as nossas conclusões e trabalhos futuros são apresentados em VI.

II. TRABALHOS ANTERIORES

APLICAÇÕES DE APRENDIZAGEM AUTOMÁTICA EM REPOSITÓRIOS DE ERROS.

Existe uma extensa literatura na aplicação de mineração de texto, processamento de linguagem natural e aprendizado de máquina em repositórios de bugs na tentativa de automatizar tarefas trabalhosas, como deteção de bugs de segurança [2], [7], [8], [18], identificação de duplicados de bugs [3], triagem de bugs [1], [11], para citar alguns aplicativos. Idealmente, o casamento do aprendizado de máquina (ML) com o processamento de linguagem natural potencialmente reduz o trabalho manual necessário para selecionar bancos de dados de bugs, encurta o tempo necessário para realizar essas tarefas e pode aumentar a confiabilidade dos resultados.

Em [7] os autores propõem um modelo de linguagem natural para automatizar a classificação de SBRs com base na descrição do bug. Os autores extraem um vocabulário de todas as descrições de bugs no conjunto de dados de treinamento e o organizam manualmente em três listas de palavras: palavras relevantes, palavras de parada (palavras comuns que parecem irrelevantes para a classificação) e sinônimos. Eles comparam o desempenho de um classificador de bugs de segurança treinado em dados avaliados por engenheiros de segurança e de um classificador treinado em dados rotulados por repórteres de bugs de forma geral. Embora seu modelo seja claramente mais eficaz quando treinado em dados revisados por engenheiros de segurança, o modelo proposto é baseado em um vocabulário derivado manualmente, o que o torna dependente da curadoria humana. Além disso, não há análise de como diferentes níveis de ruído afetam seu modelo, como diferentes classificadores respondem ao ruído e se o ruído em qualquer classe afeta o desempenho de forma diferente.

Zou et. al [18] fazem uso de vários tipos de informações contidas em um relatório de bug que envolvem os campos não textuais de um relatório de bug (meta-características, por exemplo, tempo, gravidade e prioridade) e o conteúdo textual de um relatório de bug (recursos textuais, ou seja, o texto em campos de resumo). Com base nesses recursos, eles constroem um modelo para identificar automaticamente os SBRs por meio de técnicas de processamento de linguagem natural e aprendizado de máquina. Em [8] os autores realizam uma análise semelhante, mas adicionalmente comparam o desempenho de técnicas de aprendizado de máquina supervisionadas e não supervisionadas e estudam a quantidade de dados necessários para treinar seus modelos.

Em [2] os autores também exploram diferentes técnicas de aprendizado de máquina para classificar bugs como SBRs ou NSBRs (Non-Security Bug Report) com base em suas descrições. Eles propõem um pipeline para processamento de dados e treinamento de modelos com base no TFIDF. Eles comparam o pipeline proposto com um modelo baseado em bag-of-words e naive Bayes. Wijayasekara et al. [16] também usaram técnicas de extração de texto para gerar o vetor de características de cada relatório de bug com base em palavras frequentes para identificar Bugs de Impacto Oculto (HIB). Yang et al. [17] afirmaram identificar relatórios de bugs de alto impacto (por exemplo, SBRs) com o auxílio do Term Frequency (TF) e do Naive Bayes. Em [9] os autores propõem um modelo para prever a gravidade de um bug.

RUÍDO DA ETIQUETA

O problema de lidar com conjuntos de dados com ruído nos rótulos tem sido amplamente estudado. Frenay e Verleysen propõem uma taxonomia de ruído de rótulo em [6], a fim de distinguir diferentes tipos de rótulo ruidoso. Os autores propõem três tipos diferentes de ruído: ruído de rótulo que ocorre independentemente da classe real e dos valores das características da instância; ruído de rótulo que depende apenas do rótulo verdadeiro; e ruído de rótulo em que a probabilidade de rotulagem incorreta também depende dos valores das características. No nosso trabalho estudamos os dois primeiros tipos de ruído. Do ponto de vista teórico, o ruído do rótulo geralmente diminui o desempenho de um modelo [10], exceto em alguns casos específicos [14]. Em geral, métodos robustos baseiam-se na prevenção do excesso de equipamento para lidar com o ruído dos rótulos [15]. O estudo dos efeitos do ruído na classificação já foi feito anteriormente em muitas áreas, como a classificação de imagens de satélite [13], a classificação da qualidade do software [4] e a classificação do domínio médico [12]. Tanto quanto sabemos, não existem trabalhos publicados que estudem a quantificação precisa dos efeitos de rótulos ruidosos no problema da classificação SBR. Neste cenário, a relação precisa entre os níveis de ruído, os tipos de ruído e a degradação do desempenho não foi estabelecida. Além disso, vale a pena entender como diferentes classificadores se comportam na presença de ruído. De um modo mais geral, não temos conhecimento de qualquer trabalho que estude sistematicamente o efeito de conjuntos de dados ruidosos no desempenho de diferentes algoritmos de aprendizagem automática no contexto de relatórios de bugs de software.

III. DESCRIÇÃO DO CONJUNTO DE DADOS

Nosso conjunto de dados consiste em 1.073.149 títulos de bugs, dos quais 552.073 correspondem a SBRs e 521.076 a NSBRs. Os dados foram coletados de várias equipes da Microsoft nos anos de 2015, 2016, 2017 e 2018. Todos os rótulos foram obtidos por sistemas de verificação de bugs baseados em assinatura ou etiquetados por humanos. Os títulos de bugs no nosso conjunto de dados são textos muito curtos, contendo cerca de 10 palavras, com uma visão geral do problema.

Um. Pré-processamento de dados Analisamos cada título de bug por seus espaços em branco, resultando em uma lista de tokens. Processamos cada lista de tokens da seguinte forma:

• Remova todos os tokens que são caminhos de arquivo

• Tokens divididos onde os seguintes símbolos estão presentes: { , (, ), -, }, {, [, ], }

• Remova as palavras de paragem, os tokens que são compostos apenas por caracteres numéricos e os tokens que aparecem menos de 5 vezes em todo o corpus.

IV. METODOLOGIA

O processo de treinamento de nossos modelos de aprendizado de máquina consiste em duas etapas principais: codificação dos dados em vetores de recursos e treinamento de classificadores supervisionados de aprendizado de máquina.

Um. Vetores de recursos e técnicas de aprendizado de máquina

A primeira parte envolve a codificação de dados em vetores de feição usando o termo algoritmo de frequência de documento inverso de frequência (TF-IDF), como usado em [2]. TF-IDF é uma técnica de recuperação de informação que pesa a frequência dos termos (TF) e sua frequência inversa de documento (IDF). Cada palavra ou termo tem sua respetiva pontuação TF e IDF. O algoritmo TF-IDF atribui a importância a essa palavra com base no número de vezes que ela aparece no documento e, mais importante, verifica o quão relevante a palavra-chave é ao longo da coleção de títulos no conjunto de dados. Treinamos e comparamos três técnicas de classificação: Bayes ingênuo (NB), árvores de decisão impulsionadas (AdaBoost) e regressão logística (LR). Escolhemos essas técnicas porque elas demonstraram um bom desempenho para a tarefa relacionada de identificar relatórios de bugs de segurança com base em todo o relatório na literatura. Estes resultados foram confirmados numa análise preliminar onde estes três classificadores superaram as máquinas vetoriais de suporte e as florestas aleatórias. Em nossos experimentos, utilizamos a biblioteca scikit-learn para codificação e treinamento de modelos.

B. Tipos de Ruído

O ruído estudado neste trabalho refere-se ao ruído no rótulo da classe nos dados de treinamento. Na presença de tal ruído, como consequência, o processo de aprendizagem e o modelo resultante são prejudicados por exemplos mal rotulados. Analisamos o impacto dos diferentes níveis de ruído aplicados às informações da classe. Tipos de ruído de rótulo têm sido discutidos anteriormente na literatura usando várias terminologias. Em nosso trabalho, analisamos os efeitos de dois ruídos de rótulos diferentes em nossos classificadores: ruído de rótulo independente de classe, que é introduzido escolhendo instâncias aleatoriamente e invertendo seu rótulo; e ruído dependente da classe, em que as classes têm diferentes probabilidades de serem ruidosas.

a) Ruído independente de classe: Ruído independente de classe refere-se ao ruído que ocorre independentemente da verdadeira classe das instâncias. Neste tipo de ruído, a probabilidade de rotular incorretamente p_br é a mesma para todas as instâncias no conjunto de dados. Introduzimos ruído independente de classe em nossos conjuntos de dados invertendo cada rótulo em nosso conjunto de dados aleatoriamente com probabilidade p_br.

b) Ruído dependente da classe: O ruído dependente da classe refere-se ao ruído que depende da verdadeira classe das instâncias. Neste tipo de ruído, a probabilidade de rotulagem incorreta na classe SBR é p_sbr e a probabilidade de rotulagem incorreta na classe NSBR é p_nsbr. Introduzimos ruído dependente de classe no nosso conjunto de dados ao alterar cada entrada cuja etiqueta verdadeira é SBR com probabilidade p_sbr. Analogamente, alteramos o rótulo de classe das instâncias NSBR com uma probabilidade de p_nsbr.

c) Ruído de Classe Única: O ruído de classe única é um caso especial de ruído dependente de classe, onde p_nsbr = 0 e p_sbr> 0. Note que para ruído independente de classe temos p_sbr = p_nsbr = p_br.

C. Geração de Ruído

Nossos experimentos investigam o impacto de diferentes tipos e níveis de ruído no treinamento de classificadores SBR. Em nossos experimentos, definimos 25% do conjunto de dados como dados de teste, 10% como validação e 65% como dados de treinamento.

Adicionamos ruído aos conjuntos de dados de treinamento e validação para diferentes níveis de p_br, p_sbr e p_nsbr . Não fazemos quaisquer modificações ao conjunto de dados de teste. Os diferentes níveis de ruído utilizados são P = {0,05 × i|0 < i < 10}.

Em experimentos de ruído independentes de classe, para p_br ∈ P fazemos o seguinte:

• Gerar ruído para conjuntos de dados de treinamento e validação;

• Treinar regressão logística, modelos Bayes e AdaBoost ingênuos usando conjunto de dados de treinamento (com ruído); * Sintonizar modelos usando conjunto de dados de validação (com ruído);

• Testar modelos usando o conjunto de dados de teste (sem ruído).

Em experimentos de ruído dependentes de classe, para p_sbr ∈ P e p_nsbr ∈ P fazemos o seguinte para todas as combinações de p_sbr e p_nsbr:

• Gerar ruído para conjuntos de dados de treinamento e validação;

• Treinar regressão logística, modelos Bayes e AdaBoost ingênuos usando conjunto de dados de treinamento (com ruído);

• Sintonizar modelos utilizando conjunto de dados de validação (com ruído);

• Teste modelos usando o conjunto de dados de teste (sem ruído).

V. RESULTADOS EXPERIMENTAIS

Nesta seção analise os resultados de experimentos conduzidos de acordo com a metodologia descrita na seção IV.

a) Desempenho do modelo sem ruído no conjunto de dados de treinamento: Uma das contribuições deste artigo é a proposta de um modelo de aprendizado de máquina para identificar bugs de segurança usando apenas o título do bug como dados para a tomada de decisão. Isso permite o treinamento de modelos de aprendizado de máquina mesmo quando as equipes de desenvolvimento não desejam compartilhar relatórios de bugs na íntegra devido à presença de dados confidenciais. Comparamos o desempenho de três modelos de aprendizado de máquina quando treinados usando apenas títulos de bugs.

O modelo de regressão logística é o classificador com melhor desempenho. É o classificador com o maior valor de AUC, de 0,9826, e um recall de 0,9353 para um valor de FPR de 0,0735. O ingênuo Classificador Bayes apresenta desempenho ligeiramente inferior ao Classificador de regressão logística, com uma AUC de 0,9779 e um recall de 0,9189 para um FPR de 0,0769. O classificador AdaBoost tem um desempenho inferior em comparação com os dois classificadores mencionados anteriormente. Ele atinge uma AUC de 0,9143, e um recall de 0,7018 para um FPR de 0,0774. A área sob a curva ROC (AUC) é uma boa métrica para comparar o desempenho de vários modelos, pois resume em um único valor a relação TPR vs. FPR. Na análise subsequente, restringiremos a nossa análise comparativa aos valores da AUC.

Um. Ruído de classe: classe singular

Pode-se imaginar um cenário em que todos os bugs são atribuídos à classe NSBR por padrão, e um bug só será atribuído à classe SBR se houver um especialista em segurança revisando o repositório de bugs. Este cenário é representado no cenário experimental de classe única, onde assumimos que p_nsbr = 0 e 0 < p_sbr< 0,5.

A partir da tabela II, observamos um impacto muito pequeno na AUC para os três classificadores. A AUC-ROC de um modelo treinado em p_sbr = 0, em comparação com um AUC-ROC do modelo onde p_sbr = 0,25, difere em 0,003 para regressão logística, 0,006 para Naïve Bayes e 0,006 para AdaBoost. No caso de p_sbr = 0,50, a AUC medida para cada um dos modelos difere do modelo treinado com p_sbr = 0 por 0,007 para regressão logística, 0,011 para Bayes ingênuos e 0,010 para AdaBoost. classificador de regressão logística treinado na presença de ruído de classe única apresenta a menor variação em sua métrica AUC, ou seja, um comportamento mais robusto, quando comparado aos nossos ingênuos classificadores Bayes e AdaBoost.

B. Ruído de classe: independente da classe

Comparamos o desempenho dos nossos três classificadores para o caso em que o conjunto de treinamento é corrompido por um ruído independente da classe. Medimos a AUC para cada modelo treinado com diferentes níveis de p_br nos dados de treinamento.

Na Tabela III observa-se uma diminuição do AUC-ROC para cada incremento de ruído no experimento. O AUC-ROC medido a partir de um modelo treinado em dados sem ruído em comparação com um AUC-ROC de um modelo treinado com ruído independente de classe, com p_br = 0,25, difere por 0,011 para regressão logística, 0,008 para Bayes ingênuo e 0,0038 para AdaBoost. Observamos que o ruído da etiqueta não afeta significativamente a AUC dos classificadores Bayes e AdaBoost ingênuos quando os níveis de ruído são inferiores a 40%. Por outro lado, o Classificador de regressão logística experimenta um impacto na medida da AUC para níveis de ruído da etiqueta acima de 30%.

Fig. 1. Variação de AUC-ROC no ruído independente da classe. Para um nível de ruído p_br =0,5 o classificador atua como um classificador aleatório, ou seja, AUC≈0,5. Mas podemos observar que para níveis de ruído mais baixos (p_br ≤0,30), o aluno de regressão logística apresenta melhor desempenho em comparação com os outros dois modelos. No entanto, para 0,35≤ p_br ≤0,45 aluno Bayes ingênuo apresenta melhores métricas AUCROC.

C. Ruído de classe: dependente da classe

No conjunto final de experimentos, consideramos um cenário onde diferentes classes contêm diferentes níveis de ruído, ou seja, p_sbr ≠ p_nsbr. Incrementamos sistematicamente p_sbr e p_nsbr de forma independente em 0,05 nos dados de treino e observamos a mudança de comportamento dos três classificadores.

As tabelas IV, V, VI mostram a variação da AUC à medida que o ruído é aumentado em diferentes níveis em cada classe para regressão logística na Tabela IV, para Bayes naïve na Tabela V e para AdaBoost na Tabela VI. Para todos os classificadores, notamos um impacto na métrica da AUC quando ambas as classes apresentam um nível de ruído superior a 30%. Bayes ingênuo se comporta de forma robusta. O impacto na AUC é muito pequeno, mesmo quando os 50% do rótulo na classe positiva são invertidos, desde que a classe negativa contenha 30% de rótulos ruidosos ou menos. Neste caso, a queda na AUC é de 0,03. O AdaBoost apresentou o comportamento mais robusto dos três classificadores. Uma mudança significativa na AUC só acontecerá para níveis de ruído superiores a 45% em ambas as classes. Nesse caso, começamos a observar um decaimento AUC maior que 0,02.

D. Sobre a presença de ruído residual no conjunto de dados original

Nosso conjunto de dados foi rotulado por sistemas automatizados baseados em assinatura e por especialistas humanos. Além disso, todos os relatórios de bugs foram revisados e fechados por especialistas humanos. Embora esperemos que a quantidade de ruído em nosso conjunto de dados seja mínima e não estatisticamente significativa, a presença de ruído residual não invalida nossas conclusões. De facto, para efeitos de ilustração, suponha que o conjunto de dados original está corrompido por um ruído independente da classe igual a 0 < p < 1/2, sendo este independente e distribuído de forma idêntica (i.i.d) para cada entrada.

Se, além do ruído original, adicionarmos um ruído independente de classe com probabilidade p_br i.i.d, o ruído resultante por entrada será p∗ = p(1 − p_br )+(1 − p)p_br . Para 0 < p,p_br< 1/2, temos que o ruído real por etiqueta p∗ é estritamente maior do que o ruído que adicionamos artificialmente ao conjunto de dados p_br . Assim, o desempenho de nossos classificadores seria ainda melhor se eles fossem treinados com um conjunto de dados completamente silencioso (p = 0) em primeiro lugar. Em resumo, a existência de ruído residual no conjunto de dados real significa que a resiliência contra o ruído dos nossos classificadores é melhor do que os resultados aqui apresentados. Além disso, se o ruído residual em nosso conjunto de dados fosse estatisticamente relevante, a AUC de nossos classificadores se tornaria 0,5 (um palpite aleatório) para um nível de ruído estritamente inferior a 0,5. Não observamos tal comportamento em nossos resultados.

VI. CONCLUSÕES E TRABALHOS FUTUROS

A nossa contribuição neste artigo tem duas vertentes.

Primeiro, mostramos a viabilidade da classificação do relatório de bug de segurança com base apenas no título do relatório de bug. Isso é particularmente relevante em cenários em que todo o relatório de bug não está disponível devido a restrições de privacidade. Por exemplo, no nosso caso, os relatórios de bugs continham informações privadas, como senhas e chaves criptográficas, e não estavam disponíveis para treinar os classificadores. Nosso resultado mostra que a identificação SBR pode ser realizada com alta precisão, mesmo quando apenas os títulos dos relatórios estão disponíveis. Nosso modelo de classificação que utiliza uma combinação de TF-IDF e regressão logística é realizado a uma AUC de 0,9831.

Em segundo lugar, analisamos o efeito de dados de treinamento e validação rotulados incorretamente. Comparámos três técnicas de classificação de aprendizagem automática bem conhecidas (Bayes ingénuos, regressão logística e AdaBoost) em termos da sua robustez face a diferentes tipos de ruído e níveis de ruído. Todos os três classificadores são robustos para ruído de classe única. O ruído nos dados de treinamento não tem efeito significativo no classificador resultante. A diminuição da AUC é muito pequena ( 0,01) para um nível de ruído de 50%. Para o ruído presente em ambas as classes e independente da classe, os modelos Bayes e AdaBoost ingénuos apresentam variações significativas na AUC apenas quando treinados com um conjunto de dados com níveis de ruído superiores a 40%.

Finalmente, o ruído dependente da classe afeta significativamente a AUC apenas quando há mais de 35% ruído em ambas as classes. O AdaBoost mostrou a maior robustez. O impacto na AUC é muito pequeno, mesmo quando a classe positiva tem 50% dos seus rótulos ruidosos, contanto que a classe negativa contenha 45% de rótulos ruidosos ou menos. Neste caso, a queda na AUC é inferior a 0,03. Até onde sabemos, este é o primeiro estudo sistemático sobre o efeito de conjuntos de dados barulhentos para a identificação de relatórios de bugs de segurança.

TRABALHOS FUTUROS

Neste artigo iniciamos o estudo sistemático dos efeitos do ruído no desempenho de classificadores de machine learning para a identificação de bugs de segurança. Há várias sequências interessantes para este trabalho, incluindo: examinar o efeito de conjuntos de dados barulhentos na determinação do nível de gravidade de um bug de segurança; compreender o efeito do desequilíbrio de classes na resiliência dos modelos treinados contra o ruído; compreender o efeito do ruído introduzido adversariamente no conjunto de dados.

REFERÊNCIAS

[1] John Anvik, Lyndon Hiew e Gail C Murphy. Quem deve corrigir este bug? Nas Atas da 28ª Conferência Internacional de Engenharia de Software, páginas 361-370. ACM, 2006.

[2] Diksha Behl, Sahil Handa e Anuja Arora. Uma ferramenta de detecção de bugs para identificar e analisar bugs de segurança usando Naive Bayes e tf-idf. In Optimization, Reliabilty, and Information Technology (ICROIT), Conferência Internacional de 2014, páginas 294–299. IEEE, 2014.

[3] Nicolas Bettenburg, Rahul Premraj, Thomas Zimmermann e Sunghun Kim. Realmente, relatórios de bugs duplicados são considerados prejudiciais? Em Manutenção de Software, 2008. ICSM 2008. Conferência Internacional do IEEE sobre, páginas 337–345. IEEE, 2008.

[4] Andres Folleco, Taghi M Khoshgoftaar, Jason Van Hulse e Lofton Bullard. Identificação de alunos robustos a dados de baixa qualidade. Em Reutilização e Integração da Informação, 2008. IRI 2008. Conferência Internacional do IEEE sobre, páginas 190–195. IEEE, 2008.

[5] Benoˆıt Frenay.' Incerteza e ruído de etiquetas na aprendizagem automática. Tese de doutoramento, Universidade Católica de Lovaina, Louvain-la-Neuve, Bélgica, 2013.

[6] Benoˆıt Frenay e Michel Verleysen. Classificação na presença de ruído de rótulo: um levantamento. IEEE Transactions on Neural Networks and Learning Systems, 25(5):845–869, 2014.

[7] Michael Gegick, Pete Rotella e Tao Xie. Identificação de relatórios de bugs de segurança por meio de mineração de texto: um estudo de caso industrial. Na conferência de trabalho da IEEE, 7ª edição, 2010, sobre Mining software repositories (MSR), em, páginas 11–20. IEEE, 2010.

[8] Katerina Goseva-Popstojanova e Jacob Tyo. Identificação de relatórios de bugs relacionados à segurança via mineração de texto usando classificação supervisionada e não supervisionada. Em 2018 IEEE International Conference on Software Quality, Reliability and Security (QRS), páginas 344–355, 2018.

[9] Ahmed Lamkanfi, Serge Demeyer, Emanuel Giger e Bart Goethals. Prevendo a gravidade de um bug relatado. Na Mining Software Repositories (MSR), 7ª Conferência de Trabalho IEEE em 2010 sobre, páginas 1–10. IEEE, 2010.

[10] Naresh Manwani e PS Sastry. Tolerância ao ruído sob minimização de riscos. IEEE transactions on cybernetics, 43(3):1146–1151, 2013.

[11] G Murphy e D Cubranic. Triagem automática de bugs usando categorização de texto. In Anais da Décima Sexta Conferência Internacional sobre Engenharia de Software & Engenharia do Conhecimento. Citeseer, 2004.

[12] Mykola Pechenizkiy, Alexey Tsymbal, Seppo Puuronen e Oleksandr Pechenizkiy. Ruído de aula e aprendizagem supervisionada em domínios médicos: O efeito da extração de características. Em nulo, páginas 708-713. IEEE, 2006.

[13] Charlotte Pelletier, Silvia Valero, Jordi Inglada, Nicolas Champion, Claire Marais Sicre e Gerard Dedieu. Efeito do ruído nos rótulos das classes de treino no desempenho da classificação para mapeamento de cobertura do solo com séries temporais de imagens de satélite. Sensoriamento Remoto, 9(2):173, 2017.

[14] PS Sastry, GD Nagendra e Naresh Manwani. Uma equipa de autómatos de aprendizagem de ação contínua para a aprendizagem tolerante ao ruído de semiespaços. IEEE Transactions on Systems, Man, and Cybernetics, Parte B (Cibernética), 40(1):19–28, 2010.

[15] Choh-Man Teng. Uma comparação das técnicas de manipulação de ruído. In FLAIRS Conference, páginas 269-273, 2001.

[16] Dumidu Wijayasekara, Milos Manic e Miles McQueen. Identificação e classificação de vulnerabilidades através de bases de dados de bugs de mineração de texto. In Industrial Electronics Society, IECON 2014-40th Annual Conference of the IEEE, páginas 3612–3618. IEEE, 2014.

[17] Xinli Yang, David Lo, Qiao Huang, Xin Xia e Jianling Sun. Identificação automatizada de relatórios de bugs de alto impacto, alavancando estratégias de aprendizagem desequilibradas. Em Computer Software and Applications Conference (COMPSAC), 2016 IEEE 40th Anual, volume 1, páginas 227–232. IEEE, 2016.

[18] Deqing Zou, Zhijun Deng, Zhen Li e Hai Jin. Identificação automática de relatórios de bugs de segurança através da análise de características multitipo. Na Conferência Australásia sobre Segurança da Informação e Privacidade, páginas 619–633. Springer, 2018.