Vulnerability patch verification method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a vulnerability patch verification method and device, computer equipment, a readable storage medium and a program product. The method comprises the following steps: acquiring vulnerability information associated with each component in to-be-verified software, establishing a vulnerability list according to the vulnerability information, acquiring historical submission data of the to-be-verified software, and identifying first patch content associated with potential vulnerabilities in the historical submission data, and removing potential vulnerabilities associated with the first patch content from the vulnerability list, acquiring second patch content associated with the residual vulnerabilities from the historical submission data for the residual vulnerabilities in the vulnerability list, and performing validity verification on the first patch content and the second patch content. By adopting the method, the bug patch can be comprehensively and accurately identified.

Description

Technical Field

[0001] The present application relates to the field of software security technology, and in particular to a vulnerability patch verification method, apparatus, computer equipment, readable storage medium, and program product. Background Art

[0002] With the rapid development of information technology, software applications have penetrated into all aspects of social life and become an indispensable infrastructure to support modern life and work. With the increasing popularity of software applications, its security issues have become increasingly prominent and have become an important factor restricting the further development of software. Once the vulnerabilities in the software are maliciously exploited, they may cause serious consequences such as data leakage and system crashes, posing a serious threat to the privacy and property security of users. At present, in software security practice, vulnerability patch detection technology is an important means to prevent software vulnerabilities.

[0003] Traditional vulnerability patch detection methods mainly identify the code patch sequence in the software to verify whether the vulnerability has been patched. However, this method often relies too much on the annotation information when the code is submitted, but not all patches come with detailed annotation information. Especially for those vulnerabilities that need to be fixed urgently, developers may ignore the addition of annotations due to time constraints, making it difficult to find the unannotated patch content, which reduces the comprehensiveness of vulnerability patch identification. Summary of the invention

[0004] Based on this, it is necessary to provide a vulnerability patch verification method, device, computer equipment, readable storage medium and program product that can comprehensively and accurately identify vulnerability patches in response to the above technical problems.

[0005] In a first aspect, the present application provides a vulnerability patch verification method, comprising:

[0006] Obtain vulnerability information associated with each component in the software to be verified, and establish a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information;

[0007] Obtaining historical submission data of the software to be verified, and identifying first patch content associated with the potential vulnerability in the historical submission data; the first patch content includes patch content with annotation information;

[0008] The potential vulnerabilities associated with the first patch content are removed from the vulnerability list, and for the remaining vulnerabilities in the vulnerability list, second patch content associated with the remaining vulnerabilities is obtained from the historical submission data; the second patch content includes patch content without annotation information;

[0009] The validity of the first patch content and the second patch content is verified.

[0010] In one embodiment, the step of obtaining historical submission data of the software to be verified includes:

[0011] Access the code repository of the software to be verified to obtain the historical submission records of the software to be verified;

[0012] According to the log files corresponding to the historical submission records, the metadata corresponding to each historical submission record is obtained; the metadata includes the submitter, submission time, submission information and the list of changed files.

[0013] In one embodiment, the step of identifying a first patch content associated with a potential vulnerability in the historical submission data includes:

[0014] Perform natural language analysis on all metadata to obtain key information related to vulnerability patching and corresponding target submission records;

[0015] According to the list of changed files in the target submission record, obtain the candidate patch content corresponding to the target submission record;

[0016] According to the annotation information of the candidate patch content, first patch content associated with the potential vulnerability is obtained from the candidate patch content.

[0017] In one embodiment, the step of obtaining second patch content associated with the remaining vulnerability from the historical submission data includes:

[0018] Obtain the abstract syntax tree of historical submission data through a static code analysis tool, and obtain the code data flow of the historical submission data based on the abstract syntax tree;

[0019] A difference analysis is performed based on the abstract syntax tree and the code data flow, and second patch content associated with the remaining vulnerability is obtained according to the result of the difference analysis.

[0020] In one embodiment, the step of performing a difference analysis based on the abstract syntax tree and the code data flow, and obtaining the second patch content associated with the remaining vulnerability according to the result of the difference analysis includes:

[0021] Obtain public information related to the remaining vulnerabilities; the public information includes vulnerability descriptions related to the remaining vulnerabilities;

[0022] Based on public information, perform differential analysis on abstract syntax trees and code data flows;

[0023] When there is a difference inconsistent with the public information and the difference is fixed, the potential patch content corresponding to the difference is obtained, and the potential patch content is used as the second patch content associated with the remaining vulnerability.

[0024] In one embodiment, the step of verifying the validity of the first patch content and the second patch content includes:

[0025] Perform simulation tests on the first patch content and the second patch content by using a symbolic execution tool to verify whether there are unpatched vulnerability paths in the first patch content and the second patch content;

