Vulnerability detection method and related device

Abstract

The present application provides a vulnerability detection method, comprising: acquiring a target branch of a target API in a detected code; generating a test case of the target API on the basis of proof information of a vulnerability API, wherein the test case of the target API is used for testing whether the target API has a vulnerability; determining an original seed for performing fuzz testing on the target branch of the target API; inputting the original seed into the test case of the target API; testing the target branch by means of the test case into which the original seed is inputted; screening for a seed on the basis of a test result; mutating the screened seed, and then inputting the mutated seed into the test case of the target API; and performing the next round of testing on the target branch by means of the test case into which the mutated seed is inputted so as to detect the vulnerability in the detected code. According to the method, saturation fuzz testing is performed on a specific branch (i.e., the target branch) of a specific API in a detected code, thereby achieving the objective of triggering the vulnerability quickly, realizing efficient fuzz testing for a vulnerability discovery scenario, and improving the vulnerability discovery efficiency.

Description

A vulnerability detection method and related equipment

[0001] This application claims priority to 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”, and claims priority to the Chinese patent application filed with the State Intellectual Property Office on September 8, 2023, with application number 202311159880.2 and invention name “A vulnerability detection method and related equipment”, the entire contents of which are incorporated by reference into 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, also known as vulnerabilities, refer to flaws in computer system security that threaten the confidentiality, integrity, availability, and access control of the system or its application data. Vulnerability mining is crucial for software security, quality, and innovation. It helps discover and fix vulnerabilities, prevent potential attacks, improve software quality, and promote security innovation and research. Through vulnerability mining, we can build a more secure and trustworthy software ecosystem.

[0004] Automated vulnerability discovery tools or techniques accelerate the vulnerability discovery process, improving the efficiency and accuracy of vulnerability discovery. Fuzz testing tools are a typical example of automated vulnerability discovery tools. Fuzz testing tools search for potential vulnerabilities by inputting large amounts of random or semi-random data into target applications. Fuzz testing tools can utilize various techniques, such as mutation generation, symbolic execution, and pattern recognition, to improve test case coverage.

[0005] However, the above-mentioned fuzz testing tools usually aim to improve coverage, and are unlikely to make any progress in vulnerability mining. Vulnerability mining efficiency is low and it is difficult to meet business needs.

[0006] Summary of the Invention

[0007] This application provides a vulnerability detection method that performs saturated fuzz testing on a specific branch (i.e., a target branch) of a specific application programming interface (API) in the code being tested. This method can quickly trigger vulnerabilities, implement efficient fuzz testing for vulnerability mining scenarios, and improve vulnerability mining efficiency. This 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.

[0008] 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, provided to users (such as developers) in the form of a complete vulnerability detection platform. Alternatively, the software system can 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. 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 vulnerability detection capabilities. When the hardware system is running, the vulnerability detection method of the present application is executed.

[0009] 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. Then, a test case of the target API is generated 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. The original seed used for fuzz testing the target branch of the target API is determined. The original seed is then input into the test case of the target API. The target branch is tested by inputting the test case of the original seed. The seeds are screened according to the test results. The screened seeds are mutated and input into the test case of the target API. The target branch is subjected to the next round of testing by inputting the test case of the mutated seed to detect vulnerabilities in the inspected code.

[0010] In this method, the target API and target branch are the APIs and branches with a higher probability of generating vulnerabilities in the inspected code. By performing saturation fuzz testing on the specific branch of this 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.

[0011] 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.

[0012] This method saves vulnerability information so as to provide timely warning and verification based on the vulnerability information. In addition, subsequent vulnerability mining can also be carried out based on the vulnerability information of the mined vulnerabilities.

[0013] 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 may further perform coverage-based fuzz testing on the target API.

[0014] 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, coverage-based fuzz testing is used to test each branch of the target API to uncover as many vulnerabilities as possible.

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

[0016] By inputting the test cases of the original seed and the mutated seed mentioned above to test the target branch, a saturation fuzz test can be performed on the target branch, thereby quickly finding vulnerabilities and improving vulnerability mining efficiency.

