A code detection method and device, a storage medium and an electronic device

Abstract

The specification discloses a code detection method and device, a storage medium and an electronic device, wherein the method comprises: acquiring a code to be detected, generating a syntax tree, determining a data flow and a control flow of the code to be detected based on the syntax tree, generating a data dependency graph based on the data flow, the data dependency graph comprising a plurality of nodes and data dependency edges corresponding to each node, generating a control flow graph based on the control flow, embedding the data dependency edges into the control flow graph, generating a hybrid dependency graph, performing code risk detection based on the hybrid dependency graph, and generating a code risk detection report.

Description

Technical Field

[0001] This specification relates to the field of code detection technology, and in particular to a code detection method, apparatus, storage medium, program product, and electronic device. Background Technology

[0002] In existing technologies, the detection of policy code relies on general code detection tools or simple rule matching methods, which are difficult to handle complex associations or logical relationships, are prone to false positives or false negatives, are time-consuming, have low inspection efficiency, and have weak recognition capabilities, resulting in poor detection results and failing to provide reliable assurance for the quality of policy code. Summary of the Invention

[0003] This specification provides a code detection method, apparatus, storage medium, and electronic device, the technical solution of which is as follows:

[0004] Firstly, this specification provides a code detection method, which includes:

[0005] Obtain the code to be tested and generate a syntax tree;

[0006] The data flow and control flow of the code to be detected are determined based on the syntax tree.

[0007] A data dependency graph is generated based on the data flow; the data dependency graph includes multiple nodes and the data dependency edges corresponding to each node.

[0008] Generate a control flow graph based on the control flow;

[0009] Embed data dependency edges into the control flow graph to generate a hybrid dependency graph;

[0010] Code risk detection is performed based on a hybrid dependency graph, generating a code risk detection report. The code risk detection includes null value propagation detection, value domain conflict detection, and redundant code detection.

[0011] Code risk detection is performed based on a hybrid dependency graph, generating a code risk detection report, including:

[0012] Null value propagation detection is performed based on the hybrid dependency graph to obtain the null value propagation detection results;

[0013] Value domain conflict detection is performed based on the hybrid dependency graph to obtain the value domain conflict detection results;

[0014] Redundancy detection is performed based on a hybrid dependency graph, and the redundancy detection results are obtained.

[0015] Based on the results of null value propagation detection, value domain conflict detection, and redundant code detection, a code risk detection report is generated.

[0016] Generate a control flow graph based on the control flow, including:

[0017] Define the continuous, branchless execution logic in the syntax tree as basic blocks;

[0018] Based on the control structure in the control flow, establish the execution jump relationship between basic blocks and generate control flow edges;

[0019] By using basic blocks as nodes and control flow edges as edges connecting the nodes, a control flow graph is generated.

[0020] Secondly, this specification provides a code detection device, which includes:

[0021] The acquisition module is used to acquire the code to be detected and generate a syntax tree;

[0022] The analysis module is used to determine the data flow and control flow of the code to be detected based on the syntax tree;

[0023] The first generation module is used to generate a data dependency graph based on the data flow; the data dependency graph includes multiple nodes and data dependency edges corresponding to each node.

[0024] The second generation module is used to generate a control flow graph based on the control flow.

[0025] The fusion module is used to embed data dependency edges into the control flow graph to generate a hybrid dependency graph;

[0026] The detection module is used to perform code risk detection based on the hybrid dependency graph and generate a code risk detection report. The code risk detection includes null value propagation detection, value domain conflict detection, and redundant code detection.

[0027] The detection module is specifically used for:

[0028] Null value propagation detection is performed based on the hybrid dependency graph to obtain the null value propagation detection results;

[0029] Value domain conflict detection is performed based on the hybrid dependency graph to obtain the value domain conflict detection results;

[0030] Redundancy detection is performed based on a hybrid dependency graph, and the redundancy detection results are obtained.

[0031] Based on the results of null value propagation detection, value domain conflict detection, and redundant code detection, a code risk detection report is generated.

[0032] The second generation module is specifically used for:

[0033] Define the continuous, branchless execution logic in the syntax tree as basic blocks;

[0034] Based on the control structure in the control flow, establish the execution jump relationship between basic blocks and generate control flow edges;

[0035] By using basic blocks as nodes and control flow edges as edges connecting the nodes, a control flow graph is generated.

[0036] Thirdly, this specification provides a computer storage medium storing multiple instructions adapted for loading by a processor and executing the above-described method steps.

[0037] Fourthly, this specification provides an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0038] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0039] In one or more embodiments of this specification, by generating a syntax tree of the code to be detected, the dependencies between variables become clearer, making the detection of the code more accurate. The separation and extraction of data flow and control flow can capture the dependencies between variables and the execution path logic respectively. The data dependency graph accurately locates the propagation chain between variables, while the control flow graph covers all possible execution branches. The fusion of the two graphs yields a hybrid dependency graph. Risk detection on the hybrid dependency graph can efficiently locate risks caused by data flow and execution logic, effectively reduce false positives or false negatives, improve code detection efficiency and detection rate, and provide reliable assurance for code quality. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a scenario illustration of a code detection method provided in this manual;

[0042] Figure 2 This is a flowchart illustrating a code detection method provided in this manual;

[0043] Figure 3 This is a flowchart illustrating the optimization process of data dependency graph construction in a code detection method provided in this manual;

[0044] Figure 4 This is a flowchart illustrating the code detection and risk marking process in a code detection method provided in this manual;

[0045] Figure 5This is a flowchart illustrating the compliance check process in one of the code detection methods provided in this manual;

[0046] Figure 6 This is a flowchart illustrating an example of a code detection method provided in this manual;

[0047] Figure 7 This is a schematic diagram of the structure of a code detection device provided in this manual;

[0048] Figure 8 This is a schematic diagram of the structure of an electronic device provided in this specification;

[0049] Figure 9 This is a schematic diagram of the operating system and user space provided in this manual;

[0050] Figure 10 yes Figure 9 Architecture diagram of the Android operating system in China;

[0051] Figure 11 yes Figure 9 Architecture diagram of the iOS operating system. Detailed Implementation

[0052] The technical solutions in this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0053] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0054] The present specification will now be described in detail with reference to specific embodiments.

[0055] Please see Figure 1 This is a schematic diagram of a code detection system provided in this specification. Figure 1 As shown, a code detection system can include at least 100 server-side components and a client cluster.

[0056] A client cluster can include at least one client, such as Figure 1 As shown, it specifically includes client 1 corresponding to user 1, client 2 corresponding to user 2, ..., client n corresponding to user n, where n is an integer greater than 0.

[0057] Each client in the client cluster can be used to initiate code detection requests, display detection results, and receive remediation instructions after detection. In specific application scenarios, clients can be electronic devices with communication capabilities, including but not limited to: wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices can have different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), and electronic devices in 5G networks or future evolved networks.

[0058] The server-side 100 can be a standalone server device, such as a rack-mount, blade, tower, or cabinet-mount server, or a workstation, mainframe, or other hardware device with strong computing power. Alternatively, it can be a server cluster composed of multiple servers. The servers in the cluster can be arranged symmetrically, where each server is functionally and hierarchically equivalent in the transaction chain, and each server can independently provide services. Providing services independently can be understood as not requiring the assistance of other servers. The core basis for choosing the server-side hardware form factor can be the policy scale and the required inspection efficiency.

[0059] In one or more embodiments of this specification, the server 100 can establish a communication connection with at least one client in the client cluster, and complete the data interaction during the code detection process based on the communication connection, such as the transmission of client detection instructions, or the visualization of the detection results obtained by the server 100 based on the code detection method of this specification on the client; or the server 100 can obtain the repair instructions after detection from the client and repair the code to be detected.

