Continuous fuzzy test method and device based on static analysis technology

Abstract

The invention belongs to the technical field of network security, and particularly discloses a continuous fuzz test method and device based on a static analysis technology, and the method comprises the steps: extracting a test interface of a target fuzz test drive program in a to-be-tested project; analyzing a control flow dependency relationship and a data flow dependency relationship between a test interface of the target fuzzy test driver and the submitted code patch through a static analysis technology; determining whether the target fuzzy test driving program is executed or not and the priority of execution based on the analysis result of the control flow dependency relationship and the data flow dependency relationship; and selecting an executable fuzzy test driving program in the to-be-tested item and carrying out continuous fuzzy test based on the priority. According to the method and the device, a result that a fuzzy test driving program irrelevant to a code patch does not need to be called is achieved, the efficiency of continuous fuzzy test is improved, the test cost is reduced, and waste of system computing resources is reduced.

Description

Technical Field

[0001] The present application belongs to the field of network security technology, and more specifically, to a continuous fuzz testing method and device based on static analysis technology. Background Art

[0002] With the rapid development of the digital economy, thousands of software have emerged and are widely used in industry, commerce and people's daily lives. However, due to various environmental factors in the software development process, software inevitably has various forms of security issues. Attackers can use software vulnerabilities to steal valuable information and cause immeasurable consequences. Therefore, it is necessary to conduct sufficient security testing on the software.

[0003] Fuzz testing is a method of discovering software vulnerabilities by providing unexpected (random, deformed, illegal test cases) inputs to the program entry and monitoring abnormal results. With the widespread application of fuzz testing and the practice of security left shift, a fuzz testing technology combined with the continuous integration / continuous development (CI / CD) pipeline, namely continuous fuzz testing, is proposed. Every time a developer submits code to the code repository, the system automatically triggers the fuzz testing operation and performs fuzz testing on the currently submitted code snippet. Once the software under test crashes, the crash information is fed back to the developer, and the developer makes improvements before submitting the next round.

[0004] Continuous fuzz testing has achieved good results, but there are still some problems: when there are multiple fuzz testing drivers in the project to be tested, once a code merge request is triggered, the system will call all fuzz testing drivers for code testing, which not only affects the efficiency of vulnerability mining but also wastes the system's computing resources. Summary of the invention

[0005] In view of the defects existing in the related technology, the embodiments of the present application provide a continuous fuzz testing method and device based on static analysis technology, aiming to solve the problems of low efficiency of vulnerability mining and waste of system computing resources in the related technology.

[0006] In a first aspect, an embodiment of the present application provides a continuous fuzz testing method based on static analysis technology, comprising:

[0007] Extract the test interface of the target fuzz test driver in the project to be tested;

[0008] Analyze the control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch through static analysis technology;

[0009] Determine whether to execute the target fuzz test driver and the execution priority based on the analysis results of the control flow dependency and the data flow dependency;

[0010] Select executable fuzz testing drivers from the project to be tested and perform continuous fuzz testing based on priority.

[0011] In some embodiments, the control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch are analyzed by static analysis technology, including:

[0012] Use static analysis techniques to analyze whether there is a control flow dependency between the test interface of the target fuzz test driver and the submitted code patch;

[0013] If there is a control flow dependency, we further analyze whether there is a data flow dependency between the test interface of the target fuzz test driver and the submitted code patch.

[0014] In some embodiments, the control flow dependency and data flow dependency between the test interface of each fuzz test driver and the submitted code patch are analyzed by static analysis technology, including:

[0015] The control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch are analyzed by the static analysis tool Joern.

[0016] In some embodiments, determining whether to execute the target fuzz test driver and the execution priority based on the analysis results of the control flow dependency and the data flow dependency includes:

[0017] When both control flow dependency and data flow dependency exist, the target fuzz testing driver is marked as executable and high priority;

[0018] When there are control flow dependencies but no data flow dependencies, mark the target fuzz driver as executable and low priority;