[0017] 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 certification information of the vulnerable API with a corpus or dictionary to obtain the original seed, where the original seed is the original data in the corpus or dictionary that matches the target data. In actual applications, the vulnerability detection system can also obtain parts of the original seed through different methods and mix the original seeds obtained by different methods.

[0018] This method supports obtaining original seeds through 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.

[0019] 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. The vulnerability detection system may then 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-mentioned 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.

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

[0021] 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.

[0022] This allows for saturation fuzz testing of 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 vulnerability discovery efficiency.

[0023] 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.

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

[0025] A similarity analysis subsystem is configured 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;

[0026] 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 of 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 of the target API, test the target branch by inputting the test case of the original seed, screen seeds based on the test results, mutate the screened seeds and input them 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 inspected code.

[0027] In some possible implementations, the fuzz testing subsystem is further configured to:

[0028] 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, where the vulnerability information includes at least one of a vulnerability type, a vulnerability path, or a test case that triggers the vulnerability.

[0029] In some possible implementations, the fuzz testing subsystem is further configured to:

[0030] 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.

[0031] In some possible implementations, the condition for 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.

[0032] In some possible implementations, the fuzz testing subsystem is specifically configured to:

[0033] Perform constraint solving based on the test case of the target API and the path of the test case to obtain the original seed; and / or,

[0034] 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.

[0035] In some possible implementations, the similarity analysis subsystem is specifically configured to:

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

[0037] 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.

[0038] In some possible implementations, the similarity analysis subsystem is specifically configured to:

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

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

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

[0042] In a third aspect, the present application provides a computing device cluster. The computing device cluster includes at least one computing device, each of which 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 configured to execute instructions stored in the at least one memory, causing the computing device or computing device cluster to perform the vulnerability detection method described in the first aspect or any implementation of the first aspect.

[0043] 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 first aspect or any implementation of the first aspect.

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

[0045] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical methods of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments.

[0047] FIG1 is a schematic diagram of the architecture of a vulnerability detection system provided in an embodiment of the present application;

[0048] FIG2 is a schematic diagram of a fuzzy test subsystem for performing fuzzy testing according to an embodiment of the present application;

[0049] FIG3 is a schematic diagram of a similarity analysis subsystem for performing similarity analysis according to an embodiment of the present application;

[0050] FIG4 is a flow chart of a vulnerability detection method provided in an embodiment of the present application;

[0051] FIG5 is a schematic diagram of an application scenario of a vulnerability detection method provided in an embodiment of the present application;

[0052] FIG6 is a schematic diagram of an application scenario of a vulnerability detection method provided in an embodiment of the present application;

[0053] FIG7 is a schematic diagram of an application scenario of a vulnerability detection method provided in an embodiment of the present application;

[0054] FIG8 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0055] FIG9 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0056] FIG10 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application;

[0057] FIG11 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0058] The terms "first" and "second" in the embodiments of this application are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include one or more of the features.

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

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

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

[0062] Dynamic vulnerability mining technology uses runtime monitoring and analysis to discover vulnerabilities. It tracks and records information during software (e.g., application) execution, such as memory states, function calls, and network communications, to detect potential vulnerabilities and abnormal behavior. Dynamic vulnerability mining can help discover runtime memory errors, illegal operations, and security vulnerabilities.

[0063] Fuzz testing is an automated testing technique that searches for potential vulnerabilities by inputting large amounts of random or semi-random data into target applications. Fuzz testing tools typically leverage various techniques, such as mutation generation, symbolic execution, and pattern recognition, to improve test case coverage and vulnerability detection accuracy.

[0064] AI-based vulnerability mining technologies include machine learning-based vulnerability mining. Specifically, machine learning-based vulnerability mining tools can learn vulnerability patterns from a large number of samples and discover new vulnerabilities based on these patterns. Machine learning-based vulnerability mining tools can automatically analyze source code, execute programs, and detect potential vulnerabilities.

[0065] Fuzz testing is a widely used continuous testing method that can continuously uncover vulnerabilities. However, fuzz testing tools in the industry generally mutate seeds to improve coverage. This mutation model is well suited to covering all branches of the Application Programming Interface (API), but it is difficult to find vulnerabilities, resulting in low vulnerability discovery efficiency.

