Vulnerability detection method and related equipment

Abstract

The invention provides a vulnerability detection method which comprises the steps that a target branch of a target API in a detected code is obtained, a test case of the target API is generated according to proof information of the vulnerability API, the test case of the target API is used for testing whether the target API has vulnerabilities, an original seed used for conducting fuzzy testing on the target branch of the target API is determined, and the original seed is used for conducting fuzzy testing on the target branch of the target API. The method comprises the following steps: inputting an original seed into a test case of a target API, testing a target branch by inputting the test case of the original seed, screening the seed according to a test result, carrying out variation on the screened seed, inputting the test case of the target API, and carrying out a next round of test on the target branch by inputting the test case of the varied seed. And detecting the vulnerability in the detected code. According to the method, saturation fuzz testing is carried out on the specific branch (namely the target branch) of the specific API in the detected code, the purpose of rapidly triggering the vulnerability can be achieved, efficient fuzz testing for the vulnerability mining scene is achieved, and the vulnerability mining efficiency is improved.

Description

[0001] This application claims the priority of the Chinese patent application filed with the State Intellectual Property Office of China on June 28, 2023, with application number 202310777426.7 and invention name “A Vulnerability Detection Method and Related Equipment”, the entire contents of which are incorporated by reference in this application. Technical Field

[0002] The present application relates to the field of software testing technology, and in particular to a vulnerability detection method, system, computing device cluster, computer-readable storage medium, and computer program product. Background Art

[0003] In the field of software testing, vulnerabilities are also called vulnerabilities, which refer to defects in computer system security that threaten the confidentiality, integrity, availability, access control, etc. of the system or its application data. Vulnerability mining is of great significance to software security, software quality, and software innovation. It can help discover and fix vulnerabilities, prevent potential attacks, improve software quality, and promote security innovation and research. Through vulnerability mining, a more secure and trusted software ecosystem can be established.

[0004] Automated vulnerability mining tools or technologies accelerate the vulnerability discovery process and improve the efficiency and accuracy of vulnerability mining. A typical automated vulnerability mining tool is a fuzz testing tool. Fuzz testing tools input a large amount of random or semi-random data into the target application to find potential vulnerabilities. Fuzz testing tools can use various technologies, such as mutation generation, symbolic execution, and pattern recognition, to improve the coverage of test cases.

[0005] However, the above-mentioned fuzz testing tools usually aim to improve coverage, and it is difficult to make any achievements in vulnerability mining. The vulnerability mining efficiency is low and it is difficult to meet business needs. Summary of the invention

[0006] The present application provides a vulnerability detection method, which performs saturated fuzz testing on a specific branch (i.e., target branch) of a specific application programming interface (API) in the code under test, so as to achieve the goal of quickly triggering vulnerabilities, realize efficient fuzz testing for vulnerability mining scenarios, and improve vulnerability mining efficiency. The present application also provides a vulnerability detection system, a computing device cluster, a computer-readable storage medium, and a computer program product corresponding to the above-mentioned vulnerability detection method.

[0007] In a first aspect, the present application provides a vulnerability detection method. The method can be performed by a vulnerability detection system. The vulnerability detection system can be a software system. The software system can be an independent software system, which is provided to users (such as developers) in the form of a complete vulnerability detection platform. Alternatively, the software system can also be integrated into other software systems in the form of a software development kit (Software Development Kit, SDK), a plug-in, or a functional module, providing an interface for calling. The above-mentioned software system can be deployed in a computing device cluster, and the computing device cluster executes the program code of the software system, thereby executing the vulnerability detection method of the present application. In some possible implementations, the vulnerability detection system can also be a hardware system, and the hardware system can be a computing device cluster with a vulnerability detection function. When the hardware system is running, the vulnerability detection method of the present application is executed.

[0008] Specifically, the vulnerability detection system obtains the target branch of the target API in the inspected code, where the target branch is at least one branch in the target API, and then generates a test case for the target API based on the proof information of the vulnerable API, the test case of the target API is used to test whether the target API has a vulnerability, and determines the original seed for fuzz testing the target branch of the target API, and then inputs the original seed into the test case of the target API, tests the target branch by inputting the test case of the original seed, screens the seeds based on the test results, mutates the screened seeds and inputs them into the test case of the target API, and performs the next round of testing on the target branch by inputting the test case of the mutated seed to detect vulnerabilities in the inspected code.

[0009] In this method, the target API and target branch are the APIs and branches in the tested code that have a higher probability of generating vulnerabilities. By performing saturation fuzz testing on the specific branch of the specific API (i.e., the target branch), the goal of quickly triggering the vulnerability can be achieved, and efficient fuzz testing for vulnerability mining scenarios can be implemented, thereby improving vulnerability mining efficiency.

[0010] In some possible implementations, when a vulnerability is triggered during the testing of a target branch by inputting a test case of the original seed or the mutated seed, the vulnerability detection system can also save vulnerability information, which includes at least one of the vulnerability type, vulnerability path, or test case that triggered the vulnerability.

[0011] The method saves vulnerability information to facilitate timely early warning and verification based on the vulnerability information. In addition, subsequent vulnerability mining can also be performed based on the vulnerability information of the mined vulnerability.

[0012] In some possible implementations, when no vulnerability is triggered during the testing of the target branch by inputting the test case of the original seed or the mutated seed, the vulnerability mining system can also perform coverage-based fuzz testing on the target API.

[0013] In this method, coverage-based fuzz testing can serve as a supplement to branch fuzz testing. When branch fuzz testing does not trigger a vulnerability, each branch of the target API is tested through coverage-based fuzz testing to uncover as many vulnerabilities as possible.

[0014] In some possible implementations, the condition of the target branch is that the target variable falls into the target value set, and the original seed and the mutated seed cover the target value set. For example, the target value set can be an interval [1000, 2000], the original seed can be 1000, 1100, 1200, 1300...2000], and the seeds after a round of mutation can include [1501, 1551, 1601...1951, 1999].

[0015] By inputting the test cases of the original seed and the mutated seed to test the target branch, a saturation fuzz test on the target branch can be implemented, which can quickly reach the vulnerability and improve the efficiency of vulnerability mining.

[0016] In some possible implementations, the vulnerability detection system can perform constraint solving based on the test cases of the target API and the paths of the test cases to obtain the original seed. The vulnerability detection system can also match the target data in the proof information of the vulnerability API with a corpus or a dictionary to obtain the original seed, where the original seed is the original data in the corpus or the dictionary that matches the target data. In actual applications, the vulnerability detection system can also obtain part of the original seed in different ways and mix the original seeds obtained in different ways.

[0017] This method supports obtaining original seeds in different ways. On the one hand, it can enrich the original seeds and improve diversity. On the other hand, it can improve usability and can be applied to different scenarios.

[0018] In some possible implementations, the vulnerability detection system may match at least one API in the inspected code with the vulnerability API to determine the target API. The similarity between the target API and the vulnerability API satisfies a first set condition. Then the vulnerability detection system may match at least one branch in the target API with the branch that triggers the vulnerability in the vulnerability API to determine the target branch. The target branch and the branch that triggers the vulnerability in the vulnerability API meet a second set condition. The above set conditions (such as the first set condition, the second set condition) may be that the similarity is greater than a threshold (such as the first threshold, the second threshold) or the similarity is maximum.

[0019] This method determines the target API whose similarity with the vulnerability API meets the set conditions based on the similarity of APIs and branches, and determines the branches whose similarity with the branches that trigger the vulnerability meet the set conditions from the branch paths of the target API, thereby determining the path that is most likely to trigger the vulnerability and improving the efficiency of vulnerability mining.