[0060] It should be noted that the server 100 establishes a communication connection with at least one client in the client cluster via a network for interactive communication. This network can be a wireless network or a wired network. Wireless networks include, but are not limited to, cellular networks, wireless LANs, infrared networks, or Bluetooth networks. Wired networks include, but are not limited to, Ethernet, universal serial bus (USB), or controller area networks. In one or more embodiments of the specification, technologies and / or formats including Hyper Text Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network (such as target compressed packets). Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0061] The code detection system embodiments provided in this specification and the code detection methods in one or more embodiments belong to the same concept. The execution entity corresponding to the code detection method in one or more embodiments of this specification can be the aforementioned server 100; the execution entity corresponding to the code detection method in one or more embodiments of this specification can also be the electronic device corresponding to the client, depending on the actual application environment. The implementation process of the code detection system embodiments can be detailed in the following method embodiments, and will not be repeated here.

[0062] based on Figure 1 The following is a detailed description of the code detection method provided by one or more embodiments of this specification, illustrated in the scenario diagram.

[0063] Please see Figure 2 This document provides a flowchart illustrating a code detection method according to one or more embodiments. This method can be implemented using a computer program and can run on a code detection device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application. The code detection device can be a service platform.

[0064] Specifically, the code detection method includes:

[0065] S100: Obtain the code to be tested and generate a syntax tree.

[0066] The code to be detected can be the policy code to be detected. The application scenarios corresponding to the detection process of the policy code can include network service scenarios, financial scenarios, intelligent manufacturing scenarios and network security scenarios. In these application scenarios, the core of code detection is to check the logical consistency, completeness and correctness of structured rules or policies in order to detect risks.

[0067] The syntax tree can include the abstract syntax tree.

[0068] Specifically, the code to be detected is obtained, the application scenario corresponding to the code is determined, and the corresponding lexical and grammatical rules are determined based on the application scenario. The code to be detected is then parsed to generate a syntax tree. By judging the application scenario, the detection method can adapt to the lexical and grammatical rules under different scenarios. Without the need to write data preparation in advance, a data dependency graph can be cold-started to build, which improves the usability and efficiency of the code detection method.

[0069] In practice, the syntax tree can be an abstract syntax tree with semantic labels. The process of generating the syntax tree includes: determining the lexical and grammatical rules of the code to be tested through a domain-specific parser, parsing various grammatical structures such as conditional branches and nested functions, generating an abstract syntax tree, and annotating the variable scope, type, and contextual relationships on the abstract syntax tree to obtain an abstract syntax tree with semantic labels.

[0070] In specific implementations, in network service or financial scenarios, the code to be detected can be risk control strategy code. The strategy code is obtained, a corresponding abstract syntax tree is generated, and a data dependency graph and control flow graph are generated based on the abstract syntax tree. These graphs are then merged to obtain a hybrid dependency graph. Strategy risk detection is performed based on the hybrid dependency graph, resulting in a risk detection report that is visualized and the locations of existing risks are marked. In intelligent manufacturing scenarios, the code to be detected can be equipment control logic code or production scheduling code. The equipment control logic code or production scheduling code is obtained, a corresponding abstract syntax tree is generated, and a data dependency graph and control flow graph are generated based on the abstract syntax tree. These graphs are then merged to obtain a hybrid dependency graph. Equipment control logic risk detection or production scheduling risk detection is performed based on the hybrid dependency graph, resulting in a risk detection report that is visualized. In cybersecurity scenarios, the code to be detected can be security protection rule code. The security protection rule code is obtained, a corresponding abstract syntax tree is generated, and a data dependency graph and control flow graph are generated based on the abstract syntax tree. These graphs are then merged to obtain a hybrid dependency graph, and security protection rule risk detection is performed based on the hybrid dependency graph, resulting in a risk detection report that is visualized.

[0071] S200: Determines the data flow and control flow of the code to be detected based on the syntax tree.

[0072] S300: Generates data dependency graphs based on data flows.

[0073] S400: Generates control flow graphs based on control flow.

[0074] Among them, the data flow is the process of the fields or variables in the code to be detected, the control flow is the execution path of the code to be detected, and the data dependency graph includes multiple nodes and the data dependency edges corresponding to each node. The nodes can be variable nodes.

[0075] Specifically, the syntax tree is traversed, variables in the code to be tested are marked, the definition and usage chains of each variable are determined, and a data flow is obtained. The nodes of the syntax tree are traversed, and continuous, branchless execution logic is identified as basic blocks. The execution jump relationships of each basic block are determined, resulting in a control flow. Based on the data flow, the usage chains between nodes are obtained, and the data dependency edges corresponding to each node are obtained, generating a data dependency graph. This data dependency graph is used for code risk detection, solving the problem that traditional static tools cannot trace variable dependency chains, improving the detection rate of code risks, and reducing false positives and false negatives. In the control flow, continuous, branchless execution logic is merged into basic blocks. Based on the control structures in the control flow, execution jump relationships between basic blocks are established, generating control flow edges. Basic blocks are used as nodes, and control flow edges are used as edges connecting nodes, generating a control flow graph. The control structures can include conditional branches (IF-ELSE), conditional triggers (WHEN-THEN), loops, and rule calls, etc.

[0076] In the specific implementation process, when constructing the data dependency graph, four types of graph nodes can be defined: variable nodes, literal nodes, function nodes, and conditional branch nodes. When constructing the data dependency graph, an incremental construction algorithm can be used, which only re-parses the modified or updated code snippets. This can ensure that the update delay of the data dependency graph is less than the preset delay threshold in scenarios with thousands of lines of strategy code, effectively improving code detection efficiency.

[0077] In the specific implementation process, such as Figure 3 As shown, when executing the code testing method, the administrator 301 checks the processor CPU and memory metrics to determine if the hardware resources are normal. Then, the administrator monitors the execution of the code testing method through the running monitoring module. If a timeout is detected in the data dependency graph construction, a timeout alarm is triggered. The developer 303 optimizes the graph construction algorithm to generate the data dependency graph.

[0078] S500: Embed data dependency edges into the control flow graph to generate a hybrid dependency graph.

[0079] Specifically, based on data flow analysis and control flow analysis, the obtained control flow graph is used as the basis to determine the data dependency edges of the corresponding nodes in the data dependency graph. The data dependency edges are then embedded into the corresponding nodes in the control flow graph to generate a hybrid dependency graph containing variable nodes and conditional branch nodes, which solves the problem that traditional detection tools cannot trace variable dependency chains.

[0080] In the specific implementation process, the data dependency graph and the control flow graph are merged into an attribute graph (i.e., a hybrid dependency graph). The attributes of the edges in the attribute graph record the conditional expressions and data operation types, such as assignment or operation, so that the attribute graph supports multi-dimensional queries, thereby improving the ability of code detection methods to locate risks and improving the accuracy of risk detection.

[0081] In another implementation, the data dependency graph and the control flow graph are merged to obtain a hybrid dependency graph. The specific steps include: establishing a mapping relationship between nodes in the control flow graph and variable nodes in the data dependency graph through a node alignment mechanism; mapping the execution jump relationships corresponding to the control flow graph to the corresponding edges in the data dependency graph based on the mapping relationship; and merging to obtain the hybrid dependency graph. The method for establishing the mapping relationship includes: parsing the unique identifiers of variable nodes in the data dependency graph; parsing the node identifiers in the control flow graph; and merging or establishing associations between matching node identifiers and the unique identifiers of variable nodes to establish the mapping relationship.

[0082] S600: Performs code risk detection based on a hybrid dependency graph and generates a code risk detection report.

[0083] Specifically, a graph traversal algorithm is used to perform code risk detection on the hybrid dependency graph. The code risk detection can include: null value propagation detection, value domain conflict detection, and dead code detection. The detection results are obtained and a visual code risk detection report is generated.

[0084] In practical implementation, null value propagation detection traces the source of variables by performing backward slicing on the mixed dependency graph and marks uninitialized features. Range conflict detection derives the range of variable values ​​based on symbolic execution, identifying out-of-bounds usage. Dead code identification, combined with control flow graph detection, identifies nodes that are not called by any branch or covered by any path.

[0085] In the specific implementation process, after obtaining the code risk detection report, the code risk detection report can be visualized. Specifically, through the integrated development tool plugin, the code to be detected and the code risk detection report can be displayed in an editable form on the strategy editing interface. The risk location can be marked in real time on the strategy editing interface. For example, red wavy lines can be used to mark null value risks, and green horizontal lines can be used to mark value domain conflict risks. This allows developers to more intuitively identify nodes with risks and thus fix the risk nodes in a timely manner.

