A vulnerability fixing method, device, equipment and readable storage medium

Abstract

The application discloses a vulnerability repair method, device and equipment and a readable storage medium. After at least one dependency chain is determined according to version dependency relationships between component packages in a target project file, in the case that a certain component package in a certain dependency chain is marked with vulnerability information, the component packages in the dependency chain are repaired from the starting position of the dependency chain according to a forward dependency order. Since the forward dependency order follows the component dependency principle of software development itself, when the component package at the root node position of a dependency chain is upgraded, the component packages at the corresponding leaf node positions are also upgraded accordingly, thereby multiple component packages in a dependency chain are repaired in batches, the component vulnerability repair efficiency is improved, and dependency conflicts and compatibility problems are not easily introduced. Correspondingly, the vulnerability repair device, equipment and readable storage medium provided by the application also have the above technical effects.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a vulnerability repair method, apparatus, device, and readable storage medium. Background Technology

[0002] Currently, vulnerability patching for software components can begin by creating a dependency tree based on the version dependencies between components. This dependency tree contains at least one dependency chain. Then, for each dependency chain, starting from the smallest leaf node, each component in that dependency chain is patched sequentially in reverse order.

[0003] For example, consider a dependency chain A->B->C. Assume components A and B themselves have no publicly disclosed high-risk vulnerabilities (low vulnerability level); component C is the base package and has a publicly disclosed high-risk vulnerability (high vulnerability level). The current remediation process is as follows: Based on B's version dependency on C, find the patched version of C. Then, upgrade C to a version without the high-risk vulnerability to patch the vulnerability in C. If B's ​​version dependency on C is fixed, and B only depends on the vulnerable version of C, upgrading C will introduce dependency conflicts and compatibility issues. Therefore, do not upgrade C initially; instead, decide whether to upgrade C based on whether B has a vulnerability. If B itself has a vulnerability, B can be upgraded, indirectly upgrading C. If B itself has no vulnerability, keep the versions of B and C unchanged. Once B is upgraded, it is necessary to backtrack to A, that is, check the dependency relationship between B and A, and repeat the above process.

[0004] As can be seen, the existing solution backtracks from the smallest leaf node of the dependency chain to the root node. In many cases, it cannot solve the compatibility problems caused by version dependencies. It is necessary to repeat similar processes, which makes the backtracking process cumbersome and inefficient.

[0005] Therefore, improving the efficiency of component vulnerability repair and resolving compatibility issues caused by version dependencies during the repair process are problems that need to be addressed by those skilled in the art. Summary of the Invention

[0006] In view of this, the purpose of this application is to provide a vulnerability remediation method, apparatus, device, and readable storage medium to improve the efficiency of component vulnerability remediation and solve compatibility issues caused by version dependencies during the remediation process. The specific solution is as follows:

[0007] Firstly, this application provides a vulnerability remediation method, including:

[0008] Retrieve the component packages from the target project files;

[0009] Determine at least one dependency chain based on the version dependencies between the component packages;

[0010] If any component package in any dependency chain is marked with vulnerability information, then starting from the beginning of the dependency chain, the vulnerability is fixed for each component package in the dependency chain in the forward dependency order.

[0011] Optionally, the step of patching vulnerabilities in each component package of the dependency chain, starting from the beginning of the dependency chain and proceeding in a forward dependency order, includes:

[0012] Starting from the beginning of the dependency chain, the component package at each position in the dependency chain is taken as the target to be tested according to the forward dependency order;

[0013] If a patched version of the target exists, the vulnerability is patched based on the version dependency between the target and the component package preceding the target.

[0014] Optionally, the step of patching vulnerabilities in the target under test based on the version dependency relationship between the component package preceding the target under test and the target under test includes:

[0015] Determine the current version of the component package at the previous position of the target under test;

[0016] Determine the version dependency range of the current version on the target under test;

[0017] Update the target under test to any version within the version dependency range.

[0018] Optionally, determining the version dependency range of the current version on the target under test includes:

[0019] The version dependency scope is determined using the version management tool corresponding to the target project file.

[0020] Optionally, it also includes:

[0021] If no patch version exists for the target under test, the vulnerability patch for the target under test is skipped, and the next target under test is determined, until the component package at each position in the dependency chain has been used as the target under test.

[0022] Optionally, the vulnerability information annotation process for any component package in any dependency chain includes:

[0023] Determine the vulnerability information of each component package in the current dependency chain;

[0024] For each component package in the current dependency chain, determine the leaf component package at each leaf node position with the current component package as the parent node;

[0025] The vulnerability information of the current component package and the leaf component package are combined into a vulnerability information set, and the highest risk level is selected from the vulnerability information set;

[0026] Mark the highest risk level in the current component package.

[0027] Optionally, determining the vulnerability information of each component package in the current dependency chain includes:

[0028] Query the vulnerability database for vulnerability information of each component package in the current dependency chain.

[0029] Optionally, the vulnerability information annotation process for any component package in any dependency chain includes:

[0030] Determine the vulnerability information of each component package in the current dependency chain;

[0031] The vulnerability information of each component package in the current dependency chain is marked on the corresponding component package in the current dependency chain.

[0032] Secondly, this application provides a vulnerability remediation device, comprising:

[0033] The acquisition module is used to acquire the component packages in the target project file;

[0034] A determination module is used to determine at least one dependency chain based on the version dependency relationships between the component packages;

[0035] The repair module is used to repair vulnerabilities in each component package of any dependency chain if any component package in any dependency chain is marked with vulnerability information, starting from the beginning of the dependency chain and following the forward dependency order.

[0036] Thirdly, this application provides an electronic device, comprising:

[0037] Memory, used to store computer programs;

[0038] A processor for executing the computer program to implement the aforementioned disclosed vulnerability remediation method.

[0039] Fourthly, this application provides a readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned disclosed vulnerability remediation method.

[0040] As can be seen from the above scheme, this application provides a vulnerability repair method, including: obtaining each component package in the target project file; determining at least one dependency chain according to the version dependency relationship between the component packages; if any component package in any dependency chain is marked with vulnerability information, then starting from the beginning of the dependency chain, performing vulnerability repair on each component package in the dependency chain in a forward dependency order.

[0041] As can be seen, after determining at least one dependency chain based on the version dependencies between component packages in the target project file, this application, when a component package in a dependency chain is marked with vulnerability information, starts from the beginning of the dependency chain and performs vulnerability repair on each component package in the dependency chain according to the forward dependency order. Since the forward dependency order follows the component dependency principles of software development, when upgrading the component package at the root node of a dependency chain, the corresponding component packages at the leaf nodes will also be upgraded, thereby batch repairing multiple component packages in a dependency chain and improving the efficiency of component vulnerability repair. Furthermore, since the version dependency range of the component packages at the upper-level nodes on the component packages at the lower-level nodes is known, batch upgrading of each component package is less likely to introduce dependency conflicts and compatibility issues. For example, in a dependency chain A->B->C, if A is upgraded from version 1.0 to version 1.1, and version 1.1 depends on version B for version 1.1 and above, then upgrading A will correspondingly upgrade B to version 1.1 or above. Similarly, based on the version dependency range of B on C after the upgrade, C will also be upgraded. In this way, vulnerabilities in each component package in a dependency chain can be patched in batches according to the forward dependency order.

[0042] Correspondingly, the vulnerability repair device, equipment, and readable storage medium provided in this application also have the above-mentioned technical effects. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0044] Figure 1 This is a flowchart of a vulnerability remediation method disclosed in this application;

[0045] Figure 2 This is a schematic diagram of a dependency tree disclosed in this application;

[0046] Figure 3 This is a schematic diagram of a vulnerability repair device disclosed in this application;

[0047] Figure 4 This is a schematic diagram of an electronic device disclosed in this application;

[0048] Figure 5 This is a schematic diagram of another electronic device disclosed in this application. Detailed Implementation

[0049] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0050] Currently, existing solutions backtrack from the smallest leaf node in the dependency chain towards the root node. This often fails to resolve compatibility issues caused by version dependencies, requiring repeated steps and resulting in a cumbersome and inefficient backtracking process. Therefore, this application provides a vulnerability remediation solution that improves the efficiency of component vulnerability remediation and resolves compatibility issues caused by version dependencies during the remediation process.