[0019] When there are no control flow dependencies and data flow dependencies, the target fuzz testing driver is marked as non-executable.

[0020] In some embodiments, extracting a test interface of a target fuzz test driver in a project to be tested includes:

[0021] Based on the documents or header files in the project to be tested, obtain the external interface information of the project to be tested; convert the source code of the target fuzz test driver into an abstract syntax tree;

[0022] Based on the function node information of the abstract syntax tree, the functions of the external interface of the project to be tested are marked to determine the test interface sequence of the target fuzz test driver.

[0023] In a second aspect, the embodiment of the present application further provides a continuous fuzz testing device based on static analysis technology, comprising:

[0024] An extraction module, used to extract the test interface of the target fuzz test driver in the project to be tested;

[0025] An analysis module, used for analyzing control flow dependency and data flow dependency between a test interface of a target fuzz test driver and a submitted code patch by using static analysis technology;

[0026] A determination module, used to determine whether the target fuzz test driver is executed and the execution priority based on the analysis results of the control flow dependency and the data flow dependency;

[0027] The selection module is used to select the executable fuzz test drivers in the project to be tested and perform continuous fuzz testing based on priority.

[0028] In a third aspect, an embodiment of the present application further provides an electronic device, comprising: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0029] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0030] In a fifth aspect, an embodiment of the present application further provides a computer program product, which, when executed on a processor, enables the processor to execute the method described in the first aspect or any possible implementation of the first aspect.

[0031] The continuous fuzz testing method and device based on static analysis technology provided in the embodiment of the present application use static analysis technology to judge the control flow dependency and data flow dependency between the test interface of the fuzz test driver and the code patch, thereby screening and prioritizing the fuzz test drivers in the project to be tested, achieving the result of not needing to call fuzz test drivers unrelated to the code patch, thereby improving the efficiency of continuous fuzz testing, reducing testing costs, and reducing the waste of system computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the present application or related technologies, the following is a brief introduction to the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0033] Figure 1 This is one of the flow charts of the continuous fuzz testing method based on static analysis technology provided in the embodiment of the present application;

[0034] Figure 2 This is the second flow chart of the continuous fuzz testing method based on static analysis technology provided in the embodiment of the present application;

[0035] Figure 3 It is a structural schematic diagram of a continuous fuzzy testing device based on static analysis technology provided in an embodiment of the present application;

[0036] Figure 4 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0038] Figure 1 This is one of the flow charts of the continuous fuzz testing method based on static analysis technology provided in the embodiment of the present application, such as Figure 1 As shown, the method comprises at least the following steps:

[0039] S101, extracting the test interface of the target fuzz test driver of the project to be tested;

[0040] S102, analyzing the control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch by static analysis technology;

[0041] S103, determining whether the target fuzz test driver is executed and the execution priority based on the analysis results of the control flow dependency and the data flow dependency;

[0042] S104: Select an executable fuzz test driver and perform continuous fuzz testing based on priority.

[0043] Specifically, when there are multiple fuzz test drivers in the project to be tested, once a code merge request is triggered, the system will call all fuzz test drivers to perform code testing. Different fuzz test drivers call different test interfaces, and different fuzz test drivers have different fuzz test capabilities. However, the code patch may not be within the test scope of some fuzz test drivers, causing fuzz test drivers unrelated to the code patch to be called and run, which not only affects the efficiency of vulnerability mining but also wastes the system's computing resources.

[0044] Therefore, this application considers using static analysis technology to judge the control flow dependency and data flow dependency between the test interface of the fuzz test driver and the code patch, so as to screen and prioritize the fuzz test drivers in the project to be tested, and achieve the result of not needing to call fuzz test drivers that are not related to the code patch.

[0045] In some embodiments, S101 specifically includes:

[0046] Based on the documents or header files in the project to be tested, obtain the external interface information of the project to be tested; based on the external interface information, convert the source code of the target fuzz test driver into an abstract syntax tree;

