Software item dependency package management method

Abstract

The present disclosure relates to a software project dependency package management method, an electronic device and a computer readable storage medium. The software project dependency package management method comprises: detecting a security vulnerability of a dependency package in a software project based on a security vulnerability database and a dependency information file; generating a repair scheme according to the detection result; and updating the dependency information file to repair the security vulnerability according to the repair scheme, wherein the dependency information file comprises information for building a dependency tree of the software project.

Description

Technical Field

[0001] This disclosure relates to the software field, and in particular to methods for managing software project dependency packages, electronic devices, and computer-readable storage media. Background Technology

[0002] As software development becomes increasingly complex, dependency management has become a critical aspect of ensuring the stability and security of software projects. Modern software development often relies on multiple third-party libraries or components, which provide the functionality and services required by the project. However, version updates or inappropriate selection of dependency packages can introduce security vulnerabilities, thereby affecting the security and stability of the entire software project. Existing dependency management tools typically only provide dependency version management and updates, lacking the ability to automatically detect and patch security vulnerabilities.

[0003] Currently, developers typically rely on manual detection and updates when addressing dependency vulnerabilities. This process is not only tedious but also error-prone, especially in multi-layered dependency relationships where vulnerabilities may be introduced indirectly by dependent packages, increasing the complexity of detection. Furthermore, existing tools cannot automatically verify the compatibility of patched versions, and patched projects may experience functional abnormalities due to version conflicts or incompatibility issues. Therefore, how to efficiently and automatically detect and patch security vulnerabilities in dependency packages, while ensuring that the patched project version is compatible with the original project, has become a major technological challenge. Summary of the Invention

[0004] In view of the above problems, this disclosure aims to provide a method for managing software project dependency packages, an electronic device, and a computer-readable storage medium.

[0005] The first aspect of this disclosure provides a software project dependency package management method, comprising: detecting security vulnerabilities in dependency packages within a software project based on a security vulnerability database and a dependency information file; generating a remediation plan based on the detection results; and updating the dependency information file to remediate the security vulnerabilities based on the remediation plan, wherein the dependency information file includes information used to construct the dependency tree of the software project.

[0006] According to some embodiments of the software project dependency package management method disclosed herein, optionally, a dependency information file is used to describe the dependency packages of the software project and their version information.

[0007] According to some embodiments of the software project dependency package management method disclosed herein, optionally, the security vulnerability database includes publicly available vulnerability data sources, and the vulnerability data sources include the correspondence between dependency package versions and vulnerabilities.

[0008] According to some embodiments of the software project dependency package management method disclosed herein, optionally, detecting security vulnerabilities further includes: obtaining vulnerability information from a security vulnerability database; matching the vulnerability information with version information of the dependency package and its sub-dependencies; and caching the detected vulnerability information and the matched patch version information.

[0009] According to some embodiments of the software project dependency package management method disclosed herein, the remediation scheme optionally includes: determining a security version of the vulnerability to be remediated; verifying whether the security version is compatible with the software project; and applying the security version after successful verification.

[0010] According to some embodiments of the software project dependency package management method disclosed herein, optionally, the process of updating the dependency information file is implemented by: modifying the version information of the dependency package to be repaired in the dependency information file according to the repair plan, and triggering the software project's rebuild and automated testing process to verify whether the updated dependency package is compatible with the current software project.

[0011] According to some embodiments of the software project dependency package management method disclosed herein, optionally, the automated testing process includes: unit testing, used to verify whether the updated dependency package does not affect the individual functional modules in the software project; and integration testing, used to verify whether the updated dependency package is compatible with other dependency packages and the overall functionality of the software project.

[0012] According to some embodiments of the software project dependency package management method disclosed herein, optionally, when an updated dependency package causes a test failure, a rollback operation is performed to restore the dependency package version before the update.

[0013] According to some embodiments of the software project dependency package management method disclosed herein, optionally, the rollback operation includes: restoring the affected dependency package version information in the dependency information file; cleaning up the updated dependency packages in the software project; and triggering the software project build again to verify whether the rollback was successful.

[0014] According to some embodiments of the software project dependency package management method disclosed herein, optionally, the dependency information file is the pom.xml file of a Maven project.

[0015] According to some embodiments of the software project dependency package management method disclosed herein, optionally, the dependency tree of the software project is constructed by recursively analyzing the dependency packages and their sub-dependency packages. The dependency tree includes the identification information, version information and dependency relationship of each dependency package.

[0016] According to some embodiments of the software project dependency package management method disclosed herein, optionally, the dependency information repository periodically synchronizes the dependency package version information and its corresponding security vulnerability information from the Maven Central Repository.