[0051] See Figure 1 As shown in the figure, this application discloses a vulnerability remediation method, including:

[0052] S101. Obtain the component packages in the target project file.

[0053] Generally, a target project file includes multiple component packages. For example... Figure 2 The dependency tree shown shows that the project file Project includes the following component packages: A, B, C, D, E, F, G, and H. A, E, and G are located at the root node of their respective dependency chains. Based on this project file, four dependency chains can be identified: A-->B-->C, A-->D, E-->F, and G-->H-->D.

[0054] It's important to note that a component package (e.g., "A" in A->B->C) records its own version information and the version dependency range of its next-level component packages (e.g., "B" in A->B->C). Therefore, if the version of a component package changes, the version dependency range of its next-level component packages may also change accordingly. Thus, regardless of whether a next-level component package has vulnerabilities, it needs to be updated according to the changed version dependency range. This achieves batch updates of component packages, i.e., batch vulnerability patching. Updating component packages includes upgrading or downgrading them. Higher-version component packages are less likely to contain vulnerabilities; therefore, upgrading component packages often achieves vulnerability patching. However, downgrading component packages can also achieve vulnerability patching.

[0055] Due to version dependency limitations, some component packages may not be upgradable. Therefore, after patching vulnerabilities, it may be discovered that some component packages still contain vulnerabilities. In this case, the vulnerability patching can be performed again according to this embodiment once a new version of the corresponding component package is available.

[0056] S102. Determine at least one dependency chain based on the version dependencies between the component packages.

[0057] S103. If any component package in any dependency chain is marked with vulnerability information, then starting from the beginning of the dependency chain, the vulnerability is fixed for each component package in the dependency chain in the forward dependency order.

[0058] Generally, if a component package has a vulnerability, that component package can be labeled with vulnerability information; vulnerability information includes: a detailed description of the vulnerability, the severity level, etc. Therefore, in one specific implementation, the process of labeling vulnerability information for any component package in any dependency chain includes: determining the vulnerability information of each component package in the current dependency chain; and labeling the vulnerability information of each component package in the current dependency chain onto the corresponding component package in the current dependency chain. However, this labeling method does not consider the dependency of a component package on its next-level component package, and the labeling is not comprehensive enough. For example, in the case of A-->B-->C, if A has no vulnerability but B has a vulnerability, since the operation of A depends on the vulnerable B, although A itself has no vulnerability, A indirectly has a vulnerability because A depends on B.

[0059] Therefore, in this embodiment, when annotating vulnerability information of a component package, the vulnerability information of its subordinate leaf components is considered. That is, if any leaf component package of a component package has a vulnerability, regardless of whether the component package itself has a vulnerability, it is marked as having a vulnerability. So, should the annotated vulnerability information be based on its own vulnerability or on the vulnerabilities of certain leaf component packages? In this embodiment, the highest risk level is selected as the vulnerability level to be annotated for these vulnerabilities, and the vulnerabilities of the current component package itself and all its leaf component packages are annotated on the current component package. Therefore, in one specific implementation, the vulnerability information annotation process for any component package in any dependency chain includes: determining the vulnerability information of each component package in the current dependency chain; for each component package in the current dependency chain, determining the leaf component packages at the leaf node positions with the current component package as the parent node; forming a vulnerability information set from the vulnerability information of the current component package and the leaf component packages, and selecting the highest risk level from the vulnerability information set; and annotating the highest risk level on the current component package. Determining the vulnerability information of each component package in the current dependency chain includes: querying the vulnerability information of each component package in the current dependency chain in the vulnerability database.

[0060] This embodiment determines at least one dependency chain based on the version dependencies between component packages in the target project file. If a component package within a dependency chain is flagged for a vulnerability, the vulnerability is patched for each component package in that dependency chain, starting from the beginning of the chain and proceeding in a forward dependency order. Since the forward dependency order follows the component dependency principles of software development, upgrading the component package at the root node of a dependency chain automatically upgrades the corresponding leaf node components, thus batch-patching multiple component packages within a dependency chain and improving component vulnerability patching efficiency. Furthermore, because the version dependencies of a higher-level component package on its lower-level component packages are known, batch upgrading of component packages is less likely to introduce dependency conflicts and compatibility issues.