[0047] Based on the function node information of the abstract syntax tree, the functions of the external interface of the project to be tested are marked to determine the test interface sequence of the target fuzz test driver.

[0048] Specifically, all fuzz test drivers in the project to be tested are analyzed, and a test interface of a target fuzz test driver is extracted. The target fuzz test driver is any fuzz test driver in the project to be tested.

[0049] In a possible implementation, an abstract syntax tree is used to extract the test interface of the target fuzz test driver in the project to be tested. The abstract syntax tree AST is an abstract representation of the grammatical structure of the source code, where each node represents a grammatical construct, such as an expression, statement, function, etc. The test interface of the target fuzz test driver in the project to be tested can also be extracted through the concrete syntax tree CST, but AST omits some unimportant details, such as blank characters, comments, etc., which is more concise and easy to handle.

[0050] The following is a description of the specific implementation process of using the abstract syntax tree to extract the test interface of the target fuzz test driver in the project to be tested:

[0051] Based on the documents or header files in the project to be tested, obtain the external interface information of the project to be tested. The header file of the project to be tested is the main place to define the interface (including function, type and other declarations), so the external interface information of the project to be tested can be obtained and understood through the header file.

[0052] Convert the target fuzz test driver's source code into an abstract syntax tree. This is the parsing process of the target fuzz test driver's source code, which generally includes lexical analysis, syntax analysis, semantic analysis, and AST construction.

[0053] After obtaining the external interface information of the project to be tested and constructing the abstract syntax tree corresponding to the source code of the target fuzz test driver, the functions of the external interface belonging to the project to be tested are marked based on the function node information of the abstract syntax tree to determine the test interface sequence of the target fuzz test driver.

[0054] For example, for target fuzz test driver A, the target fuzz test driver A source code is converted into an abstract syntax tree, and the function node information of the abstract syntax tree is called to compare and analyze whether function A1 belongs to the external interface (ie, the test interface) of the project to be tested. If function A1 belongs to the external interface of the project to be tested, it is marked. Finally, the target fuzz test driver A corresponds to a set of function call sequences (A1, A2, A3...), which is also a test interface sequence.

[0055] In some embodiments, S102 specifically includes:

[0056] Use static analysis techniques to analyze whether there is a control flow dependency between the test interface of the target fuzz test driver and the submitted code patch;

[0057] If there is a control flow dependency, we further analyze whether there is a data flow dependency between the test interface of the target fuzz test driver and the submitted code patch.

[0058] Specifically, static analysis refers to the analysis before the program is run to determine whether the program meets the required property requirements. Static analysis is relative to dynamic analysis. The main difference between the two is whether the analysis is performed before or after the program is run. Static analysis focuses more on the process of program operation, while dynamic analysis focuses more on the results of program operation.

[0059] Static analysis includes control flow analysis, data flow analysis and other analysis methods. Static analysis technology is used to judge the control flow dependency and data flow dependency between the test interface of the fuzz test driver and the code patch, so as to screen and prioritize the fuzz test drivers in the project under test, and achieve the result of not calling fuzz test drivers unrelated to the code patch.

[0060] During the analysis process, priority is given to analyzing whether there is a control flow dependency between the test interface of the target fuzz test driver and the submitted code patch; if there is a control flow dependency, further analysis is performed on whether there is a data flow dependency between the test interface of the target fuzz test driver and the submitted code patch; if there is no control flow dependency, there is no need to further analyze whether there is a data flow dependency between the test interface of the target fuzz test driver and the submitted code patch.

[0061] Control flow analysis combines all control flows that may be generated when the program is running into a control flow set, so as to fully understand the overall architecture of the program. Through control flow analysis, the paths, loops, conditional branches and other structures in the execution process of the target fuzz test driver can be identified. When the test interface of the target fuzz test driver receives different input data, the conditional statements inside the driver will select different execution paths according to the value of the input data. This selection process reflects the control flow dependency; if the code patch modifies the logic of the conditional statement or adds a new conditional statement, the original control flow dependency may be changed.