[0026] A stress test is performed on the first patch content and the second patch content by using a fuzz testing tool to verify whether there is an invalid patch in the first patch content and the second patch content.

[0027] In a second aspect, the present application also provides a vulnerability patch verification device, including:

[0028] A vulnerability information acquisition module is used to obtain vulnerability information associated with each component in the software to be verified, and to establish a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information;

[0029] A first patch acquisition module is used to acquire historical submission data of the software to be verified, and identify first patch content associated with potential vulnerabilities in the historical submission data; the first patch content includes patch content with annotation information;

[0030] A second patch acquisition module is used to remove the potential vulnerability associated with the first patch content from the vulnerability list, and for the remaining vulnerabilities in the vulnerability list, obtain the second patch content associated with the remaining vulnerabilities from the historical submission data; the second patch content includes the patch content without annotation information;

[0031] The validity verification module is used to verify the validity of the first patch content and the second patch content.

[0032] In a third aspect, the present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements any one of the method steps in the first aspect when executing the computer program.

[0033] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements any one of the method steps in the first aspect when the computer program is executed by a processor.

[0034] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which implements any one of the method steps in the first aspect when executed by a processor.

[0035] The above-mentioned vulnerability patch verification method, device, computer equipment, readable storage medium and program product can comprehensively grasp the potential vulnerabilities that may exist in each component of the software to be verified by establishing a vulnerability list. By identifying the patch content without annotations in the historical submission data, all vulnerability patches in the software to be verified can be comprehensively identified, and the validity of all patches with annotation information and patches without annotation information can be verified, which can improve the accuracy of patch identification. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0037] Figure 1 A diagram of an application environment of a vulnerability patch verification method in an embodiment;

[0038] Figure 2 A schematic diagram of a process of a vulnerability patch verification method in one embodiment;

[0039] Figure 3 A schematic diagram of a flow chart of a vulnerability patch verification method in another embodiment;

[0040] Figure 4 is a structural block diagram of a vulnerability patch verification device in an embodiment;

[0041] Figure 5 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0043] The vulnerability patch verification method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. Among them, the terminal 102 is used to obtain vulnerability information associated with each component in the software to be verified, and establish a vulnerability list based on the vulnerability information, obtain the historical submission data of the software to be verified, and identify the first patch content associated with the potential vulnerability in the historical submission data, remove the potential vulnerability associated with the first patch content from the vulnerability list, and for the remaining vulnerabilities in the vulnerability list, obtain the second patch content associated with the remaining vulnerabilities from the historical submission data, and verify the validity of the first patch content and the second patch content. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The head mounted device may be a virtual reality (VR) device, an augmented reality (AR) device, smart glasses, etc. The server 104 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0044] In an exemplary embodiment, Figure 2 As shown, a vulnerability patch verification method is provided, which is applied to Figure 1 The terminal 102 in the example is used as an example to illustrate, including the following steps 202 to 208. Among them:

[0045] S202: Acquire vulnerability information associated with each component in the software to be verified, and establish a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information.

[0046] Optionally, first, the software to be verified needs to be disassembled and analyzed to identify all the components therein, which can be various functional modules, library files, drivers, etc. in the software. For each identified component, its version information is accurately obtained. The version information is usually presented in a specific format, reflecting the iteration of the component in the software development process. Different versions of the same component may have different features, functional improvements, and potential vulnerabilities. Based on the version information of each component, the potential vulnerability information corresponding to each component version is obtained by querying the relevant vulnerability database, etc., and all vulnerability information is summarized to establish a vulnerability list containing all potential vulnerabilities.

[0047] S204: Obtain historical submission data of the software to be verified, and identify first patch content associated with potential vulnerabilities in the historical submission data; the first patch content includes patch content with annotation information.

[0048] Optionally, the historical submission data records modifications, updates, etc. of the software at various stages of the development process, including submissions made to fix vulnerabilities. Afterwards, patch content associated with potential vulnerabilities is identified in these historical submission data to obtain first patch content, wherein the first patch content includes patch content with annotation information. The annotation information can usually help understand the role of the patch, the specific problems it fixes, etc. The specific vulnerability that the patch targets can be clarified through the annotation information.

[0049] S206: removing the potential vulnerabilities associated with the first patch content from the vulnerability list, and acquiring second patch content associated with the remaining vulnerabilities in the vulnerability list from the historical submission data; the second patch content includes patch content without annotation information.