[0061] Based on the above embodiments, it should be noted that, in one specific implementation, starting from the beginning of the dependency chain, vulnerabilities are patched in each component package in the dependency chain according to the forward dependency order, including: starting from the beginning of the dependency chain, taking the component package at each position in the dependency chain as the target to be tested according to the forward dependency order; if a patched version of the target to be tested exists, then the vulnerability is patched in the target to be tested according to the version dependency relationship between the component package at the previous position of the target to be tested and the target to be tested.

[0062] For example, regarding the path A->B->C, A is first considered the target to be tested. If a patched version of A exists (i.e., A' exists that fixes the vulnerability in A), then since there are no other component packages preceding A, there's no need to consider the version dependency between the preceding component package and A. A is directly upgraded to A' to fix the vulnerability in A. Next, B is considered the target to be tested. If a patched version of B exists (i.e., B' exists that fixes the vulnerability in B), then the version dependency of A' on B is considered, and B is updated to a certain version to fix the vulnerability in B. If B cannot be updated due to the version dependency of A' on B, then B's version remains unchanged. Therefore, in one specific implementation, if a patched version of the target to be tested does not exist, the vulnerability fix for the target to be tested is skipped, and the next target to be tested is determined, until every component package in the dependency chain has been considered a target to be tested.

[0063] After skipping the update of B, take C as the target to be tested and repeat the above process until A, B, and C in the current dependency chain are all considered as targets to be tested. Of course, when updating B to a certain version, the vulnerability status of the C version that the updated version of B depends on must also be considered. For example, if A' depends on B versions 1.1, 1.2, and 1.3, then for A', upgrading B to any one of versions 1.1, 1.2, or 1.3 is sufficient. However, if B version 1.3 depends on C version 1.0, and C version 1.0 has a vulnerability, then it is not advisable to upgrade B to version 1.3.

[0064] In one specific implementation, vulnerability patching of the target under test is performed based on the version dependency relationship between the target under test and the component package preceding it. This includes: determining the current version of the component package preceding the target under test; determining the version dependency range of the current version on the target under test; and updating the target under test to any version within the version dependency range. The version updated to by the target under test is selected considering the vulnerability status of the target under test's versions of its next-level component packages.

[0065] It should be noted that the version dependencies involved differ for project files in different programming languages, and can be determined based on the version management tools for the respective programming language. Therefore, in one specific implementation, determining the version dependency range of the target to be tested includes: using the version management tool corresponding to the target project file to determine the version dependency range.

[0066] The following embodiments consider the vulnerability information of each leaf component in the lower level to mark each component package in the dependency chain, and perform vulnerability repair on each component package in the dependency chain in the forward dependency order.

[0067] The annotation of vulnerability information for component packages at each node in the dependency chain includes two dimensions: first, the vulnerability information of the component package itself; and second, the vulnerability information introduced by the component package's downstream dependencies. The specific vulnerability level is also comprehensively judged and analyzed based on these two dimensions. If the highest vulnerability levels of the two dimensions are the same, the vulnerability level of the component package itself is prioritized for annotation; if the highest vulnerability levels are different, the higher level is prioritized. That is, the vulnerability information annotated for a node may include: its own vulnerability information, the vulnerability information of its downstream nodes, and the labeled vulnerability level is the highest level of all vulnerability information annotated by that node. Therefore, the vulnerability information annotated in this embodiment is comprehensive and can integrate all vulnerability information to generate remediation suggestions. The vulnerability of a component package that is a parent node in a dependency chain depends on the vulnerability of the package itself and the vulnerabilities of its downstream leaf nodes.

[0068] For example, regarding the path A->B->C, suppose A, B, and C all have vulnerabilities, and all of them are classified as high-level vulnerabilities. Then, the vulnerabilities labeled for A include: vulnerabilities inherent to A itself, vulnerabilities inherent to B, and vulnerabilities inherent to C; all are classified as high-level vulnerabilities. The vulnerabilities labeled for B include: vulnerabilities inherent to B itself, and vulnerabilities inherent to C; all are classified as high-level vulnerabilities. Therefore, when patching vulnerabilities in A, the vulnerabilities of A itself, B, and C can be comprehensively considered, resulting in more comprehensive patching recommendations.