[0066] 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, provided to users (such as developers) in the form of a complete vulnerability detection platform. Alternatively, the software system can 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 repository 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-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 vulnerability detection function. When the hardware system is running, the vulnerability detection method of the present application is executed.

[0067] 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. The vulnerability detection system can then generate a test case for the target API based on the proof information of the vulnerability API, such as a proof of concept (POC). 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, filters the seeds according to the test results, mutates the filtered 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.

[0068] In this method, the target API and target branch are the APIs and branches with a higher probability of generating vulnerabilities in the inspected code. By performing saturation fuzz testing on the specific branch of this 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.

[0069] 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 with reference to the accompanying drawings.

[0070] 1 shows a schematic diagram of the vulnerability detection system architecture. 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 described below.

[0071] 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 based on the vulnerability API's certification information. The target API can be a candidate API that triggers a vulnerability, also known as a suspected vulnerability API. The test case for the target API is used to test whether the target API has a vulnerability.

[0072] The seed selection module 104 is used to obtain a target branch in the target API and determine an original seed for fuzz testing the target branch of the target API. An API may include one or more operation sequences, and an API branch may be an operation sequence of the API. For example, an API may include the operation sequences OP1, OP2, OP3, OP5 and OP1, OP2, OP4, OP6, and an API branch may be OP1, OP2, OP3, OP5. A target branch is at least one branch in the target API. A target branch may be a candidate branch that triggers a vulnerability, also known as a suspected vulnerability branch. Seeds are an important component of fuzz testing and are typically the input to the test case used for fuzz testing. Seed selection has a significant impact on test efficiency and results. Considering that fuzz testing involves multiple rounds, the seed selection module 104 may first select an original seed and then perform the next round of screening based on the test results. The original seed is the initial (first batch) input to the test case. In some possible implementations, the condition for entering the target branch in the API is that the target variable falls within the target value set. The original seed may be a set of value sequences within 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}.

[0073] The fuzz testing module 106 is configured to input the original seed into a test case of the target API and test the target branch using the test case input with the original seed. The fuzz testing module 106 can obtain a test result. The test result can include the processing results (including intermediate results) of each node of the target branch (e.g., each operation in an operation sequence).

[0074] The seed selection module 104 is also used to filter seeds based on 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 [2000, 2200], there is a high probability that the vulnerability will not be triggered. Therefore, the seed selection module 104 can filter seeds with consistent test results and retain the remaining seeds. Furthermore, the seed selection module 104 can also mutate the screened seeds.

[0075] 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 saturation fuzz testing 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 saturation fuzz testing. The fuzz testing module 106 performs multiple rounds of testing based on the above-mentioned original seed and mutated seed, thereby achieving saturation fuzz testing for all scenarios in the target branch.

[0076] Furthermore, the fuzz testing module 106 is further configured to store vulnerability information when a vulnerability is triggered during the testing of a target branch using a test case inputting the original seed or the mutated seed. The vulnerability information may include at least one of the vulnerability type, the vulnerability path, or the test case that triggered the vulnerability. It should be noted that the vulnerability path may be the path that triggered the vulnerability.

[0077] The above mainly illustrates fuzz testing of a specific branch. This application also supports coverage-based fuzz testing. In some possible implementations, the fuzz testing module 106 is further 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.

[0078] It should be noted that another key point in achieving efficient vulnerability mining in this application lies in the determination of target APIs and target branches. The vulnerability detection system 10 can determine the target APIs and target branches in the inspected code through similarity analysis. In some possible implementations, the vulnerability detection system 10 can also include a similarity analysis subsystem 200.

[0079] The similarity analysis subsystem 200 is used to match at least one API in the inspected code with the vulnerable API to determine the target API. The similarity between the target API and the vulnerable API meets 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 the branch that triggers the vulnerability in the vulnerable API to determine the target branch. The target branch and the branch that triggers the vulnerability in the vulnerable API 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.

