Vulnerability processing method, electronic device, program product and storage medium

Abstract

The present invention provides a vulnerability handling method, electronic device, program product, and storage medium, relating to the field of computer technology. The method can determine the unpatched software version corresponding to the software affected by the vulnerability in a business system, and can search whether the software has a patched software version that has fixed the vulnerability. If the patched software version is present, to prevent code in the patched software version that is unrelated to the patched vulnerability from interfering with the operation of the business system, the target code for fixing the vulnerability can be located based on the patched software version and the unpatched software version, and a patch file can be generated based on the target code to improve the pertinence of the patch file. Furthermore, if the patched software version is not present, system environment information of the business system can be obtained, and a pre-trained machine learning model can be used to predict the vulnerability repair method corresponding to the vulnerability information, unpatched software version, and system environment information. In the absence of a patch file, other methods can be used to repair the vulnerability, effectively improving the pertinence and timeliness of vulnerability repairs.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a vulnerability processing method, electronic equipment, program product, and storage medium. Background Art

[0002] To ensure the security and stability of business system operations, timely patching of software vulnerabilities within them is crucial. In related technologies, vulnerability repair relies on patch files provided by software vendors. However, on the one hand, developing patch files is time-consuming. In the absence of patch files, business systems continue to operate with vulnerabilities exposed, lacking a response plan. On the other hand, software vendors may not provide patch files, but instead fix vulnerabilities through software version updates. However, these updated software versions may contain updates unrelated to the vulnerability fix, which can easily lead to incompatibility between the software and the business system, thereby impacting the normal operation of the business system. Summary of the Invention

[0003] The present invention provides a vulnerability handling method, electronic device, program product and storage medium, which can locate the target code for repairing the vulnerability based on the repaired software version and the unrepaired software version of the software when the software has a repaired software version with the repaired vulnerability, and generate a patch file based on the target code; and can use a pre-trained machine learning model to predict the repair method of the vulnerability when the software does not have a repaired software version with the repaired vulnerability, thereby effectively improving the pertinence and timeliness of vulnerability repair.

[0004] To solve the above technical problems, the present invention provides a vulnerability processing method, comprising:

[0005] Obtain vulnerability information and, based on the vulnerability information, determine the unpatched software versions corresponding to the software affected by the vulnerability in the business system;

[0006] Find out if the software has a patched version with fixed vulnerabilities;

[0007] If a repaired software version is available, determining a difference code between the software code of the repaired software version and the software code of the unrepaired software version, determining a target code for repairing the vulnerability in the difference code, and generating a patch file based on the target code to repair the vulnerability based on the patch file;

[0008] If there is no repair software version, the system environment information of the business system is obtained, and the vulnerability information, unrepaired software version, and system environment information are input into the pre-trained machine learning model to obtain the vulnerability repair method output by the pre-trained machine learning model, and the vulnerability is repaired based on the vulnerability repair method.

[0009] The present invention also provides an electronic device, comprising:

[0010] Memory for storing computer programs;

[0011] A processor is used to implement the above-mentioned vulnerability handling method when executing a computer program.

[0012] The present invention also provides a computer program product, including a computer program or instructions, which implements the above-mentioned vulnerability processing method when the computer program or instructions are executed by a processor.

[0013] The present invention also provides a non-volatile computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are loaded and executed by a processor, the above-mentioned vulnerability processing method is implemented.

[0014] The beneficial effect of the present invention is that when the vulnerability information is obtained, the present invention can determine the unrepaired software version corresponding to the software affected by the vulnerability in the business system according to the vulnerability information. Subsequently, the present invention can search whether the software has a repaired software version with the fixed vulnerability. If there is a repaired software version, in order to avoid the content in the repaired software version that is irrelevant to the vulnerability affecting the normal operation of the business system, the difference code between the software code of the repaired software version and the software code of the unrepaired software version can be determined, the target code for repairing the vulnerability can be located in the difference code, and a patch file can be generated based on the target code to improve the pertinence of the patch file. If there is no repaired software version, the present invention can also obtain the system environment information of the business system, and input the vulnerability information, the unrepaired software version, and the system environment information into the pre-trained machine learning model to obtain the vulnerability repair method output by the pre-trained machine learning model, that is, use the pre-trained machine learning model to predict potential vulnerability repair methods, so as to try to repair the vulnerability in the absence of a patch file. In this way, the present invention can effectively improve the pertinence and timeliness of vulnerability repair, thereby improving the vulnerability repair effect.

[0015] The present invention also provides an electronic device, a program product and a storage medium, which have the above beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 A flowchart of a vulnerability handling method provided by an embodiment of the present invention;

[0018] Figure 2 A schematic diagram of another vulnerability handling process provided by an embodiment of the present invention;

[0019] Figure 3 A schematic diagram of a differential patch generation process provided by an embodiment of the present invention;

[0020] Figure 4 A schematic diagram of a model processing flow provided by an embodiment of the present invention;

[0021] Figure 5 A structural block diagram of a vulnerability processing device provided by an embodiment of the present invention;

[0022] Figure 6 This is a structural block diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0023] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0024] It should be noted that, in the description of the present invention, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. The terms "first," "second," etc., in the present invention are used to distinguish similar objects, and are not used to describe a particular order or precedence.

[0025] In order to enable those skilled in the art to better understand the solutions of the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0026] To ensure the security and stability of business system operations, timely patching of software vulnerabilities within them is crucial. In related technologies, vulnerability repair relies on patch files provided by software vendors. However, on the one hand, developing patch files is time-consuming. In the absence of patch files, business systems continue to operate with vulnerabilities exposed, lacking a response plan. On the other hand, software vendors may not provide patch files, but instead fix vulnerabilities through software version updates. However, these updated software versions may contain updates unrelated to the vulnerability fix, which can easily lead to incompatibility between the software and the business system, thereby impacting the normal operation of the business system.

[0027] In view of this, in order to quickly and specifically repair software vulnerabilities, the present invention can provide a vulnerability handling method, which can locate the target code for repairing the vulnerability based on the repaired software version and the unrepaired software version of the software when the software has a repaired software version with the fixed vulnerability, and generate a patch file based on the target code; and when the software does not have a repaired software version with the fixed vulnerability, it can use a pre-trained machine learning model to predict the repair method of the vulnerability, thereby effectively improving the pertinence and timeliness of vulnerability repair.