[0017] According to some embodiments of the software project dependency package management method disclosed herein, optionally, after the remediation plan is generated, a vulnerability detection report is automatically generated. The vulnerability detection report includes: the identification information and version of the dependency package with the vulnerability; the vulnerability remediation suggestion and its security version information; and the compatibility verification results of the post-remediation test.

[0018] The electronic device of the second aspect of this disclosure includes a memory and a processor, the memory storing instructions that, when executed by the processor, implement the software project dependency package management method according to any of the foregoing embodiments.

[0019] The third aspect of this disclosure provides a computer-readable storage medium storing instructions that, when executed by a processor, implement a software project dependency package management method according to any of the foregoing embodiments. Attached Figure Description

[0020] Figure 1 A flowchart of a software project dependency package management method 100 according to some embodiments is shown.

[0021] Figure 2 A schematic diagram of a vulnerability detection process according to some embodiments is shown.

[0022] Figure 3 A schematic diagram of a dependency package analysis process according to some embodiments is shown.

[0023] Figure 4 A schematic diagram of a dependency information base update process according to some embodiments is shown. Detailed Implementation

[0024] The following description describes some of the various embodiments of this disclosure, intended to provide a basic understanding of the disclosure. It is not intended to identify key or decisive elements of the disclosure or to limit the scope of protection sought.

[0025] For purposes of brevity and illustrativeness, the principles of this disclosure are described herein primarily with reference to exemplary embodiments thereof. However, those skilled in the art will readily recognize that the same principles are equivalently applicable to all types of software project dependency package management methods, electronic devices, and computer-readable storage media in which these same principles can be implemented, and that any such variations do not depart from the true spirit and scope of this patent application.

[0026] Furthermore, reference is made in the accompanying drawings, which illustrate specific exemplary embodiments. Electrical, mechanical, logical, and structural changes may be made to these embodiments without departing from the spirit and scope of this disclosure. Moreover, while features of this disclosure are disclosed in combination with only one of several embodiments, such features may be combined with one or more other features of other embodiments if desired and / or advantageous for any given or identifiable function. Therefore, the following description should not be considered limiting in any sense, and the scope of this disclosure is defined by the appended claims and their equivalents.

[0027] Terms such as “possessing” and “comprising” indicate that, in addition to having units (modules) and steps that are directly and explicitly stated in the specification and claims, the technical solutions of this disclosure do not exclude the presence of other units (modules) and steps that are not directly or explicitly stated.

[0028] In this article, the terms "dependency" and "dependency" are used interchangeably, referring to external libraries, components, or modules referenced by a software project to provide specific functionality or services. Furthermore, a dependency may further depend on other packages; these indirectly dependent packages are called sub-dependencies. The scope of dependency packages and sub-dependencies typically includes basic package information (such as groupId, artifactId, and version number), a functional description, and their referencing relationships.

[0029] In this article, a “vulnerability” or “security vulnerability” refers to a defect or weakness in a software system or component that could be maliciously exploited, leading to unauthorized access, data breaches, or system corruption. Within the scope of a dependency package, a vulnerability typically refers to a known or unknown security flaw, including detailed information about the vulnerability (such as a vulnerability description, affected version number, and suggested remediation) and its potential impact on the software project.

[0030] In this article, "remediation" and "automatic remediation" refer to the process of automatically generating remediation plans and executing remediation operations after a security vulnerability is detected in a software project. In dependency package management scenarios, the scope of automatic remediation typically includes, but is not limited to, upgrading vulnerable dependency packages to secure versions, applying security patches, or adjusting configurations to eliminate the threat of the vulnerability. Its scope covers the entire process from vulnerability detection to remediation completion and may involve the automatic verification of the remediation results.

[0031] In this article, "rollback" and "rollback mechanism" refer to the system's ability to automatically restore the project to its original state before the repair operation if the repair operation fails or causes new problems during the automatic repair process. The scope of the rollback mechanism includes, for example, detecting repair failures or incompatible triggering conditions, restoring to a stable version, and ensuring the project's normal operation after rollback. Its purpose is to guarantee the stability and security of the project during or when a repair operation fails.

[0032] In this article, a "dependency repository" refers to a platform that stores and manages all dependency packages and related information in a software project. The scope of the dependency repository includes basic information about dependency packages (such as groupId, artifactId, and version number), the reference relationships between dependency packages, and known vulnerability information and update history for each dependency package. The dependency repository can be used to support functions such as dependency analysis, vulnerability detection, automatic remediation, and compatibility checks, and is the core data source for dependency package management.

[0033] In this article, "compatibility checking" refers to the process of verifying whether a project's dependencies, code, or other dependencies can still work correctly after a dependency upgrade or fix. The scope of compatibility checking may include, for example, detecting whether a new version of a dependency is compatible with existing code, identifying potential dependency conflicts, and issuing warnings or triggering rollback mechanisms when incompatible versions exist. Its purpose is to ensure that dependency updates do not disrupt the overall functionality and performance of the project.