[0050] Optionally, since the first patch contents in the historical submission data have been identified, these patch contents are annotated and associated with certain potential vulnerabilities. By combing through these associations, it is possible to clarify which potential vulnerabilities have theoretically been handled by these patches. Therefore, these potential vulnerabilities associated with the first patch contents are removed from the vulnerability list, and the focus is placed on the remaining vulnerabilities that do not yet have clear annotated patches corresponding to them. For these remaining vulnerabilities, the patch contents related to them, i.e., the second patch contents, are searched again in the historical submission data. In the actual software development process, there may be some patches that modify the code but do not clearly record that they are used to fix a specific vulnerability. These patches may be submitted in emergency repairs or due to negligence of developers. By obtaining these second patch contents, it is possible to further explore the code modification records that may be used to fix the remaining vulnerabilities, providing more clues for comprehensive verification and repair of all vulnerabilities in the software.

[0051] S208: Verify the validity of the first patch content and the second patch content.

[0052] Optionally, the main goal of validating the first patch content and the second patch content is to determine whether these patches have truly fixed the potential vulnerabilities they correspond to. Among them, although the first patch content has annotation information, in the actual development process, the patch may become invalid. Therefore, it is necessary to verify the validity of both the first patch content and the second patch content to ensure that the patches can truly prevent vulnerability attacks.

[0053] In the above vulnerability patch verification method, by establishing a vulnerability list, the potential vulnerabilities that may exist in each component of the software to be verified can be fully grasped. By identifying the patch content without annotations in the historical submission data, all vulnerability patches in the software to be verified can be fully identified, and the validity of all patches with annotation information and patches without annotation information can be verified, which can improve the accuracy of patch identification.

[0054] In an exemplary embodiment, the step of obtaining historical submission data of the software to be verified includes: accessing the code repository of the software to be verified to obtain the historical submission records of the software to be verified; obtaining the corresponding metadata of each historical submission record according to the log file corresponding to the historical submission record; the metadata includes the submitter, submission time, submission information and a list of changed files.

[0055] Optionally, during the development process of the software to be verified, its code is usually stored in a code repository, such as a common Git repository. Developers will modify and improve the software code at different stages and submit these modifications to the code repository. By interacting with the code repository and using the relevant interfaces or commands provided by the warehouse management system, all historical submission records of the software from the initial creation to the current moment can be obtained. For each historical submission record obtained, there is a corresponding log file, where the log file usually contains metadata for each submission, such as the submitter, submission time, submission information, and a list of changed files. Among them, the submission information is usually a brief description written by the developer when submitting the code, which usually describes the purpose of this submission, such as adding a new function, fixing a vulnerability, optimizing the performance of a module, etc. The list of changed files lists in detail all the changed files involved in this submission, including which files have been modified, deleted, or added.

[0056] In this embodiment, by acquiring the historical submission data of the software to be verified, the patch content with annotation information in the software to be verified can be accurately acquired, thereby improving the accuracy of patch identification.

[0057] In an exemplary embodiment, the step of identifying the first patch content associated with a potential vulnerability in historical submission data includes: performing natural language analysis on all metadata to obtain key information related to vulnerability patching and a corresponding target submission record; obtaining candidate patch content corresponding to the target submission record based on a list of changed files in the target submission record; and obtaining the first patch content associated with the potential vulnerability from the candidate patch content based on annotation information of the candidate patch content.

[0058] Optionally, all metadata in the acquired historical submission data of the software to be verified are subjected to natural language analysis, such as lexical analysis, syntactic analysis, semantic understanding, etc., to extract key information related to vulnerability patching from the submission information, and further screen out the corresponding target submission records based on the extracted key information. For each determined target submission record, by viewing the list of changed files in the target submission record and integrating the relevant content involved in modifying, adding or deleting the software code, the candidate patch content corresponding to the target submission record can be obtained. The candidate patch content is actually the code part that may be used to patch the vulnerability in this submission. Afterwards, based on the annotation information of the candidate patch content, those patch contents that explicitly mention being associated with potential vulnerabilities are screened out, and finally those patch contents that have clear annotations indicating that they are used to patch specific potential vulnerabilities are determined.

[0059] In this embodiment, by acquiring the first patch content associated with the potential vulnerability according to the annotation information, the patch content that is truly associated with the potential vulnerability can be accurately located from the historical submission data, thereby improving the accuracy of patch identification.

[0060] In an exemplary embodiment, the step of obtaining second patch content associated with the remaining vulnerabilities from the historical submission data includes: obtaining an abstract syntax tree of the historical submission data through a static code analysis tool, and obtaining a code data flow of the historical submission data based on the abstract syntax tree; performing a difference analysis based on the abstract syntax tree and the code data flow, and obtaining the second patch content associated with the remaining vulnerabilities based on the results of the difference analysis.

