Simple Science

Ciencia de vanguardia explicada de forma sencilla

# Informática# Ingeniería del software# Lenguajes de programación

Nuevo método optimiza el proceso de compilación de Java

Un nuevo enfoque simplifica la compilación de cambios en proyectos de Java, mejorando la seguridad.

― 8 minilectura


Compilación de Java HechaCompilación de Java HechaMás Fácilcompilar cambios en proyectos de Java.Nuevo método mejora la eficiencia al
Tabla de contenidos

Las aplicaciones de Java a menudo dependen de bibliotecas de terceros, pero algunas de ellas pueden tener problemas de seguridad. Los investigadores han trabajado en herramientas para ayudar a identificar estas vulnerabilidades y corregirlas. Sin embargo, para identificar eficazmente estas vulnerabilidades, es crucial tener el Bytecode correcto disponible después de aplicar un parche. Esto puede ser complicado porque el código a menudo existe en una forma que no se puede compilar fácilmente en bytecode. Este artículo presenta una nueva manera de compilar solo el código que ha cambiado en un commit específico, facilitando el mantenimiento de la seguridad y la integridad en las aplicaciones de Java.

Desafíos actuales con la compilación de código Java

Los proyectos de Java normalmente incluyen muchas Dependencias como bytecode en lugar de como código fuente. Si hay una vulnerabilidad en alguna de estas dependencias, se necesita un parche que solucione el problema. Estos parches se almacenan en bases de datos como fix-commits, pero compilar todo el proyecto para obtener el bytecode necesario puede ser muy difícil. Esto es especialmente cierto para versiones más antiguas del código. Además, no todos los repositorios de código mantienen las mismas prácticas de desarrollo, lo que hace aún más complicado encontrar la versión correcta del proyecto para compilar.

El proceso existente para identificar vulnerabilidades a menudo se basa en Metadatos asociados con las dependencias incluidas. Sin embargo, este metadato puede ser inexacto o faltar, lo que lleva a errores en la identificación de las vulnerabilidades. Por ejemplo, muchas herramientas solo miran los metadatos y los comparan con vulnerabilidades conocidas en una base de datos. Esto no es suficiente, ya que muchas de las vulnerabilidades están más escondidas en el código real.

Es importante notar que las bases de datos de vulnerabilidades existentes generalmente solo dan un vistazo del repositorio donde se aplicó un arreglo. No ofrecen la versión de lanzamiento que incluye el parche. Para identificar eficazmente si existe una vulnerabilidad en un determinado bytecode, los parches deben compilarse correctamente en bytecode que refleje esas correcciones.

Enfoque propuesto

Para abordar estos desafíos, se ha propuesto un nuevo método. Este método se centra en compilar solo las partes relevantes del proyecto Java que han cambiado en un commit determinado. El proceso comienza con el código fuente del proyecto Java, que luego se reduce para incluir solo la información necesaria para compilar esos cambios específicos. Esto no solo agiliza el proceso, sino que también minimiza el riesgo de errores durante la compilación.

El enfoque utiliza una técnica de marcar y barrer. Inicialmente, el código marca las partes que son relevantes para los cambios. Luego, identifica las referencias esenciales en el código, manteniendo solo las necesarias para compilar los cambios objetivos. Las partes innecesarias se eliminan, dejando solo lo que se requiere.

Un desafío es que este corte podría llevar a errores si faltan los nombres de las entidades requeridas para completar la compilación. Para lidiar con este problema, el método genera automáticamente stubs para esas referencias que faltan. Estos stubs permiten al compilador entender lo que se necesita, incluso si el código real está ausente.

Evaluación del enfoque

El nuevo método se probó en 347 proyectos de Java populares extraídos de GitHub. La evaluación involucró 32,970 métodos y constructores, y se encontró que el 72% de ellos podían compilarse de forma aislada. De esos, el 89% produjo bytecode que era exactamente el mismo que el original.

En pruebas donde se utilizaron scripts de compilación tradicionales, solo el 8% de los archivos modificados por los fix-commits pudieron ser compilados. En marcado contraste, el nuevo método logró compilar el 73% de todos los archivos alterados sin depender de ningún script de compilación.

Esto demuestra que el enfoque compila efectivamente los cambios mientras mantiene un alto nivel de similitud con el bytecode original. El método retiene el código relevante y le da al compilador solo la información necesaria para hacer su trabajo sin el desorden del código innecesario.

Pasos del proceso de compilación

Identificación de entrada y objetivo

El proceso comienza con las firmas de los métodos que necesitan ser compilados. Los archivos fuente que contienen estos métodos se proporcionan como entradas. Junto con esto, se incluyen todos los demás archivos de código fuente disponibles en el proyecto y cualquier archivo JAR de dependencia recuperable.

Marcado y resolución

El siguiente paso consiste en marcar el método, indicando que debe mantenerse intacto durante el proceso de corte. Después de esto, el código revisa todas las referencias dentro del método para ver qué más podría necesitar del proyecto. Si se encuentran estas referencias en el código, se marcan para retención.

Corte

Después de marcar, el método procede a eliminar partes del código que no son necesarias para la compilación. Esto incluye la eliminación de dependencias y cualquier código no necesario para compilar el método objetivo.

Generación de stubs