[0034] In this article, "building" refers to the process of packaging software project code and dependencies into an executable program, and "testing" is the process of running automated tests to verify the project's functionality and performance. After dependency vulnerabilities are fixed, the scope of building and testing includes checking whether the project's build process is normal, running test cases to verify whether the fixed functionality meets expectations, and ensuring that no new bugs or vulnerabilities have been introduced.

[0035] Figure 1 A flowchart illustrating a software project dependency package management method 100 according to some embodiments is shown. The method 100 may include the following steps.

[0036] In step 110, based on a security vulnerability database and a dependency information file, security vulnerabilities in the dependency packages of the software project are detected. The dependency information file includes information used to construct the dependency tree of the software project. In this step, vulnerability detection can be performed on each dependency package in the software project based on a publicly available vulnerability database (such as CVE, NVD, etc.) and the dependency information file. The dependency information file can be, for example, a file describing the various dependency packages and their version information in the project, such as Maven's pom.xml file or other similar dependency management files. This file records the name, version, and dependency relationships of each dependency package with other dependency packages. In some examples, the information in the dependency information file not only confirms the specific version of each dependency package but also includes the dependency tree that constructs the project. The dependency tree represents the hierarchical relationship and version information between each dependency package and its child dependency packages, thus allowing tracing all indirect dependencies. Based on this, by comparing the version information of the dependency packages in the software project with security vulnerability data in the vulnerability database, dependency packages with security vulnerabilities can be identified. This process can automatically identify security vulnerability dependency packages in the project, ensuring that the software project is protected from known vulnerabilities during use and providing data support for vulnerability remediation.

[0037] In step 120, a remediation plan is generated based on the detection results. In this step, a corresponding remediation plan can be generated based on the vulnerability information detected in step 110. The generation process includes analyzing the versions and vulnerability information of the dependent packages containing the vulnerability to determine a secure version that can resolve the vulnerability. In some examples, this process may be based on vulnerability remediation suggestions obtained from a security vulnerability database, combined with the actual needs of the project, to select the latest secure version compatible with the current project. After the remediation plan is generated, the compatibility of the remediation version can be evaluated to ensure that the updated version is compatible with other dependent packages and code in the project, avoiding project build failures or functional abnormalities due to version conflicts or incompatibility. If compatibility issues exist, the remediation plan can be further optimized, recommending a suitable secure version and performing rollback operations or compatibility adjustments. This ensures the accuracy and effectiveness of the remediation plan, automatically selecting a suitable remediation version by analyzing vulnerability information and dependent package versions, avoiding human intervention and improving remediation efficiency. Furthermore, compatibility checks can reduce other problems caused by remediation, ensuring the stability of the project after remediation.

[0038] In step 130, the dependency information file is updated to fix the security vulnerability according to the remediation plan. In this step, the dependency information file can be automatically updated based on the generated remediation plan. In some examples, this process can be achieved by modifying the dependency package versions involved in the dependency information file according to the remediation plan, ensuring that the dependency packages are upgraded to secure versions without vulnerabilities. The updated dependency information file will reflect the new versions of the dependency packages and provide the latest dependency data for the project build. After updating the dependency information file, the project rebuild and automated testing processes can be triggered. The rebuild process will recompile and integrate all components in the project based on the updated dependency information. In some examples, the automated testing process will verify whether the updated dependency packages are compatible with other parts of the project and check whether the overall functionality of the software is normal. This step updates the dependency information file, avoiding errors and tedious manual operations, and ensures that dependency package vulnerabilities are fixed.

[0039] In some examples, to improve development efficiency and responsiveness, the tools used to execute the methods described in this article can be integrated with common development tools such as IDE plugins and CI / CD pipeline tools. By integrating development environment plugins (e.g., in IntelliJ IDEA or Eclipse), developers can receive real-time security alerts for dependency packages and directly perform one-click fixes. Furthermore, integration with continuous integration (CI) / continuous delivery (CD) pipelines (e.g., Jenkins, GitLab CI) can automatically trigger vulnerability scanning and remediation processes with each code commit or project build, ensuring that dependencies are security-checked for each build and reducing manual intervention.

[0040] In some embodiments, a dependency information file is used to describe the dependency packages and their version information of a software project. For example, a dependency information file can be a configuration file used to manage the various dependent libraries and their versions within a software project. Taking Maven as an example, the pom.xml file records information such as the groupId, artifactId, and version of each dependency package, identifying the external dependencies used by the project. This file helps developers clearly identify the various libraries that the software project depends on and their versions, ensuring that the dependency packages used during project build are accurate and repeatable. In this file, the version information of the dependency packages is critical data, used to ensure that the versions of the external libraries the project depends on are consistent, avoiding incompatibility issues caused by version mismatches. This step, through the management of the dependency information file, ensures the accuracy of the external libraries and their version information dependent on the software project, contributing to the stability and predictability of the project build process.