[0028] For easier understanding, please refer to Figure 1 , Figure 1 A flowchart of a vulnerability handling method provided by an embodiment of the present invention may include:

[0029] S101. Obtain vulnerability information, and determine, in the business system based on the vulnerability information, an unpatched software version corresponding to the software affected by the vulnerability.

[0030] In this step, vulnerability information refers to information related to software vulnerabilities, including, for example, vulnerability number, vulnerability description, affected software version, vulnerability triggering conditions, vulnerability type, vulnerability severity, etc. This information can be obtained from multiple data sources, such as vulnerability databases, security advisories, and vulnerability exploit code libraries. After obtaining the vulnerability information, this embodiment can save it to a local database for subsequent processing.

[0031] Furthermore, this step will determine the unpatched software version corresponding to the software affected by the vulnerability in the business system based on the vulnerability information. The unpatched software version refers to the software version that has the vulnerability. It should be noted that this embodiment is not limited to a specific business system and can be set arbitrarily according to application requirements.

[0032] S102: Check whether the software has a repair software version that has fixed the vulnerability. If the software has a repair software version, proceed to step S103; if not, proceed to step S104.

[0033] In this step, you can check whether the software has a repair software version that has fixed the vulnerability. The repair software version is generally provided by the software manufacturer, and you can find the repair software version through the download channel provided by the software manufacturer.

[0034] S103: Determine the difference code between the software code of the repaired software version and the software code of the unrepaired software version, determine the target code for repairing the vulnerability in the difference code, and generate a patch file based on the target code to repair the vulnerability based on the patch file.

[0035] It should be noted that when a repair software version is found in this step, the repair software version will not be used immediately to fix the software vulnerability. This is because software manufacturers usually integrate several updates into one repair software version and update them together. In this case, the repair software version contains not only the update content to fix the vulnerability, but also other updates, such as code optimization, function enhancement, etc. In this case, the additional update content can easily cause the software to be incompatible with other software / operating systems, thereby affecting the normal operation of the business system. Therefore, this step will extract the target code for fixing the vulnerability from the repair software version and generate a patch file based on the target code, thereby improving the pertinence of the patch file.

[0036] Specifically, this step can obtain the software code of the repaired software version and the software code of the unrepaired software version, and determine the difference code between the two versions of the software code. The difference code refers to the code portion of the repaired software version that has been modified compared to the software code of the unrepaired software version, such as added code, deleted code, and adjusted code. At this point, the difference code contains both the code used to fix the vulnerability and other updated code. Therefore, this step will continue to locate the target code for the vulnerability fix in the difference code, and then generate a patch file based on the target code.

[0037] Regarding the location of the target code, this embodiment can determine whether the code logic of the difference code is related to the vulnerability repair. Specifically, the vulnerability triggering condition can be obtained from the vulnerability information. The vulnerability triggering condition can indicate in what software environment and what software operation the vulnerability can be reproduced, and the software environment and software operation can be used to locate the target code. Subsequently, this embodiment can determine the code logic for repairing the vulnerability in the difference code according to the vulnerability triggering condition to obtain the target code, for example, execute the difference code to determine which code is related to avoiding the vulnerability, thereby obtaining the target code.

[0038] Based on this, the target code to fix the vulnerability is determined in the difference code, which may include:

[0039] Step 11: Determine the vulnerability triggering conditions based on the vulnerability information.

[0040] Step 12: Determine the code logic for fixing the vulnerability in the difference code based on the vulnerability triggering condition and obtain the target code.

[0041] In order to further improve the accuracy of locating the target code, this embodiment can provide another target code locating method. First, the system environment information of the business system can be obtained, and the system environment information can represent the operating system environment in the business system. Subsequently, a first test environment can be constructed based on the system environment information and the unrepaired software version, and a second test environment can be constructed based on the system environment information and the repaired software version. Subsequently, the vulnerability triggering condition can be used to trigger the vulnerability in the first test environment to determine the first code fragment that causes the vulnerability in the unrepaired software version, and the vulnerability triggering condition can be used to trigger the vulnerability in the second test environment to determine the second code fragment that fixes the vulnerability in the repaired software version. At this point, the first code fragment and the second code fragment are both the code fragments that are most closely associated with the vulnerability. Finally, the target code can be determined based on the first code fragment, the second code fragment and the difference code, so that the actual code content that is actually used for vulnerability repair can be extracted from the difference code.

[0042] Based on this, the code logic for fixing the vulnerability is determined in the difference code according to the vulnerability triggering conditions, and the target code is obtained, which may include:

[0043] Step 21: Construct a first test environment based on the system environment information and the unpatched software version.

[0044] Step 22: Build a second test environment based on the system environment information and the repair software version.

[0045] In step 21 and step 22, different virtual machine environments can be constructed based on virtualization technology according to system environment information and different software versions, so that different virtual machine environments can be used as different test environments.

[0046] Step 23: Utilize the vulnerability triggering condition to trigger the vulnerability in the first test environment, and determine the first code snippet causing the vulnerability in the unpatched software version.

[0047] Step 24: Utilize the vulnerability triggering condition to trigger the vulnerability in the second test environment, and determine a second code snippet in the repair software version that fixes the vulnerability.

[0048] In steps 23 and 24, the propagation path from user input to the vulnerability trigger point can be tracked based on static analysis, or dynamic analysis methods such as code instrumentation can be used to observe the stack trace and memory status when the vulnerability is triggered, thereby determining the first code snippet that causes the vulnerability and the second code snippet that fixes the vulnerability.

[0049] Step 25: Determine the target code based on the first code segment, the second code segment and the difference code.

[0050] In step 25 , the first code segment, the second code segment, and the difference code may be cross-compared to more accurately determine the target code.

[0051] S104. Obtain system environment information of the business system, input vulnerability information, unrepaired software versions, and system environment information into a pre-trained machine learning model, obtain a vulnerability repair method output by the pre-trained machine learning model, and repair the vulnerability based on the vulnerability repair method.