[0061] Optionally, static code analysis tools can parse the code in historical submission data and convert it into an abstract syntax tree (AST). An abstract syntax tree is a way to represent the syntax structure of code in a tree structure, which can clearly show the hierarchical relationship and syntax rules between various elements in the code (such as variables, functions, statements, etc.). For example, for a simple piece of code "if(a>10){b=a*2;}", its abstract syntax tree will use the "if" statement as the root node, "a>10" as the conditional child node, "b=a*2" as the execution child node, etc., so that the structure of the code can be understood more intuitively. Based on the construction of the abstract syntax tree, static code analysis tools can also track the flow of data in the code, that is, the code data flow, which describes how data is created, used, and modified in the program. For example, in the above code, the data is read from the variable "a", and after the comparison operation "a>10", if the condition is met, the data "a" will participate in the multiplication operation "a*2", and then the result will be assigned to the variable "b". This analysis of the code data flow helps to understand the behavior of the code and potential logical errors.

[0062] Furthermore, a difference analysis is performed on the abstract syntax tree and the code data flow, mainly comparing the differences between different historical submissions. When focusing on the patch content related to the remaining vulnerabilities, the changes in the code parts that may be related to the remaining vulnerabilities in different submissions will be focused on. This difference analysis can be achieved by comparing the structural changes of the abstract syntax tree and the changes in the code data flow. For example, by comparing the abstract syntax trees of two versions, it is found that the parameters of a function call node have changed in the new submission, and the corresponding code data flow shows that the verification method of the input data has also changed, which may imply a fix for the potential vulnerability. According to the results of the difference analysis, the code modification part associated with the remaining vulnerabilities is found, that is, the second patch content. Since the second patch content is a patch content without comment information, this method can be used to mine the content that may be used to fix the remaining vulnerabilities from the actual changes in the code without the guidance of comments.

[0063] In this embodiment, by analyzing the changes in the abstract syntax tree and the code data flow, it is possible to delve into the syntax structure and data flow level of the code, accurately mine the patch content that may be related to the remaining vulnerabilities, and improve the accuracy and efficiency of patch detection.

[0064] In an exemplary embodiment, the steps of performing a difference analysis based on an abstract syntax tree and a code data flow, and obtaining a second patch content associated with the remaining vulnerabilities based on the results of the difference analysis, include: obtaining public information about the remaining vulnerabilities; the public information includes vulnerability descriptions related to the remaining vulnerabilities; based on the public information, performing a difference analysis on the abstract syntax tree and the code data flow; in the case where there are differences inconsistent with the public information and the differences are fixed, obtaining potential patch content corresponding to the differences, and using the potential patch content as the second patch content associated with the remaining vulnerabilities.

[0065] Optionally, first obtain public information related to the remaining vulnerabilities, which usually includes detailed vulnerability descriptions, such as the cause of the vulnerability, possible security risks (such as data leakage, system crash, etc.), software components or functional modules affected by the vulnerability, the environment and conditions in which the vulnerability was discovered, etc. This public information can be obtained from security vulnerability databases (such as CVE-Common Vulnerabilities and Exposures Database), security notices issued by software vendors, reports from security research institutions, and other channels.

[0066] Furthermore, using the obtained public information of the remaining vulnerabilities, perform differential analysis on the abstract syntax tree and code data flow. At the abstract syntax tree level, check the changes in the syntax structure corresponding to the software components or functional modules related to the vulnerabilities in different submissions. At the code data flow level, analyze whether the flow of data related to the vulnerability in the program has changed. In the process of differential analysis, look for differences that are inconsistent with the public information, and these differences are fixed. When such differences are found, obtain the potential patch content corresponding to this difference. These potential patch contents are the parts that modify the software code as the second patch content associated with the remaining vulnerabilities.

[0067] In this embodiment, by combining the public information of the remaining vulnerabilities and the difference analysis, the patch content that may be used to repair the remaining vulnerabilities can be more accurately located, so as to accurately obtain the second patch content without annotation information in the software to be identified, thereby improving the accuracy of patch identification.

[0068] In an exemplary embodiment, the step of verifying the validity of the first patch content and the second patch content includes: performing simulation testing on the first patch content and the second patch content through a symbolic execution tool to verify whether there are unfixed vulnerability paths in the first patch content and the second patch content; performing stress testing on the first patch content and the second patch content through a fuzz testing tool to verify whether there are invalid patches in the first patch content and the second patch content.