[0041] In some embodiments, a security vulnerability database includes publicly available vulnerability data sources, which include the mapping between dependency package versions and vulnerabilities. Security vulnerability databases (such as CVE, NVD, etc.) record known security vulnerabilities and provide a mapping between each vulnerability and its affected dependency package versions. Each vulnerability record typically includes a detailed description of the vulnerability, its severity level, and information about the affected dependency package versions. By comparing the dependency package versions used in the software project with the data in the vulnerability database, vulnerability-ridden dependency package versions can be identified, and targeted remediation suggestions can be provided. This process, through comparison with publicly available vulnerability databases, enables timely detection of known vulnerabilities in dependency packages used in the project, providing accurate vulnerability information for generating remediation solutions and ensuring software security.

[0042] In some embodiments, detecting security vulnerabilities further includes: retrieving vulnerability information from a security vulnerability database; matching the vulnerability information with version information of dependent packages and their sub-dependent packages; and caching the detected vulnerability information and the matched fix version information. First, vulnerability information related to the project's dependent package versions can be retrieved from the security vulnerability database to identify affected dependent packages in the project. Next, based on the dependency tree structure, the versions of the dependent packages and their sub-dependent packages can be checked for known vulnerabilities. Upon successful matching, the vulnerability information and the corresponding fix version can be stored in the cache for subsequent operations. This detection process ensures comprehensive detection of all directly and indirectly dependent security vulnerabilities in the project, providing accurate data support for generating remediation solutions and avoiding the omission of any potential vulnerabilities.

[0043] In some embodiments, the remediation plan includes: determining a secure version of the vulnerability to be patched; verifying the compatibility of the secure version with the software project; and applying the secure version after successful verification. Version selection must be based not only on vulnerability remediation but also on compatibility with other dependencies in the project. Compatibility checks with the project's dependency tree ensure that the patched version can be successfully integrated into the existing project without introducing new problems. After successful verification, developers can be automatically or recommended to apply the patched version to their projects. This process, by accurately determining the patched version and performing compatibility verification, ensures the effectiveness of the remediation plan, avoids causing other compatibility issues due to the patch, and improves the automation and accuracy of the remediation process.

[0044] Figure 2This diagram illustrates a vulnerability detection process according to some embodiments, showing how, after updating the dependency information repository, the local dependency information repository and the dependency tree of the previously obtained software project are used to analyze vulnerabilities in the application. This process aims to identify existing vulnerabilities and generate information such as suggested upgradeable version numbers by detecting compatibility relationships between dependency versions. This process can be summarized, for example, as follows: reading the software project's dependency tree information from the cache; extracting dependency information and querying the dependency information repository for vulnerability records for each dependency package and its sub-dependencies in the dependency tree; if a vulnerability is detected, querying the corresponding secure version and recording the recommended upgrade version; verifying the compatibility of the recommended version, and if incompatible, progressively selecting lower versions for testing until a compatible and vulnerability-free version is found; updating the dependency tree and cache information to complete vulnerability detection and remediation for all dependency packages and sub-dependencies.

[0045] like Figure 2 As shown, the specific steps of the example are as follows: 1. Retrieve the dependency list of the software project from the cache: Read the dependency tree information of the software project generated by the dependency package analysis phase from the cache, that is, list all the dependency packages referenced by the software project; 2. Traverse the dependency list: Check and traverse these dependency packages one by one; 3. Obtain dependency package information: Obtain the groupId, artifactId, and version number of each dependency package; 4. Query vulnerability information from the dependency information database: Query the relevant detailed information in the dependency information database, including the dependency, sub-dependencies, version, and corresponding vulnerability information, etc., to further check whether the current dependency and any of its sub-dependencies have known vulnerabilities; 5. Check for vulnerabilities: If the current dependency and all its sub-dependencies do not have vulnerabilities... Upon discovering a vulnerability, the system will proceed to step 8. Once a vulnerability is found in the current dependency or any sub-dependency, this vulnerability information can be cached, and the system will proceed to step 6. 6. Query the latest security version: Regardless of when a vulnerability is discovered, or when a suitable upgrade or the highest version is found, the system will record this information for subsequent vulnerability management and remediation strategy development. 7. Cache vulnerability information and recommended upgrade versions: Throughout the process, a cache containing all known vulnerabilities and their recommended solutions is continuously updated and maintained for developers to review and take action. 8. Check the next dependency package: After completing the check of the current dependency, the system will continue processing the next dependency in the list and proceed to step 3, until all dependencies have been reviewed. For the highest version of a dependency, it can be determined whether a new version without vulnerabilities and compatible with other dependency versions exists. If such a version is found, but it is found to be incompatible with other dependencies, the version level can be gradually reduced, and testing can continue until a highest version that is both vulnerability-free and compatible is found.