[0086] In one implementation, the code risk detection report may include a data dependency graph, a control flow graph, a hybrid dependency graph, and risk nodes or segments of the code to be detected. When the code risk detection report is visualized, the code to be detected can be directly displayed and the risky locations can be marked. Alternatively, the data dependency graph, control flow graph, and hybrid dependency graph can be displayed and the risk nodes can be marked in the graph.

[0087] In the specific implementation process, such as Figure 4As shown, developers upload the code for the new strategy version (corresponding to use case UC1 in the figure), perform lexical and syntactic analysis on the code to generate a syntax tree (corresponding to use case UC2 in the figure), construct a data dependency graph for the incremental code based on the syntax tree (corresponding to use case UC3 in the figure), perform multi-dimensional checks based on the data dependency graph to obtain a code risk detection report (corresponding to use case UC4 in the figure), and visualize the code risk report, displaying risk markers visually using wavy lines and other methods for developers to view.

[0088] In practical implementation, experiments on the code detection method showed that it detected 147 instances of uninitialized variables (null value risk), 89 instances of value domain conflicts, and 32 instances of dead code (redundant code risk) in over two hundred real-world strategies, achieving a 40-fold efficiency improvement compared to traditional manual review. In specific domain applications, such as network services, this code detection method reduced customer complaints caused by strategy logic errors by 67% and improved compliance audit efficiency by 55%, effectively reducing risks in network service processes. The aforementioned code detection method consumes relatively little memory during the analysis and detection of a large number of strategies; the memory usage in analyzing thousands of lines of strategies is less than 500MB, and it can achieve thousands of concurrent detections on an 8-core, 16GB server.

[0089] In another implementation, the above-mentioned code detection method can also detect configurable policies. By configuring policies through configuration operations, generating a syntax tree based on the policies, and converting the policies into a parsable structure based on the syntax tree, the methods can be directly detected. Essentially, the logic is the same as that of code detection. Whether detecting policies or code, the analysis of control flow and propagation flow and code risk detection are used to identify logical vulnerabilities, and the specific detection steps are the same.

[0090] In this specification, by generating a syntax tree of the code to be detected, the dependencies between variables become clearer, making the detection of the code more accurate. The separation and extraction of data flow and control flow can capture the dependencies between variables and the execution path logic respectively. The data dependency graph accurately locates the propagation chain between variables, while the control flow graph covers all possible execution branches. The fusion of the two graphs yields a hybrid dependency graph. Risk detection on the hybrid dependency graph can efficiently locate risks caused by data flow and execution logic, effectively reduce false positives or false negatives, improve code detection efficiency and detection rate, and provide reliable assurance for code quality. The resulting code risk detection report has high accuracy, making it easy for developers to quickly locate and fix problems.

[0091] In one embodiment of this specification, obtaining the code to be detected and generating a syntax tree includes:

[0092] The code to be detected is obtained, and its syntax is analyzed to obtain syntactic units and their corresponding semantic information.

[0093] The grammatical units and semantic information are validated based on preset grammatical rules.

[0094] A syntax tree is generated based on the validated syntax units and semantic information.

[0095] Specifically, the code to be tested is obtained, lexical and syntactic analysis is performed on the code to be tested to obtain syntactic units and corresponding semantic information, the syntactic units and semantic information are verified based on preset syntactic rules, and a syntax tree is generated based on the verified syntactic units and semantic information.

[0096] In the specific implementation process, lexical analysis is used to analyze the code to be tested, breaking down the code text into the smallest syntactic units such as keywords, identifiers, operators, and constants. Syntactic analysis is performed according to preset syntactic rules, recursively parsing the hierarchical logical relationship of the sequence of smallest syntactic units, constructing a tree structure containing root nodes and child nodes, including condition nodes and action nodes. Then, the legality of the syntax is verified, and an abstract syntax tree that accurately reflects the code logic is output. The preset syntactic rules can be historical syntactic rules or exclusive syntactic rules customized based on the application scenario corresponding to the code to be tested, which can meet the needs of different syntactic rules in different scenarios.

[0097] In this specification, a syntax tree of the code to be detected is constructed, and parsing is performed based on the syntax tree. This method is more accurate than regular expression matching and probabilistic inference, which can effectively reduce the false alarm rate and improve the efficiency and accuracy of code risk detection.

[0098] In one embodiment of this specification, generating a data dependency graph based on a data flow includes:

[0099] The assignment statement is parsed to obtain the first variable of the assignment statement, and the dependency relationship between the first variables is determined to generate the assignment dependency edge of the first variable;

[0100] The branch structure is parsed to obtain the second variable of the branch structure, and the condition constraint edges of the second variable are generated based on the judgment conditions corresponding to the branch structure.

[0101] The function call is parsed to obtain the third variable of the function call, and the dependencies between the third variables are determined to generate the function dependency edges of the third variables;

[0102] Using the first, second, and third variables as nodes, a data dependency graph is generated based on assignment dependency edges, conditional constraint edges, and functional dependency edges.

[0103] The data flow includes assignment statements, branching structures, and function calls; the first variable may include the left and right values ​​of the assignment statement, and the third variable may include the input parameters and return value of the function call.

[0104] Specifically, the assignment statement is parsed to determine the first variable of the assignment statement and the dependencies between the first variables, such as the relationship between lvalues ​​and rvalues. Assignment dependency edges for the first variables are generated. The branch structure is parsed to obtain the second variable of the branch structure. Condition constraint edges for the second variable are generated based on the judgment conditions corresponding to the branch structure. The function call is parsed to obtain the third variable of the function call and the dependencies between the third variables are determined. Function dependency edges for the third variable are generated. The first, second, and third variables are used as nodes, and the nodes are connected based on assignment dependency edges, condition constraint edges, and function dependency edges to generate a data dependency graph.

[0105] In the specific implementation process, the variable dependency relationship between the left and right values ​​of the assignment statement is modeled, the branch structure such as IF-ELSE and WHEN-THEN is analyzed, conditional constraint edges are generated, the function call nodes are parsed, and the dependency chain between input parameters and return values ​​is obtained, thereby generating a data dependency graph.

[0106] In the specific implementation process, the code to be tested may include assignment statements, branching structures, and function calls. Assignment statements are parsed to identify their left and right values, establishing variable dependencies between them and mapping these dependencies to variable dependency edges in the data dependency graph. Branching structures are parsed, including CASE-WHEN and IF-ELSE structures. The judgment conditions for each branch are extracted, and conditional constraint edges are generated based on these conditions. These conditional constraint edges are added to the data dependency graph to represent the constraints of branch execution logic on data dependencies. Function call nodes are parsed to identify their input parameters and return values. The upstream data dependencies of the input parameters and the downstream data dependencies of the return values ​​are traced, constructing dependency chains between input parameters and return values. These dependency chains are mapped to function dependency edges in the data dependency graph. Variable dependency edges, conditional constraint edges, and function dependency edges are integrated to form a complete data dependency graph.

[0107] In the specific implementation process, the steps to establish the variable dependency relationship between lvalues ​​and rvalues ​​include: identifying all variables, constants and expression factors contained in the rvalue; determining that the assignment source of the lvalue variable is the calculation result of the variables, constants and expressions in the rvalue; if the rvalue contains nested assignment expressions, then recursively parse the lvalues ​​and rvalues ​​of the nested assignment expressions, establish the variable dependency relationship of the nested level, and then associate it with the lvalue of the outermost assignment statement.

[0108] In the specific implementation process, the steps for constructing the dependency chain between input parameters and return values ​​include: parsing the function definition, determining the source of the actual parameters corresponding to the function's formal parameters, tracing the upstream assignment relationships and variable reference relationships of each actual parameter in the code to form the upstream dependency sub-chain of input parameters, parsing the internal logic of the function body, establishing the internal dependency relationship from the formal parameters to the function's return value to form the internal dependency sub-chain of the function, tracing the downstream variable reference and assignment relationships of the return value after the function call to form the downstream dependency sub-chain of the return value; and connecting the upstream dependency sub-chain, the internal dependency sub-chain, and the downstream dependency sub-chain to form a complete dependency chain between input parameters and return values.