[0069] When fixing component packages in a dependency chain marked with vulnerabilities, vulnerability remediation suggestions are generated forward from the root node of the dependency chain, rather than backward from the leaf nodes. Forward remediation adheres to the software dependency principle, enables batch updates of component packages, is simple and efficient, and reduces compatibility issues and complexity associated with reverse remediation.

[0070] Specifically, this embodiment attempts to repair the entire dependency chain forward from the root node to the leaves based on the dependencies between different components. Only when there is no new version at the root node or the repair is already completed will it move down layer by layer to find the new version of the next level node and generate repair suggestions based on the next level node. This method adheres to the positive software dependency relationship and avoids the version dependency and compatibility issues that can easily be caused by backtracking from the leaves to the root node. Moreover, the forward upgrade starting from the root node can update the component dependency versions in batches, making the problem repair simpler and faster.

[0071] Taking A->B->C as an example, this embodiment attempts to repair from A to B and then to C, proceeding forward along the dependency chain, unlike the existing solution which proceeds in reverse from C to B and then to A. Upgrading version A may directly upgrade both B and C on the dependency chain at once, which follows the dependency principle inherent in software development and solves the version compatibility problem encountered by the old solution that prioritizes upgrading the leaf node C.

[0072] For software, component dependencies are divided into direct dependencies and indirect dependencies. For example... Figure 2 As shown, the project has direct dependencies A, E, and G, and indirect dependencies B, D, F, H, and C. Assume components C and D have publicly known vulnerabilities. The goal of component vulnerability remediation is to fix the vulnerabilities that may exist in the direct dependencies A, E, and G themselves, as well as the vulnerabilities introduced by their indirect dependencies. If the existing approach is used, searching for remediation solutions by backtracking from the leaf nodes C and D of the dependency chain will not be feasible. Different dependency chains have different dependency situations, and the deeper the dependency tree, the greater the version compatibility issues and complexity that will result from directly upgrading the components at the leaf nodes.

[0073] by Figure 2Taking the dependency relationships Project-->A-->B-->C and Project-->A-->D as an example, assume that components A and B themselves do not have publicly disclosed high-risk vulnerabilities; components C and D are base packages and have publicly disclosed high-risk vulnerabilities. In this embodiment, the vulnerability labeling and rating will consider: A itself has a low vulnerability level, but it contains vulnerability information of C indirectly introduced by its dependency on B, and vulnerability information of D also exists. Considering both its own vulnerability and the vulnerability introduced by its dependencies, its level is high. B itself has a low vulnerability level, but due to the vulnerability information introduced by its direct dependency on C, considering both its own vulnerability and the vulnerability introduced by its dependencies, its level is high. C and D have high-risk vulnerabilities, and their vulnerability rating is high. Thus, each node (such as A and B), in addition to its own vulnerability information, will also integrate vulnerability information introduced by its lower-level dependencies.

[0074] Based on the vulnerability labeling and rating results above, this embodiment analyzes vulnerabilities in a forward manner according to the software's dependency principles, starting from the root node of the project. For example, starting with vulnerability A, the analysis prioritizes recommending developers upgrade A to a specific version, thereby indirectly leading to a batch upgrade of versions C and D at once. If no new version of A is available, then developers are advised to upgrade B and D sequentially. If no new version of B is available, then C is finally recommended to be upgraded directly. This forward-looking remediation suggestion will fix the entire dependency chain at once, minimizing the risk of component version compatibility issues and providing greater operability for developers.

[0075] If version A requires some API upgrades, developers can modify the code in the project that calls A's APIs to complete the upgrade and fix. However, if C is upgraded first, due to the fixed dependency between A and B, developers will have no way to resolve the compatibility issues between B and C from the project's code level.

[0076] As can be seen, this embodiment integrates the vulnerability information of components in the dependency chain with the vulnerability information introduced by their subordinate dependencies. At the same time, it follows the software dependency principle to search and repair in a forward manner in batches, which effectively improves the rationality of the repair suggestions, reduces version compatibility issues, and is more convenient and operable for developers.