[0069] Alternatively, symbolic execution is an important formal method and software analysis technology. It represents the input of the program as a symbolic value, and represents the value of the variables in the program and the output as a computational expression composed of symbolic values ​​and constants. By solving these expressions, the specific input for executing a specific code area can be obtained, thereby simulating the attack scenario. Using symbolic execution technology, the code path after the patch repair can be tracked to check whether there is an unpatched vulnerability path. The test cases generated by symbolic execution can cover more code paths and improve the comprehensiveness of the test. Fuzz testing is a method for detecting abnormal behavior of software based on inputting random or abnormal data. By providing unexpected input to the first patch content and the second patch content, observing the abnormal response of the program (such as crash, abnormal behavior or error), potential security issues are discovered. Fuzz testing can simulate various possible attack scenarios, including those that are difficult to predict. Through a large number of randomly generated test cases, it can be verified whether the patch will fail under certain extreme or special input conditions.

[0070] In this embodiment, by combining the simulation test of the symbolic execution tool and the stress test of the fuzz testing tool, it is possible to comprehensively detect from different angles whether the patch content has truly and effectively fixed the vulnerability, thereby ensuring the effectiveness of the first patch content and the second patch content and improving the quality and applicability of the patch.

[0071] In an exemplary embodiment, Figure 3 As shown, a vulnerability patch verification method is provided, the method comprising the following steps:

[0072] The vulnerability information associated with each component in the software to be verified is obtained, and a vulnerability list is established based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information.

[0073] Access the code repository of the software to be verified to obtain the historical submission records of the software to be verified; obtain the corresponding metadata of each historical submission record according to the log file corresponding to the historical submission record; the metadata includes the submitter, submission time, submission information and the list of changed files.

[0074] Perform natural language analysis on all metadata to obtain key information related to vulnerability patching and the corresponding target submission record; obtain candidate patch content corresponding to the target submission record based on the change file list of the target submission record; and obtain the first patch content associated with the potential vulnerability from the candidate patch content based on the annotation information of the candidate patch content.

[0075] The potential vulnerabilities associated with the first patch content are removed from the vulnerability list. For the remaining vulnerabilities in the vulnerability list, the abstract syntax tree of the historical submission data is obtained through a static code analysis tool, and the code data flow of the historical submission data is obtained based on the abstract syntax tree; public information about the remaining vulnerabilities is obtained; the public information includes vulnerability descriptions related to the remaining vulnerabilities.

[0076] Based on public information, a difference analysis is performed on the abstract syntax tree and the code data flow; when there are differences inconsistent with the public information and the differences are fixed, the potential patch content corresponding to the differences is obtained, and the potential patch content is used as the second patch content associated with the remaining vulnerabilities; the second patch content includes patch content without annotation information.

[0077] The first patch content and the second patch content are simulated tested by a symbolic execution tool to verify whether there are unfixed vulnerability paths in the first patch content and the second patch content; the first patch content and the second patch content are stress tested by a fuzz testing tool to verify whether there are invalid patches in the first patch content and the second patch content.

[0078] In this embodiment, by establishing a vulnerability list, the potential vulnerabilities that may exist in each component of the software to be verified can be fully understood. By identifying the patch content without annotations in the historical submission data, all vulnerability patches in the software to be verified can be fully identified, and the validity of all patches with annotation information and patches without annotation information can be verified, which can improve the accuracy of patch identification.

[0079] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0080] Based on the same inventive concept, the embodiment of the present application also provides a vulnerability patch verification device for implementing the vulnerability patch verification method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more vulnerability patch verification device embodiments provided below can refer to the limitations of the vulnerability patch verification method above, and will not be repeated here.

[0081] In an exemplary embodiment, Figure 4 As shown, a vulnerability patch verification device is provided, comprising: a vulnerability information acquisition module 10, a first patch acquisition module 20, a second patch acquisition module 30 and a validity verification module 40, wherein:

[0082] The vulnerability information acquisition module 10 is used to obtain vulnerability information associated with each component in the software to be verified, and to establish a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information.

[0083] The first patch acquisition module 20 is used to acquire historical submission data of the software to be verified, and identify first patch content associated with potential vulnerabilities in the historical submission data; the first patch content includes patch content with annotation information.

[0084] The second patch acquisition module 30 is used to remove potential vulnerabilities associated with the first patch content from the vulnerability list, and for the remaining vulnerabilities in the vulnerability list, obtain second patch content associated with the remaining vulnerabilities from the historical submission data; the second patch content includes patch content without annotation information.

[0085] The validity verification module 40 is used to verify the validity of the first patch content and the second patch content.

[0086] In an exemplary embodiment, the first patch acquisition module 20 is also used to access the code repository of the software to be verified to obtain the historical submission records of the software to be verified; according to the log files corresponding to the historical submission records, obtain the corresponding metadata of each historical submission record; the metadata includes the submitter, submission time, submission information and the list of changed files.