[0046] The vulnerability detection process described above enables a comprehensive vulnerability scan of the software project and all its dependent packages and sub-dependencies, accurately identifying potential vulnerabilities and providing recommended secure versions and compatible upgrade solutions. By caching vulnerability information and upgrade suggestions, this method significantly improves the efficiency of vulnerability management and remediation, and reduces the security risks associated with each step.

[0047] In some embodiments, updating the dependency information file is achieved by modifying the version information of the dependency packages to be fixed in the dependency information file according to the fix plan, and triggering a rebuild and automated testing process for the software project to verify whether the updated dependency packages are compatible with the current software project. Dependency information files such as pom.xml can be automatically modified according to the fix plan to update the version information of the affected dependency packages. For example, the update process is implemented through Maven build scripts, so developers do not need to intervene manually. After the update, an automated build process is triggered to recompile the project and execute a series of automated tests, including unit tests and integration tests, to ensure that the new version of the dependency packages does not break existing functionality. This automated process reduces manual intervention, ensures the accuracy of the dependency information file update, and ensures the compatibility of the updated dependency packages with the project through automated build and testing processes, guaranteeing the stability and security of the project after the fix.

[0048] In some embodiments, the automated testing process includes: unit testing, used to verify whether the updated dependency packages do not affect the individual functional modules in the software project; and integration testing, used to verify whether the updated dependency packages are compatible with other dependency packages and the overall functionality of the software project. Unit testing verifies whether each functional module can still function as expected after the dependency packages are updated, ensuring that no new functional issues are introduced due to the fixes. Integration testing verifies the collaborative work between multiple modules, ensuring that the updated dependency packages can be seamlessly integrated with other modules and dependency libraries in the project. This testing process comprehensively verifies the compatibility and functional integrity of the updated dependency packages, ensuring that the project's fixes do not introduce new problems, and improving stability and reliability.

[0049] In some embodiments, when an updated dependency causes a test to fail, a rollback operation is performed to restore the dependency version before the update. If an automated test fails, a rollback operation can be automatically triggered to restore the dependency version before the fix. This process ensures that the software project remains stable during the fix process, avoiding project interruptions due to dependency update failures. Thus, by restoring to a previous stable version, the rollback operation ensures that the software project is not affected when encountering fix failures, enhancing the reliability and fault tolerance of the method steps.

[0050] In some embodiments, the rollback operation includes: restoring the affected dependency package version information in the dependency information file; cleaning up the updated dependency packages in the software project; and re-triggering the software project build to verify whether the rollback was successful. The rollback operation not only restores the dependency package versions but also cleans up invalid or incompatible dependency packages temporarily introduced during the update process, ensuring the software project returns to a stable state. As mentioned earlier, the rollback operation ensures that when dependency package updates fail, the project can be quickly restored to a usable state, reducing the impact of the repair process on the software project and improving the stability of the software project implementation.

[0051] In some embodiments, the dependency information file is the pom.xml file of a Maven project. The pom.xml file is the core configuration file in the Maven build tool, recording all dependency packages, their versions, and build-related configuration information. By modifying the dependency versions in the pom.xml file, Maven automatically downloads and manages the dependency packages, thereby achieving automated management of project dependencies. Using a standard pom.xml file ensures consistency and standardization in dependency management, enabling convenient version control and dependency package management for the project.

[0052] In some embodiments, the dependency tree of a software project is constructed by recursively analyzing dependent packages and their sub-dependencies. The dependency tree includes the identification information, version information, and dependencies of each dependent package. The dependency tree structure describes the relationship between each dependent package and its direct or indirect dependencies, providing a complete view to help developers understand all the dependent packages used in the project and their hierarchical relationships. The construction of the dependency tree enables accurate tracking of the version information of each dependent package and its sub-dependencies, and provides clear structural support for vulnerability detection and remediation.

[0053] Figure 3 This document illustrates a dependency package analysis and dependency tree construction process according to some embodiments. It describes how, when compiling an application or executing a plugin command, a plugin scans the dependency packages and their sub-dependencies within the project to obtain the dependency tree information for the entire application system. This process involves, for example, the acquisition and processing of key information such as the relationships between dependency packages and the groupId, artifactId, and version of each dependency package. The process can be summarized as traversing the dependency package list, sequentially extracting and saving the dependency information of each dependency package, and recursively scanning the dependency information of all sub-dependencies after determining whether the dependency package contains sub-dependencies, until the information of all dependency packages and their sub-dependencies is recorded in the dependency information database, generating a complete dependency tree.