[0052] In this step, if the repair software version is not queried, the vulnerability cannot be repaired by generating a patch file at this time. In order to prevent the business system from working when the vulnerability is exposed, this embodiment can also try to adopt other vulnerability repair methods to repair the vulnerability. Among them, the vulnerability repair method is a process method for handling vulnerabilities, such as limiting functions, adjusting configuration parameters, upgrading software versions, installing existing patch files, etc. Specifically, in order to ensure the effectiveness of vulnerability repair, this embodiment can set a pre-trained machine learning model, which has been trained using historical vulnerability repair information (including historical vulnerability information, historical unrepaired software versions, historical system environment information and historical vulnerability repair methods). It can predict the corresponding vulnerability repair method based on the input vulnerability information, unrepaired software versions, and system environment information, thereby improving the pertinence of the vulnerability repair method.

[0053] Specifically, this embodiment can first combine vulnerability information, unpatched software versions, and system environment information into raw input data. Subsequently, the raw input data can be encoded to obtain input data, thereby ensuring that the model can recognize the input data. Furthermore, the input data can be fed into a pre-trained machine learning model to obtain the vulnerability remediation method output by the pre-trained machine learning model and the corresponding credibility of the vulnerability remediation method. This credibility can represent the reliability of the vulnerability remediation method. Finally, the vulnerability remediation method and its credibility can be output for selection by operations and maintenance personnel.

[0054] Based on this, vulnerability information, unpatched software versions, and system environment information are input into the pre-trained machine learning model to obtain the vulnerability repair method output by the pre-trained machine learning model, including:

[0055] Step 31: Vulnerability information, unpatched software versions, and system environment information are combined into raw input data.

[0056] Step 32: Encode the original input data to obtain input data.

[0057] Step 33: Input the input data into the pre-trained machine learning model to obtain the vulnerability repair method output by the pre-trained machine learning model and the credibility corresponding to the vulnerability repair method.

[0058] Step 34: Output the vulnerability repair method and credibility.

[0059] It should be noted that this embodiment does not limit the specific type of pre-trained machine learning model. For example, it can be a classification model or a language model (such as a Large Language Model (LLM)). For ease of implementation, this embodiment can select a classification model as the pre-trained machine learning model. Specifically, a decision tree model can be trained to obtain the desired pre-trained machine learning model.

[0060] Based on this, the training process of the pre-trained machine learning model can include:

[0061] Step 41: Obtain historical vulnerability repair information and use the historical vulnerability repair information to generate original training data; the historical vulnerability repair information includes historical vulnerability information, historical unrepaired software versions, historical system environment information, and historical vulnerability repair methods.

[0062] Step 42: Encode the original training data to obtain training data.

[0063] Step 43: Use the training data to train a decision tree model, and use the trained decision tree model as a pre-trained machine learning model.

[0064] Finally, when a reliable patch file or vulnerability repair method is obtained, the patch file or vulnerability repair method can be used to repair the business system to avoid long-term exposure of the business system to vulnerability risks.

[0065] Based on this, the method further includes:

[0066] S105. Repair the business system using patch files or vulnerability repair methods.

[0067] Based on the above embodiment, when the present invention obtains vulnerability information, it can determine the unrepaired software version corresponding to the software affected by the vulnerability in the business system according to the vulnerability information. Subsequently, the present invention can search whether the software has a repaired software version that has fixed the vulnerability. If there is a repaired software version, in order to avoid the content in the repaired software version that is irrelevant to the vulnerability affecting the normal operation of the business system, the difference code between the software code of the repaired software version and the software code of the unrepaired software version can be determined, the target code for repairing the vulnerability can be located in the difference code, and a patch file can be generated based on the target code to improve the pertinence of the patch file. If there is no repaired software version, the present invention can also obtain the system environment information of the business system, and input the vulnerability information, the unrepaired software version, and the system environment information into the pre-trained machine learning model to obtain the vulnerability repair method output by the pre-trained machine learning model, that is, use the pre-trained machine learning model to predict potential vulnerability repair methods, so as to try to repair the vulnerability in the absence of a patch file. In this way, the present invention can effectively improve the pertinence and timeliness of vulnerability repair, thereby improving the vulnerability repair effect.

[0068] Based on the above embodiment, after generating the patch file, in order to verify the validity of the patch file and avoid repair failures that may cause huge losses to the business system, this embodiment can also determine the validity of the patch file in a verification environment. Based on this, after generating the patch file based on the target code, the following steps can also be included:

[0069] S201. Construct a verification environment based on system environment information and unpatched software versions.

[0070] In this step, a virtual machine environment may be constructed based on virtualization technology according to the system environment information and the unpatched software version, so as to use the virtual machine environment as a verification environment.

[0071] S202: Repair the software using the patch file in the verification environment.

[0072] S203. Determine the vulnerability triggering condition of the vulnerability based on the vulnerability information, and judge whether the repaired software cannot trigger the vulnerability based on the vulnerability triggering condition; if it is determined that the repaired software cannot trigger the vulnerability, proceed to step S204; if it is determined that the repaired software can trigger the vulnerability, proceed to step S205.

[0073] S204: Determine whether the patch file is valid.

[0074] S205: Determine whether the patch file is invalid.

[0075] In steps S202-S205, the patch file can be used to repair the software. After the repair, the repaired software is triggered according to the vulnerability trigger conditions of the vulnerability, and a determination is made as to whether the vulnerability recurs. If the vulnerability does not recur, the patch file can be determined to be valid and can be used to repair the business system. If the vulnerability recurs, the patch file can be determined to be invalid, and the patch file cannot be used to repair the business system. Thus, through pre-verification, this embodiment can determine the validity of the patch file and avoid using invalid patches to repair the business system.

[0076] Of course, in addition to determining whether the vulnerability has disappeared, this embodiment can also detect whether the verification environment encounters other faults, thereby further verifying the effectiveness of the patch.

[0077] Furthermore, after confirming the validity of the patch file, we can generate supplemental training data using vulnerability information, unpatched software versions, system environment information, and the patch file's corresponding vulnerability fix. This supplemental training data can then be used to supplement the pre-trained machine learning model. This can further improve the model's understanding of the vulnerability fix method, enabling it to provide more accurate predictions.

[0078] Based on this, after determining that the patch file is valid, the following steps may also be performed:

[0079] Step 51: Generate a vulnerability repair method using the patch file.

[0080] Step 52: Generate supplementary training data using vulnerability information, unpatched software versions, system environment information, and vulnerability repair methods corresponding to patch files.

[0081] Step 53: Perform additional training on the pre-trained machine learning model using the additional training data.

[0082] Based on the above embodiment, after using the pre-trained machine learning model to predict the vulnerability repair method, this embodiment can first verify the effectiveness of the vulnerability repair method in a verification environment. If the method is confirmed to be effective, it can be used to repair the business system, thereby avoiding repair failures that would cause huge losses to the business system. Based on this, after obtaining the vulnerability repair method output by the pre-trained machine learning model, it can also include:

[0083] S301. Construct a verification environment based on system environment information and unpatched software versions.

[0084] In this step, a virtual machine environment may be constructed based on virtualization technology according to the system environment information and the unpatched software version, so as to use the virtual machine environment as a verification environment.

[0085] S302: Repair the software in the verification environment according to the vulnerability repair method.

[0086] S303. Determine the vulnerability triggering condition of the vulnerability based on the vulnerability information, and judge whether the repaired software cannot trigger the vulnerability based on the vulnerability triggering condition; if it is determined that the repaired software cannot trigger the vulnerability, proceed to S304; if it is determined that the repaired software can trigger the vulnerability, proceed to step S305.

[0087] S304: Determine whether the vulnerability repair method is effective.

[0088] S305: Determine that the vulnerability repair method is invalid.

[0089] In steps S302-S305, the software can be repaired using the vulnerability repair method predicted by the model. After repair, the repaired software is triggered according to the vulnerability triggering conditions of the vulnerability, and a determination is made as to whether the vulnerability recurs. If the vulnerability does not recur, the vulnerability repair method can be determined to be effective and can be used to repair the business system. If the vulnerability recurs, the vulnerability repair method can be determined to be invalid, and the business system cannot be repaired using the vulnerability repair method. Thus, through pre-verification, this embodiment can determine the effectiveness of the vulnerability repair method and avoid using invalid patches to repair the business system.

[0090] Of course, in addition to determining whether the vulnerability has disappeared, this embodiment can also detect whether the verification environment encounters other faults, thereby further verifying the effectiveness of the vulnerability repair method.

[0091] Furthermore, after confirming that a vulnerability fix is ​​effective, additional training data can be generated using vulnerability information, unpatched software versions, system environment information, and the vulnerability fix. This additional training data can then be used to train the pre-trained machine learning model. This can further improve the model's understanding of the vulnerability fix, enabling it to provide more accurate predictions.

[0092] Based on this, after determining that the vulnerability repair method is effective, it also includes:

[0093] Step 61: Generate supplementary training data using vulnerability information, unpatched software versions, system environment information, and vulnerability repair methods.

[0094] Step 62: Perform additional training on the pre-trained machine learning model using the additional training data.

[0095] Based on the above embodiment, considering that conventional vulnerability information usually does not include the priority of vulnerability repair, which leads to many low-priority vulnerability repairs affecting the repair progress of high-priority vulnerabilities, causing the system to be affected by high-risk vulnerabilities for a longer period of time. Therefore, before performing vulnerability repairs, this embodiment can also determine the priority of vulnerability repair based on vulnerability information and business systems to effectively repair high-priority vulnerabilities. Based on this, before checking whether the software has a repair software version that has fixed the vulnerability, it can also include:

[0096] S401. Determine a general evaluation score and threat intelligence of the vulnerability based on the vulnerability information.

[0097] The Common Vulnerability Scoring System (CVSS) score is a common attribute in CVE vulnerability information (Common Vulnerabilities & Exposures), which can represent the risk level of the vulnerability itself.

[0098] Threat intelligence characterizes the threat situation of a vulnerability. Common threat intelligence may include vulnerability activity (based on the frequency of public discussion of the vulnerability, such as the number of CVE entry updates and the amount of POC code (Proof of concept) released), wild exploitation, attack complexity, etc.

[0099] By obtaining general evaluation scores and threat intelligence, this embodiment can effectively assess the risk of the vulnerability itself.

[0100] S402: Determine asset information of deployed software in the business system.

[0101] Assets in business systems include servers, databases, applications, network devices, and so on. By identifying the assets that deploy software affected by a vulnerability, this embodiment can determine the impact of the vulnerability within the business system and the potential impact of remediating the vulnerability on the business system, thereby effectively assessing the risk posed by the vulnerability to the business system.

[0102] S403. Determine a vulnerability score for the vulnerability using the general evaluation score, threat intelligence, and asset information, and determine a vulnerability remediation level for the vulnerability based on the vulnerability score.

[0103] In this step, the vulnerability score of the vulnerability can be determined using the general evaluation score, threat intelligence, and asset information. The vulnerability remediation level of the vulnerability can be determined based on the vulnerability score, thereby determining the priority of vulnerability remediation by comprehensively considering the risk of the vulnerability itself and the risk of the vulnerability to the business system.

[0104] It should be noted that this embodiment does not limit the specific vulnerability remediation level, which can be set according to actual application needs, such as setting low, medium, and high levels. This embodiment also does not limit the correspondence between vulnerability scores and vulnerability remediation levels, which can also be set according to actual application needs.

[0105] The following describes a possible method for determining vulnerability scores. Based on this, the vulnerability scores of vulnerabilities are determined using general evaluation scores, threat intelligence, and asset information. These methods may include:

[0106] Step 71: Determine the threat intelligence scores corresponding to the threat intelligence in at least two preset threat intelligence evaluation dimensions, and fuse the threat intelligence scores using the preset weights corresponding to the preset threat intelligence evaluation dimensions to obtain a total threat intelligence score.

[0107] In this step, threat intelligence can be evaluated from multiple dimensions to obtain threat intelligence scores corresponding to each dimension, and the total threat intelligence score can be obtained by weighted summation. This embodiment does not limit the specific preset threat intelligence evaluation dimensions. For example, it may include vulnerability activity (based on the frequency of public discussion of the vulnerability, such as the number of CVE entry updates and the number of POC code releases), wild exploitation (the number of times the vulnerability has been detected as an actual attack), attack complexity (directly using the Attack Complexity value in CVSS), threat intelligence credibility (authoritative sources > commercial intelligence > community intelligence), etc.