[0077] Of course, the analysis of component dependency versions is also related to the dependency management methods, version coverage, and selection of specific programming languages. These need to be determined based on the specific programming language, such as Java (Maven, Gradle), PHP (Composer), Go (Module), etc.

[0078] The following describes a vulnerability repair device provided in an embodiment of this application. The vulnerability repair device described below and the vulnerability repair method described above can be referred to each other.

[0079] See Figure 3 As shown in the figure, this application discloses a vulnerability repair device, including:

[0080] Module 301 is used to obtain the component packages in the target project file;

[0081] Module 302 is used to determine at least one dependency chain based on the version dependencies between component packages;

[0082] The repair module 303 is used to repair vulnerabilities in each component package of any dependency chain if any component package in any dependency chain is marked with vulnerability information, starting from the beginning of the dependency chain and following the forward dependency order.

[0083] In one specific implementation, the repair module includes:

[0084] The selection unit is used to select the component package at each position in the dependency chain as the target to be tested, starting from the beginning of the dependency chain and following the forward dependency order.

[0085] The repair unit is used to repair vulnerabilities in the target under test based on the version dependency relationship between the component package in the previous position of the target under test and the target under test if a repaired version exists.

[0086] In one specific embodiment, the repair unit is specifically used for:

[0087] Determine the current version of the component package preceding the target under test;

[0088] Determine the version dependency scope of the target to be tested in the current version;

[0089] Update the target to be tested to any version within the version dependency range.

[0090] In one specific embodiment, the repair unit is specifically used for:

[0091] Use the version management tool corresponding to the target project files to determine the version dependency scope.

[0092] In one specific implementation, the repair module further includes:

[0093] The skip module is used to skip the vulnerability patch for the target under test if no patch version exists, and to determine the next target under test until the component package at each position in the dependency chain has been used as a target under test.

[0094] In one specific implementation, the vulnerability information annotation process for any component package in any dependency chain includes:

[0095] Determine the vulnerability information of each component package in the current dependency chain;

[0096] For each component package in the current dependency chain, determine the leaf component package at each leaf node position with the current component package as the parent node;

[0097] Combine the vulnerability information of the current component package and the leaf component package into a vulnerability information set, and select the highest risk level from the vulnerability information set;

[0098] Mark the highest risk level in the current component package.

[0099] In one specific implementation, the vulnerability information annotation process for any component package in any dependency chain includes:

[0100] Determine the vulnerability information of each component package in the current dependency chain;

[0101] The vulnerability information of each component package in the current dependency chain is marked on the corresponding component package in the current dependency chain.

[0102] For more detailed information on the working process of each module and unit in this embodiment, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0103] As can be seen, this embodiment provides a vulnerability remediation device that improves the access security of business systems, offers higher control efficiency and is easier to implement, and provides many conveniences for subsequent operation and maintenance. The device can be any type of software program, such as a software program deployed on a cloud computing platform.

[0104] The following describes an electronic device provided by an embodiment of this application. The electronic device described below can be referred to in conjunction with the vulnerability repair method and apparatus described above.

[0105] See Figure 4 As shown in the figure, an embodiment of this application discloses an electronic device, including:

[0106] Memory 401 is used to store computer programs;

[0107] Processor 402 is configured to execute the computer program to implement the method disclosed in any of the above embodiments.

[0108] Please refer to Figure 5 , Figure 5This is a schematic diagram of another electronic device provided in this embodiment. This electronic device can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) 322 (e.g., one or more processors) and memory 332, and one or more storage media 330 (e.g., one or more mass storage devices) for storing application programs 342 or data 344. The memory 332 and storage media 330 can be temporary or persistent storage. The program stored in the storage media 330 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the data processing device. Furthermore, the central processing unit 322 may be configured to communicate with the storage media 330 and execute the series of instruction operations in the storage media 330 on the electronic device.

[0109] The electronic device may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341. Examples include Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0110] exist Figure 5 In this context, application 342 may be a program that executes a vulnerability remediation method, and data 344 may be data required or generated for executing the vulnerability remediation method.

