Software dependency upgrading method and device, computer equipment, storage medium and product

Abstract

The invention relates to a software dependency upgrading method and device, computer equipment, a storage medium and a product, and belongs to the technical field of software. The method comprises the steps of obtaining a dynamically updated relational knowledge graph, extracting a corresponding project knowledge sub-graph from the relational knowledge graph based on dependency configuration of a target software project, performing risk analysis on the project knowledge sub-graph by using a graph model, and predicting a risk propagation path of the target software project. The risk propagation path comprises at least one of a vulnerability propagation path and a compatibility fracture path, and generating at least one dependency upgrading strategy for the risk propagation path through a multi-objective optimization algorithm, the optimization objectives of the multi-objective optimization algorithm comprise at least two of the following objectives: minimizing the security risk, maximizing the compatibility confidence and minimizing the upgrading cost; and performing dependency upgrading on the target software project based on the at least one dependency upgrading strategy. Through the method, the automation level, the safety and the overall efficiency of dependency management can be improved.

Description

Technical Field

[0001] This application relates to the field of software technology, and in particular to a software dependency upgrade method, apparatus, computer equipment, storage medium, and product. Background Technology

[0002] In the field of software project dependency management, related technologies mainly rely on static dependency tree analysis and single-target vulnerability scanning.

[0003] However, current solutions struggle to effectively predict and resolve compatibility issues during version upgrades, lack overall control over collaborative upgrades of multiple dependencies, and rely heavily on manual intervention for vulnerability remediation, which is both inefficient and prone to overlooking deeper security vulnerabilities. Existing tools are severely out of step with the rapidly evolving open-source ecosystem, failing to obtain the latest version and interface change information in a timely manner. Furthermore, current solutions can only be optimized for a single objective, failing to achieve an effective balance between multiple important dimensions such as security, compatibility, and maintenance costs, resulting in poor dependency management performance. Summary of the Invention

[0004] This application provides a software dependency upgrade method, apparatus, computer device, storage medium, and product, which can improve the automation level, security, and overall efficiency of dependency management. The technical solution is as follows.

[0005] On the one hand, a software dependency upgrade method is provided, the method comprising: Obtain dynamically updated relationship knowledge graphs; Based on the dependency configuration of the target software project, the corresponding project knowledge subgraph is extracted from the relational knowledge graph; Risk analysis is performed on the project knowledge subgraph using a graph model to predict the risk propagation path of the target software project. The risk propagation path includes at least one of the following: vulnerability propagation path, compatibility failure path. At least one dependency upgrade strategy is generated for the risk propagation path using a multi-objective optimization algorithm. The optimization objectives of the multi-objective optimization algorithm include at least two of the following: minimizing security risk, maximizing compatibility confidence, and minimizing upgrade cost. The target software project is upgraded based on at least one of the aforementioned dependency upgrade strategies.

[0006] On the other hand, a software dependency upgrade apparatus is provided, the apparatus comprising: The graph acquisition module is used to acquire dynamically updated relationship knowledge graphs. The subgraph extraction module is used to extract the corresponding project knowledge subgraph from the relational knowledge graph based on the dependency configuration of the target software project. The risk analysis module is used to perform risk analysis on the project knowledge subgraph using a graph model, and predict the risk propagation path of the target software project. The risk propagation path includes at least one of the following: vulnerability propagation path and compatibility failure path. The strategy generation module is used to generate at least one dependency upgrade strategy for the risk propagation path through a multi-objective optimization algorithm. The optimization objectives of the multi-objective optimization algorithm include at least two of the following: minimizing security risks, maximizing compatibility confidence, and minimizing upgrade costs. A dependency upgrade module is used to perform dependency upgrades on the target software project based on the at least one dependency upgrade strategy.

[0007] In one possible implementation, the strategy generation module includes: The model building submodule is used to build a multi-objective optimization model, wherein the objective functions of the multi-objective optimization model include a safety objective function, a compatibility objective function, and a cost objective function. The strategy generation submodule is used to simulate dependency escalation actions using a reinforcement learning model based on the risk propagation path, and generate a set of candidate escalation strategies. The computational submodule is used to take the set of candidate upgrade strategies as input, solve it using a multi-objective genetic algorithm, and obtain the Pareto optimal solution set of the multi-objective optimization model, wherein the Pareto optimal solution set contains at least one dependent upgrade strategy.

[0008] In one possible implementation, the dependency upgrade module includes: The function value acquisition submodule is used to acquire the function value of the objective function corresponding to each optimization objective of the at least one dependency upgrade strategy; The sorting submodule is used to prioritize the at least one dependency upgrade strategy based on a pre-defined priority order of optimization objectives and the function values ​​of the objective functions corresponding to each optimization objective of the at least one dependency upgrade strategy. The first upgrade submodule is used to perform dependency upgrades on the target software project based on the highest priority target dependency upgrade strategy.

[0009] In one possible implementation, the dependency upgrade module includes: The priority calculation submodule is used to calculate the upgrade priority of each entity on the vulnerability propagation path when the risk propagation path includes the vulnerability propagation path. The second upgrade submodule is used to perform dependency upgrades on each entity of the target software project according to the upgrade priority order of each entity; The upgrade priority of an entity is negatively correlated with the number of connections in the project knowledge subgraph and negatively correlated with the corresponding upgrade cost.

[0010] In one possible implementation, the device further includes: The data acquisition module is used to collect data from multiple data sources to obtain multi-source data; The graph construction module is used to extract entity metadata and relationships between entities based on the multi-source data in order to construct or update the relationship knowledge graph.