[0054] like Figure 3As shown, the specific steps of the example are as follows: 1. Execute the scanning plugin to scan the software project: When the application is compiled or a specific plugin command is executed, the plugin calls the Maven plugin API to obtain a list of dependency packages referenced in the application's pom.xml file; 2. Traverse the dependency list of the software project: Each dependency package in the list can be traversed and checked to extract basic information such as the dependency package's groupId, artifactId, and version; 3. Find and obtain dependency package information: Based on the extracted groupId and artifactId, the corresponding dependency information can be searched in the dependency information repository; 4. Determine whether the dependency information of the dependency package exists in the dependency information repository; 5. Save the new dependency information: If the dependency information does not exist in the dependency information repository, it indicates that this is a newly discovered dependency (dependency package). This allows the information to be saved in the dependency information repository; 6. Record dependency information: Regardless of whether the dependency information exists in the dependency information repository, it can be recorded there, and a copy can be kept, for example, in the dependency tree cache of the software project, for later analysis of vulnerability information of the current software project's dependency packages; 7. Check for sub-dependencies: Next, the current dependency package will be scanned to see if it contains sub-dependency information; 8. Recursively process sub-dependencies: If sub-dependency package information exists, it will be scanned to obtain a list of sub-dependency packages, and steps 2 to 7 will be repeated until all sub-dependencies have been processed; 9. Continue to check the next dependency: If no sub-dependency package information is found in step 7, the next dependency package will be checked, and steps 3 to 7 will be repeated until all dependency packages have been traversed. Finally, after scanning all dependency packages and their sub-dependencies, the dependency tree of the software project can be constructed, which includes the dependency relationships between each level.

[0055] Through the above steps, this method can effectively achieve a comprehensive analysis of project dependency packages, fully construct the dependency tree at each level, and ensure that even complex and ever-changing dependency relationships can be clearly identified, which can improve the traceability and management efficiency of dependency information.

[0056] In some embodiments, the dependency repository periodically synchronizes dependency package version information and corresponding security vulnerability information from the Maven Central Repository. To ensure that the project's dependencies are always up-to-date and secure, data from the dependency repository and public sources such as the Maven Central Repository can be synchronized periodically. Synchronization allows for the acquisition of the latest dependency package versions and their corresponding security vulnerability information, ensuring that the project always uses vulnerability-free and secure dependency versions. The dependency repository synchronization process can be executed via a scheduled task to promptly update vulnerability information and dependency versions, reducing the potential risks posed by security vulnerabilities. Furthermore, the dependency repository periodically retrieves the latest dependency package versions and security vulnerability information associated with each version from the Maven Central Repository, ensuring that the project's dependencies are always up-to-date and secure. Regular synchronization of the dependency repository guarantees the timeliness of dependency package version information and security vulnerability data, ensuring that the project always uses the latest and most secure dependency versions.

[0057] Figure 4 The diagram illustrates a flowchart of updating a dependency information repository according to some embodiments. A local dependency repository can be established to manage (e.g., store and maintain) all or part of the dependency package information in a software project or application, including version information, vulnerability information, and sub-dependency package information. To ensure the dependency information repository is updated promptly, all version information and related vulnerability information of dependency packages can be periodically synchronized from a central repository (e.g., a Maven repository). Optionally, it can be configured so that only dependency packages actually used in the software project are synchronized, thereby avoiding unnecessary data redundancy and saving database storage space. Therefore, the steps for updating the dependency information repository can be summarized as follows: initiate an update task, traverse the dependency packages and their records in the dependency information repository; query the version information of each dependency package from the Maven central repository using groupId and artifactId; compare with existing records in the dependency information repository and update the vulnerability information of existing dependency packages; recursively process unrecorded dependency package versions and their sub-dependency package information, saving their version numbers, download links, and vulnerability information; until all dependency packages and their sub-dependencies have been updated, achieving complete synchronization of the dependency information repository.