[0108] It should be noted that this embodiment does not limit the weights corresponding to the preset threat intelligence evaluation dimensions, and can be set according to actual application requirements.

[0109] Step 72: Determine the asset importance scores corresponding to the asset information in at least two preset asset evaluation dimensions, and fuse the asset importance scores using the preset weights corresponding to the preset asset evaluation dimensions to obtain a total asset importance score.

[0110] In this step, asset information can also be evaluated in multiple dimensions to obtain the asset importance score corresponding to each dimension, and the total asset importance score can be obtained by weighted summation. This embodiment does not limit the specific preset asset evaluation dimensions, for example, it can include business criticality, data sensitivity, system dependency, and business continuity. Among them, business criticality can be scored according to the degree of impact of the business module affected by the vulnerability on the core business. Data sensitivity can be classified and weighted according to the type of data involved in the asset (such as public data, internal data, confidential data). System dependency can evaluate the dependency of assets in the system (such as whether it is an upstream dependency of other systems). Business continuity can be graded according to the maximum downtime (MTD, Maximum Tolerable Downtime) allowed by the system or the recovery time objective (RTO, Recovery Time Object).

[0111] For example, the core payment system is the business system that is most obviously perceived by users and involves user data, so its business criticality = 10 and data sensitivity = 10; the internal test server is a business system that is not obviously perceived by users and only involves non-important internal data, so its business criticality = 1 and data sensitivity = 1.

[0112] It should be noted that this embodiment does not limit the weights corresponding to the preset asset evaluation dimensions; these can be set based on actual application requirements. Furthermore, the weights corresponding to the preset asset evaluation dimensions can be dynamically adjusted. For example, initial weights can be set based on the business scenario (e.g., 40% for business criticality, 30% for data sensitivity, and 30% for service continuity). Subsequently, a real-time feedback mechanism can be introduced to automatically increase the weight of an asset if it has recently been attacked or experienced a failure. This allows for flexible response to user needs.

[0113] Based on this, the method may further include:

[0114] Step 81: Obtain attack information of the asset corresponding to the asset information.

[0115] Step 82: Adjust the preset weights corresponding to the preset asset evaluation dimensions according to the attack information.

[0116] Step 73: Determine the vulnerability score for the vulnerability using the general assessment score, the total threat intelligence score, and the total asset importance score.

[0117] In this step, the general evaluation score, the total threat intelligence score, and the total asset importance score can be weighted to obtain a vulnerability score for the identified vulnerability.

[0118] S404: For vulnerabilities whose vulnerability repair level is higher than a preset level, immediately perform a step of searching whether the software has a repair software version that has fixed the vulnerability.

[0119] S405: For vulnerabilities whose repair level is not higher than a preset level, while waiting for the business system to enter a low-load state, perform a step of searching whether the software has a repair software version that has fixed the vulnerability.

[0120] In steps S404-S405, this embodiment prioritizes processing vulnerabilities with a higher-than-preset level of vulnerability repair. For vulnerabilities with a lower-than-preset level of vulnerability repair, processing can be delayed until the business system enters a low-load state. This allows high-priority vulnerabilities to be processed first, preventing the processing of lower-priority vulnerabilities from interfering with the processing of higher-priority vulnerabilities.

[0121] Based on the above embodiment, the following is an introduction to the vulnerability handling method based on specific examples and schematic diagrams. Figure 2 , Figure 2 This is a schematic diagram of another vulnerability handling process provided by an embodiment of the present invention. This method may include:

[0122] 1. The multi-dimensional scoring system is responsible for classifying the collected vulnerabilities into different levels to ensure that high-priority vulnerabilities are handled first.

[0123] It mainly includes the following dimensions: CVSS basic score (Common Vulnerability Scoring System), total asset importance score, and threat intelligence coefficient.

[0124] 1. CVSS basic score: an attribute information of the vulnerability obtained, which can be obtained directly.

[0125] 2. Total Asset Importance Score: Assets include servers, databases, applications, network equipment, etc. The importance of an asset is determined by factors such as its business criticality, data sensitivity, and impact on business continuity. Each dimension can be quantified on a scale of 1-10 (10 being the highest importance). The following is a possible quantitative evaluation method:

[0126] Table 1 Quantitative evaluation methods

[0127]

[0128] For example:

[0129] Core payment system: Business criticality = 10, Data sensitivity = 10;

[0130] Internal test server: Business criticality = 1, Data sensitivity = 1.

[0131] At the same time, this embodiment adopts a dynamic weighting method to configure the weights of each scenario. For example:

[0132] 1) Set initial weights based on the business scenario (40% for business criticality, 30% for data sensitivity, and 30% for service continuity).

[0133] 2) Introducing a real-time feedback mechanism: If an asset is recently attacked or experiences a malfunction, its weight will be automatically increased.

[0134] 3. Threat intelligence coefficient: The threat intelligence coefficient needs to be dynamically obtained and standardized from multiple dimensions, including vulnerability activity (based on the frequency of public discussion of the vulnerability, such as the number of CVE entry updates and the number of POC code releases), wild exploitation (the number of times the vulnerability is detected to be actually attacked), attack complexity (directly using the Attack Complexity value in CVSS), and threat intelligence credibility (authoritative sources > commercial intelligence > community intelligence).

[0135] The final level of the vulnerability is obtained through evaluation and calculation of the above three dimensions.

[0136] 2. Differential patch generation is responsible for comparing and analyzing the software version affected by the vulnerability with the fixed software version, extracting the difference code between the two, and generating a lightweight differential patch.

[0137] The goal of this function is to generate efficient, reliable, and compatible differential patches to provide a basis for subsequent vulnerability repairs. At the same time, this function will also input the patch information into the learning model for the model to learn and enhance the accuracy of the subsequent model to provide repair solutions. Figure 3 , Figure 3 This is a schematic diagram of a differential patch generation process provided by an embodiment of the present invention. The specific process is as follows:

[0138] 1. Version acquisition and preprocessing:

[0139] Input: The software version affected by the vulnerability and the fixed software version.

[0140] Processing: Perform pre-processing operations such as decompression, compilation, and symbol resolution on the code to ensure code readability and analyzability.