[0111] The steps in the vulnerability remediation method described above can be implemented by the structure of an electronic device. In addition, the electronic device can be a traditional single hardware entity or a multi-hardware entity, such as a cluster of multiple computers or a cloud computing platform.

[0112] The following describes a readable storage medium provided in an embodiment of this application. The readable storage medium described below can be referred to in conjunction with the vulnerability repair method, apparatus and device described above.

[0113] A readable storage medium is provided for storing a computer program, wherein the computer program, when executed by a processor, implements the vulnerability remediation method disclosed in the foregoing embodiments. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0114] The terms “first,” “second,” “third,” “fourth,” etc., used in this application (if applicable) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, or apparatus that includes a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, or apparatus.

[0115] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0116] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0117] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of readable storage medium known in the art.

[0118] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A vulnerability remediation method, characterized in that, include: Retrieve the component packages from the target project files; Determine at least one dependency chain based on the version dependencies between the component packages; If any component package in any dependency chain is marked with vulnerability information, then starting from the beginning of the dependency chain, the vulnerability is fixed for each component package in the dependency chain in the forward dependency order. The forward dependency order follows the component dependency principle of software development itself. When upgrading the component package at the root node in a dependency chain, the component packages at the corresponding leaf nodes will be upgraded accordingly. If there is no new version at the root node or the fix has been completed, the new version of the next level node is searched down layer by layer, and a fix suggestion based on the next level node is generated.

2. The vulnerability remediation method according to claim 1, characterized in that, The process of patching vulnerabilities in each component package of the dependency chain, starting from the beginning of the dependency chain and proceeding in a forward dependency order, includes: Starting from the beginning of the dependency chain, the component package at each position in the dependency chain is taken as the target to be tested according to the forward dependency order; If a patched version of the target exists, the vulnerability is patched based on the version dependency between the target and the component package preceding the target.

3. The vulnerability remediation method according to claim 2, characterized in that, The step of patching vulnerabilities in the target under test based on the version dependency relationship between the component package preceding the target under test and the target under test includes: Determine the current version of the component package at the previous position of the target under test; Determine the version dependency range of the current version on the target under test; Update the target under test to any version within the version dependency range.

4. The vulnerability remediation method according to claim 2, characterized in that, Also includes: If no patch version exists for the target under test, the vulnerability patch for the target under test is skipped, and the next target under test is determined, until the component package at each position in the dependency chain has been used as the target under test.

5. The vulnerability remediation method according to claim 1, characterized in that, The process of annotating vulnerability information for any component package in any dependency chain includes: Determine the vulnerability information of each component package in the current dependency chain; For each component package in the current dependency chain, determine the leaf component package at each leaf node position with the current component package as the parent node; The vulnerability information of the current component package and the leaf component package are combined into a vulnerability information set, and the highest risk level is selected from the vulnerability information set; Mark the highest risk level in the current component package.

6. The vulnerability remediation method according to claim 5, characterized in that, The process of determining the vulnerability information of each component package in the current dependency chain includes: Query the vulnerability database for vulnerability information of each component package in the current dependency chain.

7. The vulnerability remediation method according to claim 1, characterized in that, The process of annotating vulnerability information for any component package in any dependency chain includes: Determine the vulnerability information of each component package in the current dependency chain; The vulnerability information of each component package in the current dependency chain is marked on the corresponding component package in the current dependency chain.

8. A vulnerability repair device, characterized in that, include: The acquisition module is used to acquire the component packages in the target project file; A determination module is used to determine at least one dependency chain based on the version dependency relationships between the component packages; The repair module is used to repair vulnerabilities in each component package of any dependency chain if any component package in any dependency chain is marked with vulnerability information, starting from the beginning of the dependency chain and following the forward dependency order. The forward dependency order follows the component dependency principle of software development itself. When upgrading the component package at the root node in a dependency chain, the component packages at the corresponding leaf nodes will be upgraded accordingly. If there is no new version at the root node or the fix has been completed, the new version of the next level node is searched down layer by layer, and a fix suggestion based on the next level node is generated.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the vulnerability remediation method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the vulnerability repair method as described in any one of claims 1 to 7.

Images