[0062] Data flow analysis mainly calculates the control flow analysis results and function call relationships to obtain the values ​​of certain variables when the program executes to certain nodes, which depends on the control flow analysis results. When the test interface of the target fuzz test driver receives different input data, it will go through a series of calculations and processing, which will eventually affect the values ​​of the program's internal variables. This influence process reflects the data flow dependency; if the code patch modifies the variable assignment or adds new variables, it may change the original data flow dependency.

[0063] If there is a control flow dependency and a data flow dependency between the test interface of the target fuzz test driver and the submitted code patch, it means that the code patch is within the scope of the target fuzz test driver test and needs to call to run the target fuzz test driver; if there is no control flow dependency and data flow dependency, there is no need to call to run the target fuzz test driver.

[0064] Optionally, static analysis uses the static analysis tool Joern. Joern is dedicated to the analysis of source code, bytecode, and binary executable files. It is a powerful static analysis tool that can help developers identify potential security vulnerabilities.

[0065] In some embodiments, S103 specifically includes:

[0066] When both control flow dependency and data flow dependency exist, the fuzz testing driver is marked as executable and high priority;

[0067] When there are control flow dependencies but no data flow dependencies, mark the target fuzz driver as executable and low priority;

[0068] When there are no control flow dependencies and data flow dependencies, the target fuzz testing driver is marked as non-executable.

[0069] Specifically, the control flow dependency and data flow dependency between the test interface of the fuzz test driver and the code patch are judged, including whether there is a dependency and the degree of dependency, and the priority is obtained according to the degree of dependency.

[0070] When there are both control flow dependencies and data flow dependencies between the test interface of the target fuzz test driver and the submitted code patch, the target fuzz test driver is marked as executable and high priority; when there is a control flow dependency but no data flow dependency between the test interface of the target fuzz test driver and the submitted code patch, the target fuzz test driver is marked as executable and low priority; when there is no control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch, the target fuzz test driver is marked as non-executable.

[0071] Generally speaking, when there is no control flow dependency between the test interface of the target fuzz testing driver and the submitted code patch, there is no data flow dependency by default.

[0072] The continuous fuzz testing method based on static analysis technology provided in the embodiment of the present application uses static analysis technology to judge the control flow dependency and data flow dependency between the test interface of the fuzz test driver and the code patch, thereby screening and prioritizing the fuzz test drivers in the project to be tested, thereby achieving the result of not needing to call fuzz test drivers unrelated to the code patch, thereby improving the efficiency of continuous fuzz testing, reducing testing costs, and reducing the waste of system computing resources; it can effectively detect software vulnerabilities of the target program and can detect and discover deep-level vulnerabilities hidden in the target software.

[0073] The technical solution provided in the embodiment of the present application is further illustrated below through a specific example.

[0074] Figure 2 This is the second flow chart of the continuous fuzzy testing method based on static analysis technology provided in the embodiment of the present application. Figure 2 As shown, the method comprises the following steps:

[0075] Step 1, extract the interface of the fuzzy test driver. Obtain all the external interface information of the project according to the documents or header files in the project to be tested, and then convert the source code of the fuzzy test driver A into an abstract syntax tree. Based on the abstract syntax tree, call the function node information to compare and analyze whether the function A1 belongs to the external interface of the project to be tested. If the function A1 belongs to the external interface of the project to be tested, mark it. Finally, the fuzzy test driver A corresponds to a set of function call sequences (A1, A2, A3...).

[0076] Step 2: Static dependency analysis of code patches. Assume that the fuzz test driver A has a call sequence (A1, A2, A3...), and the code patch submitted by the user is T. Use the static analysis tool Joern to analyze whether there is a control flow dependency between functions A1, A2, A3, etc. and code patch T. If so, further analyze the data flow dependency between the function and the code patch. Determine whether the fuzz test driver is executed and the execution priority based on the control flow and data flow dependencies. Specifically:

[0077] If there is a control flow dependency between the functions (A1, A2, A3...) in the calling sequence and the code patch T, and there is also a data flow dependency, then the fuzz testing driver A is marked as executable and high priority.