[0020] In some possible implementations, the vulnerability detection system may also present to the user at least one API in the inspected code that satisfies a first set condition with the vulnerable API, and then, in response to the user's selection operation, determine the API selected by the user from the at least one API as the target API.

[0021] In this way, saturation fuzz testing can be performed on similar APIs that users are interested in (for example, similar APIs that users have determined based on their experience to have a high probability of triggering vulnerabilities), further improving the efficiency of vulnerability mining.

[0022] In some possible implementations, the inspected code includes incremental code, code in the user's code repository, or code in the code platform. For example, vulnerability detection is integrated into the vulnerability warning platform, and the inspected code can be the full code in the code platform. Accordingly, the vulnerability detection system can analyze the full code to implement vulnerability detection. For another example, the vulnerability detection system is integrated into the code inspection platform, and the inspected code can be the code in the user's code repository. The vulnerability detection system can analyze the code in the user's code repository to implement vulnerability detection. For another example, the vulnerability detection system can be integrated into the code hosting platform to analyze the incremental code when submitting a code merge request to implement vulnerability detection. In this way, the vulnerability detection needs of different scenarios can be met, and vulnerability mining can be implemented on demand.

[0023] In a second aspect, the present application provides a vulnerability detection system. The system comprises:

[0024] A similarity analysis subsystem, used to obtain a target branch of a target application programming interface API in the inspected code, wherein the target branch is at least one branch in the target API;

[0025] A fuzz testing subsystem is used to generate a test case for the target API based on the proof information of the vulnerable API, the test case for the target API is used to test whether the target API has a vulnerability, determine an original seed for fuzz testing a target branch of the target API, input the original seed into the test case for the target API, test the target branch by inputting the test case for the original seed, screen seeds based on the test results, mutate the screened seeds and input them into the test case for the target API, and perform the next round of testing on the target branch by inputting the test case for the mutated seed to detect vulnerabilities in the tested code.

[0026] In some possible implementations, the fuzz testing subsystem is further used to:

[0027] When a vulnerability is triggered during the test of the target branch by inputting a test case of the original seed or the mutated seed, vulnerability information is saved, and the vulnerability information includes at least one of a vulnerability type, a vulnerability path, or a test case that triggers the vulnerability.

[0028] In some possible implementations, the fuzz testing subsystem is further used to:

[0029] When no vulnerability is triggered during the test of the target branch by inputting the test case of the original seed or the mutated seed, a coverage-based fuzz test is performed on the target API.

[0030] In some possible implementations, the condition of the target branch is that the target variable falls into a target value set, and the original seed and the mutated seed cover the target value set.

[0031] In some possible implementations, the fuzz testing subsystem is specifically used to:

[0032] performing constraint solving according to the test case of the target API and the path of the test case to obtain an original seed; and / or,

[0033] The target data in the proof information of the vulnerability API is matched with a corpus or a dictionary to obtain an original seed, where the original seed is the original data in the corpus or the dictionary that matches the target data.

[0034] In some possible implementations, the similarity analysis subsystem is specifically used to:

[0035] Matching at least one API in the inspected code with the vulnerable API to determine a target API, wherein the similarity between the target API and the vulnerable API satisfies a first set condition;

[0036] At least one branch in the target API is matched with a branch in the vulnerability API that triggers a vulnerability to determine a target branch, where the target branch and the branch in the vulnerability API that triggers a vulnerability meet a second set condition.

[0037] In some possible implementations, the similarity analysis subsystem is specifically used to:

[0038] Presenting to the user at least one API in the inspected code that satisfies a first set condition with the vulnerable API;

[0039] In response to the selection operation of the user, an API selected by the user from the at least one API is determined as a target API.

[0040] In some possible implementations, the inspected code includes incremental code, code in a user's code repository, or code in a code platform.

[0041] In a third aspect, the present application provides a computing device cluster. The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is used to execute instructions stored in the at least one memory, so that the computing device or the computing device cluster performs the vulnerability detection method as described in the first aspect or any implementation of the first aspect.

[0042] In a fourth aspect, the present application provides a computer-readable storage medium, in which instructions are stored, and the instructions instruct a computing device or a computing device cluster to execute the vulnerability detection method described in the above-mentioned first aspect or any implementation of the first aspect.

[0043] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computing device or a computing device cluster, enables the computing device or the computing device cluster to execute the vulnerability detection method described in the first aspect or any one of the implementations of the first aspect.

[0044] Based on the implementations provided in the above aspects, the present application can also be further combined to provide more implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical method of the embodiments of the present application, the drawings required for use in the embodiments are briefly introduced below.

[0046] Figure 1 A schematic diagram of the architecture of a vulnerability detection system provided in an embodiment of the present application;

[0047] Figure 2 A schematic diagram of a fuzzy test subsystem for performing fuzzy testing provided in an embodiment of the present application;

[0048] Figure 3 A schematic diagram of a similarity analysis subsystem for performing similarity analysis provided in an embodiment of the present application;

[0049] Figure 4 A flowchart of a vulnerability detection method provided in an embodiment of the present application;

[0050] Figure 5 A schematic diagram of an application scenario of a vulnerability detection method provided in an embodiment of the present application;

[0051] Figure 6 A schematic diagram of an application scenario of a vulnerability detection method provided in an embodiment of the present application;

[0052] Figure 7 A schematic diagram of an application scenario of a vulnerability detection method provided in an embodiment of the present application;

[0053] Figure 8 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0054] Fig. 9 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0055] Fig.10 A schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application;

[0056] Fig.11 A schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0057] The terms "first" and "second" in the embodiments of the present application are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features.

[0058] First, some technical terms involved in the embodiments of the present application are introduced.

[0059] Vulnerability mining refers to the process of analyzing security vulnerabilities in software, computer systems or networks that deploy software to discover and exploit these vulnerabilities. Vulnerability mining techniques may include but are not limited to static code analysis techniques, dynamic vulnerability mining techniques, fuzz testing (fuzzing) or vulnerability mining techniques based on artificial intelligence (AI).

[0060] Static code analysis technology can automatically scan source code to identify potential security vulnerabilities and code defects. Static code analysis technology can detect common vulnerability types, such as buffer overflows, input validation issues, and authorization issues, and provide accurate vulnerability reports to assist developers in fixing vulnerabilities.

[0061] Dynamic vulnerability mining technology uses runtime monitoring and analysis to discover vulnerabilities. Dynamic vulnerability mining technology tracks and records information during the execution of software (such as applications), such as recording memory status, function calls, and network communications, to detect potential vulnerabilities and abnormal behaviors. Dynamic vulnerability mining technology can help discover memory errors, illegal operations, and security vulnerabilities at runtime.

[0062] Fuzz testing is an automated testing technique that searches for potential vulnerabilities by inputting a large amount of random or semi-random data into the target application. Fuzz testing tools can usually use various techniques, such as mutation generation, symbolic execution, and pattern recognition, to improve the coverage of test cases and the accuracy of vulnerability discovery.

[0063] Vulnerability mining technology based on artificial intelligence includes vulnerability mining based on machine learning. Specifically, vulnerability mining tools based on machine learning can learn vulnerability patterns from a large number of samples and discover new vulnerabilities based on the learned vulnerability patterns. Among them, vulnerability mining tools based on machine learning can automatically analyze source code, execute programs, and detect potential vulnerabilities.

[0064] Among them, fuzz testing is a method of continuous testing that can continuously discover vulnerabilities and is therefore widely used. However, fuzz testing tools in the industry generally perform seed mutation based on the goal of improving coverage. This mutation mode is very suitable for covering all branches of the Application Programming Interface (API), but it is difficult to make any achievements in discovering vulnerabilities, resulting in low vulnerability mining efficiency.