[0141] 2. Code comparison and analysis:

[0142] Use a code comparison tool to compare two versions of the code and identify all modified files, functions, and lines of code.

[0143] Distinguish between modifications related to bug fixes and unrelated modifications (such as code optimization, feature enhancement, etc.).

[0144] 3. Difference code extraction:

[0145] Extract code differences (added, deleted, and modified lines of code) related to the bug fix.

[0146] The extracted differential code is organized and formatted to generate differential patches that are easy to apply.

[0147] 4. Patch optimization and verification:

[0148] Optimize patches: compress patch size, eliminate redundant code, and resolve dependencies.

[0149] Verify the patch: Ensure that the patch is correctly applied to the target version and does not introduce new issues.

[0150] 5. Patch file generation:

[0151] The optimized and verified differential patch is packaged with the patch metadata to generate the final patch file.

[0152] 3. Adaptive learning is responsible for using machine learning technology to analyze and learn historical vulnerability repair data, build vulnerability repair models, and predict the best repair solutions for new vulnerabilities based on the models.

[0153] The goal of this function is to make vulnerability repair strategies intelligent and adaptive, and to improve the accuracy and efficiency of repair solutions.

[0154] Model input and output:

[0155] enter:

[0156] Historical vulnerability repair data (including vulnerability information, software environment, repair plan, and repair results) can be expressed as ,in The feature vector representing the i-th vulnerability (including vulnerability type, software environment, repair solution, etc.), Indicates the repair result.

[0157] New vulnerability information (including vulnerability type, affected software version, and vulnerability severity level);

[0158] Current software environment information (including operating system version, software version, and configuration information).

[0159] Output:

[0160] Best repair solution (including repair strategies, repair steps, and expected results);

[0161] The credibility score s of the repair solution.

[0162] Model processing flow (please refer to Figure 4 ):

[0163] 1. Data collection and preprocessing:

[0164] Collect historical vulnerability repair data from multiple sources such as vulnerability databases, security announcements, and repair records.

[0165] Perform pre-processing operations such as cleaning, deduplication, and formatting on the collected data to ensure data quality and obtain a pre-processed data set .

[0166] 2. Feature Engineering:

[0167] Repair data from historical vulnerabilities Extract features from the vulnerability, such as vulnerability type, software environment, repair plan, repair result, etc.

[0168] The extracted features are encoded and normalized to make them suitable for the input of the machine learning model to obtain the feature matrix and label vector .

[0169] 3. Model training and evaluation:

[0170] Use the decision tree algorithm to build a vulnerability repair model, specifically using the decision tree algorithm right and Train and get the model .

[0171] The model is trained using historical vulnerability repair data, and the performance of the model is evaluated using methods such as cross-validation.

[0172] 4. Repair plan prediction:

[0173] New vulnerability information and current software environment information Input Model , get the predicted repair solution and credibility score , helping users judge the reliability of the repair solution.

[0174] 5. Model update and optimization:

[0175] Regularly collect new vulnerability repair data, update and optimize the model, and improve the model's prediction accuracy.

[0176] Based on user feedback and actual repair effects, adjust model parameters and algorithms to improve the practicality of the model.

[0177] The above process can be formulated as:

[0178] 1. Data preprocessing:

[0179] ;

[0180] 2. Feature Engineering

[0181] ;

[0182] 3. Model training:

[0183] ;

[0184] 4. Repair plan prediction:

[0185] ;

[0186] Comprehensive formula: Combining the above steps, we can get a comprehensive formula:

[0187] .

[0188] Assume the following training dataset:

[0189] Table 2 Training dataset

[0190]

[0191] After training the decision tree, for a new vulnerability (e.g., vulnerability type = "buffer overflow", software version = "1.0", and severity = "high"), the decision tree will predict the fix as "upgrade version".

[0192] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0193] The embodiment of the present invention also provides a vulnerability processing device. Figure 5 , Figure 5 This is a structural block diagram of a vulnerability processing device provided by an embodiment of the present invention. The device may include:

[0194] An acquisition module 501 is configured to acquire vulnerability information and determine, in the business system, the unpatched software version corresponding to the software affected by the vulnerability based on the vulnerability information;

[0195] A search module 502 is used to search whether the software has a repair software version that has fixed the vulnerability;

[0196] The patch file generation module 503 is configured to determine the difference between the software code of the repaired software version and the software code of the unrepaired software version if a repaired software version is available, determine the target code for repairing the vulnerability in the difference, and generate a patch file based on the target code to repair the vulnerability based on the patch file;

[0197] The repair method prediction module 504 is used to obtain the system environment information of the business system if there is no repair software version, input the vulnerability information, unrepaired software version, and system environment information into the pre-trained machine learning model, obtain the vulnerability repair method output by the pre-trained machine learning model, and repair the vulnerability based on the vulnerability repair method.

[0198] Optionally, the patch file generation module 503 may include:

[0199] The trigger condition determination submodule is used to determine the vulnerability trigger condition based on the vulnerability information;

[0200] The target code location submodule is used to determine the code logic for fixing the vulnerability in the difference code according to the vulnerability triggering conditions and obtain the target code.

[0201] Optionally, the target code location submodule may include:

[0202] A first test environment construction unit, configured to construct a first test environment according to system environment information and an unpatched software version;

[0203] A second test environment construction unit, configured to construct a second test environment according to the system environment information and the repair software version;

[0204] a first vulnerability triggering unit, configured to trigger a vulnerability in a first test environment using a vulnerability triggering condition, and determine a first code fragment causing the vulnerability in an unpatched software version;

[0205] a second vulnerability triggering unit, configured to trigger the vulnerability in the second test environment using the vulnerability triggering condition, and determine a second code snippet in the repair software version that fixes the vulnerability;

[0206] The target code locating unit is configured to determine the target code based on the first code segment, the second code segment and the difference code.

[0207] Optionally, the device may further include:

[0208] Patch verification environment construction module, used to build a verification environment based on system environment information and unpatched software versions;

[0209] The patch verification environment repair module is used to repair the software using the patch file in the verification environment;