[0080] 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 vulnerable API, and determine at least one API in the inspected code that satisfies a first set condition with the vulnerable API. The interaction module 204 is used to present to the user at least one API in the inspected code that satisfies the first set condition with the vulnerable API, 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 a branch that triggers a vulnerability in the vulnerable API, and determine a branch in at least one branch of the target API that satisfies a second set condition with the branch that triggers the vulnerability in the vulnerable API. The interaction module 204 is used to present to the user at least one branch in the target API that satisfies the second set condition with the branch that triggers the vulnerability in the vulnerable API, 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.

[0081] It should be noted that the vulnerability API and vulnerability branch can come from vulnerability information released by the open source community or from a 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, which 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 that collects various information security weaknesses and vulnerabilities and assigns them numbers for public access. Based on this, the collection subsystem 300 is also called a CVE collector. The collection subsystem 300 can store the captured vulnerability information in a database for use. Furthermore, the vulnerability detection system 10 may also include a filtering subsystem 400, which is used to filter out 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.

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

[0083] Referring to FIG2 , a schematic diagram of a fuzz testing subsystem 100 performing fuzz testing is shown. As shown in FIG2 , 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 include a coverage fuzz testing submodule 1064 (also called a coverage fuzzer).

[0084] The test case generation module 102 supports inputting a specific code snippet, such as a POC. For this specific code snippet, the test case generation module 102 can generate a test case for testing whether the target API has vulnerabilities, i.e., a test case for the target API. This can reduce manual access costs.

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

[0086] In a first possible implementation, the seed selection module 104 performs constraint solving based on the target API's test case and the test case's path to obtain the original seed. The test case's path may be a candidate path, also known as a suspected path, that triggers the target API's vulnerability.

[0087] 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 domains, 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 the solver.

[0088] In a second possible implementation, the seed selection module 104 matches the target data in the vulnerability API's proof information with a corpus or dictionary to obtain an 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 can be a proof of concept (POC), and the target data can be a value or set of values ​​of a variable in the POC.

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

[0090] The fuzz testing module 106 is configured to input the original seed into the target API's test case and test the target branch using the test case input with the original seed. After selecting seeds based on the test results, the selected seeds can be mutated and input into the target API's test case. The target branch can then be tested using the test case input with the mutated seed to detect vulnerabilities in the tested code.

[0091] 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 input parameters as the target of the genetic algorithm. 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 the nodes of the target branch of the target API to obtain the processing results of each node as the test result. The 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.

[0092] The coverage fuzzer submodule 1064 can complement the Branch Fuzzer by performing coverage-based fuzz testing on the target API when no vulnerability is triggered during testing of the target branch using test cases that input the original seed or the mutated seed. The coverage fuzzer submodule 1064 is less efficient than the Branch Fuzzer, but it provides greater coverage and can gradually mutate the seed to trigger the vulnerability over time.

[0093] Referring to FIG3 , a schematic diagram illustrating a similarity analysis subsystem 200 performing similarity analysis is shown. As shown in FIG3 , similarity analysis subsystem 200 includes a matching module 202 . Matching module 202 can perform similarity matching based on the API's control flow graph and vector representation (e.g., embedding) to determine the target API and target branch. Based on this, similarity analysis subsystem 200 can also include a parser 206 and a deep learning model 208 .

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

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

[0096] The matching module 202 includes a natural language model (e.g., a large number of natural language models) and a similarity matching algorithm (e.g., a large number of similarity matching algorithms). The similarity matching algorithm can compare a code segment with parsed code segments in a database to find the most similar API.

[0097] 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 as well as POCs that trigger the vulnerability from the vulnerability data. By sending the vulnerability code snippets, call chains and POCs into AST Parser and DL Model, the control flow graph of the vulnerability API and the branch in the control flow that triggers the vulnerability can be obtained. 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 greater than a set threshold (for example, the first threshold).

[0098] Furthermore, in matching module 202, the branch triggering the vulnerability in the vulnerable API can be matched with at least one branch in the target API to determine the target branch. The target branch and the branch triggering the vulnerability in the vulnerable API meet a second set condition. Similarly, the second set condition can be maximum similarity, a top n similarity ranking, or a similarity greater than a set threshold (e.g., a second threshold).

