El autor: Keun Soo Yim Author: Título: Keun Soo Yim Table Of Links Mesa de la izquierda Abstracción I. INTRODUCTION I. Introducción II. BACKGROUND II. El fondo III. DESIGN III. El diseño Definiciones Objetivos de diseño Framework Extensiones IV. MODELING IV. Modelización Clases Factores V. DATA COLLECTION V. Recopilación de datos VI. CHARACTERIZATION VI. Caracterización Vulnerabilidad que fija la latencia Análisis de la vulnerabilidad fijando cambios Análisis de los cambios de vulnerabilidad VII. RESULT VII. El resultado Validación N-Fold Evaluación utilizando el modo de implementación en línea VIII. DISCUSSION VIII. La discusión Implicaciones para los proyectos multiproyectos Implicaciones para los trabajos de seguridad de Android Amenazas a la validez Enfoques alternativos IX. RELATED WORK IX. Trabajo relacionado CONCLUSION AND REFERENCES Conclusión y referencias ABSTRACT Abstracción Este documento presenta un marco que desencadena selectivamente las revisiones de seguridad para los cambios de código fuente entrantes. Funcionando como un bot de revisión dentro de un servicio de revisión de código, el marco puede solicitar automáticamente revisiones de seguridad adicionales en el momento de la presentación previa antes de que los cambios de código se envíen a un repositorio de código fuente. Debido a que la realización de tales revisiones de código seguro agregan costes, el marco emplea un clasificador capacitado para identificar los cambios de código con una alta probabilidad de vulnerabilidades. El clasificador en línea aprovecha diferentes tipos de funciones de entrada para analizar los patrones de revisión, rastrear el proceso de ingeniería de software y extraer patrones de texto específicos dentro de los cambios de código. El clasificador y sus características se seleccionan y optimizan meticulosamente utilizando datos de los cambios de código enviados y reportan vulnerabilidades en Android Open Source Project (AOSP). Los resultados de la evaluación demuestran que nuestro marco de Prevención de Vulnerabilidad (VP) identifica aproximadamente el 80% de los cambios de código que inducen la vulnerabilidad en el conjunto de datos con un ratio de precisión de alrededor del 98% y una tasa de falso positivo de alrededor del 1,7%. Este artículo explora y valida nuestro enfoque para la predicción de vulnerabilidades de cambio de código-granularidad, ofreciendo una técnica preventiva para la seguridad del software al detectar previamente los cambios de código vulnerables antes de su envío. I. INTRODUCTION I. Introducción Las cadenas de suministro de software libre y de código abierto (FOSS) para los dispositivos de Internet de las Cosas (por ejemplo, teléfonos inteligentes y televisores) presentan un objetivo atractivo y económico para los atacantes de seguridad (por ejemplo, ataques de la cadena de suministro [20][21][28]). Es por ejemplo porque pueden enviar cambios de código aparentemente inofensivos que contienen vulnerabilidades sin revelar sus identidades y motivos. El enfoque de proyectos específicos y ampliamente utilizados de código abierto (por ejemplo, núcleos de sistema operativo, bibliotecas, navegadores o reproductores de medios) puede maximizar el impacto, ya que estos proyectos suelen apoyar una amplia gama de productos de consumo.Los ciclos de actualización de software rápidos de esos productos pueden tomar rápidamente vulnerabilidades en las últimas actualizaciones de sus proyectos FOSS ascendentes si no se implementan revisiones de seguridad rigurosas y pruebas antes de cada actualización o lanzamiento de software. Desde una perspectiva social holística, el coste total de las pruebas de seguridad se puede optimizar identificando tales cambios de código vulnerables temprano en el momento de la presentación, antes de que esos cambios se envíen a los repositorios de proyectos de código abierto. Estos proyectos descendentes no pueden confiar en los primeros proyectos descendentes para encontrar y corregir las vulnerabilidades fusionadas, ascendentes porque el plazo para tales correcciones y su posterior ascenso es impredecible (por ejemplo, en parte debido a las políticas internas [22]). Un enfoque ingenuo de requerir revisiones de seguridad completas para cada cambio de código causa un coste poco realista para muchos propietarios de proyectos de código abierto. Esto es especialmente cierto para los proyectos FOSS que reciben un gran volumen de cambios de código o requieren experiencia especializada en seguridad para revisiones (por ejemplo, específicas para los dominios). Framework que automatiza la evaluación de vulnerabilidades de los cambios de código utilizando un clasificador de aprendizaje automático (ML). Vulnerability Prevention (VP) El modelo de clasificador estima la probabilidad de que un cambio de código dado contenga o induza al menos una vulnerabilidad de seguridad. Cambios de código por encima de un umbral promedio probable-vulnerable. El modelo se capacita sobre los datos históricos generados utilizando un conjunto de herramientas de análisis asociadas. El modelo utiliza las características comunes utilizadas para la predicción de defectos de software, así como cuatro tipos de características nuevas que capturan: 1) la complejidad del patch, 2) los patrones de revisión del código, (3) la fase del ciclo de vida del desarrollo de software de cada archivo de código fuente, y (4) la naturaleza de un cambio de código, como se determina mediante el análisis de las líneas de código fuente editadas.En total, este estudio examina de forma exhaustiva 6 tipos de clasificadores utilizando más de 30 tipos de datos de características para optimizar la precisión del modelo ML. Para generar los datos de capacitación y pruebas, aprovechamos los errores de seguridad descubiertos y corregidos en el Proyecto de código abierto de Android (AOSP)1 . se dirige específicamente al proyecto de medios AOSP2 (es decir, para el procesamiento de datos multimedia) que ha sido extensamente probado y así ha revelado muchos defectos de seguridad. (1) identificar los cambios de corrección de vulnerabilidades asociados con cada error de seguridad objetivo, y (2) cambios inductores de vulnerabilidad en retroceso vinculados a cada uno de los cambios de corrección de vulnerabilidad identificados.Todos los cambios inductores de vulnerabilidad identificados se analizan y verifican manualmente antes de asociarse con los respectivos errores de seguridad.Los cambios inductores de vulnerabilidad asociados se etiquetan como "1", mientras que todos los otros cambios de código enviados al proyecto de medios de destino se etiquetan como "0" en el conjunto de datos. El La evaluación utilizando el primer año de datos identifica el bosque aleatorio como el clasificador más eficaz basado en su precisión. El clasificador identifica el ~60% de los cambios de código que inducen la vulnerabilidad con una precisión de ~85%. También identifica el ~99% de los cambios de código probable-normal con una precisión de ~97% cuando se utilizan todas las características para la capacitación y las pruebas. N-fold Cuando se aplica a aproximadamente seis años de los datos de la vulnerabilidad3, el marco demuestra una recogida de aproximadamente 80% y una precisión de aproximadamente 98% para los cambios inducidos por la vulnerabilidad, junto con una recogida de 99.8% y una precisión de 98.5% para los cambios probablemente normales. En resumen, el 7,4% de los cambios de código revisados y fusionados se clasifican como inductores de vulnerabilidad. En promedio, el número de cambios probables-normales que requieren atención adicional durante sus revisiones de código es de alrededor de 7 por mes. Este volumen manejable (menos de 2 cambios de código por semana) justifica el coste, teniendo en cuenta el alto rechazo (~80%) y la precisión (~98%) para identificar los cambios inductores de vulnerabilidad. Las principales contribuciones de este estudio incluyen: 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. El fondo Esta sección describe el proceso de revisión y presentación de código de un proyecto de software de código abierto, utilizando AOSP (Android Open Source Project) como estudio de caso. Un cambio de código (simplemente, cambio) consiste en un conjunto de líneas de código fuente añadidas, eliminadas y/o editadas para los archivos de código fuente en un repositorio de código fuente objetivo (por ejemplo, git). Un ingeniero de software típico envía un cambio de código a un servicio de revisión de código (por ejemplo, Gerrit4 ) para revisiones de código obligatorias antes de su envío. Un cambio de código se atribuye a un autor que tiene una dirección de correo electrónico asociada en AOSP. El cambio también puede tener uno o más revisores de código. Cambio de Código . Cambio de Código Durante el proceso de revisión de código, un cambio de código puede sufrir varias revisiones, lo que resulta en uno o más conjuntos de parches. Cada conjunto de parches cargado al servicio de revisión de código representa una versión actualizada del cambio de código. El autor del cambio de código puede revisar y reenviar el cambio como un nuevo conjunto de parches para una revisión o aprobación adicional por el revisor de código designado.Los permisos del revisor clave incluyen: una puntuación de +1 para indicar que el cambio es bueno para el revisor, una puntuación de +2 para aprobar el cambio de código, una puntuación de -1 para decir que el cambio no es bueno (por ejemplo, un problema menor), y una puntuación de -2 para bloquear la presentación del cambio de código. Revisión del código. Revisión del código. Los proyectos (por ejemplo, repositorios git o subdirectorios en un repositorio git) pueden tener permisos personalizados y reglas de revisión. por ejemplo, una regla de revisión personalizada es permitir a los autores marcar sus cambios de código listos para la prueba de presunción porque a menudo los autores cargan versiones no finales al servicio de revisión de código (por ejemplo, para inspeccionar los diffs5 y los comentarios preliminares). Este artículo está disponible en archivo bajo la licencia CC by 4.0 Deed (Attribution 4.0 International). Este documento es Con la licencia CC 4.0 Deed (Attribution 4.0 International). available o n arxiv El archivo