[0087] In an exemplary embodiment, the first patch acquisition module 20 is also used to perform natural language analysis on all metadata to obtain key information related to vulnerability patching and corresponding target submission records; obtain candidate patch content corresponding to the target submission record based on the change file list of the target submission record; and obtain the first patch content associated with the potential vulnerability from the candidate patch content based on the annotation information of the candidate patch content.

[0088] In an exemplary embodiment, the second patch acquisition module 30 is also used to obtain the abstract syntax tree of the historical submission data through a static code analysis tool, and obtain the code data flow of the historical submission data based on the abstract syntax tree; perform a difference analysis based on the abstract syntax tree and the code data flow, and obtain the second patch content associated with the remaining vulnerabilities based on the results of the difference analysis.

[0089] In an exemplary embodiment, the second patch acquisition module 30 is also used to obtain public information related to the remaining vulnerabilities; the public information includes vulnerability descriptions related to the remaining vulnerabilities; based on the public information, a difference analysis is performed on the abstract syntax tree and the code data flow; when there are differences inconsistent with the public information and the differences are repaired, the potential patch content corresponding to the differences is obtained, and the potential patch content is used as the second patch content associated with the remaining vulnerabilities.

[0090] In an exemplary embodiment, the validity verification module 40 is also used to perform simulation testing on the first patch content and the second patch content through a symbolic execution tool to verify whether there are unfixed vulnerability paths in the first patch content and the second patch content; and to perform stress testing on the first patch content and the second patch content through a fuzz testing tool to verify whether there are invalid patches in the first patch content and the second patch content.

[0091] Each module in the above vulnerability patch verification device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0092] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 5 As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, a vulnerability patch verification method is implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0093] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0094] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the following steps when executing the computer program: obtaining vulnerability information associated with each component in the software to be verified, and establishing a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information; obtaining historical submission data of the software to be verified, and identifying first patch content associated with the potential vulnerabilities in the historical submission data; the first patch content includes patch content with annotation information; removing the potential vulnerabilities associated with the first patch content from the vulnerability list, and for the remaining vulnerabilities in the vulnerability list, obtaining second patch content associated with the remaining vulnerabilities from the historical submission data; the second patch content includes patch content without annotation information; and verifying the validity of the first patch content and the second patch content.

[0095] In one embodiment, obtaining historical submission data of the software to be verified involved in executing a computer program by a processor includes: accessing a code repository of the software to be verified to obtain historical submission records of the software to be verified; obtaining metadata corresponding to each historical submission record based on a log file corresponding to the historical submission record; the metadata includes the submitter, submission time, submission information, and a list of changed files.

[0096] In one embodiment, the identification of the first patch content associated with the potential vulnerability in the historical submission data involved in the execution of the computer program by the processor includes: performing natural language analysis on all metadata to obtain key information related to the vulnerability patch and the corresponding target submission record; obtaining candidate patch content corresponding to the target submission record according to the change file list of the target submission record; and obtaining the first patch content associated with the potential vulnerability from the candidate patch content according to the annotation information of the candidate patch content.

[0097] In one embodiment, the method of obtaining second patch content associated with remaining vulnerabilities from historical submission data when a processor executes a computer program includes: obtaining an abstract syntax tree of the historical submission data through a static code analysis tool, and obtaining a code data flow of the historical submission data based on the abstract syntax tree; performing a difference analysis based on the abstract syntax tree and the code data flow, and obtaining the second patch content associated with the remaining vulnerabilities based on the result of the difference analysis.

[0098] In one embodiment, when a processor executes a computer program, a difference analysis based on an abstract syntax tree and a code data flow is performed, and second patch content associated with the remaining vulnerabilities is obtained based on the result of the difference analysis, including: obtaining public information about the remaining vulnerabilities; the public information includes vulnerability descriptions related to the remaining vulnerabilities; based on the public information, a difference analysis is performed on the abstract syntax tree and the code data flow; in the case where there is a difference inconsistent with the public information and the difference is fixed, potential patch content corresponding to the difference is obtained, and the potential patch content is used as the second patch content associated with the remaining vulnerability.

[0099] In one embodiment, the validity verification of the first patch content and the second patch content involved in the execution of the computer program by the processor includes: performing simulation testing on the first patch content and the second patch content through a symbolic execution tool to verify whether there are unfixed vulnerability paths in the first patch content and the second patch content; performing stress testing on the first patch content and the second patch content through a fuzz testing tool to verify whether there are invalid patches in the first patch content and the second patch content.