[0099] 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 APIs with the greatest similarity and 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 POC new shown in Figure 3) through dynamic verification, so as to achieve the effect of enhancing similar APIs and similar paths.

[0100] 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 the similar API to the user, for example, 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, for example, 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.

[0101] 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 fuzz testing.

[0102] 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.

[0103] Referring to the flowchart of a vulnerability detection method shown in FIG4 , the method includes:

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

[0105] 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.

[0106] The inspected code includes at least one API. The target API is an API in the inspected code that has a high probability of triggering a vulnerability. The target branch is a branch path in the target API that has a high probability of triggering a vulnerability. Vulnerability detection system 10 can determine the target API and the target branch in the target API through similarity matching.

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

[0108] 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 the API call stack) 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 the 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 the 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 vulnerability API, or calculate the similarity between the vector representation of the API in the inspected code and the vector representation of the vulnerability API, and determine the similarity between the API in the inspected code and the vulnerability API based on at least one of the similarity of the control flow graph or the similarity of the vector representation.

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

[0110] The vulnerability detection system 10 may determine the similarity between the branch that triggers the vulnerability in the vulnerable API and the at least one branch in the target API based on the similarity between the vector representation of the branch that triggers the vulnerability in the vulnerable API and the vector representation of at least one branch in the target API. In some examples, the vulnerability detection system 10 may also determine the similarity between the branch that triggers the vulnerability in the vulnerable API and the 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.

[0111] It should be noted that, after determining the APIs or branches whose similarity meets the set conditions, the vulnerability detection system 10 also supports presenting the APIs or branches whose similarity meets the set conditions to the user, so that the user can select the APIs or branches that are of interest or that the user believes have 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, determine the API selected by the user from the at least one API 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, determine the branch selected by the user from the at least one branch as the target branch.

[0112] S404: The vulnerability detection system 10 generates a test case for the target API based on the certification information of the vulnerable API.

[0113] The target API's test cases are used to test whether the target API has vulnerabilities. The vulnerability detection system 10 can utilize proof of concept (PoC) information of known vulnerable APIs to generate test cases for the target API. The vulnerability detection system 10 can adapt the PoC of the known vulnerable API to the target API using an adapter, thereby generating test cases for the target API.

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

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

[0116] 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 the corpus or dictionary, and mixing the above seeds to obtain the original seeds for fuzz testing the target branch of the target API.

[0117] 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.

[0118] 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.

[0119] Specifically, the vulnerability detection system 10 can execute a target branch based on a test case inputted with the target API of the original seed, monitor each node of the target branch, and thereby test the target branch and obtain a test result. The test result may include the processing result of each node (including but not limited to intermediate results and final results).

[0120] S410 , the vulnerability detection system 10 filters seeds according to the test results.

[0121] For different original seeds, the vulnerability detection system 10 can compare the test results corresponding to the different original seeds. If 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.

[0122] S412. The vulnerability detection system 10 mutates the screened seeds and inputs the mutated seeds 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.

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

[0124] Vulnerability detection system 10 can execute a target branch based on a test case of a target API with a mutated seed, monitor each node of the target branch, and thus perform the next round of testing on the target branch to obtain test results. By continuously screening seeds, mutating, and then executing the target branch using a test case of the target API with the mutated seed, vulnerability detection system 10 can perform saturation fuzz testing on the target branch.

[0125] 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 process of the target branch by inputting the test case of the original seed or the mutated seed, the vulnerability detection system 10 can also save the 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 the path that triggers the vulnerability. When the vulnerability is not triggered during the test process of the target branch by inputting the 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.

[0126] 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.

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

[0128] First, refer to the application scenario diagram of a vulnerability detection method shown in Figure 5. 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, a first-level filtering can be performed to screen 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. This capability supports 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.