[0109] In the specific implementation process, when constructing the dependency chain between input parameters and return values, it also includes: detecting whether there are circular dependencies or contradictory constraints in the dependency chain; if there are circular dependencies, marking the circular dependency nodes and associated edges in the data dependency graph; if there are contradictory constraints, determining the valid constraints based on the code execution priority rules, retaining the dependency edges corresponding to the valid constraints, and marking the invalid constraints and associated nodes.

[0110] In this manual, by parsing the code to be tested, the assignment dependencies, condition constraints, and function dependencies between variables are transformed into a data dependency graph, making the logical connections of the code more intuitive, reducing the complexity of understanding, and allowing for quick tracing of variable propagation and constraint paths through the dependency graph, accurately locating risk locations, and improving the reliability of code detection.

[0111] In one embodiment of this specification, code risk detection is performed based on a hybrid dependency graph to generate a code risk detection report, including:

[0112] Null value propagation detection is performed based on the hybrid dependency graph to obtain the null value propagation detection results;

[0113] Value domain conflict detection is performed based on the hybrid dependency graph to obtain the value domain conflict detection results;

[0114] Redundancy detection is performed based on a hybrid dependency graph, and the redundancy detection results are obtained.

[0115] Based on the results of null value propagation detection, value domain conflict detection, and redundant code detection, a code risk detection report is generated.

[0116] Code risk detection includes null value propagation detection, value domain conflict detection, and redundant code detection.

[0117] Specifically, null value propagation detection is performed based on the hybrid dependency graph to determine whether each variable node on the propagation path of the variable node is initialized. If there are uninitialized variables, there is a risk of null values, and a null value propagation detection result is obtained. Value domain conflict detection is performed based on the hybrid dependency graph to determine whether the value of the variable node exceeds the corresponding value range, and a value domain conflict detection result is obtained. Redundant code detection is performed based on the hybrid dependency graph to determine whether a node is a node that has not passed through any execution path or propagation path. If so, the node is a redundant node, and a redundant code detection result is obtained. Based on the null value propagation detection result, value domain conflict detection result, and redundant code detection result, a code risk detection report is generated.

[0118] In practice, null value propagation detection involves tracing the propagation path of uninitialized variables backward along the data dependency graph, marking code locations that may cause runtime exceptions. Range conflict detection derives the maximum and minimum values ​​of variables through symbolic execution, obtaining the variable's value range and identifying out-of-bounds risks in arithmetic operations. Redundant code detection, combined with control flow graph detection, identifies nodes not covered by any execution path; the content corresponding to these nodes constitutes the redundancy rules.

[0119] In this manual, the code to be tested is organized into a hybrid dependency graph. The hybrid dependency graph clearly shows the propagation path and dependency relationship corresponding to each node. Risk detection based on the hybrid dependency graph can accurately and quickly locate risky code segments according to the clear node propagation path. This not only improves the accuracy and detection rate of code risk detection, but also locates the entire propagation execution path and dependency chain with risk. This makes it convenient to fix the risks in the code to be tested according to the propagation execution path and dependency chain, thereby ensuring the security and stability of code execution.

[0120] In one embodiment of this specification, null value propagation detection is performed based on a hybrid dependency graph to obtain null value propagation detection results, including:

[0121] Perform a backward slice operation on the variable nodes in the mixed dependency graph to determine the data propagation path of the variable nodes;

[0122] Determine if there are any uninitialized dependency variables in the data propagation path;

[0123] If there are uninitialized dependency variables in the data propagation path, the variable node is marked as a risk node, and the null value propagation detection result is obtained.

[0124] Specifically, starting from the variable node in the hybrid dependency graph, the code logic that affects the execution or value of the variable node is traced backward to determine the data propagation path corresponding to the variable node. It is then determined whether there are any uninitialized dependency variables in the data propagation path. If there are uninitialized dependency variables, the variable node is marked as a risk node, and the corresponding data propagation path is marked as a risk code fragment.

[0125] In the specific implementation process, if there are uninitialized dependent variables in the propagation path of the variable node, then the variable node, the line of code corresponding to the uninitialized dependent variable, and all paths from the variable node to the dependent variable will be marked with a risk.

[0126] For example, the code to be tested may include an expression node: t.value=f.a+fb. A data dependency graph is generated based on the code to be tested. The source of fa and fb is traced back along the data dependency graph. If any variable is not initialized, the expression is marked as high risk, and the risky code line and dependency path are marked.

[0127] In practical implementation, the above-mentioned null value propagation detection can be used to detect uninitialized variables and nodes without default values, as well as nodes that return empty data queries. The detected risk nodes can also be marked with different risk levels based on their type, so that different display methods can be used to clearly show them to developers during visualization, quickly locate risks and clearly distinguish the degree of risk.

[0128] This manual addresses the inefficiency of manually checking for uninitialized variables by performing backward slicing on the hybrid dependency graph. By accurately locating variable nodes and associated propagation paths, it helps developers quickly focus on the source of risks, reduce the time cost of risk investigation, and improve risk detection efficiency.

[0129] In one embodiment of this specification, range conflict detection is performed based on a hybrid dependency graph to obtain range conflict detection results, including:

[0130] Determine the value range of variable nodes based on the hybrid dependency graph;

[0131] Determine if the variable node is within the range of values;

[0132] If a variable node is outside the range of values, the variable node is marked as a risk node, and the value range conflict detection result is obtained.

[0133] Specifically, based on the hybrid dependency graph, the value range of variable nodes is derived through symbolic execution. It is then determined whether the variable node is within the value range and whether the statements related to the variable node conflict with the value range. If the variable node is not within the value range, it is marked as a risk node. If the statements related to the variable node do not meet the corresponding value range, the corresponding code is marked as a risk fragment, thus obtaining the value range conflict detection result.

[0134] For example, if the code to be tested includes a conditional statement: WHEN t.rule_score>100, and the symbolic execution derivation variable t.rule_score has a value range of [0,100], then the maximum value of the variable is 100. Therefore, the above conditional statement exceeds the value range of the variable, and the conditional statement is invalid. In this case, the corresponding variable node and code fragment will be marked as risk nodes and risk fragments.

[0135] In the specific implementation process, the steps for deriving the value range of variable nodes through symbolic execution include: representing the variable node with symbols, preserving the abstract attributes of the variable node, extracting the logical constraints of the variable node from the hybrid dependency graph, such as the variable value being greater than a first threshold and less than a second threshold, merging all constraints using symbolic operations, deriving the symbolic value range of the variable node, propagating the derived value range to all nodes according to the data flow edge corresponding to the variable node in the hybrid dependency graph, judging whether there is a contradiction in the derivation results, thereby judging whether the variable node and the code fragments related to the variable node are risky, and obtaining a risk detection report.

[0136] For example, the logical constraints corresponding to the variable node include WHEN device_fail_1h≥5 and device_fail_1h≤10. Symbolizing the variable device_fail_1h as X=device_fail_1h, the constraints are extracted as X≥5 and X≤10. By merging the constraints, the value range of X is [5, 10]. If the subsequent related statement is risk_score=X*20, then the value range of risk_score is [100, 200]. Therefore, this statement does not conflict with the value range of X.

[0137] This specification describes how symbolic execution is used to deduce the range of variable node values ​​to assess risks. Without relying on real service data, it can abstract and analyze the legal value range and logical constraints of variables before the strategy goes live, accurately identifying hidden risks such as value range conflicts, abnormal thresholds, and unreachable branches. This effectively avoids missed detections caused by insufficient data samples or incomplete scenario coverage, significantly improving the depth and accuracy of static checks on strategy code. It also reduces the risk of misjudgments, missed judgments, or system failures caused by abnormal variable values ​​after the strategy goes live, providing quantifiable logical verification support for strategy quality.

[0138] In one embodiment of this specification, redundant code detection is performed based on a hybrid dependency graph to obtain redundant code detection results, including:

[0139] Traverse the mixed dependency graph and filter out redundant nodes;

[0140] Redundant nodes are marked as risk nodes, and the redundancy code detection results are obtained.

[0141] Redundant nodes are those not covered by the execution path.