[0065] In view of this, the present application provides a vulnerability detection method. The vulnerability detection method can be executed by a vulnerability detection system. The vulnerability detection system can be a software system. The software system can be an independent software system, which is provided to users (such as developers) in the form of a complete vulnerability detection platform. Alternatively, the software system can also be integrated into other software systems in the form of a software development kit (SDK), a plug-in, or a functional module, providing an interface for calling. For example, the vulnerability detection system can be integrated into a vulnerability warning platform to analyze the full amount of code in the code platform to implement vulnerability detection, or the vulnerability detection system can be integrated into a code inspection platform to analyze the code in the user's code warehouse to implement vulnerability detection, or the vulnerability detection system can be integrated into a code hosting platform to analyze the incremental code when submitting a code merge request to implement vulnerability detection. The above software system can be deployed in a computing device cluster, and the computing device cluster executes the program code of the software system, thereby executing the vulnerability detection method of the present application. In some possible implementations, the vulnerability detection system can also be a hardware system, and the hardware system can be a computing device cluster with a vulnerability detection function. When the hardware system is running, the vulnerability detection method of the present application is executed.

[0066] Specifically, the vulnerability detection system can obtain the target branch of the target API in the inspected code, where the target branch is at least one branch in the target API, and then the vulnerability detection system can generate a test case for the target API based on the proof information of the vulnerability API, such as a proof of concept (POC). Among them, the test case of the target API is used to test whether the target API has a vulnerability. The vulnerability detection system then determines the original seed (or initial seed) used to perform fuzz testing on the target branch of the target API, inputs the original seed into the test case of the target API, tests the target branch by inputting the test case of the original seed, screens the seeds according to the test results, mutates the screened seeds and inputs them into the test case of the target API, and performs the next round of testing on the target branch by inputting the test case of the mutated seed to detect vulnerabilities in the inspected code.

[0067] In this method, the target API and target branch are the APIs and branches in the tested code that have a higher probability of generating vulnerabilities. By performing saturation fuzz testing on the specific branch of the specific API (i.e., the target branch), the goal of quickly triggering the vulnerability can be achieved, and efficient fuzz testing for vulnerability mining scenarios can be implemented, thereby improving vulnerability mining efficiency.

[0068] In order to make the technical solution of the present application clearer and easier to understand, the system architecture of the vulnerability detection system of the present application is first introduced in conjunction with the accompanying drawings.

[0069] See also Figure 1 The schematic diagram of the architecture of a vulnerability detection system is shown, the system 10 includes a fuzzy testing subsystem 100, wherein the fuzzy testing subsystem 100 includes a test case generation module 102, a seed selection module 104 and a fuzzy testing module 106. Each module is introduced below.

[0070] The test case generation module 102 is used to obtain the target API in the inspected code and generate a test case for the target API according to the proof information of the vulnerable API. The target API may be a candidate API that triggers a vulnerability, also known as a suspected vulnerable API. The test case of the target API is used to test whether the target API has a vulnerability.

[0071] The seed selection module 104 is used to obtain the target branch in the target API and determine the original seed (seed) for fuzz testing the target branch of the target API. The API may include one or more operation sequences, and the branch of the API may be an operation sequence of the API. For example, the API includes the operation sequences OP1, OP2, OP3, OP5 and OP1, OP2, OP4, OP6, and a branch of the API may be OP1, OP2, OP3, OP5. The target branch is at least one branch in the target API, and the target branch may be a candidate branch that triggers a vulnerability, also known as a suspected vulnerability branch. Seed is an important part of fuzz testing and can usually be the input of a test case for fuzz testing. Seed selection has a great impact on test efficiency and results. Considering that fuzz testing includes multiple rounds, the seed selection module 104 may first select the original seed, and then perform the next round of screening based on the test results. The original seed is the first (first batch) input of the test case. In some possible implementations, the condition for entering the target branch in the API is that the target variable falls into the target value set, and the original seed may be a set of value sequences in the target value set. For example, the target value set may be [2000, 3000], and the original seed may be {2000, 2100, 2200, 2300, 2400, 2500, 2600, 2700, 2800, 2900, 3000}.

[0072] The fuzz testing module 106 is used to input the original seed into the test case of the target API, and test the target branch by inputting the test case of the original seed. The fuzz testing module 106 can obtain the test result. The test result can include the processing result (including the intermediate result) of each node (such as each operation in the operation sequence) of the target branch.

[0073] The seed selection module 104 is also used to filter seeds according to the test results. Specifically, the seed selection module 104 can filter seeds with consistent test results and retain the remaining seeds. For example, if the test results of 2000, 2100, and 2200 in the original seeds are consistent (for example, the processing results of each node are consistent), it means that when the target variable takes the value of [2000, 2200], there is a high probability that the vulnerability will not be triggered. Therefore, the seed selection module 104 can filter the seeds with consistent test results and retain the remaining seeds. Furthermore, the seed selection module 104 can also mutate the screened seeds.

[0074] The fuzz testing module 106 is also used to input the mutated seed into the test case of the target API, and perform the next round of testing on the target branch by inputting the test case of the mutated seed to detect vulnerabilities in the tested code. Among them, the fuzz testing module 106 can perform a saturation fuzz test on the target branch. Specifically, the condition of the target branch is that the target variable falls into the target value set, then the original seed and the mutated seed can cover the target value set to achieve a saturation fuzz test. The fuzz testing module 106 performs multiple rounds of testing based on the above-mentioned original seed and mutated seed, thereby achieving a saturated fuzz test for all scenarios in the target branch.

[0075] Furthermore, the fuzz testing module 106 is also used to trigger a vulnerability during the test of the target branch by inputting a test case of the original seed or the mutated seed, and save vulnerability information. The vulnerability information may include at least one of a vulnerability type, a vulnerability path, or a test case that triggers the vulnerability. It should be noted that the vulnerability path may be a path that triggers the vulnerability.

[0076] The above mainly illustrates fuzz testing of specific branches, and the present application also supports coverage-based fuzz testing. In some possible implementations, the fuzz testing module 106 is also used to: when no vulnerability is triggered during the test of the target branch by inputting the test case of the original seed or the mutated seed, perform coverage-based fuzz testing on the target API.

[0077] It should be noted that another key point of the present application to achieve efficient vulnerability mining is the determination of the target API and the target branch. The vulnerability detection system 10 can determine the target API and the target branch in the inspected code through similarity analysis. In some possible implementations, the vulnerability detection system 10 can also include a similarity analysis subsystem 200.

[0078] The similarity analysis subsystem 200 is used to match at least one API in the inspected code with the vulnerability API to determine the target API. The similarity between the target API and the vulnerability API satisfies a first set condition. The first set condition may be that the similarity is greater than a first threshold or that the similarity is maximum. The similarity analysis subsystem 200 is also used to match at least one branch in the target API with a branch in the vulnerability API that triggers the vulnerability to determine the target branch. The target branch and the branch in the vulnerability API that triggers the vulnerability meet a second set condition. Similar to the first set condition, the second set condition may be that the similarity is greater than a second threshold or that the similarity is maximum.