[0058] Specifically, such as Figure 4As shown, the specific steps of the example are as follows: 1. Start the scheduled task: An update task can be started at a preset time interval. This step is optional and can be performed simultaneously with step 2; 2. Traverse the dependency information repository: After the task starts, traverse all dependency packages and their lists in the dependency information repository; 3. Obtain dependency package information: For each dependency record (dependency package), its groupId and artifactId can be extracted, for example; 4. Query the Maven Central Repository and extract the version list of the dependency package: Based on the groupId and artifactId of the dependency package, send a request to the Maven Central Repository to obtain all available version information of the dependency package; 5. Traverse the version list and information: Check the version list of each dependency package and the detailed information of each version, including the version number and known vulnerability details. 6. Obtain the version information of the specified dependency package: Search the dependency information repository for a record of the specified dependency package version based on the groupId, artifactId, and version number; 7. Check the dependency information repository: For each obtained dependency package version, check the dependency information repository for a record of that version; 8. Update existing records: If a record of that version already exists in the dependency information repository, only the associated vulnerability information needs to be updated, and proceed to step 15; 9. Save the new version information: If the version has not yet been recorded, its relevant information (including version number and download link for the JAR package) needs to be saved to the dependency information repository; 10. Save vulnerability information for the new version; 11. Check if... 11. Check if sub-dependencies exist: Check if the current version of the dependency package contains other sub-dependencies. If sub-dependencies exist, proceed to step 12; otherwise, proceed directly to step 15. 12. Traverse the sub-dependency list: Further obtain and traverse the sub-dependency list. 13. Synchronize sub-dependency information: For each sub-dependency, the system will also check if its record already exists in the dependency information database. If not, proceed to step 14; otherwise, skip directly and proceed to step 15. 14. Add the corresponding record (save the sub-dependency information). 15. Continue processing the next version: After completing the processing of the current version and its sub-dependencies, the system will backtrack to the previous step and continue processing the next version (i.e., re-enter step 6 for a loop). This process continues until all dependencies in the dependency information database are completely synchronized and updated.

[0059] This update mechanism ensures that the dependency information repository reflects the latest version information and security vulnerability data in a timely manner, achieving a comprehensive update of all dependency packages and their sub-dependencies in the repository, and synchronously obtaining the latest version numbers, download links, and vulnerability information. This process improves the efficiency and accuracy of dependency information management.

[0060] In some embodiments, after a remediation plan is generated, a vulnerability detection report is automatically generated. This report includes: identification information and versions of the vulnerable dependency packages; vulnerability remediation recommendations and their security version information; and compatibility verification results from post-remediation testing. The report may include, for example, a detailed process of dependency upgrades, failed test cases, build logs, and can list all affected dependency packages and their corresponding remediation recommendations, ensuring developers can accurately execute remediation operations. This provides developers with detailed remediation information and compatibility verification results, further improving the efficiency and accuracy of the remediation process.

[0061] Furthermore, while most security vulnerabilities can be automatically detected and fixed, developers can still manually control the remediation process to ensure that the fixes meet the specific needs of the project. Developers can configure remediation strategies through configuration files, such as restricting automatic upgrades of certain dependencies, setting priorities for different dependencies, or requiring manual verification of certain compatibility risks. This feature provides flexibility, giving developers greater control on top of automated remediation, ensuring that the remediation process meets the specific needs and requirements of the project.

[0062] This disclosure provides a method for automatically detecting and remediating security vulnerabilities in dependency packages within software projects. This automated remediation process significantly improves the security and stability of the software project. First, automated vulnerability detection ensures that all known security vulnerabilities are identified promptly, providing accurate data support for subsequent remediation efforts. The automatic generation and updating of remediation plans allows developers to quickly and accurately select appropriate remediation versions without manual intervention, and automatically apply them while ensuring compatibility. By updating dependency information files and triggering build and testing processes, the system effectively avoids errors and tedious manual operations, greatly improving the efficiency of the remediation process.

[0063] Furthermore, this disclosure includes a rollback mechanism, enabling rapid reversion to the stable version before the fix when a patch causes test failures, thus ensuring the continued stable operation of the project. This method supports seamless integration with development tools, further enhancing the automation of the patching process, shortening patching time, and improving development efficiency through integration with IDEs and CI / CD pipelines. Ultimately, this disclosure not only improves the accuracy and efficiency of vulnerability patching but also ensures the long-term stability and security of software projects, reducing the risks associated with manual error fixing.

[0064] According to a second aspect of this disclosure, an electronic device may be provided, comprising a memory storing instructions and a processor, which, when executing the instructions, implements the software project dependency package management method described in any of the foregoing embodiments. The electronic device may be a hardware device of any software environment capable of running the above-described method, specifically including but not limited to: servers, backend servers for supporting software project development, building, and deployment, particularly build servers or continuous integration / continuous delivery (CI / CD) servers, which, by executing the methods herein, can automatically detect and repair security vulnerabilities in dependency packages; developer workstation devices: computers or terminal devices (such as desktops, laptops, or high-performance development machines) used by developers to write and debug code, on which integrated development environment (IDE) plugins or tools can invoke the methods to achieve real-time detection and repair of dependency package vulnerabilities; embedded development devices: devices for IoT or embedded project development, such as hardware platforms for embedded compilation and building, which, by executing the methods of this disclosure, can effectively manage dependency packages and security vulnerabilities in resource-constrained environments. In addition, there are cloud computing platforms, mobile devices (such as devices in specific mobile development scenarios, such as devices running Android or iOS development tools) and other smart terminals, including but not limited to smart edge devices, IoT terminals, or other devices related to software project development and building.