[0142] Specifically, the mixed dependency graph is traversed to filter out isolated redundant nodes or redundant code fragments that are not covered by any execution path or data propagation path. Redundant nodes are marked as risk nodes, and redundant code fragments are marked as risk fragments, thus obtaining the redundant code detection results.

[0143] In practice, redundant code detection, also known as dead code detection, is used to identify actions following false conditions, nodes without calls, or recurring branch logic before the strategy code goes live. This not only removes redundant nodes, simplifies the code structure, and reduces execution performance loss, but also avoids the risk of misjudgment caused by logical vulnerabilities contained in dead code, thus improving the reliability of code risk detection.

[0144] For example, if we deduce that the value range of variable t.rule1 is {0,1}, the node in the mixed dependency graph can be the statement: mark t.rule1=2 as a false condition. The node content will conflict with the value range of the variable because t.rule1 cannot take the value 2. Therefore, this node is a redundant node and is marked as a risk node. The corresponding repair suggestion is generated: delete the redundant condition branch.

[0145] This manual demonstrates how redundant code detection can accurately identify logic segments in risk control strategies that can never be executed before the strategy goes live. This process eliminates redundant logic, simplifies the strategy structure, reduces maintenance costs and performance degradation, reduces the risk of missed detections, ensures the integrity and traceability of the strategy logic, and improves the execution efficiency and reliability of risk interception.

[0146] In one embodiment of this specification, the method further includes:

[0147] The risk type of the risk node is matched with the preset repair method table, and repair suggestions for the risk node are generated based on the matching results.

[0148] The code risk detection report includes risk nodes and the risk types corresponding to the risk nodes; the preset repair method table includes multiple risk types and the preset repair methods corresponding to each risk type.

[0149] Specifically, the risk type of a risk node is matched with a preset repair method table, and repair suggestions for the risk node are generated based on the matching results. For example, if the risk type of a risk node is null value risk, the corresponding repair suggestion could be to set a default value for the variable corresponding to the risk node or to set a control branch judgment for the risk node. If the risk type of a risk node is value range conflict risk, the repair suggestion could be to adjust the threshold range. If the risk type of a risk node is redundancy risk, the repair suggestion could be to delete redundant code snippets. The system can determine the corresponding repair suggestions based on the detected risk type, providing a reference for developers.

[0150] For example, when testing the code to be tested, the data dependency graph shows that the variable t.risk_score depends on f.income and f.asset. Tracing back, it is found that f.asset is not defined in the module. Therefore, the null value risk is marked on the first line of the code. Since f.asset is not initialized, a null value will cause the process to be interrupted. Based on the type of null value risk, it is matched with the preset repair method table to generate a repair suggestion, that is, add the default value: COALESCE(f.asset, 0).

[0151] This manual provides precise and actionable optimization directions for risk issues such as null value risk, value domain conflict analysis, and redundant risk control. It helps developers quickly locate the root cause of risks and complete logical corrections, effectively eliminating misjudgments, omissions, or failures caused by abnormal variable values ​​or conflicting conditional logic after the strategy is deployed. It can reduce the cost of strategy iteration and maintenance, ensure the stability of code execution, logical correctness, and the effectiveness of risk interception, and provide reliable support for applications in real-world scenarios.

[0152] In one embodiment of this specification, the method further includes:

[0153] In response to a compliance testing request, determine the compliance template corresponding to the compliance testing request;

[0154] The code to be tested is matched with a compliance template, and a compliance report is generated based on the matching results.

[0155] Specifically, the application scenario corresponding to the code to be tested is determined, multiple candidate compliance templates are obtained, and in response to the compliance testing request, the corresponding compliance template is selected from the multiple candidate compliance templates. The code to be tested is matched with the compliance template, and a compliance report is generated based on the matching result. The compliance template is a preset rule logic.

[0156] For example, the code to be tested includes a rejection reason field. The content of the field is matched against a word blacklist. If non-compliant words are found in the rejection reason field, a compliance report is generated for developers to download.

[0157] In the specific implementation process, such as Figure 5 As shown, auditors upload compliance testing requests, select the corresponding compliance template, match the compliance template with the code to be tested, and perform compliance verification (i.e., use case UC7 shown in the figure). Based on the matching results, a risk report is obtained (i.e., use case UC5 shown in the figure). Auditors can download the compliance report in a specified format, such as PDF, and send the compliance report to the developers so that the developers can modify and update the code to be tested (i.e., the remediation shown in the figure).

[0158] This manual describes a compliance check of the code, which can effectively identify potential non-compliance risks. This can not only avoid data security or regulatory conflicts caused by non-compliance, but also standardize code writing, unify technical standards, improve code readability and maintainability, reduce system vulnerabilities and performance risks caused by non-compliant code, and lay a solid foundation for stable operation and long-term iteration of the code.

[0159] In one embodiment of this specification, the method further includes:

[0160] Pattern detection is performed on the code to be detected based on a preset risk control rule base, and the pattern detection results are obtained.

[0161] Pattern detection includes detecting nesting depth and / or threshold coupling degree.

[0162] Specifically, pattern detection is performed on the code to be detected. If multiple layers of nesting are detected, a judgment is made based on the preset risk nesting threshold in the preset risk control rule base. If the number of nesting layers exceeds the preset risk nesting threshold, a risk is detected. The pattern detection based on threshold coupling focuses on identifying high-risk patterns of excessive threshold coupling in risk control strategies, such as cross-rule hard-coding of threshold reuse, threshold calculation relying on unlabeled rules, and single threshold associating with multiple rules. The coupling degree is calculated by parsing the threshold node dependency relationship and matching the high-coupling risk features in the preset risk control rule base to obtain the pattern detection result.

[0163] In this specification, pattern detection can accurately locate complex structures in strategy code, such as multi-level nesting, which are prone to logical confusion and missed judgments. By matching risk characteristics with a preset nesting level threshold, the identified risks can be repaired by decomposing nested logic, simplifying compound conditions, and adding threshold verification. This effectively reduces the complexity of strategy logic, avoids derivative risks caused by structural complexity, and improves the maintainability and execution stability of the code.

[0164] In one embodiment of this specification, an example of the above-described code detection method is as follows: Figure 6 As shown, it specifically includes:

[0165] The code inspection method can include multiple test cases to implement different functions, including test case UC1, test case UC2, test case UC3, test case UC4, test case UC41, test case UC42, test case UC43, test case UC5, test case UC6 and test case UC7.

[0166] Specifically, the process involves uploading the strategy code (UC1), parsing the strategy code to generate an abstract syntax tree (UC2), constructing a data dependency graph based on the abstract syntax tree (UC3), performing risk detection based on the data dependency graph (UC4), generating a code risk detection report (UC5), visually displaying the risk detection report to developers, and generating corresponding remediation suggestions based on the risk detection results and preset remediation logic (UC6).

[0167] The risk detection steps based on the data dependency graph include: null value propagation detection (UC41), value domain conflict detection (UC42), and redundant code detection (UC43). Null value propagation detection uses a backward data flow analysis algorithm to trace paths, preventing runtime anomalies caused by uninitialized variables and reducing the accident rate after code deployment. Value domain conflict detection uses symbolic execution to deduce value ranges, eliminating false rejections or false passes caused by logical contradictions and improving policy accuracy by up to 30%. Redundant code detection uses control flow graph coverage analysis to identify redundant policy rules, reducing policy maintenance complexity.

[0168] Additionally, compliance verification (UC7) can be performed on the code to be detected, ensuring that the policy complies with regulatory requirements by embedding a regulatory rule base.

[0169] Furthermore, the above methods may also include high-risk pattern recognition, detection of nesting depth and threshold coupling, early warning of overfitting risk, and guidance for strategy optimization.

[0170] In one embodiment of this specification, the new customer access strategy in a financial scenario obtains the strategy code for code detection. Compared to the traditional average of once every two weeks, the iteration cycle can be once every four hours on average. The resource consumption of strategy code detection is much less than the cost of GPU resources consumed by traditional testing, resulting in significant resource savings and cost benefits.