[0079] In some possible implementations, the similarity analysis subsystem 200 includes a matching module 202 and an interaction module 204. The matching module 202 is used to match at least one API in the inspected code with the vulnerability API, and determine at least one API in the inspected code that satisfies the first set condition with the vulnerability API, and the interaction module 204 is used to present at least one API in the inspected code that satisfies the first set condition with the vulnerability API to the user, and in response to the user's selection operation, determine the API selected by the user from the at least one API as the target API. Similarly, the matching module 202 is also used to match at least one branch in the target API with the branch that triggers the vulnerability in the vulnerability API, and determine the branch in at least one branch of the target API that satisfies the second set condition with the branch that triggers the vulnerability in the vulnerability API. The interaction module 204 is used to present at least one branch in the target API that satisfies the second set condition with the branch that triggers the vulnerability in the vulnerability API to the user, and in response to the user's selection operation, determine the branch selected by the user from the at least one branch as the target branch.

[0080] It should be noted that the vulnerability API and vulnerability branch can come from the vulnerability information released by the open source community or from the vulnerability database. In some possible implementations, the vulnerability detection system 10 may also include a collection subsystem 300. The collection subsystem 300 is used to collect vulnerability information of historical vulnerabilities, and the vulnerability information includes vulnerability types and vulnerability paths. For example, the collection subsystem 300 can regularly capture vulnerability information released by open source communities such as Common Vulnerabilities and Exposures (CVE). CVE is a database related to information security, which collects various information security weaknesses and vulnerabilities and gives them numbers for public reference. Based on this, the collection subsystem 300 is also called CVE collector. The collection subsystem 300 can store the captured vulnerability information in the database for use. Further, the vulnerability detection system 10 may also include a filtering subsystem 400, which is used to filter vulnerabilities that do not meet the requirements and retain vulnerabilities that meet the requirements for subsequent vulnerability detection. For example, the filtering subsystem 400 can filter out kernel-type vulnerabilities and front-end page vulnerabilities.

[0081] Next, the fuzzy testing subsystem 100 and the similarity analysis subsystem 200 of the present application are introduced in detail in conjunction with the accompanying drawings.

[0082] See also Figure 2 A schematic diagram of a fuzzy testing subsystem 100 for performing fuzzy testing is shown in FIG. Figure 2 As shown, the fuzz testing subsystem 100 includes a test case generation module 102, a seed selection module 104 (also called a seed picker), and a fuzz testing module 106. The fuzz testing module 106 may include a branch fuzz testing submodule 1062 (also called a branch fuzzer), and further, the fuzz testing module 106 may also include a coverage fuzz testing submodule 1064 (also called a coverage fuzzer).

[0083] The test case generation module 102 supports inputting a specific code snippet, such as a POC. For the specific code snippet, the test case generation module 102 can generate a test case for testing whether the target API has a vulnerability, that is, a test case for the target API. This can reduce the manual access cost.

[0084] The seed selection module 104 is used to assist the vulnerability detection system 10 (or fuzz platform) to find the original seed close to the vulnerability point. The selection method of the original seed may include one or more of the following:

[0085] In a first possible implementation, the seed selection module 104 performs constraint solving based on the test case of the target API and the path of the test case to obtain the original seed, wherein the path of the test case may be a candidate path of the vulnerability of the target API triggered by the test case, also called a suspected path.

[0086] The constraint problem can be formally expressed as a triple in the form of P =<V,D,C> . Among them, V is a set of variables, which can be expressed as {v1, v2, ..., vn}; D is a set of variable ranges, that is, the value range of each variable, that is, the variable vi needs to take values ​​within its value range di; C is a set of constraints, each constraint contains one or more variables, if ci contains k variables, then the constraint is called a k-ary constraint on the set of k variables. Constraint solving is based on a series of constraint problems to find a solution that satisfies all constraints and is within its own value range. Among them, the seed selection module 104 can determine the constraint conditions based on semantic constraints, and then construct a constraint problem, and solve the above constraint problem through a solver.

[0087] In a second possible implementation, the seed selection module 104 matches the target data in the proof information of the vulnerability API with the corpus or dictionary to obtain the original seed. The original seed is the original data in the corpus or dictionary that matches the target data. The proof information of the vulnerability API may be a POC, and the target data may be a value or a set of values ​​of a variable in the POC.

[0088] In specific implementation, the seed selection module 104 may obtain a portion of the original seeds respectively through the above-mentioned multiple implementation methods, and then mix the original seeds obtained by different implementation methods as the final original seeds.

[0089] The fuzz testing module 106 is used to input the original seed into the test case of the target API, and test the target branch by inputting the test case of the original seed. After the seeds are screened out according to the test results, the screened seeds can be mutated and input into the test case of the target API, and the target branch can be tested in the next round by inputting the test case of the mutated seeds to detect vulnerabilities in the tested code.

[0090] Among them, the branch fuzz test submodule 1062 can be a Branch Fuzzer that takes a specific branch path as a benchmark and uses comprehensive coverage of input parameters as the target of genetic algorithm traction. After the Seed Picker determines the original seed, the Branch Fuzzer inputs all the original seeds into the code snippet of the test case, uses the test case after inputting the original seed to test the target branch, and monitors all nodes of the target branch of the target API to obtain the processing results of each node as the test result. Seed Picker removes the original seeds with consistent processing results, and mutates the retained seeds for the next round of fuzz testing. Finally, a saturated fuzz test is achieved for all scenarios in the branch. Compared with the original Fuzzer, the efficiency of Branch Fuzzer has been greatly improved in the dimension of vulnerability detection.

[0091] The coverage fuzz test submodule 1064 (i.e., coverage fuzzer) can be used as a supplement to Branch Fuzzer to perform coverage-based fuzz testing on the target API when no vulnerability is triggered during the test process of the target branch by inputting the test case of the original seed or the mutated seed. The coverage fuzz test submodule 1064 is less efficient than Branch Fuzzer, but has a greater coverage rate, and over time, the seed can be gradually mutated to trigger the vulnerability.

[0092] See also Figure 3 A schematic diagram of a similarity analysis subsystem 200 for performing similarity analysis is shown in FIG. Figure 3 As shown, the similarity analysis subsystem 200 includes a matching module 202, which can perform similarity matching based on the control flow graph and vector representation (e.g., embedding) of the API to determine the target API and target branch. Based on this, the similarity analysis subsystem 200 can also include a parser 206 and a deep learning model 208.

[0093] The parser 206 may be an abstract syntax tree (AST) parser. AST parsers include but are not limited to JDT, CDT, etc. The parser 206 parses the code (e.g., the API code) into a control flow graph. Furthermore, the parser 206 may store the control flow graph in a database.

[0094] The deep learning model 208 includes a large number of large language models (LLM) in the industry. The deep learning model 208 can use the input API as a natural language, parse the meaning of the natural language expression, and convert it into embedding and store it in the database.

[0095] The matching module 202 includes a natural language model (eg, a large number of natural language models) and a similarity matching algorithm (eg, a large number of similarity matching algorithms). The similarity matching algorithm can compare a code segment with a parsed code segment in a database to find the API with the highest similarity.

[0096] The similarity analysis subsystem 200 can first obtain a large amount of original code from code platforms such as open source platforms and endogenous platforms, and parse it into a large amount of control flow graphs and vector representations through AST Parser and DL Model with API and API call chain as granularity, and store it in the knowledge base Knowledge. Next, the similarity analysis subsystem 200 can regularly obtain software vulnerability data from open source community channels such as CVE, and obtain vulnerability code snippets and call chains and POCs that trigger the vulnerability from the vulnerability data. Send the vulnerability code snippets, call chains and POCs into AST Parser and DL Model, and you can get the control flow graph of the vulnerability API and the branch that triggers the vulnerability in the control flow. In the matching module 202, the vulnerability API can be matched with the massive APIs stored in the database to determine the target API. Among them, the similarity between the target API and the vulnerability API meets the first set condition. The first set condition can be the maximum similarity, the top n similarity ranking, or the similarity is greater than a set threshold (for example, the first threshold).