[0129] For a single, detailed vulnerability, the root cause method involved in its code remediation can be targeted. After triggering an API query, a list of similar APIs can be displayed, as shown in Figure b. This page primarily presents a list of similar APIs obtained through semantic characterization, presenting functionally similar APIs in a unified manner. When a user is interested in a particular API, they can proactively trigger the fuzzing capability to verify the API of interest. Finally, if a real new vulnerability is triggered, it can be displayed on the vulnerability details page, as shown in Figure c, which primarily displays the proof-of-concept (POC) and issue details.

[0130] As can be seen from the above, this embodiment can accelerate the discovery of vulnerabilities (such as 0-day vulnerabilities) by leveraging a large number of historical and newly warned vulnerability code features and fuzzing technology to accelerate the entire detection and verification process. For example, an API with a disclosed 0-day vulnerability can be generalized to APIs with similar functions. Based on the vulnerability's POC, corresponding test cases can be generated for fuzzing to quickly verify whether the API with similar functions has vulnerabilities.

[0131] Then, refer to the application scenario diagram of a vulnerability detection method shown in Figure 6. In this scenario, vulnerability detection can be integrated into the code inspection platform. Specifically, the user can establish an inspection task for the user's code repository on the code inspection platform, and then perform code characterization at the granularity of the method API. Different from the embodiment shown in Figure 5, the embodiment shown in Figure 6 no longer searches for the similarity between the API of interest and the full 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 the 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.

[0132] Compared to the embodiment shown in Figure 5, this eliminates the need for users to manually filter APIs of interest and proactively trigger fuzzing. Instead, the entire code repository is automatically monitored. When searching for similar APIs, the entire repository is no longer searched, but only historical vulnerability root cause APIs are searched for similarity. This embodiment effectively exploits historical vulnerabilities, providing 24 / 7 monitoring of the user's code repository. By leveraging a large number of historical vulnerability code features and fuzzing technology, it expands the scope of scenarios that are difficult to cover with static checks.

[0133] Next, referring to Figure 7, a schematic diagram of an application scenario for a vulnerability detection method is shown. In this scenario, vulnerability detection can be integrated into a code hosting platform. On the code hosting platform, each time a user submits a code merge request, the merge is subject to a risk check to mitigate issues such as security vulnerabilities and poor readability. This risk check can be performed incrementally, specifically by checking incremental code, including vulnerability detection.

[0134] Similar to the embodiment shown in Figure 6, the code hosting platform only focuses on similar API queries in historical vulnerabilities. After a 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 a set threshold, the fuzzing process can be automatically triggered. If a vulnerability is triggered during the fuzzing process, an alert can be issued in the Issue column of the code hosting platform. If the fuzzing result is efficient, an alert can also be issued in the comment section of the current code merge request.

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

[0136] Based on the above embodiments, the vulnerability detection method of the present application can achieve automated and efficient fuzz testing in the field of vulnerability mining by saturation fuzz testing of specific branches. Moreover, by migrating 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.

[0137] Based on the aforementioned method embodiment, the present application further provides a vulnerability detection system 10, as shown in FIG1 , comprising:

[0138] The similarity analysis subsystem 200 is configured 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;

[0139] 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 of the target API is used to test whether the target API has a vulnerability, determine the original seed for fuzz testing the target branch of the target API, input the original seed into the test case of the target API, test the target branch by inputting the test case of the original seed, screen the seeds according to the test results, mutate the screened seeds and input them 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.

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

[0141] When implemented via software, the fuzz testing subsystem 100 and similarity analysis subsystem 200 can be applications running on a computing device, such as a computing engine. These applications can be provided to users as virtualized services. Virtualized services can include virtual machine (VM) services, bare metal server (BMS) services, and container services. VM services use virtualization technology to create a virtual machine (VM) resource pool on multiple physical hosts (such as computing devices) to provide VMs on demand. BMS services create a virtual BMS resource pool on multiple physical hosts to provide BMSs on demand. Container services create a virtual container resource pool on multiple physical hosts to provide containers on demand. A VM is a simulated virtual computer, or logically a single computer. BMS is a scalable, high-performance computing service with computing performance comparable to traditional physical machines and secure physical isolation. Containers are a kernel virtualization technology that provides lightweight virtualization to isolate 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.

