Análisis del impacto de las vulnerabilidades en las dependencias de proyectos software basado en Satisfiability Modulo Theories (SMT) [Póster]

An´ alisis del impacto de las vulnerabilidades en las dependencias de proyectos software basado en Satisfiability Modulo Theories (SMT) Antonio Germ´ an M´ arquez Trujillo , ´ Angel Jes´ us Varela-Vaca , Mar´ ıa Teresa G´ omez L´ opez , Jos´ e A. Galindo , y David Benavides IDEA Research Group, Universidad de Sevilla {amtrujillo, ajvarela, maytegomez, jagalindo, benavides}@us.es Resumen—Actualmente el software desarrollado adquiere relaciones dependientes con librer´ ıas externas, lo que promueve el aumento del uso de dependencias como una pr´ actica com´ un. Cualquier vulnerabilidad que afecte a estas dependencias puede poner en riesgo todo el proyecto, lo que complica el mantenimiento de la seguridad en los proyectos de desarrollo de software. Actualmente, las herramientas disponibles no abarcan todas las posibles configuraciones de dependencias, lo que ampl´ ıa el desaf´ ıo. En este trabajo, se propone un enfoque que permite analizar el espacio de configuraci´ on de dependencias de proyectos en t´ erminos de las vulnerabilidades. Nuestra propuesta se materializa mediante la construcci´ on de un grafo de dependencias atribuido con vulnerabilidades. Para habilitar el an´ alisis autom´ atico, integramos modelos formales basados en modelos de satisfacibilidad. Esto permite el an´ alisis autom´ atico para determinar configuraciones libres de vulnerabilidades. Por ´ ultimo, se compara nuestra propuesta en repositorios Python, obteniendo resultados superiores a otras propuestas. Index Terms—Seguridad, Vulnerabilidad, An´ alisis Autom´ atico, Satisfiability Modulo Theories (SMT), Grafo de Dependencias, Desarrollo del software Tipo de contribuci´ on: Investigaci´ on ya publicada [1] I. INTRODUCCI ´ ON Hoy en d´ ıa, los proyectos de desarrollo de software dependen de bibliotecas o herramientas de terceros para diversas tareas. Estas bibliotecas, generan una cadena de dependencias entre los componentes de software, resultando en proyectos con un gran n´ umero de dependencias que necesitan gesti´ on [2]. Las vulnerabilidades en las dependencias pueden explotarse para atacar un sistema basado en un defecto de software. El elevado n´ umero de configuraciones y dependencias dificulta a los desarrolladores determinar qu´ e vulnerabilidades afectan al software y c´ omo mitigar los riesgos de seguridad. Presentamos Depex, una soluci´ on que automatiza el an´ alisis sobre el espacio de configuraci´ on de dependencias, teniendo en cuenta sus vulnerabilidades. Nuestras contribuciones incluyen un proceso de extracci´ on de dependencias, un proceso de atribuci´ on de vulnerabilidades, y un proceso de transformaci´ on del grafo de dependencias a un modelo de satisfacibilidad. Esto habilita t´ ecnicas de an´ alisis autom´ atico mediante operaciones de razonamiento sobre el espacio de configuraciones. Evaluamos nuestra propuesta con una comparaci´ on utilizando una lista de repositorios Python, donde nuestra propuesta demuestra que detecta m´ as vulnerabilidades. II. TRABAJOS RELACIONADOS Existen diferentes enfoques para la identificaci´ on de vulnerabilidades en las dependencias, incluyendo la coincidencia de nombres, t´ erminos y valores con los de las bases de datos de vulnerabilidades [3]. S´ olo unas pocas propuestas utilizan grafos de dependencias, y una de ellas se centra en la manipulaci´ on de grafos en lugar de en la transformaci´ on a modelos formales para el razonamiento autom´ atico. Otros enfoques exploran aspectos sem´ anticos [4], an´ alisis de c´ odigo [5], acoplamiento de dependencias en el c´ odigo fuente [6], y la aplicaci´ on del aprendizaje profundo para mejorar la seguridad del c´ odigo [7]. La naturaleza del proyecto de software tambi´ en es significativa, ya que la mayor´ ıa de los estudios se centran en proyectos Java que utilizan Maven [8], mientras que otros analizan proyectos JavaScript con NPM [9], o tanto Maven como NPM [10]. Nuestra propuesta destaca como ´ unica por su cobertura de proyectos basados en Python y dependencias en repositorios como PyPI. III. PROPUESTA Depex se compone de tres procesos distintos para llevar a cabo el desaf´ ıo del an´ alisis de vulnerabilidades en las dependencias de proyectos de desarrollo software: 1. Extracci´ on de grafos de dependencias. Los ficheros de requisitos de un proyecto se extraen de un repositorio, y a continuaci´ on, se analizan sus dependencias directas. Luego, se examinan las dependencias indirectas empleando informaci´ on del gestor de paquetes en un proceso recursivo. 2. Atribuci´ on de grafos de dependencias. Durante el an´ alisis de dependencias, se asigna a cada dependencia del grafo creado en la base de datos Depex informaci´ on sobre la vulnerabilidad, la cual se extrae de la base de datos de vulnerabilidades NVD del NIST. 3. Razonamiento autom´ atico. La informaci´ on se genera y codifica a partir de la base de datos de Depex en un modelo formal, utilizando un resolutor basado en Satisfiability Modulo Theories (SMT) [11], lo cual nos permite realizar un an´ alisis exhaustivo de las dependencias y sus vulnerabilidades. Mediante este enfoque, aplicamos una serie de operaciones que facilitan el razonamiento sobre la seguridad de las dependencias. JNIC 2024 ISBN:978-84-09-62140-8 448 0 25 50 75 100 125 150 175 200 saleor wagtail cookiecutter-django posthog django-cms django-oscar django-shop syte pinax shuup evennia jet-bridge django-angular restless rapidsms django-lfs swampdragon ActivFlow coderedcms django-hvad django-skel importd tetra neo4django longclaw nodeshot opps django-permission iommi ella openwisp-radius mini-django django-micro django-rest- wq django-nap sendgrid-django django-postgres django-ra-erp dcf django-readers Arkestra django-jinja-knockout openwisp-network- wq.db doorstep openwisp-monitoring djmicro django-knocker PyLucid cartoview mightylemon joeflow djangothis django-modern- django-tastypie- django-inspectional- django-ninecms django-simple- openwisp-firmware- django-easymode ganetimgr openwisp-notifications snorky django-dockit django-admin-utils colab django-mfw djangoCRUD Rhetoric evileg-core django-api-client django-permissions Roll-Your-Own sct-communitytools django-grpc-framework djapi django-dockitcms django-template-server artshow-jockey django-adminlte2- frepple-data-admin django-qwert django-webix django-minke yolla djangodjango-debits django-filtersmerger Django-Krogoth djangophysics feincms_grid django-dal Dependabot Snyk Depex Figura 1. Vulnerabilidades directas detectadas por cada herramienta 0 100 200 300 400 500 saleor wagtail cookiecutter-django posthog django-cms django-oscar django-shop syte pinax shuup evennia jet-bridge django-angular restless rapidsms django-lfs swampdragon ActivFlow coderedcms django-hvad django-skel importd tetra neo4django longclaw nodeshot opps django-permission iommi ella openwisp-radius mini-django django-micro django-rest- wq django-nap sendgrid-django django-postgres django-ra-erp dcf django-readers Arkestra django-jinja-knockout openwisp-network- wq.db doorstep openwisp-monitoring djmicro django-knocker PyLucid cartoview mightylemon joeflow djangothis django-modern- django-tastypie- django-inspectional- django-ninecms django-simple- openwisp-firmware- django-easymode ganetimgr openwisp-notifications snorky django-dockit django-admin-utils colab django-mfw djangoCRUD Rhetoric evileg-core django-api-client django-permissions Roll-Your-Own sct-communitytools django-grpc-framework djapi django-dockitcms django-template-server artshow-jockey django-adminlte2- frepple-data-admin django-qwert django-webix django-minke yolla djangodjango-debits django-filtersmerger Django-Krogoth djangophysics feincms_grid django-dal Snyk Depex Figura 2. Vulnerabilidades indirectas detectadas por cada herramienta IV. EXPERIMENTACI ´ ON En la experimentaci´ on se compara el rendimiento de Depex con herramientas existentes en el mercado, como Snyk y Dependabot de GitHub, populares y compatibles con proyectos Python. El objetivo del experimento es determinar si Depex puede detectar m´ as vulnerabilidades en las dependencias de un proyecto. Se busca proporcionar informaci´ on m´ as detallada sobre las vulnerabilidades del proyecto en comparaci´ on con otras opciones, lo que beneficiar´ ıa a los desarrolladores al ofrecerles una visi´ on m´ as completa de las posibles vulnerabilidades que podr´ ıan afectar a sus proyectos. Para minimizar sesgos en la comparaci´ on, se distinguen entre vulnerabilidades directas e indirectas, mientras que Dependabot solo analiza las dependencias directas. En las Figuras 1 y 2, se presentan los resultados del an´ alisis de los repositorios, donde se observa la detecci´ on de vulnerabilidades directas e indirectas por parte de diferentes herramientas. Para la mayor´ ıa de los proyectos, Snyk identifica m´ as vulnerabilidades directas que Dependabot, pero Depex supera a Snyk en la detecci´ on de vulnerabilidades directas en todos los proyectos. Sin embargo, en el caso del proyecto pinax, todas las herramientas detectan las mismas vulnerabilidades directas debido a que el fichero de requisitos fija las versiones de las dependencias, eliminando as´ ı la variabilidad de versiones y la capacidad de cubrir todo el rango de versiones, lo que otras herramientas no pueden hacer. En cuanto a las vulnerabilidades indirectas, solo se consideraron Depex y Snyk, ya que Dependabot no ofrece un an´ alisis de dependencias indirectas. En este aspecto, Depex detecta m´ as vulnerabilidades indirectas que Snyk en todos los casos. V. CONCLUSIONES Y TRABAJOS FUTUROS Depex aborda el desaf´ ıo del an´ alisis de vulnerabilidades en proyectos de software mediante la construcci´ on de un grafo de dependencias con informaci´ on sobre vulnerabilidades y un modelo formal basado en SMT para analizar configuraciones. Sin embargo, presenta limitaciones que requieren atenci´ on futura, 1) Dependencia exclusiva de la base de datos NVD, lo que podr´ ıa generar inconsistencias en las vulnerabilidades. Se sugiere incorporar m´ ultiples bases de datos para mejorar la coherencia; 2) Generaci´ on lenta de grafos, especialmente en proyectos asociados a NPM, debido a la gran cantidad de informaci´ on. Se planea acelerar este proceso y permitir la precarga de grafos para mejorar la velocidad de operaci´ on; y, 3) Disponibilidad limitada de m´ etricas, con solo la media y la media ponderada actualmente ofrecidas. Se sugiere implementar diversas m´ etricas para extraer m´ as informaci´ on sobre la seguridad de las dependencias. AGRADECIMIENTOS Esta publicaci´ on es parte de los proyectos COPERNICA (P20 01224) y AETHER-US PID2020-112540RB- C44 y METAMORFOSIS (US-1381375) y ALBA-US TED2021-130355B-C32 y Data-pl (PID2022-138486OB-I00) y ALBA-US TED2021-130355B-C32 y TASOVA PLUS research network (RED2022-134337-T) financiado por MICIU/AEI/10.13039/501100011033 y “European Union Next- GenerationEU/PRTR”. REFERENCIAS [1] A. Germ´ an M´ arquez, ´ Angel Jes´ us Varela-Vaca, M. T. G´ omez L´ opez, J. A. Galindo, and D. Benavides, “Vulnerability impact analysis in software project dependencies based on satisfiability modulo theories (SMT),” Computers & Security, vol. 139, p. 103669, 2024. [2] J. A. Galindo, D. Benavides, and S. Segura, “Debian packages repositories as software product line models. towards automated analysis,” in ACOTA, Belgium, September, 2010, vol. 688. CEUR-WS.org, 2010, pp. 29–34. [3] M. Cadariu, E. Bouwers, J. Visser, and A. van Deursen, “Tracking known security vulnerabilities in proprietary software systems,” in 2015 IEEE 22nd SANER, 2015, pp. 516–519. [4] S. S. Alqahtani, E. E. Eghan, and J. Rilling, “Tracing known security vulnerabilities in software repositories – a semantic web enabled modeling approach,” Science of Computer Programming, vol. 121, pp. 153–175, 2016. [5] S. Ponta, H. Plate, and A. Sabetta, “Beyond metadata: Code-centric and usage-based analysis of known vulnerabilities in open-source software,” in 2018 ICSME. Los Alamitos, CA, USA: IEEE Computer Society, sep 2018, pp. 449–460. [6] N. B. T` arrega, M. ˇ Zivkovi´ c, and A. Oprescu, “Measuring the impact of library dependency on maintenance,” vol. 2754, 2020, Conference paper, cited by: 0. [7] X. Yuan, G. Lin, Y. Tai, and J. Zhang, “Deep neural embedding for software vulnerability discovery: Comparison and optimization,” Security and Communication Networks, vol. 2022, 2022, cited by: 1; All Open Access, Gold Open Access. [8] I. Pashchenko, H. Plate, S. E. Ponta, A. Sabetta, and F. Massacci, “Vulnerable open source dependencies: Counting those that matter,” in 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, 2018, pp. 1–10. [9] J. Hejderup, “In dependencies we trust: How vulnerable are dependencies in software modules?” 2015. [10] Q. Li, J. Song, D. Tan, H. Wang, and J. Liu, “Pdgraph: A large-scale empirical study on project dependency of security vulnerabilities,” 2021, Conference paper, p. 161 – 173, cited by: 3. [11] P. Arcaini, A. Gargantini, and P. Vavassori, “Generating tests for detecting faults in feature models,” in 2015 IEEE 8th ICST. IEEE, 2015, pp. 1–10. An´alisis del impacto de las vulnerabilidades en las dependencias de proyectos software basado en Satisfiability Modulo Theories (SMT) 449