[0171] In one embodiment of this specification, after the strategy code is written, a static check is performed on the strategy code to identify risks. These risks are then repaired, a compliance report is generated, and the repaired strategy code can be directly deployed and executed. This approach can improve risk detection efficiency and detection rate with lower detection costs and provides repair suggestions, effectively improving the detection and deployment efficiency of strategy code.

[0172] The following will combine Figure 7 This manual provides a detailed description of the code detection device provided. It should be noted that... Figure 7 The code detection device shown is used to execute this specification. Figures 1-6 The methods of the embodiments shown are illustrated only in connection with this specification for ease of explanation. For specific technical details not disclosed, please refer to this specification. Figures 1-6 The example shown.

[0173] Please see Figure 7 This diagram illustrates the structure of the code detection device described in this specification. The code detection device 70 can be implemented as all or part of a server through software, hardware, or a combination of both. According to some embodiments, the code detection device 70 includes an acquisition module 710, an analysis module 720, a first generation module 730, a second generation module 740, a fusion module 750, and a detection module 760, specifically used for:

[0174] Module 710 is used to acquire the code to be detected and generate a syntax tree;

[0175] Analysis module 720 is used to determine the data flow and control flow of the code to be detected based on the syntax tree;

[0176] The first generation module 730 is used to generate a data dependency graph based on the data flow; the data dependency graph includes multiple nodes and data dependency edges corresponding to each node.

[0177] The second generation module 740 is used to generate a control flow graph based on the control flow.

[0178] The fusion module 750 is used to embed data dependency edges into the control flow graph to generate a hybrid dependency graph.

[0179] The detection module 760 is used to perform code risk detection based on the hybrid dependency graph and generate a code risk detection report.

[0180] In one embodiment, the acquisition module 710 is specifically used to: acquire the code to be detected, perform syntactic analysis on the code to be detected, and obtain syntactic units and semantic information corresponding to the syntactic units;

[0181] The grammatical units and semantic information are validated based on preset grammatical rules.

[0182] A syntax tree is generated based on the validated syntax units and semantic information.

[0183] In one embodiment, the first generation module 730 is specifically used for: the data stream including assignment statements, branch structures, and function calls;

[0184] The assignment statement is parsed to obtain the first variable of the assignment statement, and the dependencies between the first variables are determined to generate the assignment dependency edges of the first variables; the first variables include the left value and the right value of the assignment statement;

[0185] The branch structure is parsed to obtain the second variable of the branch structure, and the condition constraint edges of the second variable are generated based on the judgment conditions corresponding to the branch structure.

[0186] The function call is parsed to obtain the third variable of the function call, and the dependencies between the third variables are determined to generate the function dependency edges of the third variables; the third variable includes the input parameters and return value of the function call;

[0187] Using the first, second, and third variables as nodes, a data dependency graph is generated based on assignment dependency edges, conditional constraint edges, and functional dependency edges.

[0188] In one embodiment, the detection module 760 is specifically used for: code risk detection including null value propagation detection, value domain conflict detection, and redundant code detection;

[0189] Null value propagation detection is performed based on the hybrid dependency graph to obtain the null value propagation detection results;

[0190] Value domain conflict detection is performed based on the hybrid dependency graph to obtain the value domain conflict detection results;

[0191] Redundancy detection is performed based on a hybrid dependency graph, and the redundancy detection results are obtained.

[0192] Based on the results of null value propagation detection, value domain conflict detection, and redundant code detection, a code risk detection report is generated.

[0193] In one embodiment, the detection module 760 is specifically used to: perform a backward slicing operation on the variable nodes in the hybrid dependency graph to determine the data propagation path of the variable nodes;

[0194] Determine if there are any uninitialized dependency variables in the data propagation path;

[0195] If there are uninitialized dependency variables in the data propagation path, the variable node is marked as a risk node, and the null value propagation detection result is obtained.

[0196] In one embodiment, the detection module 760 is specifically used to: determine the value range corresponding to the variable node based on the hybrid dependency graph;

[0197] Determine if the variable node is within the range of values;

[0198] If a variable node is outside the range of values, the variable node is marked as a risk node, and the value range conflict detection result is obtained.

[0199] In one embodiment, the detection module 760 is specifically used to: traverse the hybrid dependency graph and filter out redundant nodes; redundant nodes are nodes that are not covered by the execution path;

[0200] Redundant nodes are marked as risk nodes, and the redundancy code detection results are obtained.

[0201] In one embodiment, it also includes a suggestion module, specifically used for: the code risk detection report includes risk nodes and the risk types corresponding to the risk nodes;

[0202] The risk type of the risk node is matched with the preset repair method table, and repair suggestions for the risk node are generated based on the matching results. The preset repair method table includes multiple risk types and preset repair methods corresponding to each risk type.

[0203] In one embodiment, a pattern detection module is further included, specifically used to: determine the compliance template corresponding to the compliance detection request in response to the compliance detection request;

[0204] The code to be tested is matched with a compliance template, and a compliance report is generated based on the matching results.

[0205] In one embodiment, a compliance detection module is further included, specifically used to: perform pattern detection on the code to be detected based on a preset risk control rule base, and obtain pattern detection results; the pattern detection includes detecting the nesting depth and / or detecting the threshold coupling degree.

[0206] It should be noted that the code detection device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the code detection method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the code detection device and the code detection method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0207] The serial numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0208] In this specification, by generating a syntax tree of the code to be detected, the dependencies between variables become clearer, making the detection of the code more accurate. The separation and extraction of data flow and control flow can capture the dependencies between variables and the execution path logic respectively. The data dependency graph accurately locates the propagation chain between variables, while the control flow graph covers all possible execution branches. The fusion of the two graphs yields a hybrid dependency graph. Risk detection on the hybrid dependency graph can efficiently locate risks caused by data flow and execution logic, effectively reduce false positives or false negatives, improve code detection efficiency and detection rate, and provide reliable assurance for code quality. The resulting code risk detection report has high accuracy, making it easy for developers to quickly locate and fix problems.

[0209] This specification also provides a computer storage medium that can store multiple instructions adapted to be loaded and executed by a processor as described above. Figures 1-6 The code detection method of the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-6 The specific details of the illustrated embodiments will not be elaborated here.

[0210] This specification also provides a computer program product that stores at least one instruction, which is loaded and executed by a processor as described above. Figures 1-6 The code detection method of the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-6 The specific details of the illustrated embodiments will not be elaborated here.

[0211] Please refer to Figure 8 This diagram illustrates a structural block diagram of an electronic device provided in an exemplary embodiment of this specification. The electronic device in this specification may include one or more components such as a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, memory 120, input device 130, and output device 140 may be connected via the bus 150.

[0212] Processor 110 may include one or more processing cores. Processor 110 connects to various parts of the electronic device via various interfaces and lines, and performs various functions and processes data of electronic device 100 by running or executing instructions, programs, code sets, or instruction sets stored in memory 120, and by calling data stored in memory 120. Optionally, processor 110 may be implemented using at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). Processor 110 may integrate one or more of the following: central processing unit (CPU), graphics processing unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 110 and may be implemented separately through a communication chip.

[0213] The memory 120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 120 may include a non-transitory computer-readable storage medium. The memory 120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described below, etc. The operating system may be the Android system, including systems deeply developed based on the Android system, the iOS system developed by Apple Inc., including systems deeply developed based on the iOS system, or other systems. The data storage area may also store data created by the electronic device during use, such as phonebook data, audio and video data, chat log data, etc.

[0214] See Figure 9 As shown, the memory 120 can be divided into operating system space and user space. The operating system runs in the operating system space, while native and third-party applications run in the user space. To ensure that different third-party applications can achieve good running performance, the operating system allocates corresponding system resources for each application. However, different application scenarios within the same third-party application have different requirements for system resources. For example, in local resource loading scenarios, third-party applications have high requirements for disk read speed; in animation rendering scenarios, third-party applications have high requirements for GPU performance. Since the operating system and third-party applications are independent of each other, the operating system often cannot promptly perceive the current application scenario of a third-party application, resulting in the operating system's inability to adapt system resources accordingly to the specific application scenario of the third-party application.

[0215] In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to establish data communication between the third-party applications and the operating system. This would allow the operating system to obtain the current scenario information of the third-party applications at any time, and then perform targeted system resource adaptation based on the current scenario.