[0078] If there is a control flow dependency between the functions (A1, A2, A3...) in the calling sequence and the code patch T, but no data flow dependency, the fuzz testing driver A is marked as executable and low priority.

[0079] If there is neither control flow dependency nor data flow dependency between the functions (A1, A2, A3...) in the call sequence and the code patch T, the fuzz test driver A is marked as unexecutable.

[0080] Step 3: Fuzz test driver selection and execution: According to the analysis results in step 2, the roughly executable fuzz test driver is selected and run in sequence according to the corresponding priority.

[0081] Figure 3 is a schematic diagram of the structure of a continuous fuzzy testing device based on static analysis technology provided in an embodiment of the present application. Figure 3 As shown, the device at least includes:

[0082] Extraction module 301, used to extract the test interface of the target fuzz test driver in the project to be tested;

[0083] An analysis module 302 is used to analyze the control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch by using static analysis technology;

[0084] A determination module 303, used to determine whether the target fuzz test driver is executed and the execution priority based on the analysis results of the control flow dependency and the data flow dependency;

[0085] The selection module 304 is used to select an executable fuzz test driver in the project to be tested and perform continuous fuzz testing based on priority.

[0086] In some embodiments, the analysis module 302 specifically includes:

[0087] A first analysis unit is used to analyze whether there is a control flow dependency between the test interface of the target fuzz test driver and the submitted code patch through a static analysis technology;

[0088] The second analysis unit is used to further analyze whether there is a data flow dependency between the test interface of the target fuzz test driver and the submitted code patch if there is a control flow dependency.

[0089] In some embodiments, the analysis module 302 is specifically used to:

[0090] The control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch are analyzed by the static analysis tool Joern.

[0091] In some embodiments, the determination module 303 is specifically configured to:

[0092] When both control flow dependency and data flow dependency exist, the target fuzz testing driver is marked as executable and high priority;

[0093] When there are control flow dependencies but no data flow dependencies, mark the target fuzz driver as executable and low priority;

[0094] When there are no control flow dependencies and data flow dependencies, the target fuzz testing driver is marked as non-executable.

[0095] In some embodiments, the extraction module 301 is specifically used to:

[0096] Based on the documents or header files in the project to be tested, obtain the external interface information of the project to be tested; convert the source code of the target fuzz test driver into an abstract syntax tree;

[0097] Based on the function node information of the abstract syntax tree, the functions of the external interface of the project to be tested are marked to determine the test interface sequence of the target fuzz test driver.

[0098] It is understandable that the detailed functional implementation of each of the above-mentioned units / modules can be found in the introduction of the above-mentioned method embodiment, and will not be described in detail here. It should be understood that the above-mentioned device is used to execute the method in the above-mentioned embodiment, and the corresponding program module in the device has a similar implementation principle and technical effect as described in the above-mentioned method. The working process of the device can refer to the corresponding process in the above-mentioned method, and will not be described in detail here.

[0099] Based on the method in the above embodiment, an embodiment of the present application provides an electronic device. The device may include: at least one memory for storing programs and at least one processor for executing the programs stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method described in the above embodiment.

[0100] Figure 4 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application, such as Figure 4 As shown, the electronic device may include: a processor 401, a communication interface 402, a memory 403 and a communication bus 404, wherein the processor 401, the communication interface 402 and the memory 403 communicate with each other through the communication bus 404. The processor 401 may call the software instructions in the memory 403 to execute the method described in the above embodiment.

[0101] In addition, the logic instructions in the above-mentioned memory 403 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the relevant technology or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present application.

[0102] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0103] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0104] It is understandable that the processor in the embodiment of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0105] The method steps in the embodiments of the present application can be implemented by hardware, or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory (Random Access Memory, RAM), flash memory, read-only memory (Read-Only Memory, ROM), programmable read-only memory (Programmable ROM, PROM), erasable programmable read-only memory (Erasable PROM, EPROM), electrically erasable programmable read-only memory (Electrically EPROM, EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0106] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loading and executing computer program instructions on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted by a computer-readable storage medium. The computer instructions can be transmitted from a website site, a computer, a server or a data center to another website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, a data center, etc. that contains one or more available media integrated. 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 drive (SSD)), etc.