Para referencias que aún permanecen sin resolver después de marcar y cortar, el método genera stubs. Los stubs sirven como marcadores que proporcionan información sobre los tipos de clases y métodos que se necesitan, sin requerir su implementación completa.

Compilación

Finalmente, se utiliza el compilador de Java para compilar el código cortado junto con cualquier archivo stub que se haya generado. El resultado es bytecode que debería coincidir o parecerse mucho al bytecode original obtenido de una compilación completa del proyecto.

Resultados de la evaluación

Los resultados de aplicar el nuevo método mostraron mejoras significativas en la tasa de éxito de la compilación en comparación con métodos tradicionales. La capacidad de compilar el 72% de los métodos objetivo de forma aislada es notable, especialmente considerando las dificultades que comúnmente se enfrentan al compilar proyectos de Java.

Al centrarse solo en el código relevante y generar stubs para las partes faltantes, el método pudo reducir significativamente el tiempo que se tarda en compilar. Esta eficiencia es particularmente útil al tratar con grandes bases de código donde encontrar y corregir vulnerabilidades puede ser un proceso tedioso.

Comparación con enfoques existentes

Las herramientas existentes a menudo dependen en gran medida de analizar bases de código completas, lo que puede llevar a un rendimiento lento e imprecisiones. El método propuesto, sin embargo, evita gran parte de esto al centrarse en los cambios específicos realizados dentro de un commit. Este enfoque dirigido lleva a tiempos de compilación más rápidos y una identificación más precisa de vulnerabilidades.

Además, los métodos tradicionales tienden a tener problemas con metadatos incompletos o desactualizados, lo que puede llevar a vulnerabilidades pasadas por alto. El nuevo enfoque aborda esto inferiendo tipos necesarios y generando stubs de manera dinámica, asegurando que incluso el código incompleto pueda compilarse con éxito.

Limitaciones del método

Si bien el método muestra resultados prometedores, aún hay algunas limitaciones a tener en cuenta. La tasa de éxito de la compilación depende en gran medida de la integridad del código fuente original. Si faltan o están rotas partes significativas de la base de código, esto puede afectar la efectividad del método.

Además, la tasa de éxito puede variar dependiendo de la complejidad del proyecto y de los patrones utilizados en las prácticas de desarrollo. Algunas características de Java pueden no ser completamente compatibles con el método, lo que lleva a compilaciones incompletas o bytecode que no es tan similar como se desearía.

Conclusión

El nuevo enfoque presentado para compilar cambios de commits en proyectos Java representa una solución efectiva a un problema común que enfrentan los desarrolladores al lidiar con vulnerabilidades en las dependencias. Al centrarse específicamente en las partes relevantes del código que han cambiado y generar los stubs necesarios, el método agiliza el proceso de compilar aplicaciones Java y ayuda a mantener la seguridad.

A medida que el desarrollo de software sigue evolucionando, herramientas como esta serán vitales para ayudar a los equipos a asegurar la integridad de su código mientras hacen que el proceso sea más eficiente. Los resultados de la evaluación indican que este método podría tener un impacto positivo significativo en cómo se mantienen y aseguran los proyectos Java contra vulnerabilidades. El futuro del desarrollo de software dependerá de herramientas y métodos mejorados que faciliten una mejor gestión del código y detección de vulnerabilidades.

Fuente original

Título: Compilation of Commit Changes within Java Source Code Repositories

Resumen: Java applications include third-party dependencies as bytecode. To keep these applications secure, researchers have proposed tools to re-identify dependencies that contain known vulnerabilities. Yet, to allow such re-identification, one must obtain, for each vulnerability patch, the bytecode fixing the respective vulnerability at first. Such patches for dependencies are curated in databases in the form of fix-commits. But fixcommits are in source code, and automatically compiling whole Java projects to bytecode is notoriously hard, particularly for non-current versions of the code. In this paper, we thus propose JESS, an approach that largely avoids this problem by compiling solely the relevant code that was modified within a given commit. JESS reduces the code, retaining only those parts that the committed change references. To avoid name-resolution errors, JESS automatically infers stubs for references to entities that are unavailable to the compiler. A challenge is here that, to facilitate the above mentioned reidentification, JESS must seek to produce bytecode that is almost identical to the bytecode which one would obtain by a successful compilation of the full project. An evaluation on 347 GitHub projects shows that JESS is able to compile, in isolation, 72% of methods and constructors, of which 89% have bytecode equal to the original one. Furthermore, on the Project KB database of fix-commits, in which only 8% of files modified within the commits can be compiled with the provided build scripts, JESS is able to compile 73% of all files that these commits modify.

Autores: Stefan Schott, Wolfram Fischer, Serena Elisa Ponta, Jonas Klauke, Eric Bodden

Última actualización: 2024-07-25 00:00:00

Idioma: English

Fuente URL: https://arxiv.org/abs/2407.17853

Fuente PDF: https://arxiv.org/pdf/2407.17853

Licencia: https://creativecommons.org/licenses/by/4.0/

Cambios: Este resumen se ha elaborado con la ayuda de AI y puede contener imprecisiones. Para obtener información precisa, consulte los documentos originales enlazados aquí.

Gracias a arxiv por el uso de su interoperabilidad de acceso abierto.

Más de autores

Artículos similares