[0097] Furthermore, in the matching module 202, the branch that triggers the vulnerability in the vulnerability API and at least one branch in the target API can be matched to determine the target branch. The target branch and the branch that triggers the vulnerability in the vulnerability API meet the second set condition. Similarly, the second set condition can be the maximum similarity, the top n similarity ranking, or the similarity greater than a set threshold (for example, the second threshold).

[0098] It should be noted that, in the process of determining similar APIs (such as APIs whose similarity meets the set conditions, including but not limited to the APIs with the greatest similarity and the APIs similar to the first threshold), the matching module 202 can also adapt the data in the POC and the original POC to the new interface (API) based on the static API migration technology, and inject the data of the original POC into the new POC (such as Figure 3 In the POC new) shown in , the effect of enhancing similar APIs and similar paths is achieved.

[0099] Furthermore, the similarity analysis subsystem 200 also includes an interaction module 204. When the matching module 202 determines a similar API, the interaction module 204 presents a similar API to the user, such as at least one API in the database that satisfies a first set condition with the vulnerability API, and in response to the user's selection operation, the API selected by the user from the at least one API is determined as the target API. Similarly, the interaction module 204 can also present similar branches to the user, such as at least one branch in the target API that satisfies a second set condition with the branch that triggers the vulnerability in the vulnerability API, and in response to the user's selection operation, the branch selected by the user from the at least one branch is determined as the target branch. In this way, manual intervention in vulnerability detection can be achieved, thereby improving the efficiency of vulnerability detection.

[0100] Different from similarity detection methods based on lexical, grammatical, and semantics, or similarity detection methods based on hash fingerprints, this application proposes an API-based matching method to determine similar APIs, and based on the path of the data in the POC, find the path that is most likely to trigger the vulnerability, thereby improving the efficiency of subsequent vulnerability detection based on fuzzy testing.

[0101] Based on the aforementioned vulnerability detection system 10, the present application further provides a vulnerability detection method. The vulnerability detection method of the present application is described in detail below in conjunction with an embodiment.

[0102] See also Figure 4 A flowchart of a vulnerability detection method is shown, the method comprising:

[0103] S402: The vulnerability detection system 10 obtains a target branch of a target API in the code under inspection.

[0104] The checked code refers to the code to be tested for vulnerabilities. Depending on the vulnerability detection scenario, the checked code may be different. In some possible implementations, the checked code includes incremental code, code in the user's code repository, or code in the code platform. For example, when the vulnerability detection system 10 is integrated into a vulnerability warning platform for comprehensive vulnerability detection and warning, the checked code may be the full code in the code platform. For another example, when the vulnerability detection system 10 is integrated into a code inspection platform, the checked code may be the code in the user's code repository. When the vulnerability detection system 10 is integrated into a code hosting platform, the checked code may also be the incremental code when a code merge request is submitted.

[0105] The checked code includes at least one API, the target API is an API with a higher probability of triggering a vulnerability in the checked code, and the target branch is a branch path with a higher probability of triggering a vulnerability in the target API. The vulnerability detection system 10 can determine the target API by similarity matching, and determine the target branch in the target API by similarity matching.

[0106] Specifically, the vulnerability detection system 10 can match at least one API in the inspected code with the vulnerability API to determine the target API. The similarity between the target API and the vulnerability API satisfies a first set condition. The first set condition can be the maximum similarity, the top n similarities, or the similarity greater than a set threshold.

[0107] When matching, the vulnerability detection system 10 can match based on at least one of the control flow graph or vector representation of the API. The vulnerability detection system 10 can input the API in the inspected code (in some cases, it can also include API callstack) into the parser to obtain the control flow graph of the API in the inspected code, and input the API in the inspected code (in some cases, it can also include API call stack) into the deep learning model to obtain the vector representation of the API in the inspected code. Furthermore, the vulnerability detection system 10 can store the control flow graph and vector representation of the API in the inspected code in a database, for example, in the form of a knowledge graph (Knowledge Graph) for use in subsequent matching. Similarly, the vulnerability detection system 10 can input the vulnerable API (i.e., the code snippet of the vulnerable API) into the parser to obtain the control flow graph of the vulnerable API, and input the vulnerable API into the deep learning model to obtain the vector representation of the vulnerable API. The vulnerability detection system 10 can calculate the similarity between the control flow graph of the API in the inspected code and the control flow graph of the vulnerable API, or calculate the similarity between the vector representation of the API in the inspected code and the vector representation of the vulnerable API, and determine the similarity between the API in the inspected code and the vulnerable API based on at least one of the similarity of the control flow graph or the similarity of the vector representation.

[0108] Similarly, the vulnerability detection system 10 can match at least one branch in the target API with the branch that triggers the vulnerability in the vulnerability API to determine the target branch. The target branch and the branch that triggers the vulnerability in the vulnerability API meet the second set condition. The second set condition can be the maximum similarity, the top n similarity ranking, or the similarity greater than a set threshold.

[0109] Among them, the vulnerability detection system 10 can determine the similarity between the branch that triggers the vulnerability in the vulnerable API and at least one branch in the target API based on the vector representation of the branch that triggers the vulnerability in the vulnerable API and the similarity of the vector representation of at least one branch in the target API. In some examples, the vulnerability detection system 10 can also determine the similarity between the branch that triggers the vulnerability in the vulnerable API and at least one branch in the target API based on the control flow graph of the vulnerable API and the control flow graph of the target API.

[0110] It should be noted that after determining the API or branch whose similarity meets the set conditions, the vulnerability detection system 10 also supports presenting the API or branch whose similarity meets the set conditions to the user, so that the user can select the API or branch that is of interest or that the user believes has a higher probability of triggering the vulnerability. In specific implementation, the vulnerability detection system 10 can present to the user at least one API in the inspected code that meets the first set condition with the vulnerable API, and in response to the user's selection operation, the API selected by the user from the at least one API is determined as the target API. Similarly, the vulnerability detection system 10 can present to the user at least one branch in the target API that meets the second set condition with the branch that triggers the vulnerability in the vulnerable API, and in response to the user's selection operation, the branch selected by the user from the at least one branch is determined as the target branch.

[0111] S404: The vulnerability detection system 10 generates a test case for the target API according to the certification information of the vulnerable API.

[0112] The test case of the target API is used to test whether the target API has vulnerabilities. The vulnerability detection system 10 can use the proof information of the known vulnerability API, such as POC, to generate the test case of the target API. Among them, the vulnerability detection system 10 can adapt the POC of the known vulnerability API to the target API through an adapter, thereby generating a test case of the target API.

[0113] S406 . The vulnerability detection system 10 determines an original seed for performing fuzz testing on a target branch of a target API.

[0114] In specific implementation, the vulnerability detection system 10 can perform constraint solving based on the test cases of the target API and the paths of the test cases to obtain the original seed. In some examples, the vulnerability detection system 10 can match the target data in the proof information (such as POC) of the vulnerability API with a corpus or dictionary to obtain the original seed. The original seed can be the original data in the corpus or dictionary that matches the target data.

[0115] It should be noted that the vulnerability detection system 10 can obtain part of the seeds in different ways, for example, obtaining part of the seeds by constraint solving, obtaining another part of the seeds by matching the target data in the POC with a corpus or dictionary, and mixing the above seeds to obtain the original seeds for fuzzy testing the target branch of the target API.