[0107] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0108] It is easy for those skilled in the art to understand that the above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A continuous fuzz testing method based on static analysis technology, characterized in that: include: Extract the test interface of the target fuzz test driver in the project to be tested; Analyze the control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch by static analysis technology; Determine whether the target fuzz test driver is executed and the priority of execution based on the analysis results of the control flow dependency and the data flow dependency; An executable fuzz test driver in the project to be tested is selected and continuous fuzz testing is performed based on priority.

2. The continuous fuzz testing method according to claim 1, characterized in that: The analyzing the control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch by using static analysis technology includes: Analyze whether there is a control flow dependency between the test interface of the target fuzz test driver and the submitted code patch by static analysis technology; If there is a control flow dependency, it is further analyzed whether there is a data flow dependency between the test interface of the target fuzz test driver and the submitted code patch.

3. The continuous fuzz testing method according to claim 1 or 2, characterized in that: The control flow dependency and data flow dependency between the test interface of each fuzz test driver and the submitted code patch are analyzed by static analysis technology, including: The control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch are analyzed by the static analysis tool Joern.

4. The continuous fuzz testing method according to claim 1, characterized in that: The determining whether the target fuzz test driver is executed and the execution priority based on the analysis results of the control flow dependency and the data flow dependency includes: When both the control flow dependency and the data flow dependency exist, marking the target fuzz testing driver as executable and high priority; When there is a control flow dependency but no data flow dependency, marking the target fuzz testing driver as executable and low priority; When there are no control flow dependencies and data flow dependencies, the target fuzz testing driver is marked as non-executable.

5. The continuous fuzz testing method according to claim 1, characterized in that: The test interface of the target fuzz test driver in the project to be tested is extracted, including: Based on the documents or header files in the project to be tested, obtaining the external interface information of the project to be tested; converting the source code of the target fuzz test driver into an abstract syntax tree; Based on the function node information of the abstract syntax tree, the functions of the external interface of the project to be tested are marked to determine the test interface sequence of the target fuzzy test driver.

6. A continuous fuzz testing device based on static analysis technology, characterized in that: include: An extraction module, used to extract the test interface of the target fuzz test driver in the project to be tested; An analysis module, used for analyzing the control flow dependency and data flow dependency between the test interface of the target fuzz test driver and the submitted code patch by using static analysis technology; A determination module, used to determine whether the target fuzz test driver is executed and the priority of execution based on the analysis results of the control flow dependency and the data flow dependency; The selection module is used to select an executable fuzz test driver in the project to be tested and perform continuous fuzz testing based on priority.

7. The continuous fuzzy testing device according to claim 6, characterized in that: The analysis module comprises: A first analysis unit, configured to analyze whether there is a control flow dependency between the test interface of the target fuzz test driver and the submitted code patch by using a static analysis technique; The second analyzing unit is used to further analyze whether there is a data flow dependency between the test interface of the target fuzz test driver and the submitted code patch if there is a control flow dependency.

8. The continuous fuzzy testing device according to claim 6, characterized in that: The determination module is specifically used for: When both the control flow dependency and the data flow dependency exist, marking the target fuzz testing driver as executable and high priority; When there is a control flow dependency but no data flow dependency, marking the target fuzz testing driver as executable and low priority; When there are no control flow dependencies and data flow dependencies, the target fuzz testing driver is marked as non-executable.

9. An electronic device / image signal generator / network device / transmitter / terminal / base station / industrial computer, characterized in that: include: at least one memory for storing a computer program; At least one processor is used to execute the program stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method according to any one of claims 1 to 5.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program runs on a processor, the processor is caused to execute the method according to any one of claims 1 to 5.

Images