[0011] In one possible implementation, the device further includes: The weight calculation module is used to dynamically calculate the entity weight corresponding to each entity based on the entity metadata of each entity. The entity weight includes at least one of vulnerability risk weight, version stability weight, and compatibility confidence.

[0012] In one possible implementation, the dependency upgrade module is used for, The target dependency upgrade strategy is automatically simulated and verified in a sandbox environment to obtain the verification results of the target dependency upgrade strategy. If the verification result of the target dependency upgrade strategy indicates successful verification, the target software project is upgraded based on the target dependency upgrade strategy.

[0013] In one possible implementation, the test items for the automated simulation verification include at least one of the following: unit test coverage, API change detection, and performance baseline comparison; The device further includes: An update module is configured to update at least one of the relational knowledge graph and the multi-objective optimization algorithm based on the verification result of the target dependency upgrade strategy if the verification result indicates that the verification has failed.

[0014] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the above-described software dependency upgrade method.

[0015] On the other hand, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer program, which is loaded and executed by a processor to implement the above-described software dependency upgrade method.

[0016] On the other hand, a computer program product is provided, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform to implement the software dependency upgrade method provided in the various optional implementations described above.

[0017] The technical solution provided in this application may include the following beneficial effects: The software dependency upgrade method provided in this application obtains a dynamically updated relational knowledge graph, extracts a project knowledge subgraph based on the dependency configuration of the target project, uses a graph model to perform risk analysis and predict vulnerability propagation and compatibility breakdown paths, and then generates a dependency upgrade strategy that balances security, compatibility, and cost through a multi-objective optimization algorithm, and completes the dependency upgrade based on the strategy. Through this method, leveraging dynamic knowledge graphs and graph model analysis, accurate identification and prediction of deep risk paths in complex dependency chains are achieved, significantly improving the globality and foresight of risk perception. Furthermore, by introducing a multi-objective optimization mechanism, intelligent trade-offs and optimizations can be achieved among multiple key dimensions such as security, compatibility, and upgrade cost, effectively overcoming the limitations of single-objective optimization, generating a globally optimal collaborative upgrade solution, significantly reducing reliance on manual decision-making, and improving the automation level, security, and overall efficiency of dependency management.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] Figure 1 A flowchart of a software dependency upgrade method provided in an exemplary embodiment of this application is shown; Figure 2 A schematic diagram illustrating a knowledge graph modeling process provided in an exemplary embodiment of this application is shown. Figure 3 A schematic diagram of a sandbox verification process provided in an exemplary embodiment of this application is shown; Figure 4 A block diagram of a software dependency upgrade apparatus provided in an exemplary embodiment of this application is shown; Figure 5 A structural block diagram of a computer device illustrated in an exemplary embodiment of this application is shown; Figure 6 A structural block diagram of a computer device illustrated in an exemplary embodiment of this application is shown. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0022] This application provides a software dependency upgrade method based on knowledge graphs and multi-objective optimization algorithms. It can overcome the limitations of static analysis by modeling the complex influence chain between software dependencies through the indicator graph, and achieve the global optimal decision for multi-version upgrades. The multi-objective optimization algorithm generates an upgrade strategy that takes into account security, compatibility and cost. Figure 1 This application illustrates a flowchart of a software dependency upgrade method provided in an exemplary embodiment. This method can be executed by a computer device, which can be implemented as a server or a terminal, such as... Figure 1 As shown, the method may include the following steps.

[0023] Step 110: Obtain the dynamically updated relational knowledge graph.

[0024] This dependency graph can represent the various entities with dependencies and their complex relationships through a graph structure. In this embodiment, each entity in the dependency knowledge graph may include one or more of the following: dependency libraries, dependency library versions, vulnerabilities, and developer experience. For example, a dependency library may be a library such as log4j or spring-core, and the dependency library version may be log4j:2.17.1, including release time and lifecycle status. A vulnerability may be a CVE (Common Vulnerabilities and Exposures) number, a CVSS (Common Vulnerability Scoring System) score, an affected version range, etc. Developer experience refers to verified remediation solutions in the relevant field, such as compatibility remediation solutions, security remediation solutions, etc. It should be noted that the above examples of various entities are only illustrative and this application does not impose any limitations on them.

[0025] In a relational knowledge graph, the edges connecting entities can indicate the relationships between them. In this embodiment, the relationships between entities can include one or more of the following: dependency, vulnerability association, compatibility, and substitution. For example, a dependency relationship means that version A depends on version B, such as spring-boot:3.0.0 depends on tomcat:10.0.0; a vulnerability relationship means that vulnerability V affects version A; a compatibility relationship means that version A is compatible with version B; and a substitution relationship means that version C can be a compatible substitute for version A, such as log4j can replace logback.

[0026] The relational knowledge graph can be pre-built or dynamically updated before software dependency upgrades. Therefore, before obtaining the dynamically updated relational knowledge graph, the method also includes: Data is collected from multiple data sources to obtain multi-source data; Based on multi-source data, entity metadata and relationships between entities are extracted to construct or update relationship knowledge graphs.

[0027] Multi-source data sources can include data sources corresponding to different types of entities. For example, for dependency libraries, the corresponding data sources could include Maven repositories, private repositories, etc. Computer devices can extract dependency library metadata from the corresponding data sources, such as dependency library version, release time, dependency declarations, etc. Furthermore, computer devices can identify API (Application Programming Interface) change history during version upgrades by parsing the dependency library's commit records, such as API deprecation, parameter changes, etc. For vulnerabilities, the corresponding data sources could include vulnerability databases, CVE (Common Vulnerabilities and Exposures) platforms, GitHub security announcements, etc. Computer devices can extract associated vulnerability IDs (such as CVE-2021-44228) and the range of affected dependency versions from the data sources corresponding to vulnerabilities. For developer experience, computer devices can extract relevant data from various developer discussion platforms, such as extracting frequently occurring compatibility issues and corresponding remediation solutions.

