Depex: A software for analysing and reasoning about vulnerabilities in software projects dependencies

Contents lists available at ScienceDirect SoftwareX journal homepage: www.elsevier.com/locate/softx Original software publication Depex: A software for analysing and reasoning about vulnerabilities in software projects dependencies Antonio Germán Márquez ∗, Ángel Jesús Varela-Vaca, María Teresa Gómez López, José A. Galindo, David Benavides Dpto. Lenguajes y Sistemas Informáticos, University of Seville, Spain A R T I C L E I N F O Keywords: Security Vulnerability Automated analysis Satisfiability Modulo Theories (SMT) Dependency graph Software development A B S T R A C T This paper presents Depex, a tool that allows developers to reason over the entire configuration space of the dependencies of an open-source software repository. The dependency information is extracted from the repository requirements files and the package managers of the dependencies, generating a graph that includes information regarding security vulnerabilities affecting the dependencies. The dependency graph allows automatic reasoning through the creation of a Boolean satisfiability model based on Satisfiability Modulo Theories (SMT). Automatic reasoning lets operations such as identifying the safest dependency configuration or validating if a particular configuration is secure. To demonstrate the impact of the proposal, it has been evaluated on more than 300 real open-source repositories of Python Package Index (PyPI), Node Package Manager (NPM) and Maven Central (Maven), as well as compared with current commercial tools on the market. Code metadata Current code version v0.7.5 Permanent link to code/repository used for this code version https://github.com/ElsevierSoftwareX/SOFTX-D-24-00709 Permanent link to Reproducible Capsule https://doi.org/10.5281/zenodo.14253193 Legal Code License GPL-3.0 licence Code versioning system used git Software code languages, tools, and services used Python, Z3, PyPI, NPM Maven & GitHub services Compilation requirements, operating environments & dependencies The tool is completely dockerised If available Link to developer documentation/manual https://github.com/GermanMT/depex/wiki Support email for questions [email protected] 1. Motivation and significance Nowadays, software development projects are built on third-party tools [1] to facilitate specific tasks, such as data management or communication between components and services. These tools make the code depend on their functionality; thus, they are called dependencies. The use of dependencies is a necessary practice when integrating external components; however, it can lead to long chains of dependencies in software components [2] that belong to different owners [3,4], which may introduce challenges for maintainability and security. These dependencies can also take many different versions, so the amount of ∗Corresponding author. E-mail addresses: [email protected] (A.G. Márquez), [email protected] (Á.J. Varela-Vaca), [email protected] (M.T. Gómez López ), [email protected] (J.A. Galindo), [email protected] (D. Benavides). 1https://thehackernews.com/2024/04/malicious-code-in-xz-utils-for-linux.html versioning in a dependency chain increases dramatically. As a result, developers face challenges in identifying the vulnerabilities that impact their dependencies. For example, the vulnerability CVE-2024-3094 [5], attacks a backdoor to the XZ Utils library1 for Linux systems. It affects several versions of the same library that contain the backdoor in their code. This library is widely used and is found in most Linux distributions, being used to compress and decompress files. Consequently, when integrating the versions of the XZ Utils library into a software project, the vulnerability CVE-2024-3094 is also integrated, compromising the https://doi.org/10.1016/j.softx.2025.102152 Received 30 December 2024; Received in revised form 5 March 2025; Accepted 27 March 2025 SoftwareX 30 (2025) 102152 Available online 22 April 2025 2352-7110/© 2025 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC license ( http://creativecommons.org/licenses/bync/4.0/ ). A.G. Márquez et al. project’s security. The responsibility of the software developers is to ensure that all permitted versions of the dependencies in his product are not affected by any known vulnerabilities. The challenge is mostly performed manually. Some technical solutions address vulnerability analysis but have important limitations, e.g., Snyk [6], OWASP Dependency-Check [7], and GitHub Dependabot [8]. They scan only the latest version of the dependencies for cost and lack an intelligent solver-based dependency analysis that evaluates version configurations beyond the latest available. Furthermore, the literature suggests static code analysis [9,10], including semantic aspects [11], or matching dependencies with vulnerability information [12,13]. However, there are no previous solutions to reasoning about dependencies. Although the authors in [14] use directed graph operations for dependency analysis, they lack support for automated reasoning. There are previous articles in our authorship that propose the methodology to automate the analysis and reasoning about the configuration space of the dependencies of a software development project; the first [15] is an early work where the foundations of the methodology are laid, and the second [16] is already a complete article where the methodology is described in a final state. The main difference with the present work is the construction of a functional tool that puts into practice the theoretical framework developed in previous work; making the necessary changes to make the processes efficient. Specifically, the theoretical framework is presented in [16], formed of the following steps: (1) creating a graph structure for including direct and indirect dependencies; (2) attributing the dependency graph with information related to security; (3) transforming the graph into a Satisfiability Modulo Theories (SMT) [17–19]; and, (4) performing automatic reasoning on the configuration space of the dependencies of the graph, taking into account the information related to security. This paper presents Depex, a tool created to support the method presented in our previous work [16]. Depex automates the complete process of the method, at both the logical and the user interface levels. In addition, Depex incorporates computational improvements that make the solution feasible in real scenarios. The contributions of Depex are as follows: •The support for the method generated in [16], by a tool which allows the developer of a software project to apply reasoning over the configuration space of his/her project; building a dependency graph from a public repository automatically and using an SMT model transformed in the background from the dependency graph. •The previous method was proposed for projects of Python (PyPI) nature, to make the solution more generalist, Depex expands the idea to projects of Java (Maven) and JavaScript (NPM) nature. Likewise, it implies tackling new challenges due to an increase in the complexity of software projects. •As the NP-complete satisfiability problems were not optimally used in previous work, the SMT model was not adapted to package managers such as Maven or NPM with a higher number of dependencies than PyPI. The new version has modified the SMT model to alleviate computational complexity. The main improvements within the SMT are related to the organisation of information, making it easier to reason about the information because the number of logical propositions to be processed is reduced: –The SMT model shown in Eq. (1) includes an excerpt of logical implication clause for each dependency version. For example, from version i to n, the SMT model would include as many formulas as the number of versions are between i and n. Currently, a single implication clause is included for versions with the same impact, as shown in Eq. (2). Therefore, for 𝑁 versions between i and n with the same impact, there are no 𝑁 clauses, only one that groups them all together. 𝐼𝑚𝑝𝑙𝑖𝑒𝑠(𝑃 𝑎𝑐𝑘𝑎𝑔𝑒 == 𝑉 𝑒𝑟𝑠𝑖𝑜𝑛𝑖, 𝐼𝑚𝑝𝑎𝑐𝑡𝑃 𝑎𝑐𝑘𝑎𝑔𝑒 == 𝐼𝑚𝑝𝑎𝑐𝑡) … 𝐼𝑚𝑝𝑙𝑖𝑒𝑠(𝑃 𝑎𝑐𝑘𝑎𝑔𝑒 == 𝑉 𝑒𝑟𝑠𝑖𝑜𝑛𝑛, 𝐼𝑚𝑝𝑎𝑐𝑡𝑃 𝑎𝑐𝑘𝑎𝑔𝑒 == 𝐼𝑚𝑝𝑎𝑐𝑡) (1) 𝐼𝑚𝑝𝑙𝑖𝑒𝑠(𝑃 𝑎𝑐𝑘𝑎𝑔𝑒 ≥𝑉 𝑒𝑟𝑠𝑖𝑜𝑛𝑖𝑎𝑛𝑑 𝑃 𝑎𝑐𝑘𝑎𝑔𝑒 ≤𝑉 𝑒𝑟𝑠𝑖𝑜𝑛𝑛, 𝐼𝑚𝑝𝑎𝑐𝑡𝑃 𝑎𝑐𝑘𝑎𝑔𝑒 == 𝐼𝑚𝑝𝑎𝑐𝑡) (2) –The aggregation functions have been improved by eliminating zero impacts from the calculations. For example, if the impact of a package is zero, it is not used in the average impacts. In this way, the function does not have to handle unnecessary variables. –Dead parts have been eliminated from the SMT model, meaning that dead parts are those versions of dependencies that cannot be in any configuration due to the constraints of the dependencies among other dependencies. For example, if urllib3 dependency has the constraint: ≥2.2.0,≤2.3.0 in a requirement file; automatically all versions outside the restriction, such as 2.1.0, cannot be used on the environment where the dependency is installed. Therefore, the SMT model should not take them into account. This does not affect the vulnerability analysis since versions that do not comply with the restrictions can never be present in the system configurations. Therefore, the vulnerabilities that affect them are not introduced. Having the advantage that by eliminating irrelevant information the model is smaller, which is beneficial for the efficiency and scalability of the solution. The rest of the article is organised as follows. Section 2 describes the architecture and functionalities of the Depex tool. Section 3 shows an illustrative example of how to use the tool. Section 4 develops the impact of our tool based on experimental results and available data. Section 5 introduces previous work in the current state of the art. Finally, Section 6 summarises the conclusions and highlights limitations and future work. 2. Software description Depex was developed following the Design Science Research (DSR) methodology [20]. The DSR focusses on generating scientific and technological insights to solve real-world problems encountered by professionals in the industry. The following subsections detail the architecture and functionalities of Depex. 2.1. Software architecture Fig. 1 shows an overview of the components that make up Depex, which contains five main components: 1. Frontend API component acts as a web interface for developers to use the functionality. The Front-End API has been developed with React JS. 2. Backend API component acts as a broker to standardise communication and integration with other external and internal services. The Backend API has been developed with FastAPI. 3. SMT package transforms the graph into an SMT model and applies automatic reasoning. The selected reasoner is Z3 Solver [21]. SoftwareX 30 (2025) 102152 2 A.G. Márquez et al. Fig. 1. Architecture of Depex components. 4. Depex DataBase stores graphs for later reuse, reducing the time it takes to build new graphs. Using both MongoDB and Neo4j databases. 5. Graph Generator component handles dependency extraction and attribution by connecting to External Services to search for information related to software projects (GitHub), package managers (PyPI, NPM and Maven) and vulnerabilities (NVD). The extracted information is used to enrich the Depex database. 6. Operations component calls the Graph Generator component from Depex Backend API, and using the SMT Reasoner package. Further, Fig. 1 shows a request–response example where a user, through the ReactJS-built front-end API, sends a request to verify the validity of a model, that is, if the model has at least one valid version configuration. This request is processed by the back-end API, developed with FastAPI, which interacts with various components of the Depex system. The backend extracts and attributes dependency data from external sources such as GitHub, PyPI, NPM, Maven, and NVD, storing the information in MongoDB and Neo4j. Then it applies automatic reasoning using the Z3 SMT reasoner to assess the validity of the model. Once the reasoning process is completed, the system returns a JSON response indicating that the model is valid based on the dependency analysis and SMT reasoning performed within the Depex framework. 2.2. Software functionalities The functionalities of Depex to perform reasoning on the security of dependencies are the following2: 1. Dependency Graph Extraction. We extract the requirement files from a software project repository and their direct dependencies from GitHub.3 Recursively, indirect dependencies are extracted from the package managers in a recursive process. Starting with the direct dependencies, calls are made to the 2This link also provides a demo video on how to use Depex: https://www. youtube.com/watch?v=8FoVLfNcx8o. 3GitHub: https://github.com/. APIs of the package managers to query their dependencies. Then with the second-level (indirect) dependencies, children of the direct ones, the same task is performed. And recursively, for every dependency that is added to the graph, until the ‘leaf’ dependencies are reached, i.e., software artefacts that do not depend on anything else. The information is loaded as a graph into the Depex database. 2. Attribution of dependency graphs with vulnerabilities. Each dependency included in the graph is attributed to the vulnerability information extracted from the NIST NVD vulnerability database [22]. When this step is finished, the graph is built up entirely. NVD was chosen due to its standardised structure, broad coverage, and government-backed reliability, ensuring consistency in vulnerability classification. In addition, its integration with the Common Vulnerabilities and Exposures (CVE) system facilitates automated processing and correlation with dependency data. These characteristics make NVD a suitable choice for building a comprehensive and structured vulnerability analysis within our approach. 3. Automatic Reasoning. The graph is used to create a formal model based on SMT. An SMT problem extends the Boolean satisfiability problem (SAT) [17] by incorporating richer mathematical structures such as Integers, Real numbers, arrays, and bit vectors. A SAT problem determines whether a Boolean formula is satisfiable, meaning at least one assignment of True/False to its variables makes the formula evaluate to True. For example: 𝑎∧ ¬𝑏 is satisfiable when 𝑎=True and 𝑏=False. SMT generalises this by allowing constraints over numeric and symbolic variables. A simple SMT problem could be: 𝑥+𝑦= 10 which is satisfiable if 𝑥= 5, 𝑦= 5. However, adding constraints as 𝑥 < 0 and 𝑦 < 0 makes it unsatisfiable. SMT solvers, such as Z3 [21] and cvc5 [23], efficiently determine satisfiability and can optimise constraints using techniques as: 𝑧=𝑥+𝑦 2 with constraints 0< 𝑥, 𝑦 < 10, allowing minimisation (𝑧= 0, 𝑥 = 0, 𝑦 = 0) or maximisation (𝑧= 10, 𝑥 = 10, 𝑦 = 10). SMT solvers [24] are widely used in formal verification, program analysis, and automated reasoning. Some of the operations that can be applied are, for example: (1) Check if a graph is valid, SoftwareX 30 (2025) 102152 3 A.G. Márquez et al. Fig. 2. Illustrative example of the case of use that Depex automatise. Fig. 3. Graph to SMT transformation example for RapidSMS. i.e. if there are no conflicting constraints between dependencies; (2) Return the configuration of dependencies with maximum and minimum security impact, or; (3) Return a configuration as close as possible to an impact according to the requirement of the developer. For reasoning, the depth of the graph being analysed can be a problem, as it adds more complexity to the model making it unable to solve it in time. In this case, Depex allows users to select how deep the relations are analysed, and in case it cannot give an answer within 5 s, to stop the execution of the operation. 3. Illustrative example This section shows an illustrative example of Depex application, using RapidSMS4 repository, an open-source framework that enables the development of interactive SMS applications, using Django5 to offer a comprehensive reporting interface. A RapidSMS developer who wants to preserve the security of its dependencies has to perform the manual work shown in Fig. 2 (left part), which consists of: (1) search direct dependencies and version range specified for each dependency 4RapidSMS: https://github.com/rapidsms/rapidsms. 5Django: https://github.com/django/django. from the requirements files; (2) discover the indirect dependencies recursively up to the last level, if it is wanted to have a better precision on the security of your software project; (3) for each version of the direct and indirect dependencies, find the known vulnerabilities that affect them; and, (4) perform reasoning over all that information to extract, for example a vulnerability-free version configuration. Since the number of version configurations within a software project can be large, this last step would be humanly unmanageable. Finally, the entire process of Fig. 2 must be performed again when the requirement file is updated. Following the functionality described in Section 2.2, the entire manual process shown to the left of Fig. 2 is automated as it is shown to the right part of Fig. 2. First, the dependency graph is extracted while attributing it to security-related information about the packages and their versions. Simply provide the name and owner of the repository, in this case, {owner: rapidsms, name: rapidsms}. Automatic analysis operations can be performed once the graph has been fully extracted and attributed, transforming the graph into an SMT model, as shown in Fig. 3. In Fig. 3, the red lines represent the transformation of direct dependencies, while the pink line indicates indirect dependencies. The green line illustrates the use of impact metrics (CVSS) to compute the aggregated impact for each dependency. The yellow line highlights the general aggregation of variables representing dependency impacts to determine the total effect of a configuration based on a requirements file. In addition, the dashed blue lines show the use of version SoftwareX 30 (2025) 102152 4 A.G. Márquez et al. numbers as numerical values assigned to dependencies, helping to identify vulnerabilities that affect them and contributing to the aggregation of impacts. Once the graph is transformed into an SMT model, the developer can apply reasoning operations automatically as shown in Fig. 2. An example is the operations to minimise and maximise the impact of vulnerabilities on dependencies, whose results are shown respectively in Listings 3.1 and 3.2. In this case, the results indicate that there is no configuration free of vulnerabilities, so the software development project would be vulnerable even in the best case; that is, the configuration with minimum impact. As for the configuration with maximum impact, we can see how it uses a version of Django with a higher impact of vulnerabilities, and also explores version paths, which make indirect dependencies appear as Certifi which is vulnerable. 3.1: Response of the minimise impact operation. { % Version of dependencies "django": "3.0rc1", "django-selectable": "0.7.0", "requests": "1.2.0", "django-tables2": "2.4.1", "djappsettings": "0.4.0", % Impact of dependencies "impact_requests": 2.83, "impact_django": 2.85, "impact_django-selectable": 0, "impact_djappsettings": 0, "impact_django-tables2": 0, % Impact of requirement file "file_risk_setup.py": 2.84 } 3.2: Response of the maximise impact operation. { % Version of dependencies "idna": "2.6", "urllib3": "2.0.0a4", "requests": "2.31.0", "django": "4.0.2", "certifi": "2017.7.27.1", "charset-normalizer": "3.0.0b1", "django-tables2": "2.1.1", "django-selectable": "0.7.0", "djappsettings": "0.4.0", % Impact of dependencies "impact_certifi": 5.9, "impact_requests": 0, "impact_charset-normalizer": 0, "impact_django": 4.77, "impact_idna": 0, "impact_urllib3": 0, "impact_django-selectable": 0, "impact_djappsettings": 0, "impact_django-tables2": 0, % Impact of requirement file "file_risk_setup.py": 5.4 } Finally, an example of an operation on a partial configuration is shown, where the developer requires certain dependencies to be in specific versions; for example, for specific requirements of the project, or because he/she needs to address a technical doubt before being able to choose higher versions of a dependency. Taking as an example the dependencies Django and Idna, in their versions 4.0.2 and 2.6 respectively, the complete configuration with the minimum impact, and without modifying those dependencies would be as shown in Listing 3.3 (the two dependencies whose versions are kept intact are indicated in green). 3.3: Response of the complete configuration operation. { % Version of dependencies "idna": "2.6", "django": "4.0.2", "certifi": "2023.11.17", "urllib3": "1.23", "django-tables2": "2.1.1", "chardet": "3.0.2", "django-selectable": "0.7.0", "requests": "2.19.0", "djappsettings": "0.4.0", % Impact of dependencies "impact_requests": 3.8, "impact_urllib3": 3.38, "impact_chardet": 0, "impact_certifi": 0, "impact_djappsettings": 0, "impact_django": 4.38, "impact_django-selectable": 0, "impact_idna": 0, "impact_django-tables2": 0, % Impact of requirement file "file_risk_setup.py": 3.86 } 4. Impact Dependency analysis in software development projects is a crucial task to ensure the security of organisations. To do so, software developers perform a complex and manual analysis process of third-party components, which is time-consuming, to ensure that no dependency vulnerabilities affect the main product. Depex aims to automatise the dependency analysis process, from dependency extraction to vulnerability attribution. And later, automatic reasoning that enables intelligent operation-based analysis, so that the developer can alleviate his workload. Due to the ability of Depex to analyse dependencies of different programming language natures, our tool can currently reach 47.9 million public repositories indexed on GitHub (18 million for Python, 17.4 million for JavaScript, and 12.5 million for Java). So, Depex can create graphs, discover/attribute vulnerabilities, and reason about those graphs, for 11.4% of the public repositories; out of the total of approximately 420 million indexed on GitHub. Depex has been compared with the tools on the market that currently work to discover vulnerabilities in dependencies, for a total of 93 software projects indexed on GitHub. These tools are DependaBot and Snyk, finding that Depex improves dependency and vulnerability discovery compared to both tools. For the case of DependaBot (only at the direct level, because it does not work at the indirect level), Depex can find approximately 64% more dependencies and 152% more vulnerabilities. For Snyk (both at the direct and indirect levels), Depex can find 483% more dependencies and 204% more vulnerabilities. On the other hand, Depex is the only current tool that incorporates automatic reasoning on the information extracted and shaped in a model (in this case using a graph). The results demonstrate the potential of Depex, not only in improving dependency and vulnerability detection but also in enhancing a deeper understanding of software ecosystems through automated reasoning. By incorporating SMT-based reasoning, Depex enables developers to perform advanced security assessments beyond traditional static analysis methods, as shown in the next evaluation (cf. Section 4.1). This capability facilitates proactive vulnerability detection, allowing organisations to mitigate risks more effectively before they impact production environments. Moreover, Depex opens up new research opportunities in dependency security and software supply chain analysis. Future studies could explore the integration of additional vulnerability databases, the integration of other package managers, optimisations in SMT-based reasoning, and broader applications in automated security auditing. These contributions position Depex as a valuable tool for both industry practitioners and researchers, fostering further advancements in dependency analysis and software security. SoftwareX 30 (2025) 102152 5 A.G. Márquez et al. Table 1 Performance of extraction algorithm in 24 h. Package manager PyPI Maven NPM N◦ of Packages 537 6,194 14,322 N◦ of Versions 33,816 511,331 840,790 N◦ of Require Relationships 859 1,852,000 5,353,714 Table 2 Performance of extraction algorithm in 24 h. Name Min Impact Min Time (s) Max Impact Max Time (s) RapidSMS 0.0 0.28 3.99 0.27 4.1. Evaluation To reinforce why Depex has a special impact and can be useful for developers, two simple experiments have been carried out to measure the efficiency of the tool on a set of 300 public software repositories; 100 repositories for each programming language (Python (PyPI), Java (Maven) and JavaScript (NPM)). Proving two conclusions: (1) Depex can extract graphs at great depth; (2) Improvements in Depex since previous work allow developers efficient reasoning, which enables time-efficient analysis of public software repositories. The first experiment is to measure whether Depex can generate complete graphs to a depth of N, being 𝑁 the maximum possible depth, within a time limit of 24 h. For 100 Python (PyPI) and JavaScript (NPM) repositories, the graphs could be completed in less than 24 h. For the repositories indexed in Maven, they could not be finished in that time. Table 1 shows the number of dependencies that could be extracted for the 100 PyPI, Maven, and NPM networks in 24 h. Note that PyPI, NPM, and Maven have approximately 400,000, 2 million, and 12 million dependencies, respectively. In addition, being Maven the repository with the most dependencies, Maven’s API is less modern than the other two and has worse performance. Therefore, extracting the complete graphs in less than 24 h is a cumbersome task. The second experiment details how, for most of the software development projects analysed by Depex, reasoning operations can be used in an affordable time. In total, 6 projects (1 belonging to Maven and 5 to NPM) out of 300 could not be evaluated in a reasonable time by any operation; so for 98% of the public repositories analysed, the reasoning is efficient. In addition, multiple projects without vulnerability-free configurations can be observed; in total, about 46 projects. It was determined that approximately 15% of the public repositories analysed in any of the dependency version configurations will be affected by vulnerabilities from third parties. Finally, of the repositories with vulnerability-free configurations, 10 more have at least one vulnerable configuration. Thus, the number of repositories free of vulnerable configurations is 244 (approx. 81%) compared to 56 (approx. 19%), that have at least one vulnerable configuration. Demonstrating that the automatic reasoning provided by Depex can be useful. Furthermore, Table 2 provides an overview of the RapidSMS project, analysing its performance impact. The minimum recorded impact is 0, indicating that the project has a vulnerability-free configuration of versions, while the maximum impact reaches 3.99, suggesting that some dependencies contribute notably to having some insecure configurations of versions. Regarding execution time, the minimum impact processing time recorded is 0.28 s, whereas the maximum impact time is 0.27 s, showing that the system maintains a relatively stable execution time across different scenarios. 5. Related work Regarding how dependencies have been analysed in the literature, both direct [25] and indirect dependencies have been studied [26]. There is an ongoing debate on how to handle the associated impact of these dependencies [26], as they can be grouped by the dependency owner. However, without grouping, our approach represents direct and indirect dependencies in a graph. Thus, the impact on the software project is calculated considering all dependencies collectively, with the network as the only possible grouping. Certain methods identify vulnerabilities in dependencies by matching names, terms, and values with those in CVEs and CPEs from the vulnerability database [12,13]. To our knowledge, only one approach uses dependency graphs, applying operations on directed graphs, such as cycle detection [14], rather than transforming them into a formal model for automatic reasoning. There are other methods focus on semantic aspects [11], code analysis of dependencies [9,10], and the coupling of dependencies within the source code [27], where the coupling is measured by the frequency of dependency usage in the source code. In addition, Xue et al. [28] use deep learning as a solution to generate embeddings (vector representations) to help identify vulnerabilities in open-source projects written in C. Our previous work has introduced a methodology that aims at automating the analysis and reasoning of the configuration space for dependencies in software development projects. The initial study [15] establishes the foundational principles of this methodology, while the subsequent article [16] presents a comprehensive and finalised description of the approach. These earlier contributions include: (1) constructing a graph that represents both direct and indirect dependencies, (2) enriching the dependency graph with security-related information, (3) converting the graph into a Satisfiability Modulo Theories (SMT) representation, and (4) enabling automated reasoning techniques to analyse the dependency configuration space with a focus on security attributes. However, a proposal comparable to that of in this work, i.e. the implementation of a concrete tool based on the theoretical framework described in our previous work, has not yet been implemented. In developing the tool, the complexity of Boolean satisfiability problems must be overcome to give a satisfactory dependency safety analysis in most cases. 6. Conclusions Keeping software development projects secure is a crucial task for developers, making it a real problem to keep software dependencies free of vulnerabilities. Furthermore, due to the complexity of analysing the entire configuration space, it is a complex and manually timeconsuming task, so an automatic analysis of software dependencies is necessary. To improve the state-of-the-art in this problem, the present work describes Depex. A tool applied to automatic analysis and reasoning about vulnerabilities in software dependencies. First, extract and build a dependency graph, attribute it with known vulnerabilities, and transform it into an SMT model. This allows us to reason on this information to look for answers to questions about the security status of our dependencies. The impact of Depex can be seen as the tool allows the analysis of 47.9 million public repositories indexed on GitHub. Reaching a higher dependency and vulnerability discovery power than current market tools such as DependaBot or Snyk; Depex detects a higher percentage of dependencies (approximately 274%) and vulnerabilities (approximately 178%). After an evaluation of 300 public repositories, it has been found that Depex can extract all dependencies for Python and JavaScript repositories in less than 24 h, but not for Java repositories. In addition, Depex can apply reasoning operations efficiently for 98% of the analysed repositories. Finally, Depex has helped to find vulnerable configurations in a total of 56 (approximately 19%) of the repositories, while it has shown that the rest (244 repositories) are free of vulnerabilities. However, Depex has some limitations that can be translated into future work to extend the tool. These limitations and plans are as SoftwareX 30 (2025) 102152 6 A.G. Márquez et al. follows. On the one hand, there are inconsistencies between the different vulnerability databases. Therefore, incorporating new vulnerability databases could help reduce inconsistencies, provide more security information, and perform a more accurate risk analysis. However, the inability to analyse more complex graphs is still a challenge. In very large and deep graphs, reasoning becomes time-consuming because of the variability between all possible configurations. Finally, we plan to incorporate other solvers that can work in parallel. CRediT authorship contribution statement Antonio Germán Márquez: Writing – review & editing, Writing – original draft, Visualization, Validation, Supervision, Software, Methodology, Investigation, Conceptualization. Ángel Jesús VarelaVaca: Writing – review & editing, Writing – original draft, Visualization, Validation, Conceptualization. María Teresa Gómez López: Writing – review & editing, Writing – original draft, Visualization, Validation, Conceptualization. José A. Galindo: Writing – review & editing, Writing – original draft, Visualization, Validation, Conceptualization. David Benavides: Writing – review & editing, Writing – original draft, Visualization, Validation, Conceptualization. Declaration of competing interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Acknowledgements This work was supported by the Spanish R&D Research Programme and FEDER/Ministry of Science, Innovation and Universities/Junta de Andalucía/State Research Agency/CDTI with the following grants: AETHER-US (PID2020-112540RB-C44), KOSMOS-US (PID2024155363OB-C42), ALBA-US (TED2021-130355B-C32), TASOVA PLUS research network (RED2022-134337-T), Data-pl (PID2022-138486OBI00), and AquaIA (GOPG-SE-23-0011) funded by MCIN/AEI/ 10.13039501100011033 and the ‘‘European Union NextGenerationEU/ PRTR’’. References [1] He R, He H, Zhang Y, Zhou M. Automating dependency updates in practice: An exploratory study on GitHub dependabot. IEEE Trans Softw Eng 2023;49(8):4004–22. http://dx.doi.org/10.1109/TSE.2023.3278129. [2] Cox R. Surviving software dependencies. Commun ACM 2019;62(9):36–43. http: //dx.doi.org/10.1145/3347446. [3] Duarte JAG. Evolution, testing and configuration of variability systems intensive. [Ph.D. thesis], France: University of Rennes 1; 2015, URL https://tel.archivesouvertes.fr/tel-01187958. [4] Galindo JA, Benavides D, Segura S. Debian packages repositories as software product line models. Towards automated analysis. In: ACOTA, Belgium, September, 2010, vol. 688, CEUR-WS.org; 2010, p. 29–34. [5] National Vulnerability Database. 2024, https://nvd.nist.gov/vuln/detail/CVE2024-3094. [6] Snyk. 2023, https://snyk.io/. [7] OWASP dependency-check. 2023, https://owasp.org/www-project-dependencycheck/. [8] Dependabot. 2023, https://github.com/dependabot. [9] Ponta S, Plate H, Sabetta A. 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; 2018, p. 449–60. http://dx.doi.org/ 10.1109/ICSME.2018.00054. [10] Ye R, Liu L, Hu S, Zhu F, Yang J, Wang F. JSLIM: Reducing the known vulnerabilities of JavaScript application by debloating. Commun Comput Inf Sci 2022;1403 CCIS:128–43. http://dx.doi.org/10.1007/978-3-030-93956-4_8, Cited by: 1. [11] Alqahtani SS, Eghan EE, Rilling J. Tracing known security vulnerabilities in software repositories – a semantic web enabled modeling approach. Sci Comput Program 2016;121:153–75. http://dx.doi.org/10.1016/j.scico.2016.01.005. [12] Cadariu M, Bouwers E, Visser J, van Deursen A. Tracking known security vulnerabilities in proprietary software systems. In: 2015 IEEE 22nd SANER. 2015, p. 516–9. http://dx.doi.org/10.1109/SANER.2015.7081868. [13] Hejderup J. In dependencies we trust: How vulnerable are dependencies in software modules?. 2015. [14] Li Q, Song J, Tan D, Wang H, Liu J. PDGraph: A large-scale empirical study on project dependency of security vulnerabilities. 2021, p. 161–73. http://dx.doi. org/10.1109/DSN48987.2021.00031, Cited by: 3. [15] Márquez G, Galindo JA, Varela-Vaca ÁJ, López MTG, Benavides D. Advisory: Vulnerability analysis in software development project dependencies. In: Proceedings of the 26th ACM international systems and software product line conference - volume b. New York, NY, USA: Association for Computing Machinery; 2022, p. 99–102. http://dx.doi.org/10.1145/3503229.3547058. [16] Germán Márquez A, Varela-Vaca ÁJ, Gómez López MT, Galindo JA, Benavides D. Vulnerability impact analysis in software project dependencies based on satisfiability modulo theories (SMT). Comput Secur 2024;139:103669. http: //dx.doi.org/10.1016/j.cose.2023.103669, URL https://www.sciencedirect.com/ science/article/pii/S0167404823005795. [17] Alyahya TN, Menai MEB, Mathkour H. On the structure of the boolean satisfiability problem: A survey. ACM Comput Surv 2022;55(3). http://dx.doi.org/10. 1145/3491210. [18] Barbosa H, Barrett C, Brain M, Kremer G, Lachnitt H, Mann M, Mohamed A, Mohamed M, Niemetz A, Nötzli A, Ozdemir A, Preiner M, Reynolds A, Sheng Y, Tinelli C, Zohar Y. cvc5: A versatile and industrial-strength SMT solver. In: Fisman D, Rosu G, editors. Tools and algorithms for the construction and analysis of systems. Cham: Springer International Publishing; 2022, p. 415–42. [19] The 18th international satisfiability modulo theories competition (SMT-COMP 2023). 2023, https://smt-comp.github.io/2023/. [20] Peffers K, Tuunanen T, Rothenberger MA, Chatterjee S. A design science research methodology for information systems research. J Manage Inf Syst 2014;24(3):45–77. http://dx.doi.org/10.2753/MIS0742-1222240302. [21] Z3 solver. 2023, https://github.com/Z3Prover/z3. [22] National Institute of Standards and Technology. NIST national vulnerability database. 2011, URL http://nvd.nist.gov. [23] cvc5 solver. 2023, https://github.com/cvc5/cvc5. [24] Arcaini P, Gargantini A, Vavassori P. Generating tests for detecting faults in feature models. In: 2015 IEEE 8th ICST. IEEE; 2015, p. 1–10. [25] Cox J, Bouwers E, van Eekelen M, Visser J. Measuring dependency freshness in software systems. In: 2015 IEEE/ACM 37th ICSE, vol. 2, 2015, p. 109–18. http://dx.doi.org/10.1109/ICSE.2015.140. [26] Kula RG, Germán DM, Ouni A, Ishio T, Inoue K. Do developers update their library dependencies? An empirical study on the impact of security advisories on library migration. CoRR 2017. arXiv:1709.04621. [27] Tàrrega NB, Živković M, Oprescu A. Measuring the impact of library dependency on maintenance. In: Proceedings of the CEUR workshop, vol. 2754, 2020, URL https://www.scopus.com/inward/record.uri?eid=2-s2.085098094486&partnerID=40&md5=3792b50d2683d4a69eb5331d84b54c06, Cited by: 0, [28] Yuan X, Lin G, Tai Y, Zhang J. Deep neural embedding for software vulnerability discovery: Comparison and optimization. Secur Commun Networks 2022;2022. http://dx.doi.org/10.1155/2022/5203217, https: //www.scopus.com/inward/record.uri?eid=2-s2.0-85124145032&doi=10. 115520225203217&partnerID=40&md5=d85c515814070b05ff84f3d24d82ff18, Cited by: 1; All Open Access, Gold Open Access. SoftwareX 30 (2025) 102152 7