[0065] According to a third aspect of this disclosure, a computer-readable storage medium may be provided that stores a memory of instructions, which, when executed by a processor, perform the method described in any of the foregoing embodiments.

[0066] The memory, storage module, or computer-readable storage medium described herein may include, for example, various types of computer storage media, and may be any available medium accessible to a general-purpose or special-purpose computer. For instance, computer-readable media may include RAM, ROM, EPROM, E... 2 PROM, registers, hard disk, removable disk, CD-ROM or other optical disc storage, magnetic disk storage or other magnetic storage module, or any other temporary or non-temporary medium capable of carrying or storing desired program code units in the form of instructions or data structures, accessible by a general-purpose or special-purpose computer or a general-purpose or special-purpose processor. Combinations of the above should also be included within the scope of protection for computer-readable media. An exemplary storage medium is coupled to a processor so that the processor can read and write information to / from the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in an electronic device. In an alternative, the processor and storage medium may reside as discrete components in the electronic device. The memory stores instructions executable by the processor.

[0067] Processors and memory can be, for example, processing and storage modules based on electronic devices, connected wired or wirelessly to enable data transmission or interaction. For instance, these components can be electrically connected to each other via one or more communication buses. Memory can be, for example, the computer-readable storage medium described above. Processors can be processing modules with signal processing capabilities, such as general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0068] The foregoing primarily describes the software project dependency package management method, electronic device, and computer-readable storage medium disclosed herein. Although only some specific embodiments of this disclosure have been described, those skilled in the art should understand that this disclosure can be implemented in many other forms without departing from its spirit and scope. Therefore, the examples and embodiments shown are to be considered illustrative rather than restrictive, and this disclosure may cover various modifications and substitutions without departing from the spirit and scope of this disclosure as defined by the appended claims.

Claims

1. A method for managing software project dependency packages, characterized in that, The method includes the following steps: Based on a security vulnerability database and dependency information files, detect security vulnerabilities in the dependency packages of the software project. A repair plan is generated based on the results of the detection; and According to the described remediation plan, update the dependency information file to fix the security vulnerability. The dependency information file includes information used to construct the dependency tree of the software project.

2. The method according to claim 1, characterized in that, The dependency information file is used to describe the dependency packages and their version information of the software project.

3. The method according to claim 1, characterized in that, The security vulnerability database includes publicly available vulnerability data sources, and the vulnerability data sources include the correspondence between the versions of the dependency packages and the vulnerabilities.

4. The method according to claim 1, characterized in that, The detection of the security vulnerability further includes: Retrieve vulnerability information from the security vulnerability database; The vulnerability information is matched with the version information of the dependency package and its sub-dependencies; The cache contains detected vulnerability information and matching patch information.

5. The method according to claim 1, characterized in that, The repair solution includes: Identify the security version of the vulnerability to be patched; Verify that the security version is compatible with the software project; After the verification is passed, the secure version is applied.

6. The method according to claim 1, characterized in that, The process of updating the dependency information file is implemented as follows: the version information of the dependency package to be repaired in the dependency information file is modified according to the repair plan, and the rebuilding and automated testing process of the software project is triggered to verify whether the updated dependency package is compatible with the current software project.

7. The method according to claim 6, characterized in that, The automated testing process includes: Unit tests are used to verify whether the updated dependency packages do not affect the individual functional modules in the software project; Integration testing is used to verify whether the updated dependency package is compatible with other dependency packages and the overall functionality of the software project.

8. The method according to claim 6, characterized in that, If an updated dependency causes a test to fail, a rollback operation is performed to restore the dependency version before the update.

9. The method according to claim 8, characterized in that, The rollback operation includes: Restore the affected dependency package version information in the dependency information file; Clean up the updated dependency packages in the software project; This triggers the construction of the software project again.

10. The method according to claim 1, characterized in that, The dependency information file is the pom.xml file of the Maven project.

11. The method according to claim 1, characterized in that, The dependency tree of the software project is constructed by recursively analyzing the dependency packages and their sub-dependency packages. The dependency tree includes the identification information, version information and dependency relationship of each dependency package.

12. The method according to claim 1, characterized in that, The dependency information repository periodically synchronizes the dependency package version information and corresponding security vulnerability information of the Maven Central Repository.

13. The method according to claim 1, characterized in that, After the remediation plan is generated, a vulnerability detection report is automatically generated. The vulnerability detection report includes: the identification information and version of the dependent packages with vulnerabilities; vulnerability remediation suggestions and their security version information; and the compatibility verification results of the post-remediation test.

14. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing instructions that, when executed by the processor, perform the method according to any one of claims 1-13.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed by a processor, perform the method according to any one of claims 1-13.

Images