[0028] Computer devices collect data from multiple data sources to obtain multi-source data. Based on predefined entities and the relationships between entities, entity metadata and the relationships between entities are extracted to construct or update a relational knowledge graph.

[0029] Furthermore, when constructing or updating a relational knowledge graph, the computer device can dynamically calculate the entity weight corresponding to each entity based on the entity metadata of each entity. The entity weight includes at least one of vulnerability risk weight, version stability weight, and compatibility confidence. Figure 2 This illustration shows a schematic diagram of a knowledge graph modeling process provided in an exemplary embodiment of this application, such as... Figure 2 As shown, the process includes three stages: entity definition (210), relationship definition (220), and dynamic weight calculation (230). In the entity definition stage, the entity types in the relationship knowledge graph are defined, including dependency libraries, dependency library versions, vulnerabilities, and developer experience. In the relationship definition stage, the relationships between entities in the relationship knowledge graph are defined, including dependency relationships, vulnerability association relationships, compatibility relationships, and substitution relationships. In the dynamic weight calculation stage, different entity weights can be calculated for different entity types. For example, vulnerability risk weights are calculated for vulnerability entities, version stability weights are calculated for dependency library version entities, and compatibility confidence weights are calculated for developer experience. Illustratively, the entity metadata corresponding to a vulnerability entity can include vulnerability score, vulnerability exposure time, and affected version usage rate. The calculation method for its corresponding vulnerability risk weight can be expressed as follows: CVSS score × vulnerability exposure time × affected version usage rate The metadata for the dependency library version entity can include version release duration, GitHub star growth trend, and community issue resolution rate. The calculation method for the version stability weight of the dependency library version entity can be expressed as follows: Release duration × GitHub Star growth trend × Community issue resolution rate The entity metadata of a developer's experience entity can include rule matching degree and success rate, and the corresponding compatibility confidence can be calculated as follows: Rule matching degree × Percentage of successful community verification cases The matching degree of this rule can be the matching degree of SemVer (Semantic Versioning) rules, such as the consistency between SemVer major version numbers, where 1 is the same as the major version number and 0 is the opposite.

[0030] As the entity metadata of each entity changes, its corresponding entity weight will also be updated. In one possible implementation, the computer device can periodically acquire the entity metadata of each entity to update the entity weight; the entity weight of each entity can be used as the basis for subsequent risk propagation path ranking.

[0031] Step 120: Based on the dependency configuration of the target software project, extract the corresponding project knowledge subgraph from the relational knowledge graph.

[0032] In one possible implementation, a computer device can obtain the project configuration file of the target software project. This project configuration file may contain definitions of project dependencies, build configurations, plugins, and metadata. By parsing the project configuration file, the computer device can obtain the dependency configuration of the target software project. Based on this dependency configuration, it can extract relevant entities and the relationships between relevant entities from the relational knowledge graph to construct a project knowledge subgraph. For example, if the project dependency tree corresponding to the dependency configuration of the target software project includes A→B→C (vulnerability V1) and A→D→C (vulnerability V2), then a project knowledge subgraph containing A, B, C, D, V1, V2, and their related relationships can be extracted from the relational knowledge graph.

[0033] Step 130: Use a graph model to perform risk analysis on the project knowledge subgraph and predict the risk propagation path of the target software project. The risk propagation path includes at least one of the following: vulnerability propagation path and compatibility failure path.

[0034] This graph model can be a prediction model based on graph neural networks or a propagation model based on random walks. It encodes entity nodes and edges in the project knowledge subgraph into vectors. With dynamic entity weights, this vector weight is incorporated to perform risk analysis on the project knowledge subgraph, thereby predicting risk propagation paths. Illustratively, the graph model can traverse the project knowledge subgraph to predict vulnerability propagation paths and / or compatibility breakdown paths in the target software project. A vulnerability propagation path can refer to the path taken from a known vulnerable entity, through direct or indirect dependencies, to transmit security risks to the target software project. A sequence of entities and dependencies, illustratively speaking, based on the project's knowledge subgraph, shows that the vulnerability propagation path in the target software project could be vulnerability V1→C→B→A, indicating the vulnerability's impact level. A compatibility break path refers to a sequence of conflicting entities and dependencies in the project's knowledge graph, caused by version upgrades or semantic version rule mismatches, leading to the target software project or other dependencies failing to build or run normally. Illustratively speaking, based on the project's knowledge subgraph, a compatibility break path in the target software project could be that upgrading B to a new version might cause API incompatibility between B and C, thus affecting A.

[0035] In one possible implementation, the computer device can perform risk analysis on the project knowledge subgraph to obtain multiple risk propagation paths. In this case, the computer device can sort the risk propagation paths according to the entity weights of the key entity nodes in each risk propagation path, and filter the risk propagation paths based on the sorting results, or process the risk propagation paths according to the order indicated by the sorting results. Here, the key entity node can refer to one or more entity nodes in the risk propagation path that play a decisive role in the severity of the risk, the probability of propagation, or the global scope of impact of the path. Illustratively, the key entity node can be the entity node with the highest entity weight among the entity nodes involved in the risk propagation path, or the key entity node can be the starting entity node of the risk propagation path, or it can be an entity node determined based on other custom rules. This application embodiment does not limit this.