[0210] The patch verification module is used to determine the vulnerability triggering conditions of the vulnerability based on the vulnerability information, and judge whether the repaired software cannot trigger the vulnerability based on the vulnerability triggering conditions; if it is determined that the repaired software cannot trigger the vulnerability, the patch file is determined to be valid; if it is determined that the repaired software can trigger the vulnerability, the patch file is determined to be invalid.

[0211] Optionally, the device may further include:

[0212] Repair method generation module, used to generate vulnerability repair methods using patch files;

[0213] A supplementary training data generation module is used to generate supplementary training data using vulnerability information, unpatched software versions, system environment information, and vulnerability repair methods corresponding to patch files;

[0214] The supplementary training module is used to perform supplementary training on the pre-trained machine learning model using supplementary training data.

[0215] Optionally, the repair method prediction module 504 may include:

[0216] Input module, used to combine vulnerability information, unpatched software versions, and system environment information into raw input data;

[0217] An encoding module, used for encoding the original input data to obtain input data;

[0218] The prediction module is used to input the input data into the pre-trained machine learning model to obtain the vulnerability repair method output by the pre-trained machine learning model and the corresponding credibility of the vulnerability repair method;

[0219] Output module, used to output vulnerability repair methods and credibility.

[0220] Optionally, the device may further include:

[0221] A training data generation module is used to obtain historical vulnerability repair information and use it to generate original training data; the historical vulnerability repair information includes historical vulnerability information, historical unrepaired software versions, historical system environment information, and historical vulnerability repair methods;

[0222] A training data encoding module is used to encode the original training data to obtain training data;

[0223] The training module is used to train the decision tree model using the training data and use the trained decision tree model as a pre-trained machine learning model.

[0224] Optionally, the device may further include:

[0225] Repair mode verification environment construction module, used to build a verification environment based on system environment information and unrepaired software versions;

[0226] Repair method verification environment repair module, used to repair the software according to the vulnerability repair method in the verification environment;

[0227] The repair method verification module is used to determine the vulnerability triggering conditions of the vulnerability based on the vulnerability information, and judge whether the repaired software cannot trigger the vulnerability based on the vulnerability triggering conditions; if it is determined that the repaired software cannot trigger the vulnerability, the vulnerability repair method is determined to be effective; if it is determined that the repaired software can trigger the vulnerability, the vulnerability repair method is determined to be invalid.

[0228] Optionally, after determining that the vulnerability repair method is effective, the following steps may also be performed:

[0229] A supplementary training data generation module is used to generate supplementary training data using vulnerability information, unpatched software versions, system environment information, and vulnerability repair methods;

[0230] The supplementary training module is used to perform supplementary training on the pre-trained machine learning model using supplementary training data.

[0231] Optionally, the device may further include:

[0232] The repair module is used to repair the business system using patch files or vulnerability repair methods.

[0233] Optionally, the device may further include:

[0234] A first information collection module is used to determine a general evaluation score and threat intelligence of a vulnerability based on the vulnerability information;

[0235] A second information collection module is used to determine asset information of deployed software in the business system;

[0236] A vulnerability level determination module is used to determine the vulnerability score of the vulnerability using the general evaluation score, threat intelligence and asset information, and determine the vulnerability remediation level of the vulnerability based on the vulnerability score;

[0237] A first vulnerability repair module is used to immediately perform a step of searching whether the software has a repair software version that has fixed the vulnerability for a vulnerability whose repair level is higher than a preset level;

[0238] The second vulnerability repair module is used to execute the step of searching whether the software has a repair software version that has fixed the vulnerability when the business system enters a low-load state for vulnerabilities whose repair level is not higher than a preset level.

[0239] Optionally, the vulnerability level determination module may include:

[0240] A threat assessment module is used to determine the threat intelligence scores corresponding to at least two preset threat intelligence evaluation dimensions, and to fuse the threat intelligence scores using the preset weights corresponding to the preset threat intelligence evaluation dimensions to obtain an overall threat intelligence score;

[0241] An asset evaluation module is used to determine the asset importance scores corresponding to the asset information in at least two preset asset evaluation dimensions, and to combine the asset importance scores using the preset weights corresponding to the preset asset evaluation dimensions to obtain a total asset importance score;

[0242] The scoring module is used to determine the vulnerability score of a vulnerability using the general evaluation score, the total threat intelligence score, and the total asset importance score.

[0243] Optionally, the device may further include:

[0244] An attack information acquisition module is used to obtain attack information of assets corresponding to asset information;

[0245] The weight adjustment module is used to adjust the preset weights corresponding to each preset asset evaluation dimension according to the attack information.

[0246] For the description of the features in the embodiment corresponding to the vulnerability handling device, please refer to the relevant description of the embodiment corresponding to the vulnerability handling method, and will not be repeated here.

[0247] Please refer to Figure 6 , Figure 6 This is a structural block diagram of an electronic device provided by an embodiment of the present invention. The embodiment of the present invention provides an electronic device 10, including a processor 11 and a memory 12; wherein the memory 12 is used to store computer programs; the processor 11 is used to execute the vulnerability handling method provided by the aforementioned embodiment when executing the computer program.

[0248] For the specific process of the above vulnerability handling method, please refer to the corresponding content provided in the above embodiments, which will not be repeated here.

[0249] Furthermore, the memory 12 as a carrier for resource storage may be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the storage method may be temporary storage or permanent storage.

[0250] In addition, the electronic device 10 also includes a power supply 13, a communication interface 14, an input / output interface 15 and a communication bus 16; wherein the power supply 13 is used to provide operating voltage for each hardware device on the electronic device 10; the communication interface 14 can create a data transmission channel between the electronic device 10 and an external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present invention, and is not specifically limited here; the input / output interface 15 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0251] An embodiment of the present invention further provides a non-volatile computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned vulnerability handling method embodiments when running.

[0252] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0253] An embodiment of the present invention further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned vulnerability handling method embodiments are implemented.

[0254] An embodiment of the present invention further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned vulnerability handling method embodiments are implemented.