[0116] The above S404 and S406 can be executed in parallel or in sequence according to a set order. The embodiment of the present application does not limit the execution order of S404 and S406.

[0117] S408 , the vulnerability detection system 10 inputs the original seed into the test case of the target API, and tests the target branch by inputting the test case of the original seed.

[0118] Specifically, the vulnerability detection system 10 can execute the target branch according to the test case of the target API with the original seed input, monitor each node of the target branch, and thus test the target branch to obtain the test result. The test result may include the processing result of each node (including but not limited to the intermediate result and the final result).

[0119] S410, the vulnerability detection system 10 selects seeds according to the test results.

[0120] For different original seeds, the vulnerability detection system 10 can compare the test results corresponding to the different original seeds. When the test results corresponding to the first original seed and the second original seed are consistent, it indicates that the vulnerability band probability will not be triggered between the first original seed and the second original seed. The vulnerability detection system 10 can filter out the first original seed and the second original seed, and retain the original seed with inconsistent test results. It should be noted that the first original seed and the second original seed can be one or more seeds.

[0121] S412, the vulnerability detection system 10 mutates the screened seeds and inputs them into the test case of the target API, and performs the next round of testing on the target branch by inputting the test case of the mutated seeds to detect vulnerabilities in the inspected code.

[0122] For the remaining seeds, the vulnerability detection system 10 can mutate them for the next round of testing. The vulnerability detection system 10 can compile the remaining seeds (i.e., the screened seeds) according to the mutation method. The mutation method may include but is not limited to inversion, addition and subtraction, insertion, deletion, dictionary, and random order.

[0123] The vulnerability detection system 10 can execute the target branch according to the test case of the target API with the mutated seed, monitor each node of the target branch, and then perform the next round of testing on the target branch to obtain the test result. The vulnerability detection system 10 can implement saturation fuzz testing on the target branch by continuously screening seeds and mutations, and then executing the target branch using the test case of the target API with the mutated seed.

[0124] In some possible implementations, the condition of the target branch can be that the target variable falls into the target value set, then the original seed and the mutated seed can cover the target value set, thereby achieving saturation fuzz testing. Furthermore, when a vulnerability is triggered during the test of the target branch by inputting a test case of the original seed or the mutated seed, the vulnerability detection system 10 can also save vulnerability information. The vulnerability information may include at least one of the vulnerability type, vulnerability path, or test case that triggers the vulnerability. It should be noted that the vulnerability path can be a path that triggers the vulnerability. When the vulnerability is not triggered during the test of the target branch by inputting a test case of the original seed or the mutated seed, the vulnerability detection system 10 can perform coverage-based fuzz testing on the target API to dig out potential vulnerabilities.

[0125] This method can achieve the goal of quickly triggering vulnerabilities by performing saturation fuzz testing on a specific branch of the specific API (i.e., the target branch), realize efficient fuzz testing for vulnerability mining scenarios, and improve vulnerability mining efficiency.

[0126] Next, the vulnerability detection method of this application is introduced in combination with specific application scenarios.

[0127] First, see Figure 5 The following is a schematic diagram of an application scenario of a vulnerability detection method. In this scenario, vulnerability detection is closely related to the vulnerability warning platform and is presented as a downstream capability of the vulnerability warning platform. Figure a represents the vulnerability warning platform. When a new vulnerability is generated, the vulnerability warning platform can monitor the source of vulnerability disclosure, generate vulnerability alerts in real time, and display them in the form of a list on the front-end web page. For vulnerabilities suitable for Fuzzing, the first layer of filtering can be performed to filter out vulnerability types suitable for inspection using Fuzzing technology. A query function for vulnerability details is provided in the vulnerability list, including vulnerability archives, vulnerability repair code details, etc. At the same time, the vulnerability warning platform provides vulnerability detection capabilities, which support queries for similar APIs. Query filter conditions can be set in the drop-down list, such as the number of stars in the open source code, whether there is a fork relationship, etc.

[0128] For a single detailed vulnerability, for the root cause method involved in its code repair, after triggering the API query, a list of similar APIs can be displayed, as shown in Figure b. This page mainly presents a list of similar APIs obtained through semantic representation and query, and presents APIs with similar functions in a unified manner. When a user is interested in a certain API, the Fuzzing capability can be actively triggered to trigger the verification of the API of interest. Finally, if a real new vulnerability can be triggered, it can be displayed on the vulnerability details presentation page, as shown in Figure c, which mainly displays the POC and problem details.

[0129] As can be seen from the above, this embodiment can accelerate the process of vulnerability mining (such as 0-day vulnerabilities) by utilizing a large number of historical and new warning vulnerability code features and fuzzing technology to accelerate the entire process of detection and verification. For example, the API of the disclosed 0-day vulnerability can be generalized to the API of similar functions. Based on the POC of the vulnerability, the corresponding test case can be generated for fuzzing to quickly verify whether the API of the above similar functions has vulnerabilities.

[0130] Then, see Figure 6 The following is a schematic diagram of an application scenario of a vulnerability detection method. In this scenario, vulnerability detection can be integrated into a code inspection platform. Specifically, a user can establish an inspection task for the user's code repository on the code inspection platform, and then characterize the code at the method API level, which is different from Figure 5 The embodiment shown, Figure 6 The illustrated embodiment no longer searches for the similarity between the API of interest and the entire code, but only searches for the similarity between the API in the user's code repository and the historical vulnerability API. If the similarity reaches a set threshold, the Fuzzing process can be automatically triggered. If a vulnerability is triggered during the Fuzzing process, an alarm can be issued on the code inspection platform.

[0131] and Figure 5 Compared with the embodiment shown, there is no need for users to manually filter APIs of interest, and Fuzzing is no longer triggered by users. Instead, the entire process automatically monitors the code in the user's code repository. When querying similar APIs, the entire code repository is no longer queried, but only the historical vulnerability root cause API is queried for similarity comparison. This embodiment can effectively utilize historical vulnerabilities and provide all-weather care for the user's code repository. By utilizing a large number of historical vulnerability code features and Fuzzing technology, it can increase the scenarios that are difficult to cover with static inspections.

[0132] Next, see Figure 7 The schematic diagram of an application scenario of a vulnerability detection method shown in FIG. 1 shows a scenario in which vulnerability detection can be integrated into a code hosting platform. On the code hosting platform, each time a user submits a code merge request, a risk check is required for the merge to avoid problems such as security vulnerabilities and poor readability in the code. When performing a risk check, an incremental check method can be used, specifically, to check incremental code, including vulnerability detection for incremental code.

[0133] and Figure 6Similar to the embodiment shown, the code hosting platform only focuses on similar API queries in historical vulnerabilities. After the user submits a code merge request, a similar API query is performed in the root cause API library involved in the historical vulnerability. If the similarity reaches the set threshold, the Fuzzing process can be automatically triggered. If a vulnerability is triggered during the Fuzzing process, an alarm can be issued in the Issue column of the code hosting platform. If Fuzzing can efficiently detect the result, an alarm can also be issued in the comment area of ​​the current code merge request.

[0134] This embodiment can also effectively utilize historical vulnerabilities, review each code submission by the user, and guard the user's code repository.

[0135] Based on the above embodiments, the vulnerability detection method of the present application can realize automated and efficient fuzz testing in the field of vulnerability mining by saturation fuzz testing of specific branches. Moreover, through the migration of equivalent APIs, suspected vulnerabilities with similar functions can be quickly found and automated verification can be completed. By performing vulnerability detection on user code based on historical vulnerabilities, the security of developer code can be greatly increased and vulnerability risks can be reduced.