[0036] In one possible implementation, the computer device can generate a risk report after determining the risk propagation path and send the risk report to relevant personnel to alert them to the potential risks of the target software project. The risk report may include a sorted list of risk propagation paths and potential compatibility break paths, such as "upgrading log4j to 2.x may cause incompatibility with Hadoop 2.9.0".

[0037] Step 140: Generate at least one dependency upgrade strategy for the risk propagation path using a multi-objective optimization algorithm. The optimization objectives of the multi-objective optimization algorithm include at least two of the following: minimizing security risks, maximizing compatibility confidence, and minimizing upgrade costs.

[0038] In this embodiment, the computing device can transform a multi-objective optimization problem into a computable constrained optimization problem through mathematical modeling, and set a fitness function and algorithm flow to ensure that the generated dependency upgrade strategy simultaneously satisfies the objectives of security, compatibility, and economy. At least one dependency upgrade strategy is generated for the risk propagation path using a multi-objective optimization algorithm, including: A multi-objective optimization model is established, whose objective functions include a safety objective function, a compatibility objective function, and a cost objective function. Based on the risk propagation path, a reinforcement learning model is used to simulate dependency escalation actions and generate a set of candidate escalation strategies. A multi-objective genetic algorithm is used to screen the candidate upgrade strategy set to obtain at least one dependent upgrade strategy.

[0039] Schematic, the security objective of this security objective function is to minimize the total vulnerability risk weight, and this security objective function can be expressed as:

[0040] in, The total weight used to calculate the vulnerability propagation path is expressed by the following formula:

[0041] in, This represents the vulnerability score (ranging from 1 to 10). The usage rate of the affected versions (value range: 0-1). Indicates the time when the vulnerability was exposed.

[0042] The compatibility objective of this compatibility function is to maximize the compatibility confidence between dependencies. This compatibility function can be expressed as:

[0043] in, Let S be the set of dependencies after the implementation of the candidate upgrade strategy S. The compatibility score (0-1) for dependencies i and j is calculated using the following formula:

[0044] For semantic version rule matching degree, The percentage of successful community experience cases. , These are weighting coefficients, which can be dynamically adjusted based on actual needs.

[0045] The cost objective of this cost objective function is to minimize the amount of code changes, such as the number of API changes, the scope of dependency upgrades, etc. This cost objective function can be expressed as:

[0046] in, This indicates the number of dependencies for the upgrade. The number of disruptive API changes can be identified by comparing bytecode. This represents the number of dependencies dispatched. α, β, and γ are cost coefficients. The values ​​of each coefficient can be set based on actual needs to reflect the cost of different operations.

[0047] Based on the above objective functions, a multi-objective optimization function with the objectives of minimizing security risk, maximizing compatibility confidence, and minimizing upgrade cost can be expressed as:

[0048] The multi-objective optimization problem also includes additional conditions, namely, critical vulnerabilities must be fixed and core dependency versions must not be downgraded. Critical vulnerabilities can refer to vulnerabilities with a vulnerability score higher than a score threshold, such as CVSS ≥ 7.0. The score threshold can be set based on actual needs, and this application does not impose any restrictions on it. Core dependency versions play a fundamental and supporting role in the project's technology stack. Changes to their versions may trigger cascading adaptations and a large number of code modifications to the dependency libraries. The computer equipment can determine the core dependency versions based on the amount of system code changes that each dependency library version may cause, or it can be determined based on the declaration information in the dependency management file. For example, the dependency library versions that are locked in the dependency management file can be identified as core dependency versions.

[0049] By solving this multi-objective optimization model, at least one dependency upgrade strategy for the risk propagation path can be obtained. In this process, a reinforcement learning model is first used to generate a set of candidate upgrade strategies. The state space of this reinforcement learning model represents the current state of the project dependency tree (including version, vulnerabilities, and compatibility relationships), and its action space includes operations such as upgrading, excluding, or locking dependencies. The reinforcement learning model simulates in the action space. After triggering an update to the project dependency tree, it interacts with the environment and calculates a reward score based on a comprehensive reward function. The strategy is then learned and optimized based on the reward score. This process is repeated to obtain higher reward scores, and then several candidate upgrade strategies with higher reward scores are added to the candidate upgrade strategy set. The reward function simultaneously considers security, compatibility, and cost objectives. Illustratively, the reward function can be expressed as:

[0050] Where R(S) represents the function value of the reward function corresponding to the simulated implementation of the candidate upgrade strategy S, and λ1 and λ2 are the reward weights, which can be set based on actual needs. In this embodiment, the reward weights can be set based on the goals of high compatibility and low cost.

[0051] In this way, the reinforcement learning model can output a high-quality set of candidate upgrade strategies. For example, one of the candidate upgrade strategies in the set of candidate upgrade strategies generated after exploration can be to upgrade A to version X or exclude dependency B.

[0052] After obtaining the set of candidate upgrade strategies, in order to explore more credible upgrade strategies, the computer device can use a multi-objective genetic algorithm to perform crossover, mutation, and selection on the candidate upgrade strategies in the set, thereby screening out the Pareto optimal solution set of the multi-objective optimization model to obtain at least one dependent upgrade strategy for the target software project; this process can be implemented as follows: S1401, Chromosome encoding is performed on each candidate upgrade strategy to obtain the binary chromosome of each candidate upgrade strategy; that is, the candidate upgrade strategy is encoded into a binary vector, and each bit in the binary vector is used to indicate whether the corresponding upgrade action is executed.

[0053] S1402 calculates the fitness of the binary chromosome of each candidate upgrade strategy through a fitness function, which is a multi-objective function constructed with security, compatibility and cost objectives.

[0054] Schematic, the fitness function can be expressed as:

[0055] S1403, based on the fitness of the binary chromosomes of each candidate upgrade strategy, perform the following iterative operation until the termination condition is met: The tournament selection method is used to select parent chromosomes from the current population, and the offspring chromosome population is generated using simulated binary crossover.

[0056] Randomly perform position flipping mutations on offspring chromosomes in the offspring chromosome population with a preset probability to explore new potential upgrade strategies; The mutated offspring population is merged with the parent population, and non-dominated solutions are identified and retained from the merged population to form the next generation population.

[0057] If there is no other solution in the current population that performs better or is consistent with it in all optimization objectives, then it is determined to be a non-dominated solution. For example, if there are three solutions in the current population: solution A (safety = 9, compatibility = 2), solution B (safety = 6, compatibility = 6), and solution C (safety = 2, compatibility = 9), since the safety (9) of A is better than that of B (6) and the compatibility (2) of A is worse than that of B (6), A cannot dominate B. The safety (6) of B is worse than that of A (9) and the compatibility (6) of B is better than that of A (2), so B cannot dominate A either. Similarly, comparing A and C, and B and C, will lead to the same conclusion of "mutual non-dominance". Therefore, in the current population, A, B, and C are mutually non-dominant and are all non-dominated solutions.

[0058] The iteration process is repeated until a termination condition is met. This termination condition can be that the distance between the nondominated solutions of the Pareto front in consecutive generations is less than a distance threshold, or that the number of iterations reaches a maximum threshold.

[0059] S1404, after the iteration terminates, outputs the set of non-dominated solutions in the final population as the Pareto optimal solution set.

[0060] Each non-dominated solution in the Pareto optimal solution set is at least one dependency upgrade strategy for the target software project.

[0061] Step 150: Upgrade the dependencies of the target software project based on at least one dependency upgrade strategy.

[0062] In one possible implementation, dependency upgrades of the target software project are performed based on at least one dependency upgrade strategy, including: Obtain the function value of the objective function corresponding to each optimization objective for at least one dependency upgrade strategy; Based on a pre-defined priority order of optimization objectives and the function value of the objective function corresponding to each optimization objective for at least one dependency upgrade strategy, the at least one dependency upgrade strategy is prioritized. Upgrade the dependencies of the target software project based on the highest priority target dependency upgrade strategy.

[0063] As an illustration, if in security-first mode, where minimizing security risk has the highest priority, then each dependency upgrade strategy will be implemented accordingly. Prioritize the upgrades; if the priority is economic priority (minimizing upgrade costs), then proceed according to the respective upgrade strategies for each dependency. Prioritize dependencies; if in compatibility-first mode (maximizing compatibility confidence has the highest priority), then proceed according to the respective dependency upgrade strategies. Priority ranking is performed; if in balanced mode, that is, considering all optimization objectives, the function values ​​of each objective function corresponding to the dependency upgrade strategy can be weighted and summed, and priority ranking can be performed based on the weighted summation results of each dependency upgrade strategy. The weights corresponding to each objective function can be set according to actual needs, and this application does not impose any restrictions on this.

[0064] After sorting based on the pre-defined priority order of optimization targets, the computer device can determine the highest priority dependency upgrade strategy as the target dependency upgrade strategy, and perform dependency upgrades on the target software project based on the target dependency upgrade strategy; wherein, dependency upgrade refers to replacing the dependency library used in the software project from an old version to a new version indicated by the dependency upgrade strategy.

[0065] When the risk propagation path includes a vulnerability propagation path, the target software project is upgraded based on at least one dependency upgrade strategy, including: Calculate the upgrade priority of each entity along the vulnerability propagation path; Dependency upgrades are performed on each entity in the target software project according to their upgrade priority. Among them, the upgrade priority of an entity is negatively correlated with the number of connections in the project knowledge subgraph and negatively correlated with the corresponding upgrade cost.

[0066] In other words, for vulnerability propagation paths (such as V→C→B→A), computer devices prioritize upgrading critical nodes in the propagation path, that is, the nodes with the highest upgrade priority in the path determined by the upgrade priority order, rather than directly upgrading the root node, in order to minimize the scope of impact.

[0067] The upgrade priority order can be obtained by sorting the entities based on their upgrade priority scores. For illustration, the calculation method for the upgrade priority score can be expressed as follows:

[0068] Where Degree(C) represents the degree (i.e. the number of connections) of entity node C in the dependency tree, the lower the degree, the smaller the scope of influence; UpgradeCost(C) represents the cost of upgrading entity node C.

[0069] In one possible implementation, before upgrading the dependencies of the target software project based on the dependency upgrade strategy, the computer device can first simulate the dependency upgrade strategy to verify its feasibility in order to verify the effectiveness of the strategy. If the verification result indicates success, the dependency upgrade strategy is then applied. Therefore, upgrading the dependencies of the target software project based on the highest priority target dependency upgrade strategy includes: The target dependency upgrade strategy is automatically simulated and verified in a sandbox environment to obtain the verification results of the target dependency upgrade strategy; If the verification result of the target dependency upgrade strategy indicates that the verification is successful, the target software project is upgraded based on the target dependency upgrade strategy.

[0070] The automated simulation verification test items include at least one of the following: unit test coverage, API change detection, and performance baseline comparison; the method also includes: If the verification result of the target dependency upgrade strategy indicates that the verification has failed, at least one of the relational knowledge graph and the multi-objective optimization algorithm shall be updated based on the verification result of the target dependency upgrade strategy.

[0071] Taking the test items, including unit test coverage, API change detection, and performance baseline comparison, as an example, Figure 3 A schematic diagram of a sandbox verification process provided in an exemplary embodiment of this application is shown, such as... Figure 3 As shown, the process may include a POM (Project Object Model) file rewriting phase, a sandbox environment building phase, a testing and verification phase, and a verification result classification phase.