[0142] When implemented through hardware, the fuzz testing subsystem 100 and the similarity analysis subsystem 200 may include at least one computing device, such as a server. Alternatively, the fuzz testing subsystem 100 and the similarity analysis subsystem 200 may be implemented 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.

[0143] Similarly, the test case generation module 102, seed selection module 104, and fuzzy testing module 106 in the fuzz testing subsystem 100, and the matching module 202 and 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, seed selection module 104, fuzzy testing module 106, matching module 202, and 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, seed selection module 104, fuzzy testing module 106, matching module 202, and interaction module 204 can be hardware, such as a server.

[0144] In some possible implementations, the fuzz testing subsystem 100 is further configured to:

[0145] 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, where the vulnerability information includes at least one of a vulnerability type, a vulnerability path, or a test case that triggers the vulnerability.

[0146] In some possible implementations, the fuzz testing subsystem 100 is further configured to:

[0147] 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.

[0148] In some possible implementations, the condition for 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.

[0149] In some possible implementations, the fuzz testing subsystem 100 is specifically configured to:

[0150] Perform constraint solving based on the test case of the target API and the path of the test case to obtain the original seed; and / or,

[0151] 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.

[0152] In some possible implementations, the similarity analysis subsystem 200 is specifically configured to:

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

[0154] 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.

[0155] In some possible implementations, the similarity analysis subsystem 200 is specifically configured to:

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

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

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

[0159] 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 requirements, such as kernel vulnerabilities. This allows vulnerability mining based on the remaining vulnerability information.

[0160] The collection subsystem 300 or the filtering subsystem 400 can also be implemented in software or hardware. The collection subsystem 300 or the filtering subsystem 400 can 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 can be hardware, such as a server.

[0161] 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.

[0162] This application also provides a computing device 800. This computing device 800 is used to implement some or all of the functions of the vulnerability detection system 10. As shown in Figure 8, 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 with each other via bus 802. Computing device 800 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 800.

[0163] Bus 802 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG8 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 802 may include a path for transmitting information between various components of computing device 800 (e.g., memory 806, processor 804, and communication interface 808).

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

[0165] 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.

[0166] 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 a communication network.

[0167] Embodiments of the present application also provide 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 smartphone.

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

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

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

[0171] FIG10 illustrates a possible implementation. As shown in FIG10 , 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 the fuzz testing subsystem 100. The memory in computing device 800B stores instructions for executing the functions of the similarity analysis subsystem 200. Furthermore, the memory in computing device 800B may also store instructions for executing the functions of the collection subsystem 300 and the filtering subsystem 400. In other words, the memories 806 of computing devices 800A and 800B jointly store instructions for the vulnerability detection system 10 to execute the vulnerability detection method.

[0172] The connection method between the computing device clusters shown in Figure 10 can be considered to be that considering that the vulnerability detection method provided by this application requires a large amount of computing power to perform similarity analysis to determine the target API and target branch, it is considered to transfer the functions implemented by the similarity analysis subsystem 200 to the computing device 800B.

[0173] It should be understood that the functionality of the computing device 800A shown in FIG10 may also be implemented by multiple computing devices 800. Similarly, the functionality of the computing device 800B may also be implemented by multiple computing devices 800.

[0174] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. FIG11 shows a possible implementation. As shown in FIG11 , 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. The memory 806 in the computing device 800D may also store instructions for executing the functions of the collection subsystem 300 and the filtering subsystem 400.

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

[0176] It should be understood that the functionality of the computing device 800C shown in FIG11 may also be accomplished by multiple computing devices 800. Similarly, the functionality of the computing device 800D may also be accomplished by multiple computing devices 800.

[0177] 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 magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the vulnerability detection method described above for use in the vulnerability detection system 10.

[0178] The present application also provides a computer program product comprising instructions. The computer program product may be software or a program product comprising instructions that can be executed on a computing device or stored on any available medium. When the computer program product is executed on at least one computing device, the at least one computing device executes the vulnerability detection method described above.

[0179] 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 deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various 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 the test case of the original seed or the mutated seed, save Vulnerability information, where 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