[0216] Taking the Android operating system as an example, the programs and data stored in memory 120 are as follows: Figure 10As shown, the memory 120 can store the Linux kernel layer 320, the system runtime library layer 340, the application framework layer 360, and the application layer 380. The Linux kernel layer 320, system runtime library layer 340, and application framework layer 360 belong to the operating system space, while the application layer 380 belongs to the user space. The Linux kernel layer 320 provides low-level drivers for various hardware components of the electronic device, such as display drivers, audio drivers, camera drivers, Bluetooth drivers, Wi-Fi drivers, and power management. The system runtime library layer 340 provides support for key features of the Android system through several C / C++ libraries. For example, the SQLite library provides database support, the OpenGL / ES library provides 3D graphics support, and the Webkit library provides browser kernel support. The system runtime library layer 340 also provides the Android runtime library, which mainly provides core libraries that allow developers to write Android applications using the Java language. The Application Framework Layer 360 provides various APIs that may be used when building applications. Developers can also use these APIs to build their own applications, such as activity management, window management, view management, notification management, content provider, package management, call management, resource management, and location management. At least one application runs in the Application Layer 380. These applications can be native applications that come with the operating system, such as contacts, SMS, clock, and camera apps; or third-party applications developed by third-party developers, such as games, instant messaging, and photo editing apps.

[0217] Taking the operating system as an example (iOS), the programs and data stored in memory 120 are as follows: Figure 11As shown, the iOS system includes: Core OS layer 420, Core Services layer 440, Media layer 460, and Cocoa Touch layer 480. Core OS layer 420 includes the operating system kernel, drivers, and low-level program frameworks. These low-level program frameworks provide hardware-level functionality for use by the program frameworks located in Core Services layer 440. Core Services layer 440 provides system services and / or program frameworks required by applications, such as Foundation framework, account framework, advertising framework, data storage framework, network connectivity framework, geolocation framework, motion framework, etc. Media layer 460 provides applications with audiovisual interfaces, such as interfaces related to graphics and images, audio technology, video technology, and wireless playback (AirPlay) interfaces. Cocoa Touch layer 480 provides various commonly used interface-related frameworks for application development and is responsible for user touch interaction on electronic devices. Examples include local notification services, remote push services, advertising frameworks, game tool frameworks, message user interface (UI) frameworks, UIKit user interface frameworks, map frameworks, and so on.

[0218] exist Figure 11 The framework shown includes, but is not limited to, the base framework in the core service layer 440 and the UIKit framework in the touchable layer 480. The base framework provides many basic object classes and data types, offering the most basic system services to all applications, and is independent of the UI. The UIKit framework, on the other hand, provides a basic UI class library for creating touch-based user interfaces. iOS applications can use the UIKit framework to provide their UI, thus providing the application's infrastructure for building user interfaces, drawing, handling user interaction events, responding to gestures, and so on.

[0219] The methods and principles for implementing data communication between third-party applications and the operating system in the iOS system can be found in the Android system, and will not be repeated here.

[0220] The input device 130 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 140 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In one example, the input device 130 and the output device 140 can be combined into a touch screen, which is used to receive touch operations from the user using a finger, stylus, or any suitable object on or near it, and to display the user interface of various applications. The touch screen is usually located on the front panel of the electronic device. The touch screen can be designed as a full-screen, curved screen, or irregularly shaped screen. The touch screen can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen; this specification does not limit this.

[0221] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WiFi) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0222] In this specification, the entity executing each step can be the electronic device described above. Optionally, the entity executing each step can be the operating system of the electronic device. The operating system can be Android, iOS, or other operating systems; this specification does not limit this.

[0223] The electronic device described in this manual may also be equipped with a display device. This display device can be any device capable of displaying information, such as a cathode ray tube display (CR), a light-emitting diode display (LED), an e-ink screen, a liquid crystal display (LCD), or a plasma display panel (PDP). Users can use the display device on electronic device 101 to view displayed text, images, videos, and other information. The electronic device may be a smartphone, tablet, gaming device, AR (Augmented Reality) device, automobile, data storage device, audio playback device, video playback device, laptop, desktop computing device, or wearable device such as a smartwatch, smart glasses, smart helmet, smart bracelet, smart necklace, or smart clothing.

[0224] exist Figure 8 In the electronic device shown, the electronic device can be a terminal, and the processor 110 can be used to call the network optimization application stored in the memory 120 and specifically perform the following operations: obtain the code to be detected and generate a syntax tree;

[0225] The data flow and control flow of the code to be detected are determined based on the syntax tree.

[0226] A data dependency graph is generated based on the data flow; the data dependency graph includes multiple nodes and the data dependency edges corresponding to each node.

[0227] Generate a control flow graph based on the control flow;

[0228] Embed data dependency edges into the control flow graph to generate a hybrid dependency graph;

[0229] Code risk detection is performed based on a hybrid dependency graph, and a code risk detection report is generated.

[0230] In one embodiment, when the processor 110 executes the process of acquiring the code to be detected and generating a syntax tree, it specifically performs the following operations: acquiring the code to be detected, performing syntax analysis on the code to be detected, and obtaining syntax units and semantic information corresponding to the syntax units;

[0231] The grammatical units and semantic information are validated based on preset grammatical rules.

[0232] A syntax tree is generated based on the validated syntax units and semantic information.

[0233] In one embodiment, when the processor 110 executes the data dependency graph generation based on the data flow, it specifically performs the following operations: the data flow includes assignment statements, branching structures, and function calls;

[0234] The assignment statement is parsed to obtain the first variable of the assignment statement, and the dependencies between the first variables are determined to generate the assignment dependency edges of the first variables; the first variables include the left value and the right value of the assignment statement;

[0235] The branch structure is parsed to obtain the second variable of the branch structure, and the condition constraint edges of the second variable are generated based on the judgment conditions corresponding to the branch structure.

[0236] The function call is parsed to obtain the third variable of the function call, and the dependencies between the third variables are determined to generate the function dependency edges of the third variables; the third variable includes the input parameters and return value of the function call;

[0237] Using the first, second, and third variables as nodes, a data dependency graph is generated based on assignment dependency edges, conditional constraint edges, and functional dependency edges.

[0238] In one embodiment, when processor 110 performs code risk detection based on hybrid dependency graph and generates a code risk detection report, it specifically performs the following operations: code risk detection includes null value propagation detection, value domain conflict detection, and redundant code detection.

[0239] Null value propagation detection is performed based on the hybrid dependency graph to obtain the null value propagation detection results;

[0240] Value domain conflict detection is performed based on the hybrid dependency graph to obtain the value domain conflict detection results;

[0241] Redundancy detection is performed based on a hybrid dependency graph, and the redundancy detection results are obtained.

[0242] Based on the results of null value propagation detection, value domain conflict detection, and redundant code detection, a code risk detection report is generated.

[0243] In one embodiment, when processor 110 performs null value propagation detection based on hybrid dependency graph and obtains null value propagation detection results, it specifically performs the following operations: performs backward slicing operation on variable nodes in the hybrid dependency graph to determine the data propagation path of variable nodes;

[0244] Determine if there are any uninitialized dependency variables in the data propagation path;

[0245] If there are uninitialized dependency variables in the data propagation path, the variable node is marked as a risk node, and the null value propagation detection result is obtained.

[0246] In one embodiment, when processor 110 performs value range conflict detection based on hybrid dependency graph and obtains value range conflict detection results, it specifically performs the following operations: determining the value range corresponding to the variable node based on the hybrid dependency graph;

[0247] Determine if the variable node is within the range of values;

[0248] If a variable node is outside the range of values, the variable node is marked as a risk node, and the value range conflict detection result is obtained.

[0249] In one embodiment, when the processor 110 performs redundant code detection based on the hybrid dependency graph and obtains the redundant code detection result, it specifically performs the following operations: traversing the hybrid dependency graph and filtering out redundant nodes; redundant nodes are nodes that are not covered by the execution path;

[0250] Redundant nodes are marked as risk nodes, and the redundancy code detection results are obtained.

[0251] In one embodiment, the processor 110 also performs the following operations: the code risk detection report includes risk nodes and the risk types corresponding to the risk nodes;