[0072] The POM file rewriting phase includes version upgrades, dependency exclusions, and version locking; version upgrades involve modifying the POM file according to the target dependency upgrade strategy. <version>Tags are used during this process, which allows for batch upgrades, such as simultaneously upgrading Spring Boot and its associated dependencies; dependency exclusion is automatically added. <exclusions>Tags are used to remove conflicting dependencies, such as excluding log4j 1.x and replacing it with 2.x; version locking is... <dependencymanagement>Lock critical dependency versions to prevent future conflicts.

[0073] During the sandbox environment build phase, you can execute `mvn clean install` in the Docker container based on the new `pom.xml` (dependency configuration file) to isolate environment dependencies.

[0074] After the sandbox environment is built, the testing and verification phase begins. This phase includes unit test coverage, API change detection, and performance baseline comparison. For example, in unit test coverage, the pass rate after the upgrade is obtained. Unit test coverage is considered successful if the pass rate is not lower than a preset pass rate threshold, which can be set based on actual needs, such as 95%. In API change detection, the API call relationships before and after the upgrade are compared to identify and count the destructive changes caused by the upgrade. If the number of destructive changes is not zero, the API change detection verification fails. A destructive change refers to a modification made to the exposed application programming interfaces (APIs) of the software library in the new version, causing code that depends on the old version to fail to compile or link under the new version. Changes to the connection or normal operation, such as method signature changes, interface structural changes, deletion of public fields, etc.; When comparing performance baselines, by monitoring and comparing various key performance indicators (such as application startup time, memory usage, CPU utilization, etc.) of the project before and after the upgrade, the performance change range of each key performance indicator is calculated. The performance baseline comparison is considered successful only if the change range of all key performance indicators is controlled within the corresponding preset change range threshold. If the deterioration of any key performance indicator exceeds its corresponding threshold, it is determined that the performance baseline comparison has not passed. The preset change range threshold values ​​of different key indicators can be the same or different. All the above thresholds can be set based on actual needs, and this application embodiment does not impose any restrictions on this.

[0075] During the verification result classification phase, the computer equipment can comprehensively determine the verification result of the dependency upgrade strategy based on the verification results of each test item. When the number of test items is greater than or equal to 3, the verification result of the dependency upgrade strategy can be divided into verification success, verification failure, and partial verification success. In the case of verification success, the dependency upgrade strategy is executed, such as automatically submitting code changes and generating an upgrade report. In the case of partial verification success, such as individual test cases failing, residual problems caused by manual intervention are marked. In the case of verification failure, the original version of the target software project is maintained, and the reason for the failure of the dependency upgrade strategy is recorded.

[0076] Furthermore, if the verification result is a failure, a failure case backtracking process is initiated: that is, based on the verification result of the dependency upgrade strategy, at least one of the relational knowledge graph and the multi-objective optimization algorithm is updated. For the relational knowledge graph, the reason for the sandbox verification failure is associated with the corresponding entity node in the relational knowledge graph, and the attributes of the corresponding entity node are dynamically corrected. For example, if the failure is due to unforeseen compatibility issues, the compatibility weight between related versions is reduced. The reduction in weight can be set to a fixed percentage or a dynamic value based on the severity of the failure. If community experience does not cover this failure scenario, the case is added to the graph as negative experience. For the multi-objective optimization algorithm, the verification failure result is used as negative feedback to adjust the reward function parameters in the reinforcement learning model or the fitness calculation logic of the genetic algorithm, penalizing the decision choice that leads to the failure path, thereby guiding the model to generate more feasible upgrade strategies in future iterations.

[0077] In summary, the software dependency upgrade method provided in this application obtains a dynamically updated relational knowledge graph, extracts a project knowledge subgraph based on the dependency configuration of the target project, uses a graph model to perform risk analysis and predict vulnerability propagation and compatibility breakdown paths, and then generates a dependency upgrade strategy that balances security, compatibility, and cost through a multi-objective optimization algorithm, and completes the dependency upgrade based on the strategy. Through this method, leveraging dynamic knowledge graphs and graph model analysis, accurate identification and prediction of deep risk paths in complex dependency chains are achieved, significantly improving the globality and foresight of risk perception. Furthermore, by introducing a multi-objective optimization mechanism, intelligent trade-offs and optimizations can be achieved among multiple key dimensions such as security, compatibility, and upgrade cost, effectively overcoming the limitations of single-objective optimization, generating a globally optimal collaborative upgrade solution, significantly reducing reliance on manual decision-making, and improving the automation level, security, and overall efficiency of dependency management.

[0078] Figure 4 This illustration shows a block diagram of a software dependency upgrade apparatus provided in an exemplary embodiment of this application, which can perform actions such as Figure 1 All or part of the steps in the illustrated embodiments, such as Figure 4 As shown, the device may include the following modules.

[0079] Graph acquisition module 410 is used to acquire dynamically updated relational knowledge graphs; Subgraph extraction module 420 is used to extract the corresponding project knowledge subgraph from the relational knowledge graph based on the dependency configuration of the target software project. Risk analysis module 430 is used to perform risk analysis on the project knowledge subgraph using a graph model to predict the risk propagation path of the target software project. The risk propagation path includes at least one of the following: vulnerability propagation path and compatibility failure path. The strategy generation module 440 is used to generate at least one dependency upgrade strategy for the risk propagation path through a multi-objective optimization algorithm. The optimization objectives of the multi-objective optimization algorithm include at least two of the following: minimizing security risks, maximizing compatibility confidence, and minimizing upgrade costs. The dependency upgrade module 450 is used to upgrade the dependencies of the target software project based on the at least one dependency upgrade strategy.