[0255] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0256] The above describes in detail the vulnerability handling method, electronic device, program product, and storage medium provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only intended to help understand the method and core concept of the present invention. It should be noted that for those skilled in the art, without departing from the principles of the present invention, various improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. A vulnerability handling method, characterized in that: include: Obtain vulnerability information, and determine, in the business system, the unpatched software version corresponding to the software affected by the vulnerability based on the vulnerability information; Checking whether the software has a patched version that fixes the vulnerability; If the repaired software version is available, determining a difference code between the software code of the repaired software version and the software code of the unrepaired software version, determining a target code for repairing the vulnerability in the difference code, and generating a patch file based on the target code to repair the vulnerability based on the patch file; If the repair software version is not available, obtaining system environment information of the business system, inputting the vulnerability information, the unrepaired software version, and the system environment information into a pre-trained machine learning model, obtaining a vulnerability repair method output by the pre-trained machine learning model, and repairing the vulnerability based on the vulnerability repair method; Determining the target code for repairing the vulnerability in the difference code includes: Determining a vulnerability triggering condition based on the vulnerability information; Building a first test environment according to the system environment information and the unpatched software version; Constructing a second test environment according to the system environment information and the repair software version; triggering a vulnerability in the first test environment using the vulnerability triggering condition, and determining a first code snippet in the unpatched software version that causes the vulnerability; triggering a vulnerability in the second test environment using the vulnerability triggering condition, and determining a second code snippet in the repair software version that fixes the vulnerability; A target code is determined based on the first code segment, the second code segment, and the difference code.

2. The vulnerability handling method according to claim 1, characterized in that: After generating a patch file based on the target code, the method further includes: Building a verification environment according to the system environment information and the unpatched software version; Repairing the software using the patch file in the verification environment; Determining a vulnerability triggering condition of the vulnerability according to the vulnerability information, and judging whether the repaired software cannot trigger the vulnerability according to the vulnerability triggering condition; If it is determined that the repaired software cannot trigger the vulnerability, then the patch file is determined to be valid; If it is determined that the repaired software can trigger the vulnerability, the patch file is determined to be invalid.

3. The vulnerability processing method according to claim 2, characterized in that: After determining that the patch file is valid, the method further includes: Generating a vulnerability repair method using the patch file; Generating supplementary training data using the vulnerability information, the unpatched software version, the system environment information, and the vulnerability repair method corresponding to the patch file; The pre-trained machine learning model is supplementally trained using the supplementary training data.

4. The vulnerability processing method according to claim 1, characterized in that: Inputting the vulnerability information, the unpatched software version, and the system environment information into a pre-trained machine learning model to obtain a vulnerability repair method output by the pre-trained machine learning model, including: Combining the vulnerability information, the unpatched software version, and the system environment information into original input data; Encoding the original input data to obtain input data; Inputting the input data into the pre-trained machine learning model to obtain a vulnerability repair method output by the pre-trained machine learning model and a credibility corresponding to the vulnerability repair method; The vulnerability repair method and the credibility are output.

5. The vulnerability processing method according to claim 4, characterized in that: The training process of the pre-trained machine learning model includes: Obtain historical vulnerability repair information and use the historical vulnerability repair information to generate original training data; the historical vulnerability repair information includes historical vulnerability information, historical unrepaired software versions, historical system environment information, and historical vulnerability repair methods; Encoding the original training data to obtain training data; The training data is used to train a decision tree model, and the trained decision tree model is used as the pre-trained machine learning model.

6. The vulnerability processing method according to claim 1, characterized in that: After obtaining the vulnerability repair method output by the pre-trained machine learning model, the method further includes: Building a verification environment according to the system environment information and the unpatched software version; In the verification environment, repairing the software according to the vulnerability repair method; Determining a vulnerability triggering condition of the vulnerability according to the vulnerability information, and judging whether the repaired software cannot trigger the vulnerability according to the vulnerability triggering condition; If it is determined that the repaired software cannot trigger the vulnerability, then the vulnerability repair method is determined to be effective; If it is determined that the repaired software can trigger the vulnerability, then the vulnerability repair method is determined to be invalid.

7. The vulnerability processing method according to claim 6, characterized in that: After determining that the vulnerability repair method is effective, the following steps are also included: Generating supplementary training data using the vulnerability information, the unrepaired software version, the system environment information, and the vulnerability repair method; The pre-trained machine learning model is supplementally trained using the supplementary training data.

8. The vulnerability processing method according to claim 1, characterized in that: Also includes: Repair the business system using the patch file or the vulnerability repair method.

9. The vulnerability processing method according to any one of claims 1 to 8, characterized in that: Before checking whether the software has a fixed version that fixes the vulnerability, it also includes: Determine a general evaluation score and threat intelligence of the vulnerability based on the vulnerability information; Determining asset information for deploying the software in the business system; Determining a vulnerability score for the vulnerability using the general evaluation score, the threat intelligence, and the asset information, and determining a vulnerability remediation level for the vulnerability based on the vulnerability score; For the vulnerability whose repair level is higher than the preset level, immediately perform the step of searching whether the software has a repair software version that has fixed the vulnerability; For the vulnerability whose repair level is not higher than the preset level, when waiting for the business system to enter a low-load state, a step of searching whether the software has a repair software version that has repaired the vulnerability is performed.

10. The vulnerability processing method according to claim 9, characterized in that: Determining a vulnerability score of the vulnerability using the general evaluation score, the threat intelligence, and the asset information includes: Determining threat intelligence scores corresponding to the threat intelligence in at least two preset threat intelligence evaluation dimensions, and fusing the threat intelligence scores using preset weights corresponding to the preset threat intelligence evaluation dimensions to obtain a total threat intelligence score; Determining asset importance scores corresponding to the asset information in at least two preset asset evaluation dimensions, and fusing the asset importance scores using preset weights corresponding to the preset asset evaluation dimensions to obtain a total asset importance score; The vulnerability score of the vulnerability is determined using the general evaluation score, the threat intelligence total score, and the asset importance total score.

11. The vulnerability processing method according to claim 10, characterized in that: Also includes: Obtaining attack information of the asset corresponding to the asset information; The preset weights corresponding to the preset asset evaluation dimensions are adjusted according to the attack information.

12. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the vulnerability handling method according to any one of claims 1 to 11 when executing the computer program.

13. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the vulnerability handling method according to any one of claims 1 to 11 is implemented.

14. A non-volatile computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are loaded and executed by the processor, the vulnerability processing method according to any one of claims 1 to 11 is implemented.

Images