[0136] Based on the aforementioned method embodiment, the present application also provides a vulnerability detection system 10, such as Figure 1 As shown, including:

[0137] The similarity analysis subsystem 200 is used to obtain a target branch of a target application programming interface API in the inspected code, wherein the target branch is at least one branch in the target API;

[0138] The fuzz testing subsystem 100 is used to generate a test case for the target API based on the proof information of the vulnerable API, the test case for the target API is used to test whether the target API has a vulnerability, determine an original seed for fuzz testing a target branch of the target API, input the original seed into the test case for the target API, test the target branch by inputting the test case for the original seed, screen seeds based on the test results, mutate the screened seeds and input them into the test case for the target API, perform the next round of testing on the target branch by inputting the test case for the mutated seed, so as to detect vulnerabilities in the tested code.

[0139] Exemplarily, the fuzzy testing subsystem 100 and the similarity analysis subsystem 200 may be implemented by hardware or software.

[0140] When implemented by software, the fuzzy test subsystem 100 and the similarity analysis subsystem 200 may be applications running on a computing device, such as a computing engine. The application may be provided to users in the form of virtualized services. Virtualized services may include virtual machine (VM) services, bare metal server (BMS) services, and container services. Among them, the VM service may be a service that uses virtualization technology to virtualize a virtual machine (VM) resource pool on multiple physical hosts (such as computing devices) to provide users with VMs on demand for use. The BMS service is a service that virtualizes a BMS resource pool on multiple physical hosts to provide users with BMS on demand for use. The container service is a service that virtualizes a container resource pool on multiple physical hosts to provide users with containers on demand for use. VM is a simulated virtual computer, that is, a logical computer. BMS is a high-performance computing service that can be elastically scalable, and its computing performance is no different from that of a traditional physical machine, and it has the characteristics of secure physical isolation. Containers are a kernel virtualization technology that can provide lightweight virtualization to achieve the purpose of isolating user space, processes, and resources. It should be understood that the VM service, BMS service and container service in the above-mentioned virtualization services are merely specific examples. In actual applications, the virtualization service may also be other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0141] When implemented by hardware, the fuzzy test subsystem 100 and the similarity analysis subsystem 200 may include at least one computing device, such as a server, etc. Alternatively, the fuzzy test subsystem 100 and the similarity analysis subsystem 200 may also be implemented by using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0142] Similarly, the test case generation module 102, the seed selection module 104, and the fuzzy testing module 106 in the fuzzy testing subsystem 100, and the matching module 202 and the interaction module 204 in the similarity analysis subsystem 200 can also be implemented by software or by hardware. Among them, the test case generation module 102, the seed selection module 104, the fuzzy testing module 106, the matching module 202, and the interaction module 204 can be applications running on a computing device, such as a VM service or a container service. In some examples, the test case generation module 102, the seed selection module 104, the fuzzy testing module 106, the matching module 202, and the interaction module 204 can be hardware, such as a server.

[0143] In some possible implementations, the fuzz testing subsystem 100 is further used for:

[0144] When a vulnerability is triggered during the test of the target branch by inputting a test case of the original seed or the mutated seed, vulnerability information is saved, and the vulnerability information includes at least one of a vulnerability type, a vulnerability path, or a test case that triggers the vulnerability.

[0145] In some possible implementations, the fuzz testing subsystem 100 is further used for:

[0146] When no vulnerability is triggered during the test of the target branch by inputting the test case of the original seed or the mutated seed, a coverage-based fuzz test is performed on the target API.

[0147] In some possible implementations, the condition of the target branch is that the target variable falls into a target value set, and the original seed and the mutated seed cover the target value set.

[0148] In some possible implementations, the fuzzy testing subsystem 100 is specifically used for:

[0149] performing constraint solving according to the test case of the target API and the path of the test case to obtain an original seed; and / or,

[0150] The target data in the proof information of the vulnerability API is matched with a corpus or a dictionary to obtain an original seed, where the original seed is the original data in the corpus or the dictionary that matches the target data.

[0151] In some possible implementations, the similarity analysis subsystem 200 is specifically used for:

[0152] Matching at least one API in the inspected code with the vulnerable API to determine a target API, wherein the similarity between the target API and the vulnerable API satisfies a first set condition;

[0153] At least one branch in the target API is matched with a branch in the vulnerability API that triggers a vulnerability to determine a target branch, where the target branch and the branch in the vulnerability API that triggers a vulnerability meet a second set condition.

[0154] In some possible implementations, the similarity analysis subsystem 200 is specifically used for:

[0155] Presenting to the user at least one API in the inspected code that satisfies a first set condition with the vulnerable API;

[0156] In response to the selection operation of the user, an API selected by the user from the at least one API is determined as a target API.

[0157] In some possible implementations, the inspected code includes incremental code, code in a user's code repository, or code in a code platform.

[0158] In some possible implementations, the vulnerability detection system 10 may further include a collection subsystem 300 or a filtering subsystem 400. The collection subsystem 300 is used to collect vulnerability information. The filtering subsystem 400 is used to filter out vulnerabilities that do not meet the requirements, for example, filtering out kernel vulnerabilities. In this way, vulnerability mining can be performed based on the vulnerability information of the remaining vulnerabilities.

[0159] The collection subsystem 300 or the filtering subsystem 400 may also be implemented by software or hardware. The collection subsystem 300 or the filtering subsystem 400 may be an application running on a computing device, such as a VM service or a container service. In some examples, the collection subsystem 300 or the filtering subsystem 400 may be hardware, such as a server.

[0160] The above introduces the vulnerability detection system from the perspective of functional modularization. Next, the vulnerability detection system will be introduced from the perspective of hardware entity.

[0161] The present application also provides a computing device 800. The computing device 800 is used to implement part or all of the functions of the vulnerability detection system 10. Figure 8As shown, the computing device 800 includes: a bus 802, a processor 804, a memory 806, and a communication interface 808. The processor 804, the memory 806, and the communication interface 808 communicate through the bus 802. The computing device 800 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 800.

[0162] The bus 802 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 The bus 802 is represented by only one line, but it does not mean that there is only one bus or one type of bus. The bus 802 may include a path for transmitting information between various components of the computing device 800 (eg, the memory 806, the processor 804, and the communication interface 808).

[0163] The processor 804 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0164] The memory 806 may include a volatile memory, such as a random access memory (RAM). The memory 806 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid state drive (SSD). The memory 806 stores executable program code, and the processor 804 executes the executable program code to implement the aforementioned vulnerability detection method. Specifically, the memory 806 stores instructions for the vulnerability detection system 10 to execute the vulnerability detection method.

[0165] The communication interface 808 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 800 and other devices or communication networks.

[0166] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0167] like Fig. 9 As shown, the computing device cluster includes at least one computing device 800. The memory 806 in one or more computing devices 800 in the computing device cluster may store instructions of the same vulnerability detection system for executing the vulnerability detection method.

[0168] In some possible implementations, one or more computing devices 800 in the computing device cluster may also be used to execute some instructions of the vulnerability detection system 10 for executing the vulnerability detection method. In other words, a combination of one or more computing devices 800 may jointly execute instructions of the vulnerability detection system 10 for executing the vulnerability detection method.

[0169] It should be noted that the memory 806 in different computing devices 800 in the computing device cluster can store different instructions for executing partial functions of the vulnerability detection system 10 .

[0170] Fig.10 A possible implementation is shown. Fig.10 As shown, two computing devices 800A and 800B are connected via a communication interface 808. The memory in computing device 800A stores instructions for executing the functions of fuzzy testing subsystem 100. The memory in computing device 800B stores instructions for executing the functions of similarity analysis subsystem 200. Furthermore, the memory of computing device 800B may also store instructions for executing the functions of collection subsystem 300 and filtering subsystem 400. In other words, the memories 806 of computing devices 800A and 800B jointly store instructions for vulnerability detection system 10 to execute the vulnerability detection method.