[0100] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented: obtaining vulnerability information associated with each component in the software to be verified, and establishing a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information; obtaining historical submission data of the software to be verified, and identifying first patch content associated with the potential vulnerabilities in the historical submission data; the first patch content includes patch content with annotation information; removing the potential vulnerabilities associated with the first patch content from the vulnerability list, and for the remaining vulnerabilities in the vulnerability list, obtaining second patch content associated with the remaining vulnerabilities from the historical submission data; the second patch content includes patch content without annotation information; and verifying the validity of the first patch content and the second patch content.

[0101] In one embodiment, obtaining historical submission data of the software to be verified when the computer program is executed by the processor includes: accessing the code repository of the software to be verified to obtain the historical submission records of the software to be verified; obtaining metadata corresponding to each historical submission record based on the log file corresponding to the historical submission record; the metadata includes the submitter, submission time, submission information and a list of changed files.

[0102] In one embodiment, the computer program executed by the processor involves identifying the first patch content associated with the potential vulnerability in the historical submission data, including: performing natural language analysis on all metadata to obtain key information related to the vulnerability patch and the corresponding target submission record; obtaining candidate patch content corresponding to the target submission record according to the change file list of the target submission record; and obtaining the first patch content associated with the potential vulnerability from the candidate patch content according to the annotation information of the candidate patch content.

[0103] In one embodiment, when a computer program is executed by a processor, obtaining second patch content associated with remaining vulnerabilities from historical submission data involves: obtaining an abstract syntax tree of the historical submission data through a static code analysis tool, and obtaining a code data flow of the historical submission data based on the abstract syntax tree; performing a difference analysis based on the abstract syntax tree and the code data flow, and obtaining the second patch content associated with the remaining vulnerabilities based on the results of the difference analysis.

[0104] In one embodiment, when a computer program is executed by a processor, a difference analysis based on an abstract syntax tree and a code data flow is performed, and second patch content associated with the remaining vulnerabilities is obtained based on the results of the difference analysis, including: obtaining public information about the remaining vulnerabilities; the public information includes vulnerability descriptions related to the remaining vulnerabilities; based on the public information, a difference analysis is performed on the abstract syntax tree and the code data flow; in the case where there is a difference inconsistent with the public information and the difference is fixed, potential patch content corresponding to the difference is obtained, and the potential patch content is used as the second patch content associated with the remaining vulnerability.

[0105] In one embodiment, the validity verification of the first patch content and the second patch content involved when the computer program is executed by the processor includes: performing simulation testing on the first patch content and the second patch content through a symbolic execution tool to verify whether there are unfixed vulnerability paths in the first patch content and the second patch content; performing stress testing on the first patch content and the second patch content through a fuzz testing tool to verify whether there are invalid patches in the first patch content and the second patch content.

[0106] In one embodiment, a computer program product is provided, including a computer program, which implements the following steps when executed by a processor: obtaining vulnerability information associated with each component in the software to be verified, and establishing a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information; obtaining historical submission data of the software to be verified, and identifying first patch content associated with the potential vulnerabilities in the historical submission data; the first patch content includes patch content with annotation information; removing the potential vulnerabilities associated with the first patch content from the vulnerability list, and for the remaining vulnerabilities in the vulnerability list, obtaining second patch content associated with the remaining vulnerabilities from the historical submission data; the second patch content includes patch content without annotation information; and verifying the validity of the first patch content and the second patch content.

[0107] In one embodiment, obtaining historical submission data of the software to be verified when the computer program is executed by the processor includes: accessing the code repository of the software to be verified to obtain the historical submission records of the software to be verified; obtaining metadata corresponding to each historical submission record based on the log file corresponding to the historical submission record; the metadata includes the submitter, submission time, submission information and a list of changed files.

[0108] In one embodiment, the computer program executed by the processor involves identifying the first patch content associated with the potential vulnerability in the historical submission data, including: performing natural language analysis on all metadata to obtain key information related to the vulnerability patch and the corresponding target submission record; obtaining candidate patch content corresponding to the target submission record according to the change file list of the target submission record; and obtaining the first patch content associated with the potential vulnerability from the candidate patch content according to the annotation information of the candidate patch content.

[0109] In one embodiment, when a computer program is executed by a processor, obtaining second patch content associated with remaining vulnerabilities from historical submission data involves: obtaining an abstract syntax tree of the historical submission data through a static code analysis tool, and obtaining a code data flow of the historical submission data based on the abstract syntax tree; performing a difference analysis based on the abstract syntax tree and the code data flow, and obtaining the second patch content associated with the remaining vulnerabilities based on the results of the difference analysis.