[0080] In one possible implementation, the strategy generation module 440 includes: The model building submodule is used to build a multi-objective optimization model, wherein the objective functions of the multi-objective optimization model include a safety objective function, a compatibility objective function, and a cost objective function. The strategy generation submodule is used to simulate dependency escalation actions using a reinforcement learning model based on the risk propagation path, and generate a set of candidate escalation strategies. The computational submodule is used to take the set of candidate upgrade strategies as input, solve it using a multi-objective genetic algorithm, and obtain the Pareto optimal solution set of the multi-objective optimization model, wherein the Pareto optimal solution set contains at least one dependent upgrade strategy.

[0081] In one possible implementation, the dependency upgrade module 450 includes: The function value acquisition submodule is used to acquire the function value of the objective function corresponding to each optimization objective of the at least one dependency upgrade strategy; The sorting submodule is used to prioritize the at least one dependency upgrade strategy based on a pre-defined priority order of optimization objectives and the function values ​​of the objective functions corresponding to each optimization objective of the at least one dependency upgrade strategy. The first upgrade submodule is used to perform dependency upgrades on the target software project based on the highest priority target dependency upgrade strategy.

[0082] In one possible implementation, the dependency upgrade module 450 includes: The priority calculation submodule is used to calculate the upgrade priority of each entity on the vulnerability propagation path when the risk propagation path includes the vulnerability propagation path. The second upgrade submodule is used to perform dependency upgrades on each entity of the target software project according to the upgrade priority order of each entity; The upgrade priority of an entity is negatively correlated with the number of connections in the project knowledge subgraph and negatively correlated with the corresponding upgrade cost.

[0083] In one possible implementation, the device further includes: The data acquisition module is used to collect data from multiple data sources to obtain multi-source data; The graph construction module is used to extract entity metadata and relationships between entities based on the multi-source data in order to construct or update the relationship knowledge graph.

[0084] In one possible implementation, the device further includes: The weight calculation module is used to dynamically calculate the entity weight corresponding to each entity based on the entity metadata of each entity. The entity weight includes at least one of vulnerability risk weight, version stability weight, and compatibility confidence.

[0085] In one possible implementation, the dependency upgrade module 450 is used for, The target dependency upgrade strategy is automatically simulated and verified in a sandbox environment to obtain the verification results of the target dependency upgrade strategy. If the verification result of the target dependency upgrade strategy indicates successful verification, the target software project is upgraded based on the target dependency upgrade strategy.

[0086] In one possible implementation, the test items for the automated simulation verification include at least one of the following: unit test coverage, API change detection, and performance baseline comparison; The device further includes: An update module is configured to update at least one of the relational knowledge graph and the multi-objective optimization algorithm based on the verification result of the target dependency upgrade strategy if the verification result indicates that the verification has failed.

[0087] In summary, the software dependency upgrade device provided in this application acquires a dynamically updated relational knowledge graph, extracts a project knowledge subgraph based on the dependency configuration of the target project, uses a graph model to perform risk analysis and predict vulnerability propagation and compatibility breakdown paths, and then generates a dependency upgrade strategy that balances security, compatibility, and cost through a multi-objective optimization algorithm, and completes the dependency upgrade based on the dependency upgrade strategy. Through the above method, leveraging dynamic knowledge graphs and graph model analysis, accurate identification and prediction of deep risk paths in complex dependency chains are achieved, significantly improving the globality and foresight of risk perception. Furthermore, by introducing a multi-objective optimization mechanism, intelligent trade-offs and optimizations can be achieved among multiple key dimensions such as security, compatibility, and upgrade cost, effectively overcoming the limitations of single-objective optimization, generating a globally optimal collaborative upgrade solution, significantly reducing reliance on manual decision-making, and improving the automation level, security, and overall efficiency of dependency management.

[0088] Figure 5 A structural block diagram of a computer device 500 illustrated in an exemplary embodiment of this application is shown. This computer device can be implemented as a server as described above in this application. The computer device 500 includes a Central Processing Unit (CPU) 501, a system memory 504 including Random Access Memory (RAM) 502 and Read-Only Memory (ROM) 503, and a system bus 505 connecting the system memory 504 and the CPU 501. The computer device 500 also includes a mass storage device 506 for storing an operating system 509, application programs 510, and other program modules 511.

[0089] Without loss of generality, the computer-readable medium may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid-state storage technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that the computer storage media are not limited to the above-mentioned types. The system memory 504 and mass storage device 506 described above can be collectively referred to as memory.

[0090] According to various embodiments of this disclosure, the computer device 500 can also be connected to a remote computer on a network, such as the Internet. That is, the computer device 500 can be connected to a network 508 via a network interface unit 507 connected to the system bus 505, or it can use the network interface unit 507 to connect to other types of networks or remote computer systems (not shown).

[0091] The memory also includes at least one instruction, at least one program, code set, or instruction set, which are stored in the memory. The central processing unit 501 executes the at least one instruction, at least one program, code set, or instruction set to implement all or part of the steps in the software dependency upgrade method shown in the above embodiments.

[0092] Figure 6 A structural block diagram of a computer device 600 illustrating an exemplary embodiment of this application is shown. The computer device 600 can be implemented as the aforementioned terminal device, such as a smartphone, tablet computer, laptop computer, desktop computer, etc. The computer device 600 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

[0093] Typically, computer device 600 includes a processor 601 and a memory 602.