[0252] The risk type of the risk node is matched with the preset repair method table, and repair suggestions for the risk node are generated based on the matching results. The preset repair method table includes multiple risk types and preset repair methods corresponding to each risk type.

[0253] In one embodiment, the processor 110 further performs the following operations: in response to a compliance detection request, determines a compliance template corresponding to the compliance detection request;

[0254] The code to be tested is matched with a compliance template, and a compliance report is generated based on the matching results.

[0255] In one embodiment, the processor 110 further performs the following operations: performs pattern detection on the code to be detected based on a preset risk control rule base, and obtains the pattern detection result; the pattern detection includes detecting the nesting depth and / or detecting the threshold coupling degree.

[0256] In this specification, by generating a syntax tree of the code to be detected, the dependencies between variables become clearer, making the detection of the code more accurate. The separation and extraction of data flow and control flow can capture the dependencies between variables and the execution path logic respectively. The data dependency graph accurately locates the propagation chain between variables, while the control flow graph covers all possible execution branches. The fusion of the two graphs yields a hybrid dependency graph. Risk detection on the hybrid dependency graph can efficiently locate risks caused by data flow and execution logic, effectively reduce false positives or false negatives, improve code detection efficiency and detection rate, and provide reliable assurance for code quality.

[0257] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0258] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the code to be detected, the preset repair method table, and the preset risk control rule base involved in this specification were all obtained under full authorization.

[0259] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A code detection method, characterized in that, include: Obtain the code to be tested and generate a syntax tree; The data flow and control flow of the code to be detected are determined based on the syntax tree; A data dependency graph is generated based on the data stream; the data dependency graph includes multiple nodes and data dependency edges corresponding to each node, and the data dependency edges include assignment dependency edges, condition constraint edges, and function dependency edges. A control flow graph is generated based on the control flow; The data dependency edges are embedded into the control flow graph to generate a hybrid dependency graph; Based on the hybrid dependency graph, code risk detection is performed, and a code risk detection report is generated. The code risk detection includes null value propagation detection, value domain conflict detection, and redundant code detection; The code risk detection based on the hybrid dependency graph, and the generation of a code risk detection report, includes: Null value propagation detection is performed based on the hybrid dependency graph to obtain the null value propagation detection results; Value domain conflict detection is performed based on the hybrid dependency graph to obtain the value domain conflict detection results; Redundant code detection is performed based on the hybrid dependency graph to obtain the redundant code detection results. Based on the null value propagation detection results, the value domain conflict detection results, and the redundant code detection results, the code risk detection report is generated; The generation of the control flow graph based on the control flow includes: The continuous, branchless execution logic in the syntax tree is defined as a basic block; Based on the control structure in the control flow, the execution jump relationship between the basic blocks is established, and control flow edges are generated; The basic blocks are used as nodes, and the control flow edges are used as edges connecting the nodes to generate the control flow graph; The step of embedding the data dependency edges into the control flow graph to generate a hybrid dependency graph includes: A node alignment mechanism is used to establish a mapping relationship between nodes in the control flow graph and nodes in the data dependency graph. Based on the mapping relationship, the execution jump relationship corresponding to the control flow graph is mapped to the corresponding edge of the data dependency graph, and the hybrid dependency graph is obtained by merging.

2. The method according to claim 1, wherein obtaining the code to be detected and generating a syntax tree includes: Obtain the code to be detected, perform syntactic analysis on the code to be detected, and obtain syntactic units and semantic information corresponding to the syntactic units; The grammatical units and semantic information are verified based on preset grammatical rules. The syntax tree is generated based on the validated syntax units and semantic information.

3. The method according to claim 1, wherein the data stream includes assignment statements, branching structures, and function calls; The generation of a data dependency graph based on the data stream includes: The assignment statement is parsed to obtain the first variable of the assignment statement, and the dependency relationship between the first variables is determined to generate the assignment dependency edge of the first variable; the first variable includes the left value and the right value of the assignment statement; The branch structure is parsed to obtain the second variable of the branch structure, and the condition constraint edge of the second variable is generated based on the judgment condition corresponding to the branch structure. The function call is parsed to obtain the third variable of the function call, and the dependencies between the third variables are determined to generate the function dependency edges of the third variables; the third variable includes the input parameters and return value of the function call; Using the first variable, the second variable, and the third variable as nodes, the data dependency graph is generated based on the assignment dependency edges, the condition constraint edges, and the function dependency edges.

4. The method according to claim 1, wherein performing null value propagation detection based on the hybrid dependency graph to obtain null value propagation detection results includes: Perform a backward slice operation on the variable nodes in the hybrid dependency graph to determine the data propagation path of the variable nodes; Determine whether there are any uninitialized dependency variables in the data propagation path; If there are uninitialized dependency variables in the data propagation path, the variable node is marked as a risk node, and the null value propagation detection result is obtained.

5. The method according to claim 1, wherein the step of performing range conflict detection based on the hybrid dependency graph to obtain range conflict detection results includes: The value range corresponding to the variable node is determined based on the hybrid dependency graph; Determine whether the variable node is within the range of values; If the variable node is not within the range of values, then the variable node is marked as a risk node, and the value range conflict detection result is obtained.

6. The method according to claim 1, wherein the step of performing redundant code detection based on the hybrid dependency graph to obtain redundant code detection results includes: Traverse the hybrid dependency graph and filter out redundant nodes; The redundant nodes are those not covered by the execution path; The redundant nodes are marked as risk nodes, and the redundant code detection results are obtained.

7. The method according to claim 1, wherein the code risk detection report includes risk nodes and the risk types corresponding to the risk nodes; The method further includes: The risk type of the risk node is matched with a preset repair method table, and repair suggestions for the risk node are generated based on the matching results. The preset repair method table includes multiple risk types and preset repair methods corresponding to each risk type.

8. The method according to claim 1, further comprising: In response to a compliance testing request, determine the compliance template corresponding to the compliance testing request; The code to be detected is matched with the compliance template, and a compliance report is generated based on the matching results.

9. The method according to claim 1, further comprising: Pattern detection is performed on the code to be detected based on a preset risk control rule base to obtain pattern detection results; the pattern detection includes detecting the nesting depth and / or detecting the threshold coupling degree.

10. A code detection device, characterized in that, include: The acquisition module is used to acquire the code to be detected and generate a syntax tree; The analysis module is used to determine the data flow and control flow of the code to be detected based on the syntax tree; The first generation module is used to generate a data dependency graph based on the data stream; the data dependency graph includes multiple nodes and data dependency edges corresponding to each node, and the data dependency edges include assignment dependency edges, condition constraint edges and function dependency edges. The second generation module is used to generate a control flow graph based on the control flow; The fusion module is used to embed the data dependency edges into the control flow graph to generate a hybrid dependency graph; The detection module is used to perform code risk detection based on the hybrid dependency graph and generate a code risk detection report; the code risk detection includes null value propagation detection, value domain conflict detection, and redundant code detection; The detection module is specifically used for: Null value propagation detection is performed based on the hybrid dependency graph to obtain the null value propagation detection results; Value domain conflict detection is performed based on the hybrid dependency graph to obtain the value domain conflict detection results; Redundant code detection is performed based on the hybrid dependency graph to obtain the redundant code detection results. Based on the null value propagation detection results, the value domain conflict detection results, and the redundant code detection results, the code risk detection report is generated; The second generation module is specifically used for: The continuous, branchless execution logic in the syntax tree is defined as a basic block; Based on the control structure in the control flow, the execution jump relationship between the basic blocks is established, and control flow edges are generated; The basic blocks are used as nodes, and the control flow edges are used as edges connecting the nodes to generate the control flow graph; The fusion module is specifically used for: A node alignment mechanism is used to establish a mapping relationship between nodes in the control flow graph and nodes in the data dependency graph. Based on the mapping relationship, the execution jump relationship corresponding to the control flow graph is mapped to the corresponding edge of the data dependency graph, and the hybrid dependency graph is obtained by merging.

11. A computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 9.

12. A computer program product storing at least one instruction, said at least one instruction being loaded by a processor and executing the method steps of any one of claims 1 to 9.

13. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 9.

Images