[0110] In one embodiment, when a computer program is executed by a processor, a difference analysis based on an abstract syntax tree and a code data flow is performed, and second patch content associated with the remaining vulnerabilities is obtained based on the results of the difference analysis, including: obtaining public information about the remaining vulnerabilities; the public information includes vulnerability descriptions related to the remaining vulnerabilities; based on the public information, a difference analysis is performed on the abstract syntax tree and the code data flow; in the case where there is a difference inconsistent with the public information and the difference is fixed, potential patch content corresponding to the difference is obtained, and the potential patch content is used as the second patch content associated with the remaining vulnerability.

[0111] In one embodiment, the validity verification of the first patch content and the second patch content involved when the computer program is executed by the processor includes: performing simulation testing on the first patch content and the second patch content through a symbolic execution tool to verify whether there are unfixed vulnerability paths in the first patch content and the second patch content; performing stress testing on the first patch content and the second patch content through a fuzz testing tool to verify whether there are invalid patches in the first patch content and the second patch content.

[0112] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0113] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0114] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be construed as limiting the scope of the present application. It should be noted that, for a person of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A vulnerability patch verification method, characterized in that: The method comprises: Acquire vulnerability information associated with each component in the software to be verified, and establish a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information; Acquire historical submission data of the software to be verified, and identify first patch content associated with the potential vulnerability in the historical submission data; the first patch content includes patch content with annotation information; removing the potential vulnerability associated with the first patch content from the vulnerability list, and acquiring, for the remaining vulnerabilities in the vulnerability list, second patch content associated with the remaining vulnerabilities from the historical submission data; the second patch content includes patch content without annotation information; The validity of the first patch content and the second patch content is verified.

2. The method according to claim 1, characterized in that The obtaining of historical submission data of the software to be verified includes: Access the code repository of the software to be verified to obtain the historical submission record of the software to be verified; According to the log file corresponding to the historical submission record, metadata corresponding to each historical submission record is obtained; the metadata includes the submitter, submission time, submission information and a list of changed files.

3. The method according to claim 2, characterized in that The identifying the first patch content associated with the potential vulnerability in the historical submission data includes: Perform natural language analysis on all metadata to obtain key information related to vulnerability patching and corresponding target submission records; According to the list of changed files of the target submission record, obtaining candidate patch content corresponding to the target submission record; According to the annotation information of the candidate patch content, first patch content associated with the potential vulnerability is obtained from the candidate patch content.

4. The method according to claim 1, characterized in that The acquiring, from the historical submission data, second patch content associated with the remaining vulnerability comprises: Obtaining an abstract syntax tree of the historical submission data through a static code analysis tool, and obtaining a code data flow of the historical submission data according to the abstract syntax tree; A difference analysis is performed based on the abstract syntax tree and the code data flow, and second patch content associated with the remaining vulnerability is obtained according to a result of the difference analysis.

5. The method according to claim 4, characterized in that The performing difference analysis based on the abstract syntax tree and the code data flow, and acquiring second patch content associated with the remaining vulnerability according to the result of the difference analysis, includes: Obtaining public information related to the remaining vulnerabilities; the public information includes vulnerability descriptions related to the remaining vulnerabilities; Based on the public information, performing difference analysis on the abstract syntax tree and the code data flow; In the case where there is a difference inconsistent with the public information and the difference is repaired, a potential patch content corresponding to the difference is obtained, and the potential patch content is used as a second patch content associated with the remaining vulnerability.

6. The method according to claim 1, characterized in that The verifying the validity of the first patch content and the second patch content includes: Performing simulation tests on the first patch content and the second patch content by using a symbolic execution tool to verify whether there are unpatched vulnerability paths in the first patch content and the second patch content; The first patch content and the second patch content are stress tested by a fuzz testing tool to verify whether there are invalid patches in the first patch content and the second patch content.

7. A vulnerability patch verification device, characterized in that: The device comprises: A vulnerability information acquisition module, used to acquire vulnerability information associated with each component in the software to be verified, and to establish a vulnerability list based on the vulnerability information; the vulnerability information is used to characterize potential vulnerabilities corresponding to the version information of each component, and the vulnerability list includes all potential vulnerabilities corresponding to the vulnerability information; A first patch acquisition module, used to acquire historical submission data of the software to be verified, and identify first patch content associated with the potential vulnerability in the historical submission data; the first patch content includes patch content with annotation information; A second patch acquisition module is used to remove the potential vulnerability associated with the first patch content from the vulnerability list, and for the remaining vulnerabilities in the vulnerability list, acquire second patch content associated with the remaining vulnerabilities from the historical submission data; the second patch content includes patch content without annotation information; A validity verification module is used to verify the validity of the first patch content and the second patch content.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images