O autor: Keun Soo Yim Author: Xogo Soo Yim Table Of Links Mesa da esquerda Abstraccións I. INTRODUCTION I. Introdución II. BACKGROUND II. O fondo III. DESIGN III. Deseño Definicións Obxectivos de deseño marco Extensións IV. MODELING IV. Modelización Clasificadores Feiticeiros V. DATA COLLECTION V. Recollida de datos VI. CHARACTERIZATION VI. Caracterización Vulnerabilidade fixando a latencia Análise da vulnerabilidade fixando cambios Análise de cambios de vulnerabilidade VII. RESULT VII. O resultado Validación N-FOLD Avaliación utilizando o modo de implementación en liña VIII. DISCUSSION VIII. Discusións Implicacións para proxectos multiproxectos Implicacións para os traballos de seguridade de Android Ameazas á validez Enfoques alternativos IX. RELATED WORK IX. Traballo relacionado CONCLUSION AND REFERENCES Conclusións e referencias ABSTRACT Abstraccións Funciona como un bot de revisión dentro dun servizo de revisión de código, o framework pode solicitar automaticamente revisións de seguridade adicionais no momento de pre-submisión antes de que os cambios de código sexan enviados a un repositorio de código fonte. O clasificador en liña aproveita diferentes tipos de funcións de entrada para analizar os patróns de revisión, rastrexar o proceso de enxeñaría de software e minar patróns de texto específicos dentro dun determinado cambio de código. O clasificador e as súas características son meticulosamente elixidos e optimizados utilizando datos dos cambios de código enviados e vulnerabilidades reportadas no Proxecto de código aberto de Android (AOSP). Os resultados da avaliación demostran que o noso marco de Prevención de Vulnerabilidade (VP) identifica aproximadamente o 80% dos cambios de código inducidos por vulnerabilidade no conxunto de datos cunha taxa de precisión duns 98% e unha taxa de falso positivo duns 1,7%. Este artigo explora e valida o noso enfoque para a predición de vulnerabilidades de cambio de código-granularidade, ofrecendo unha técnica preventiva para a seguridade do software ao detectar previamente os cambios de código vulnerables antes da presentación. I. INTRODUCTION I. Introdución As cadeas de subministración de software libre e de código aberto (FOSS) para os dispositivos de Internet das Cousas (por exemplo, teléfonos intelixentes e televisións) presentan un obxectivo atractivo e económico para os atacantes de seguridade (por exemplo, ataques á cadea de subministración [20][21][28]). O obxectivo de proxectos específicos de código aberto amplamente utilizados (por exemplo, núcleos de sistema operativo, bibliotecas, navegadores ou reproductores de medios) pode maximizar o impacto, xa que estes proxectos adoitan apoiar unha ampla gama de produtos de consumo. Os ciclos de actualización de software rápidos destes produtos poden rapidamente tomar vulnerabilidades nos últimos parches dos seus proxectos FOSS de arriba se non se implementan revisións de seguridade rigorosas e probas antes de cada actualización ou lanzamento de software. Desde unha perspectiva social holística, o custo global de probas de seguridade pódese optimizar identificando tales cambios de código vulnerables previamente no momento da presentación, antes de que estes cambios se envíen aos repositorios de proxectos de código aberto. Estes proxectos descendentes non poden depender dos primeiros proxectos descendentes para atopar e corrixir as vulnerabilidades fusionadas e ascendentes porque o prazo para tales correccións e o seu subsequente ascenso é imprevisible (por exemplo, en parte debido ás políticas internas [22]). Un enfoque inxenuo de esixir revisións de seguridade abrangentes para cada cambio de código causa un custo irrealista para moitos propietarios de proxectos de código aberto. Isto é especialmente certo para os proxectos FOSS que reciben un gran volume de cambios de código ou requiren experiencia especializada de seguridade para revisións (por exemplo, específicas dos dominios). Framework que automatiza a avaliación de vulnerabilidades de cambios de código usando un clasificador de aprendizaxe automática (ML). Vulnerability Prevention (VP) O modelo de clasificador estima a probabilidade de que un determinado cambio de código conteña ou induza polo menos unha vulnerabilidade de seguridade. Cambios de código que exceden un limiar de probabilidade-vulnerable. O modelo é adestrado sobre os datos históricos xerados usando un conxunto de ferramentas de análise asociadas. O modelo usa as características comúns utilizadas para a predición de fallos de software, así como catro tipos de novas características que capturan: 1) a complexidade do patch, 2) os patróns de revisión do código, (3) a fase do ciclo de vida do desenvolvemento de software de cada ficheiro de código fonte, e (4) a natureza dun cambio de código, como se determina analizando as liñas de código fonte editadas.En total, este estudo examina de forma exhaustiva 6 tipos de clasificadores utilizando máis de 30 tipos de datos de características para optimizar a precisión do modelo ML. Para xerar os datos de adestramento e de proba, aproveitamos os erros de seguridade detectados e corrixidos no Proxecto de código aberto de Android (AOSP)1. (1) identificar os cambios de corrección de vulnerabilidades asociados a cada bug de seguridade obxectivo, e (2) cambios de indución de vulnerabilidade ligados a cada un dos cambios de corrección de vulnerabilidade identificados.Todos os cambios de indución de vulnerabilidade identificados son analizados e verificados manualmente antes de asociarse aos respectivos erros de seguridade.Os cambios de indución de vulnerabilidade asociados están etiquetados como "1", mentres que todos os outros cambios de código enviados ao proxecto de medios de destino están etiquetados como "0" no conxunto de datos. A súa A avaliación usando o primeiro ano de datos identifica o bosque aleatorio como o clasificador máis eficaz baseado na súa precisión. O clasificador identifica ~60% dos cambios de código que inducen a vulnerabilidade cunha precisión de ~85%. Tamén identifica ~99% dos cambios de código probablemente normais cunha precisión de ~97% cando se utilizan todas as características para a formación e a proba. N-fold Cando se aplica a uns seis anos dos datos de vulnerabilidade3, o marco demostra unha recall de aproximadamente o 80% e unha precisión de aproximadamente o 98% para os cambios que inducen a vulnerabilidade, xunto con unha recall de 99,8% e unha precisión de 98.5% para os cambios probablemente normais. En resumo, o 7,4% dos cambios de código revisados e fusionados clasifícanse como vulnerables.En media, o número de cambios probables normais que requiren atención adicional durante as súas revisións de código é de preto de 7 por mes. Este volume xestionable (menos de 2 cambios de código por semana) xustifica o custo, tendo en conta a alta recuperación (~80%) e precisión (~98%) para identificar os cambios que inducen a vulnerabilidade. As principais contribucións deste estudo inclúen: We explore and confirm the possibility of code change-granularity vulnerability prediction that can be used to prevent vulnerabilities by flagging likelyvulnerable code changes at pre-submit time. We present the Vulnerability Prevention (VP) framework that automates online assessment of software vulnerabilities using a machine learning classifier. We devise novel feature types to improve the classifier accuracy and reduces the feature data set by evaluating the precision and recall metrics. We present the specialized tools to label code changes in AOSP, facilitating robust training and testing data collection. We demonstrate a high precision (~98%) and recall (~80%) of the VP framework in identifying vulnerability-inducing changes, showing the potential as a practical tool to reduce security risks. We discuss the implications of deploying the VP framework in multi-project settings. Our analysis data suggests two focus areas for future Android security research: optimizing the Android vulnerability fixing latency and more efforts to prevent vulnerabilities. The rest of this paper is organized as follows. Section II provides the background information. Section III analyzes the design requirements and presents the VP framework design. Section IV details the design of the ML model, including the classifier and features for classifying likelyvulnerable code changes. Section V describes the tools developed to collect vulnerability datasets for model training and testing. Section VI describes the data collection process using the tools, and characterizes the vulnerability issues, vulnerability-fixing changes, and vulnerability-inducing changes in an AOSP sub-project. Section VII presents the evaluation of the VP framework using an N-fold validation. Section VIIII extends the framework for real-time, online classification. Section IX discusses the implications and threats to validity. Section IX reviews the related works before concluding this paper in Section X. II. BACKGROUND II. O fondo Esta sección describe o proceso de revisión e presentación de código dun proxecto de software de código aberto, utilizando AOSP (Proxecto de código aberto de Android) como estudo de caso. Un cambio de código (simplemente, cambio) consiste nun conxunto de liñas de código fonte engadidas, eliminadas e/ou editadas para ficheiros de código fonte nun repositorio de código fonte obxectivo (por exemplo, git). Un enxeñeiro de software típico envía un cambio de código a un servizo de revisión de código (por exemplo, Gerrit4 ) para revisións de código obrigatorias antes da presentación. Un cambio de código atribúese a un autor que ten un enderezo de correo electrónico asociado en AOSP. O cambio tamén pode ter un ou máis revisores de código. Cambio de código . Cambio de código Durante o proceso de revisión de código, un cambio de código pode sufrir varias revisións, resultando nun ou máis conxuntos de parches. Cada conxunto de parches cargado ao servizo de revisión de código representa unha versión actualizada do cambio de código. O autor do cambio de código pode revisar e reenviar o cambio como un novo conxunto de parches para a súa revisión ou aprobación adicional polo (s) revisor (s) de código designado.Os permisos do revisor clave inclúen: unha puntuación de +1 para indicar que o cambio parece bo para o revisor, unha puntuación de +2 para aprobar o cambio de código, unha puntuación de -1 para dicir que o cambio non parece bo (por exemplo, unha emisión menor), e unha puntuación de -2 para bloquear a presentación do cambio de código. Código de revisión. Código de revisión. Por exemplo, unha regra de revisión personalizada é permitir que os autores marquen as súas modificacións de código listas para a proba de presunción porque moitas veces os autores cargan versións non finais ao servizo de revisión de código (por exemplo, para inspeccionar os diffs5 e os comentarios preliminares). Este artigo está dispoñible en arquivo baixo a licenza CC by 4.0 Deed (Attribution 4.0 International). Este documento é A súa licenza é CC by 4.0 Deed (Attribution 4.0 International). available o Arquivo de Arquivo de