[0171] Fig.10 The connection mode between the computing device clusters shown may be considered that the vulnerability detection method provided by the present application requires a large amount of computing power to perform similarity analysis to determine the target API and target branch. Therefore, it is considered that the functions implemented by the similarity analysis subsystem 200 are handed over to the computing device 800B for execution.

[0172] It should be understood that Fig.10 The functions of the computing device 800A shown in FIG. 8 may also be completed by multiple computing devices 800. Similarly, the functions of the computing device 800B may also be completed by multiple computing devices 800.

[0173] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.11 A possible implementation is shown. Fig.11 As shown, two computing devices 800C and 800D are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 806 in the computing device 800C stores instructions for executing the functions of the fuzzy testing subsystem 100. At the same time, the memory 806 in the computing device 800D stores instructions for executing the functions of the similarity analysis subsystem 200. Among them, the memory 806 in the computing device 800D can also store instructions for executing the functions of the collection subsystem 300 and the filtering subsystem 400.

[0174] Fig.11 The connection method between the computing device clusters shown can be considered to be that the vulnerability detection method provided in this application requires a lot of computing power for similarity analysis to determine the target API and target branch, so it is considered to hand over the functions implemented by the similarity analysis subsystem 200 to the computing device 800D for execution.

[0175] It should be understood that Fig.11 The functions of the computing device 800C shown in FIG. 800A may also be completed by multiple computing devices 800. Similarly, the functions of the computing device 800D may also be completed by multiple computing devices 800.

[0176] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned vulnerability detection system 10 for executing the vulnerability detection method.

[0177] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be a software or program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the above-mentioned vulnerability detection method.

[0178] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A vulnerability detection method, characterized in that: The method comprises: Obtain a target branch of a target application programming interface API in the inspected code, wherein the target branch is at least one branch in the target API; Generate a test case for the target API according to the proof information of the vulnerable API, where the test case for the target API is used to test whether the target API has a vulnerability; Determining an original seed for fuzz testing a target branch of the target API; The original seed is input into the test case of the target API, the target branch is tested by inputting the test case of the original seed, seeds are screened according to the test results, the screened seeds are mutated and input into the test case of the target API, and the target branch is subjected to the next round of testing by inputting the test case of the mutated seeds to detect vulnerabilities in the tested code.

2. The method according to claim 1, characterized in that The method further comprises: When a vulnerability is triggered during the test of the target branch by inputting a test case of the original seed or the mutated seed, vulnerability information is saved, and the vulnerability information includes at least one of a vulnerability type, a vulnerability path, or a test case that triggers the vulnerability.

3. The method according to claim 1, characterized in that The method further comprises: When no vulnerability is triggered during the test of the target branch by inputting the test case of the original seed or the mutated seed, a coverage-based fuzz test is performed on the target API.

4. The method according to any one of claims 1 to 3, characterized in that: The condition of the target branch is that the target variable falls into the target value set, and the original seed and the mutated seed cover the target value set.

5. The method according to any one of claims 1 to 4, characterized in that: The determining of an original seed for fuzz testing a target branch of the target API comprises: performing constraint solving according to the test case of the target API and the path of the test case to obtain an original seed; and / or, The target data in the proof information of the vulnerability API is matched with a corpus or a dictionary to obtain an original seed, where the original seed is the original data in the corpus or the dictionary that matches the target data.

6. The method according to any one of claims 1 to 5, characterized in that: The step of obtaining a target branch of a target application programming interface API in the inspected code includes: Matching at least one API in the inspected code with the vulnerable API to determine a target API, wherein the similarity between the target API and the vulnerable API satisfies a first set condition; At least one branch in the target API is matched with a branch in the vulnerability API that triggers a vulnerability to determine a target branch, where the target branch and the branch in the vulnerability API that triggers a vulnerability meet a second set condition.

7. The method according to claim 6, characterized in that The step of matching at least one branch in the target API with a branch in the vulnerable API that triggers the vulnerability to determine the target branch includes: Presenting to the user at least one API in the inspected code that satisfies a first set condition with the vulnerable API; In response to the selection operation of the user, an API selected by the user from the at least one API is determined as a target API.

8. The method according to any one of claims 1 to 7, characterized in that: The inspected code includes incremental code, code in a user's code repository, or code in a code platform.

9. A vulnerability detection system, characterized in that: The system comprises: A similarity analysis subsystem, used to obtain a target branch of a target application programming interface API in the inspected code, wherein the target branch is at least one branch in the target API; A fuzz testing subsystem is used to generate a test case for the target API based on the proof information of the vulnerable API, the test case for the target API is used to test whether the target API has a vulnerability, determine an original seed for fuzz testing a target branch of the target API, input the original seed into the test case for the target API, test the target branch by inputting the test case for the original seed, screen seeds based on the test results, mutate the screened seeds and input them into the test case for the target API, and perform the next round of testing on the target branch by inputting the test case for the mutated seed to detect vulnerabilities in the tested code.

10. The system according to claim 9, characterized in that The fuzz testing subsystem is also used to: When a vulnerability is triggered during the test of the target branch by inputting a test case of the original seed or the mutated seed, vulnerability information is saved, and the vulnerability information includes at least one of a vulnerability type, a vulnerability path, or a test case that triggers the vulnerability.

11. The system according to claim 9, characterized in that The fuzz testing subsystem is also used to: When no vulnerability is triggered during the test of the target branch by inputting the test case of the original seed or the mutated seed, a coverage-based fuzz test is performed on the target API.

12. The system according to any one of claims 9 to 11, characterized in that The condition of the target branch is that the target variable falls into the target value set, and the original seed and the mutated seed cover the target value set.

13. The system according to any one of claims 9 to 12, characterized in that: The fuzz testing subsystem is specifically used for: performing constraint solving according to the test case of the target API and the path of the test case to obtain an original seed; and / or, The target data in the proof information of the vulnerability API is matched with a corpus or a dictionary to obtain an original seed, where the original seed is the original data in the corpus or the dictionary that matches the target data.

14. The system according to any one of claims 9 to 13, characterized in that The similarity analysis subsystem is specifically used for: Matching at least one API in the inspected code with the vulnerable API to determine a target API, wherein the similarity between the target API and the vulnerable API satisfies a first set condition; At least one branch in the target API is matched with a branch in the vulnerability API that triggers a vulnerability to determine a target branch, where the target branch and the branch in the vulnerability API that triggers a vulnerability meet a second set condition.

15. The system according to claim 14, characterized in that The similarity analysis subsystem is specifically used for: Presenting to the user at least one API in the inspected code that satisfies a first set condition with the vulnerable API; In response to the selection operation of the user, an API selected by the user from the at least one API is determined as a target API.

16. The system according to any one of claims 9 to 15, characterized in that The inspected code includes incremental code, code in a user's code repository, or code in a code platform.

17. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory, wherein the at least one memory stores computer-readable instructions; the at least one processor executes the computer-readable instructions so that the computing device cluster executes the method as described in any one of claims 1 to 8.

18. A computer-readable storage medium, characterized in that: The method comprises computer-readable instructions; the computer-readable instructions are used to implement the method according to any one of claims 1 to 8.

19. A computer program product, characterized in that The method comprises computer-readable instructions; the computer-readable instructions are used to implement the method according to any one of claims 1 to 8.

Images