[0094] In some embodiments, the computer device 600 may optionally include a peripheral device interface 603 and at least one peripheral device. The processor 601, memory 602, and peripheral device interface 603 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 603 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 604, a display screen 605, a camera assembly 606, an audio circuit 607, and a power supply 608.

[0095] In some embodiments, the computer device 600 further includes one or more sensors 609. The one or more sensors 609 include, but are not limited to, an accelerometer 610, a gyroscope 611, a pressure sensor 612, an optical sensor 613, and a proximity sensor 614.

[0096] Those skilled in the art will understand that Figure 6 The structure shown does not constitute a limitation on the computer device 600, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0097] In one exemplary embodiment, a computer-readable storage medium is also provided, which stores at least one computer program that is loaded and executed by a processor to implement all or part of the steps in the software dependency upgrade method described above. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0098] In one exemplary embodiment, a computer program product is also provided, comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the above-described actions. Figure 1 All or part of the steps of the software dependency upgrade method shown in the embodiments.

[0099] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0100] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.< / dependencymanagement> < / exclusions> < / version>

Claims

1. A software dependency upgrade method, characterized in that, The method includes: Obtain dynamically updated relationship knowledge graphs; Based on the dependency configuration of the target software project, the corresponding project knowledge subgraph is extracted from the relational knowledge graph; Risk analysis is performed on the project knowledge subgraph using a graph model to predict the risk propagation path of the target software project. The risk propagation path includes at least one of the following: vulnerability propagation path, compatibility failure path. At least one dependency upgrade strategy is generated for the risk propagation path using a multi-objective optimization algorithm. The optimization objectives of the multi-objective optimization algorithm include at least two of the following: minimizing security risk, maximizing compatibility confidence, and minimizing upgrade cost. The target software project is upgraded based on at least one of the aforementioned dependency upgrade strategies.

2. The method according to claim 1, characterized in that, The step of generating at least one dependency upgrade strategy for the risk propagation path using a multi-objective optimization algorithm includes: A multi-objective optimization model is established, wherein the objective functions of the multi-objective optimization model include a safety objective function, a compatibility objective function, and a cost objective function; Based on the aforementioned risk propagation path, a reinforcement learning model is used to simulate dependency escalation actions and generate a set of candidate escalation strategies. Using the set of candidate upgrade strategies as input, a multi-objective genetic algorithm is used to solve the problem, resulting in a Pareto optimal solution set for the multi-objective optimization model, wherein the Pareto optimal solution set includes at least one dependent upgrade strategy.

3. The method according to claim 1 or 2, characterized in that, Upgrading the dependencies of the target software project based on the at least one dependency upgrade strategy includes: Obtain the function value of the objective function corresponding to each optimization objective of the at least one dependency upgrade strategy; Based on a pre-defined priority order of optimization objectives, and the function values ​​of the objective functions corresponding to each optimization objective, the at least one dependency upgrade strategy is prioritized. The target software project is upgraded based on the highest priority target dependency upgrade strategy.

4. The method according to claim 1, characterized in that, When the risk propagation path includes the vulnerability propagation path, the dependency upgrade of the target software project based on the at least one dependency upgrade strategy includes: Calculate the upgrade priority of each entity along the vulnerability propagation path; Dependency upgrades are performed on each entity of the target software project according to their upgrade priority. The upgrade priority of an entity is negatively correlated with the number of connections in the project knowledge subgraph and negatively correlated with the corresponding upgrade cost.

5. The method according to claim 1, characterized in that, Before obtaining the dynamically updated relational knowledge graph, the method further includes: Data is collected from multiple data sources to obtain multi-source data; Based on the multi-source data, entity metadata and the relationships between entities are extracted to construct or update the relationship knowledge graph.

6. The method according to claim 5, characterized in that, The method further includes: The entity weights of each entity are dynamically calculated based on the entity metadata of each entity. The entity weights include at least one of vulnerability risk weight, version stability weight, and compatibility confidence.

7. The method according to claim 3, characterized in that, The dependency upgrade strategy based on the highest priority target dependency upgrade strategy for the target software project includes: The target dependency upgrade strategy is automatically simulated and verified in a sandbox environment to obtain the verification results of the target dependency upgrade strategy. If the verification result of the target dependency upgrade strategy indicates successful verification, the target software project is upgraded based on the target dependency upgrade strategy.

8. The method according to claim 7, characterized in that, The automated simulation verification test items include at least one of the following: unit test coverage, API change detection, and performance baseline comparison; The method further includes: If the verification result of the target dependency upgrade strategy indicates that the verification has failed, at least one of the relational knowledge graph and the multi-objective optimization algorithm shall be updated based on the verification result of the target dependency upgrade strategy.

9. A device that relies on upgrades, characterized in that, The device includes: The graph acquisition module is used to acquire dynamically updated relationship knowledge graphs. The subgraph extraction module is used to extract the corresponding project knowledge subgraph from the relational knowledge graph based on the dependency configuration of the target software project. The risk analysis module is used to perform risk analysis on the project knowledge subgraph using a graph model, and predict the risk propagation path of the target software project. The risk propagation path includes at least one of the following: vulnerability propagation path and compatibility failure path. The strategy generation module is used to generate at least one dependency upgrade strategy for the risk propagation path through a multi-objective optimization algorithm. The optimization objectives of the multi-objective optimization algorithm include at least two of the following: minimizing security risks, maximizing compatibility confidence, and minimizing upgrade costs. A dependency upgrade module is used to perform dependency upgrades on the target software project based on the at least one dependency upgrade strategy.

10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one computer program, which is loaded and executed by the processor to implement the dependency upgrade method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the dependency upgrade method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer device, cause the computer device to perform the dependency upgrade method as described in any one of claims 1 to 8.

Images