Code checking method and apparatus, and computing device

Abstract

The present application provides a code checking method, comprising: a DSL engine acquires source code to be tested and a DSL rule; the DSL engine performs semantic analysis on the DSL rule to determine a target node and a target edge which are queried on the basis of the DSL rule; when the target node and the target edge have been stored in a graph database, the DSL engine acquires the target node and the target edge from the graph database; the DSL engine generates a check result of said source code on the basis of respective position information of the target node and the target edge in said source code, the check result being used for indicating a code position in said source code that corresponds to the DSL rule; and the DSL engine outputs the check result of said source code. The method can reduce the memory resource consumption of an DSL engine and improve the efficiency of code checking, thereby improving the use performance of the DSL engine.

Description

Methods, apparatus, and computing devices for code inspection

[0001] This application claims priority to Chinese Patent Application No. 202411215843.3, filed with the China National Intellectual Property Administration on August 30, 2024, entitled “Method, Apparatus and Computing Device for Code Inspection”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of cloud computing, and more specifically, to a method, apparatus, and computing device for code inspection. Background Technology

[0003] With the continuous development of internet technology, the scale and complexity of software are constantly expanding, and the pressure on software code security is also gradually increasing. Static code analysis is a widely used code security analysis technique. This technique can analyze code without running the software, and identify potential security risks in the code in advance through relevant static detection rules, thereby helping development and security teams to address security and quality defects early in the software development lifecycle. Among them, static code analysis techniques based on domain-specific language (DSL) rules are highly praised because their rules can be customized, modified flexibly, and their inspection capabilities are comprehensive and stable.

[0004] In the relevant technical solution, after the front-end analyzer in the DSL engine receives the source code to be tested, it parses the source code, constructs all the node and edge relationships in the source code to be tested, generates a complete code attribute graph (CPG), stores the node and edge relationships in the CPG to the graph database, and queries the node and edge relationships contained in the CPG stored in the graph database based on the DSL rules to find the node corresponding to the DSL rule, and finally locates the code position in the source code to be tested that corresponds to the DSL rule.

[0005] In the aforementioned technical solutions, the DSL engine needs to store the complete CPG graph of the source code. However, the DSL rules being queried do not always require the use of the complete CPG graph. Therefore, this technical solution wastes a lot of resources and reduces the efficiency of code querying. Furthermore, as the capabilities of the DSL engine iterate, the number of nodes and edge relationships it can support increases. This leads to an increase in the memory consumption, code parsing, and inspection time of the DSL engine, resulting in poor performance of the DSL engine and, in severe cases, even blocking.

[0006] Therefore, how to reduce the memory resource consumption of the DSL engine and improve the efficiency of code inspection has become an urgent technical problem to be solved. Summary of the Invention

[0007] This application provides a code inspection method that can reduce the memory resource consumption of the DSL engine, improve the efficiency of code inspection, and thus improve the performance of the DSL engine.

[0008] Firstly, a code inspection method is provided, which is applied to a domain-specific language (DSL) engine. The method includes: the DSL engine acquiring the source code to be tested and DSL rules; the DSL engine performing semantic analysis on the DSL rules to determine the target node and target edge queried by the DSL rule; if the target node and target edge are already stored in a graph database, the DSL engine retrieving the target node and target edge from the graph database; the DSL engine generating an inspection result for the source code to be tested based on the position information of the target node and target edge in the source code to be tested, wherein the inspection result indicates the code position in the source code to be tested corresponding to the DSL rule; and the DSL engine outputting the inspection result for the source code to be tested.

[0009] In the above technical solution, semantic analysis of the DSL rule determines the target node and target edge to be queried. Since the target node and target edge are already stored in the graph database, the DSL engine can directly query the graph database for these two elements. Based on the position information of the target node and target edge in the source code under test, it obtains the code position in the source code corresponding to the DSL rule. This avoids performing a full quantization analysis of the source code under test to obtain and store all nodes and edges corresponding to it, thereby reducing the memory resource consumption of the DSL engine and improving the efficiency and performance of its code inspection.

[0010] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: the DSL engine obtaining the position information of the target node and the target edge in the source code under test from the graph database.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: the DSL engine establishing indexes for the target node and the target edge respectively; the DSL engine comparing the indexes for the target node and the target edge with the indexes for nodes and edges stored in the graph database respectively to determine whether the target node and the target edge are stored in the graph database.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, if the graph database contains the index of the target node and the index of the target edge, the DSL engine determines that the target node and the target edge have been stored in the graph database.

[0013] In the above technical solution, the index of the target node and the target edge can be used to determine whether the target node and the target edge are stored in the graph database, which is relatively simple to implement and highly efficient.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, if the graph database does not contain an index for the target node, the DSL engine determines that the target node is not stored in the graph database. Or, if the graph database does not contain an index for the target edge, the DSL engine determines that the target edge is not stored in the graph database.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, when the target node and the target edge are not stored in the graph database, before the DSL engine obtains the target node and the target edge from the graph database, the method further includes: the DSL engine parses the source code to be tested and constructs the target node and the target edge; the DSL engine stores the target node and the target edge in the graph database.

[0016] In the above technical solution, when the source code under test is checked multiple times, the target nodes and target edges generated each time corresponding to the DSL rules can be persistently stored in the graph database, avoiding repeated parsing of the source code under test and improving the query efficiency of the DSL engine.

[0017] In the above technical solution, when the target node and target edge are not stored in the graph database, the DSL engine can perform non-full code parsing of the source code under test based on the target node and target edge information corresponding to the DSL rules. It only needs to construct the target nodes and target edges related to the DSL rules in the source code under test, as well as the general attribute information of the target nodes and target edges (e.g., the position information of the target nodes and target edges in the source code under test). The other nodes and edges in the source code under test, as well as the general attribute information of the other nodes and edges, are all skipped by the front-end analyzer in the DSL engine. This can save a large part of the parsing time of the front-end analyzer, thereby improving the parsing efficiency of the DSL engine for the source code under test.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, the DSL rule is a data flow analysis rule. The method further includes: the DSL engine configuring the data flow analysis engine based on the inspection result of the source code under test, and generating a configuration file for the data flow analysis engine; the DSL engine calling the data flow analysis engine to perform data flow analysis on the source code under test, generating the data flow analysis result of the source code under test; and outputting the data flow analysis result of the source code under test.

[0019] In the above technical solution, for DSL rules of data flow analysis, the inspection results of the source code under test are obtained according to the DSL rules without the need to build a full CPG of the source code under test, and the data flow analysis engine is configured based on the inspection results of the source code under test. In this way, compared with the need to build a full CPG of the source code under test to obtain the inspection results of the source code under test and configure the data flow analysis engine based on the inspection results, the efficiency of data flow analysis can be improved.

[0020] In conjunction with the first aspect, in some implementations of the first aspect, the data flow analysis engine is used to perform taint processing on the source code under test. The configuration file of the data flow analysis engine includes the following information: taint source information and taint convergence point information.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the configuration file of the data stream analysis engine also includes at least one of the following: taint propagation rule information and harmless treatment information.

[0022] Secondly, a code inspection method is provided, which is applied to a domain-specific language (DSL) engine. The method includes: obtaining the source code to be tested and DSL rules, wherein the DSL rules are rules of the data flow analysis class; parsing the DSL rules and converting them into a configuration file of the data flow analysis engine; calling the data flow analysis engine to perform data flow analysis on the source code to be tested and generating the data flow analysis results of the source code to be tested; and outputting the data flow analysis results of the source code to be tested.

[0023] In the above technical solution, for configuration files that can directly convert DSL rules into data stream analysis engine configuration files, the data stream analysis engine can be configured directly according to the DSL rules, thereby improving the efficiency of data stream analysis.

[0024] In conjunction with the second aspect, in some implementations of the second aspect, the data flow analysis engine is used to perform taint processing on the source code under test. The configuration file of the data flow analysis engine includes the following information: taint source information and taint convergence point information.

[0025] In conjunction with the second aspect, in some implementations of the second aspect, the configuration file of the data stream analysis engine also includes at least one of the following information: taint propagation rule information and harmless treatment information.

[0026] Thirdly, a code inspection apparatus is provided, applied to a domain-specific language (DSL) engine. The apparatus includes: an acquisition module, a determination module, a query module, and an output module. The acquisition module acquires the source code to be tested and the DSL rules; the determination module performs semantic analysis on the DSL rules to determine the target node and target edge for the DSL rule query; the determination module also retrieves the target node and target edge from a graph database; the query module, assuming the target node and target edge are already stored in the graph database, generates an inspection result for the source code to be tested based on the position information of the target node and target edge within the source code to be tested, wherein the inspection result indicates the code position in the source code to be tested corresponding to the DSL rule; and the output module outputs the inspection result of the source code to be tested.

[0027] In conjunction with the third aspect, in some implementations of the third aspect, the acquisition module is also used to obtain the position information of the target node and the target edge in the source code under test from the graph database.

[0028] In conjunction with the third aspect, in some implementations of the third aspect, the apparatus further includes: a creation module for creating indexes for the target node and the target edge respectively; and a determination module for comparing the indexes for the target node and the target edge with the indexes for nodes and edges stored in the graph database respectively, to determine whether the target node and the target edge are stored in the graph database.

[0029] In conjunction with the third aspect, in some implementations of the third aspect, if the graph database does not contain an index for the target node, the determining module is also used to determine that the target node is not stored in the graph database. Alternatively, if the graph database does not contain an index for the target edge, the determining module is also used to determine that the target edge is not stored in the graph database.

[0030] In conjunction with the third aspect, in some implementations of the third aspect, when the target node and the target edge are not stored in the graph database, the device further includes: a code parsing module and a persistence module, wherein the code parsing module is used to parse the source code to be tested and construct the target node and the target edge; the persistence module is used to store the target node and the target edge in the graph database.

[0031] In conjunction with the third aspect, in some implementations of the third aspect, the DSL rule is a data flow analysis rule, and the device further includes: a configuration module, used to configure the data flow analysis engine according to the inspection result of the source code under test, and generate a configuration file for the data flow analysis engine; a generation module, used to call the data flow analysis engine to perform data flow analysis on the source code under test, and generate the data flow analysis result of the source code under test; and an output module, also used to output the data flow analysis result of the source code under test.

[0032] In conjunction with the third aspect, in some implementations of the third aspect, the data flow analysis engine is used to perform taint removal on the source code under test. The configuration file of the data flow analysis engine includes the following information: taint source information and taint convergence point information.

[0033] In conjunction with the third aspect, in some implementations of the third aspect, the configuration file of the data stream analysis engine also includes at least one of the following: taint propagation rule information and harmless treatment information.

[0034] It should be understood that for the beneficial effects of the third aspect and its various implementations, please refer to the first aspect and its various implementations; they will not be repeated here.

[0035] Fourthly, a code inspection apparatus is provided, which is applied to a domain-specific language (DSL) engine. The apparatus includes: an acquisition module, a configuration module, a generation module, and an output module. The acquisition module acquires the source code to be tested and DSL rules, wherein the DSL rules are data flow analysis rules. The configuration module parses the DSL rules and converts them into a configuration file for the data flow analysis engine. The generation module invokes the data flow analysis engine to perform data flow analysis on the source code to be tested and generates the data flow analysis results. The output module outputs the data flow analysis results of the source code to be tested.

[0036] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the data flow analysis engine is used to perform taint processing on the source code under test. The configuration file of the data flow analysis engine includes: taint source information and taint convergence point information.

[0037] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the configuration file of the data stream analysis engine also includes at least one of the following: taint propagation rule information and harmless treatment information.

[0038] It should be understood that for the beneficial effects of the fourth aspect and its various implementations, please refer to the beneficial effects of the second aspect and its various implementations; they will not be repeated here.

[0039] Fifthly, a computing device is provided, including a processor and a memory, and optionally, an input / output interface. The processor controls the input / output interface to send and receive information, the memory stores a computer program, and the processor retrieves and runs the computer program from the memory, causing it to execute the method of the first aspect or any possible implementation thereof, or to execute the method of the second aspect or any possible implementation thereof.

[0040] Optionally, the processor can be a general-purpose processor, which can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc.; when implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. This memory can be integrated into the processor or located outside the processor and exist independently.

[0041] In a sixth aspect, a computing device cluster is provided, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, such that the computing device cluster performs a method in the first aspect or any possible implementation thereof, or performs a method in the second aspect or any possible implementation thereof.

[0042] In a seventh aspect, a chip is provided that acquires and executes instructions to implement the methods in the first aspect and any implementation thereof, or to implement the methods in the second aspect or any possible implementation thereof.

[0043] Optionally, as one implementation, the chip includes a processor and a data interface, through which the processor reads instructions stored in the memory and executes the methods in the first aspect and any implementation thereof, or executes the methods in the second aspect or any possible implementation thereof.

[0044] Optionally, as one implementation, the chip may further include a memory storing instructions, and the processor is used to execute the instructions stored in the memory. When the instructions are executed, the processor is used to execute the method in the first aspect and any implementation thereof, or to execute the method in the second aspect or any possible implementation thereof.

[0045] Eighthly, a computer program product comprising instructions is provided, which, when executed by a computing device, causes the computing device to perform the method as described in the first aspect and any implementation thereof, or to perform the method as described in the second aspect or any possible implementation thereof.

[0046] In a ninth aspect, a computer program product containing instructions is provided, which, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the methods described in the first aspect and any implementation thereof, or to perform the methods described in the second aspect or any possible implementation thereof.

[0047] In a tenth aspect, a computer-readable storage medium is provided, including computer program instructions that, when executed by a computing device, perform a method as described in the first aspect and any implementation thereof, or perform a method as described in the second aspect or any possible implementation thereof.

[0048] As examples, these computer-readable storage devices include, but are not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically EPROM (EEPROM), and hard drive.

[0049] Alternatively, as one implementation method, the aforementioned storage medium can specifically be a non-volatile storage medium.

[0050] Eleventhly, a computer-readable storage medium is provided, including computer program instructions that, when executed by a cluster of computing devices, perform the method as described in the first aspect and any implementation thereof, or perform the method as described in the second aspect or any possible implementation thereof.

[0051] As examples, these computer-readable storage devices include, but are not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically EPROM (EEPROM), and hard drive.

[0052] Alternatively, as one implementation method, the aforementioned storage medium can specifically be a non-volatile storage medium. Attached Figure Description

[0053] Figure 1 is a schematic block diagram of a cloud scenario applicable to an embodiment of this application.

[0054] Figure 2 is a schematic flowchart of a code inspection method provided in an embodiment of this application.

[0055] Figure 3 is a schematic flowchart of another code inspection method provided in an embodiment of this application.

[0056] Figure 4 is a schematic block diagram of a code inspection device 400 provided in an embodiment of this application.

[0057] Figure 5 is a schematic block diagram of another code inspection device 500 provided in an embodiment of this application.

[0058] Figure 6 is a schematic diagram of the architecture of a computing device 1500 provided in an embodiment of this application.

[0059] Figure 7 is a schematic diagram of the architecture of a computing device cluster provided in an embodiment of this application.

[0060] Figure 8 is a schematic diagram of the connection between computing devices 1500A and 1500B via a network provided in an embodiment of this application. Detailed Implementation

[0061] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0062] This application will present various aspects, embodiments, or features relating to systems comprising multiple devices, components, modules, etc. It should be understood and appreciated that individual systems may include additional devices, components, modules, etc., and / or may not include all devices, components, modules, etc. discussed in conjunction with the accompanying drawings. Furthermore, combinations of these approaches are also possible.

[0063] Furthermore, in the embodiments of this application, the words "exemplary," "for example," etc., are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the term "exemplary" is intended to present the concept in a concrete manner.

[0064] In the embodiments of this application, "corresponding" and "corresponding" can sometimes be used interchangeably. It should be noted that when the distinction is not emphasized, their intended meanings are consistent.

[0065] The business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0066] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0067] In this application, "at least one" means one or more, and "more than one" 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 mean: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0068] For ease of description, the concepts involved in the embodiments of this application will be explained below.

[0069] 1. Domain-Specific Language (DSL)

[0070] DSL is a computer language focused on a specific application domain, also known as a domain-specific language. It is characterized by its conciseness, readability, and ease of writing, and is designed to solve problems within a specific domain, allowing for the natural expression of those problems. Examples include Hypertext Markup Language (HTML) for displaying web pages and Structured Query Language (SCL) for structured database queries.

[0071] 2. DSL Rules

[0072] DSL rules are primarily used in code security analysis or security profiling. In code security checks, DSL rules define a series of security inspection standards and rules. In other words, DSL rules are mainly manifested by defining a set of DSL syntax specifically used to describe security rules. DSL rules can cover various aspects of code, such as access control, data encryption, error handling, and input validation, helping different enterprises define security specifications according to their own needs and conduct security checks during code development, testing, and other stages.

[0073] As an example, a DSL rule typically consists of the following parts:

[0074] a) Condition: Used to define the conditions that trigger security checks. These conditions can be based on specific patterns in the code, variable values, function calls, etc. For example, a condition can be defined to check whether an SQL query contains a potential SQL injection vulnerability.

[0075] b) Action: The action the system needs to take when a certain condition is met. These actions can include prohibiting code submission, marking an item as risky, sending alert notifications, etc. For example, if an SQL injection vulnerability is detected, the system can automatically prohibit the submission of that code and notify the developers to fix it.

[0076] c) Functions: DSL rules may also contain built-in functions for performing specific logical operations or data processing. These functions can simplify rule writing and improve the readability and maintainability of the rules.

[0077] 3. Abstract Syntax Tree (AST)

[0078] An Abstract Syntax Tree (AST) is a tree-like structure that represents source code in a hierarchical manner, used to represent the syntactic elements in the source code and the relationships between them. Each node in an AST represents a structure in the source code, such as an expression, statement, or function, and the relationships between nodes (such as parent-child relationships) represent the hierarchical relationships between these syntactic structures.

[0079] AST generation is typically the first stage in a compiler's or interpreter's processing of source code. In this stage, the source code is processed by a lexer and a parser. The lexer breaks down the source code string into a series of tokens, which are the basic syntactic units in the source code, such as keywords, identifiers, and operators. The parser, according to the language's grammatical rules, combines the token sequences output by the lexer into a tree-like structure, i.e., the AST.

[0080] It should be understood that an AST does not display all the syntactic details in the source code. It removes most of the syntactic details (such as parentheses, semicolons, etc.) and only retains the information that is essential to the logical structure of the source code program. Due to the abstract nature and tree-like structure of the AST, it makes it easier for compilers or interpreters to analyze and manipulate the code, such as performing syntax analysis, semantic analysis, code optimization, and code generation.

[0081] 4. Control Flow Graph (CFG)

[0082] CFG is an abstract representation of a process or program. It is an abstract data structure maintained internally by the compiler and represents all paths that a program will traverse during execution. It represents the possible flow of execution of all basic blocks within a process in the form of a graph, and can also reflect the real-time execution process of a process.

[0083] A CFG (Complete Flow Chart) is a directed graph where nodes represent basic blocks (BBs) in a program, and edges represent the direction of control flow, i.e., the transition from one BB to another. A CFG has a unique start node (the program's entry point) and a unique end node (the program's exit point). Each node in the graph has at most two direct successors (in branching structures), and there exists a path from the start node to the end node that covers all possible execution paths in the program.

[0084] 5. Code Property Graph (CPG)

[0085] CPG is a graphical representation of program code structure and attributes. It uses nodes and edges to represent elements and their relationships in the code, such as classes, functions, and variables, and stores them in a graph database. It integrates various code representation methods, such as Abstract Syntax Trees (ASTs), Control Flow Graphs (CFGs), and Program Dependency Graphs (PDGs), and combines them into a supergraph containing the most relevant information needed for program analysis.

[0086] As an example, the application scenarios for CPG may include, but are not limited to:

[0087] a) Code analysis: CPG can be used for static code analysis to help developers discover potential problems in the code, such as buffer overflows, integer overflows, memory leaks and other vulnerabilities.

[0088] b) Code optimization: By analyzing the code structure and attribute information in CPG, developers can identify redundant and inefficient parts of the code and optimize them to improve code execution efficiency.

[0089] c) Code refactoring: CPG provides an intuitive representation of code structure and attributes, which helps developers maintain the integrity of code structure and functionality when refactoring.

[0090] With the continuous development of internet technology, the scale and complexity of software are constantly expanding, and the pressure on software code security is also gradually increasing. Static code analysis (SCR) is a widely used code security analysis technique. This technique can analyze code without running the software, and identify potential security risks in the code in advance through relevant static detection rules, thereby helping development and security teams to address security and quality defects early in the software development lifecycle. Among them, static code analysis based on DSL rules is highly praised because its rules can be customized, modified flexibly, and its inspection capabilities are comprehensive and stable.

[0091] In the relevant technical solution, after receiving the source code to be tested, the front-end analyzer in the DSL engine parses the source code and generates corresponding data structures such as AST and CFG to store the attribute information of the source code. Based on these data structures, the DSL engine constructs all node and edge relationships in the source code, generating a complete code attribute graph (CPG), and stores the CPG in a graph database. Simultaneously, the upper-layer checker in the DSL engine performs syntax parsing on the DSL rules, translating them into a graph database query language (e.g., Gremlin), and queries the node and edge relationships contained in the CPG stored in the graph database based on this query language to find the node corresponding to the DSL rule, ultimately locating the code position in the source code corresponding to the DSL rule.

[0092] In the aforementioned technical solutions, the DSL engine needs to parse and save all nodes and edge relationships of the input source code to the graph database. However, the query conditions of DSL rules only involve a small portion of all nodes and edge relationships. This leads to a significant waste of resources in this full-scale analysis mode and greatly reduces the efficiency of code querying. Furthermore, as the capabilities of the DSL engine iterate, the number of nodes and edge relationships it can support increases, which leads to increased memory consumption, code parsing, and inspection time, resulting in poor performance and, in severe cases, even blocking.

[0093] In view of this, embodiments of this application provide a code inspection method that can reduce the memory resource consumption of the DSL engine, improve the efficiency of code inspection, and thus improve the performance of the DSL engine.

[0094] In one possible implementation, the method provided in this application embodiment can be applied to cloud service scenarios. For ease of description, the cloud service scenario will be described in detail below with reference to Figure 1.

[0095] Figure 1 is a schematic block diagram of a cloud scenario applicable to an embodiment of this application. As shown in Figure 1, the cloud scenario may include: a cloud management platform 110, the Internet 120, and a client 130.

[0096] As shown in Figure 1, the cloud management platform 110 is used to manage the infrastructure that provides multiple cloud services. The infrastructure includes multiple cloud data centers, each cloud data center includes multiple servers, and each server includes cloud service resources to provide corresponding cloud services to tenants.

[0097] The cloud management platform 110 can be located in a cloud data center and provides access interfaces (such as user interfaces or application program interfaces, APIs). Tenants can use client 130 to remotely access the cloud management platform 110, register a cloud account and password, and log in. After successful authentication of the cloud account and password, the tenant can further select and purchase virtual machines of specific specifications (processor, memory, disk) on the cloud management platform 110. After successful purchase, the cloud management platform 110 provides the remote login account and password for the purchased virtual machine, allowing client 130 to remotely log in and install and run the tenant's applications. Therefore, tenants can create, manage, log in to, and operate virtual machines in the cloud data center through the cloud management platform 110. Virtual machines can also be referred to as Elastic Compute Service (ECS) or Elastic Instances (different cloud service providers may use different names).

[0098] It should be understood that cloud service tenants can be individuals, businesses, schools, hospitals, government agencies, etc.

[0099] The cloud management platform 110 includes, but is not limited to, a user console, compute management services, network management services, storage management services, authentication services, and image management services. The user console provides an interface or API for interaction with tenants. The compute management services manage servers running virtual machines and containers, as well as bare metal servers. The network management services manage network services (such as gateways and firewalls). The storage management services manage storage services (such as data bucket services). The authentication services manage tenant account passwords. The image management services manage virtual machine images. Tenants can log in to the cloud management platform 110 via client 130 and the internet 120 to manage their rented cloud services.

[0100] In this embodiment of the application, the DSL engine can perform semantic analysis on DSL rules to determine whether the DSL rule is a structured query rule or a data flow analysis rule.

[0101] As examples, the following provides illustrations of rules for structured query classes and rules for data flow analysis classes.

[0102] For example, if the source code under test contains sensitive information (such as email address, employee ID, phone number, etc.), it constitutes a leakage of sensitive information. Therefore, if a DSL rule is used to check whether the input source code under test contains sensitive information (such as email address, employee ID, phone number, etc.), then that DSL rule can be identified as a structured query rule.

[0103] For example, if sensitive variables (such as variables containing certain keywords) in the source code under test are printed by log printing functions (such as functions containing `log` and `print`), this constitutes a leakage of sensitive information. Therefore, if a DSL rule is used to check whether sensitive variables in the source code under test are printed by log printing functions, then that DSL rule can be identified as a rule of the data flow analysis class.

[0104] The method for inspecting the source code under test based on DSL rules of structured query class is described in detail below with reference to Figure 2. It should be understood that the example in Figure 2 is only to help those skilled in the art understand the embodiments of this application, and is not intended to limit the embodiments of the application to the specific values ​​or specific scenarios illustrated in Figure 2. Those skilled in the art can obviously make various equivalent modifications or changes based on the examples given below in Figure 2, and such modifications and changes also fall within the scope of the embodiments of this application.

[0105] Figure 2 is a schematic flowchart of a code inspection method provided in an embodiment of this application. As shown in Figure 2, the method may include steps 210-260, which will be described in detail below.

[0106] Step 210: Obtain the source code to be tested and the DSL rules.

[0107] In this embodiment, the source code to be tested and the DSL rules can be obtained. For example, the source code to be tested and the DSL rules can be obtained by the DSL engine.

[0108] As an example, the above DSL rule is a DSL rule for the structured query class.

[0109] For example, a DSL rule for a structured query class is shown below.

[0110] fieldDeclaration fd where

[0111] fd.name=="fileName";

[0112] In this DSL rule, the target node to be queried in the source code to be tested is "fieldDeclaration", and the target edge to be queried is "name".

[0113] Step 220: Perform semantic analysis on the DSL rules to determine whether the target node and target edge to be queried in the DSL rules are stored in the graph database.

[0114] As an example, the DSL engine can perform semantic analysis on the received DSL rules to determine whether the target node and target edge to be queried in the DSL rule are stored in the graph database.

[0115] The following describes a specific implementation method for determining whether the target node and target edge to be queried in a DSL rule are stored in a graph database.

[0116] For example, each time the DSL engine checks the source code to be tested, it stores the nodes and edges to be queried in the DSL rules used for the check in the graph database for persistence, and creates a corresponding index for each edge and each node stored in the graph database.

[0117] For example, the DSL engine can create an index for the target node and determine whether the corresponding index is stored in the graph database. If the index for the target node is stored in the graph database, then the target node to be queried is stored in the graph database; otherwise, it is assumed that the target node to be queried is not stored in the graph database.

[0118] For example, the DSL engine can create an index for the target edge and determine whether the corresponding index is stored in the graph database. If the index is stored in the graph database, then the target edge being queried is stored there; otherwise, it is assumed that the target edge is not stored in the graph database.

[0119] In one possible implementation, if the target node and target edge to be queried in the above DSL rules are stored in a graph database, then step 230 below can be executed.

[0120] Step 230: If the target node and target edge are stored in the graph database, query the graph database based on the DSL rules to obtain and output the inspection results of the source code to be tested.

[0121] In this embodiment, if the target node and target edge are stored in a graph database, the DSL engine can directly query the graph database based on the DSL rules to obtain the target node and target edge. Then, based on the location information of the target node and target edge in the source code under test stored in the graph database, the engine can locate the code position in the source code under test that corresponds to the DSL rule.

[0122] In the above technical solution, the front-end analyzer parses the code to generate AST, etc., which is then integrated by the DSL engine to generate CPG and stored in the graph database for persistence. If the graph database contains indexes of the target nodes and target edges corresponding to the DSL rules, it can be queried directly in the persistent graph database without re-parsening the source code under test, thus avoiding repeated parsing of the source code under test and improving the efficiency of code query.

[0123] In another possible implementation, if the target node and target edge to be queried in the above DSL rules are not stored in the graph database, then steps 240-260 below can be executed.

[0124] Step 240: If the target node and target edge are not stored in the graph database, generate the target node and target edge information corresponding to the DSL rule.

[0125] In this embodiment of the application, if the target node and target edge are not stored in the graph database, the DSL engine can parse the node and edge of the DSL rule to generate information on the target node and target edge corresponding to the DSL rule.

[0126] For example, taking the above DSL rule "fieldDeclaration fd where fd.name == "fileName" as an example, after the DSL engine performs semantic analysis on the DSL rule, the information of the target node and target edge corresponding to the DSL rule is generated as follows.

[0127] It should be understood that the above information indicates that only the target node (e.g., "fieldDeclaration") and target edge (e.g., "name") corresponding to the DSL rule are retained, in order to guide the front-end analyzer in the DSL engine to build a non-full CPG of the source code under test.

[0128] Step 250: Based on the information of the target nodes and target edges corresponding to the DSL rules, construct the target nodes and target edges related to the DSL rules in the source code to be tested, and generate a non-full CPG.

[0129] In this embodiment, the front-end analyzer in the DSL engine can receive information about target nodes and target edges corresponding to DSL rules, and parse the source code to be tested based on the target nodes and target edges to construct the target nodes and target edges related to DSL rules in the source code to be tested. All other nodes and other edges in the source code to be tested are skipped by the front-end analyzer in the DSL engine, which can save a large part of the parsing time of the front-end analyzer, thereby improving the parsing efficiency of the DSL engine for the source code to be tested.

[0130] The target nodes and target edges constructed above in relation to DSL rules constitute the non-full CPG corresponding to the source code under test. The aforementioned front-end analyzer can also store this non-full CPG in a graph database.

[0131] Step 260: Query the graph database based on the DSL rules to obtain and output the inspection results of the source code to be tested.

[0132] In this embodiment of the application, after the target node and target edge are stored in the graph database, the DSL engine can parse the node and edge of the DSL rule to generate the target node and target edge information corresponding to the DSL rule.

[0133] In the above technical solution, non-full code parsing can be performed on the source code under test according to the DSL rules, saving only the node and edge information required by the DSL rules, thus improving the efficiency of code parsing. Simultaneously, the graph database generated by the front-end analyzer is persisted, avoiding repeated parsing of the source code under test. DSL rules can be directly queried in the persisted graph database, improving query efficiency.

[0134] The method for checking the source code under test based on DSL rules of data flow analysis class is described in detail below with reference to Figure 3. It should be understood that the examples in Figure 3 are only for helping those skilled in the art to understand the embodiments of this application, and are not intended to limit the embodiments of the application to the specific values ​​or specific scenarios illustrated in Figure 3. Those skilled in the art can obviously make various equivalent modifications or changes based on the examples given below in Figure 3, and such modifications and changes also fall within the scope of the embodiments of this application.

[0135] Figure 3 is a schematic flowchart of another code inspection method provided in an embodiment of this application. As shown in Figure 3, the method may include steps 310-350, which will be described in detail below.

[0136] Step 310: Obtain DSL rules.

[0137] As an example, embodiments of this application can obtain DSL rules, for example, a DSL engine obtains DSL rules.

[0138] For example, the above DSL rules are DSL rules of the data flow analysis class.

[0139] For example, a DSL rule for data flow analysis is as follows: variables containing keywords such as "Password" and "CipherText" are considered sensitive information sources, function parameters containing the keyword "log" are considered sensitive information leakage points, and data flow analysis is performed on the source code under test to check whether there is a data flow from the sensitive information source to the sensitive information leakage point in the source code under test.

[0140] Step 320: Perform semantic analysis on the DSL rules to determine whether the DSL rules can be directly converted into the configuration file of the data flow analysis engine.

[0141] In this embodiment of the application, after obtaining the DSL rule, the DSL engine can perform semantic analysis on the DSL rule to determine whether the DSL rule can be directly converted into a configuration file of the data flow analysis engine.

[0142] It should be understood that a data stream analytics engine is a computing engine used for real-time or near-real-time data stream processing. It efficiently handles large-scale, high-concurrency, low-latency data streams, playing a crucial role in the field of data processing and analysis. For example, it can process and analyze data immediately after it is generated by the data source to provide real-time insights. The core functions of a data stream analytics engine include data reception, processing, forwarding, and real-time analysis, thereby supporting various real-time application scenarios.

[0143] It should also be understood that the data flow analysis engine, as an external engine on the DSL engine, allows the DSL engine to improve and enhance its own code inspection capabilities by integrating the data flow analysis engine.

[0144] In a data stream analysis engine, taint handling is a core component. The following example illustrates the configuration file of a data stream analysis engine, using taint handling as an example.

[0145] As an example, consider taint removal in a data stream analytics engine. This involves tracking, analyzing, and processing sensitive data within a program. In this process, concepts such as taint source, taint sink, taint passthrough rules, and sanitizer play crucial roles.

[0146] The following section provides a detailed explanation of these concepts and their applications in stain treatment.

[0147] 1. Source of contamination

[0148] A taint source is an entry point in a program that introduces untrusted or sensitive data. This data may originate from user input, file reading, environment variables, etc., and is considered a potential threat source within the program. Taint sources are the starting point for taint analysis; any data originating from these sources needs to be tainted so that its propagation path can be traced in subsequent analysis.

[0149] 2. Stain sink

[0150] A taint convergence point is a location in a program where sensitive information may be leaked or misused. These points are typically associated with sensitive operations, such as database queries, file writes, and network transmissions. The taint convergence point is the endpoint of taint analysis; the goal of the analysis is to determine whether tainted data can reach these points. If tainted data can reach the sink, then the program may have a security vulnerability.

[0151] 3. Passthrough rules for taint records

[0152] Taint propagation rules refer to the rules governing how tainted data is passed between different variables, functions, or modules in a data flow. These rules define how tainted data propagates within a program, including direct propagation, function propagation, control flow propagation, and alias propagation. By following these rules, data flow analysis engines can accurately trace the propagation path of tainted data.

[0153] 4. Sanitizer treatment

[0154] Harmless processing refers to the process of ensuring that tainted data no longer poses a threat to the information security of software systems during its dissemination through means such as data encryption, verification, cleaning, or restriction of its use.

[0155] In taint analysis, harmless treatment is a crucial step in ensuring system security. By correctly applying harmless treatment, the number of taint markers in the system can be reduced, the efficiency of taint analysis can be improved, and inaccurate analysis results due to taint propagation can be avoided. Simultaneously, harmless treatment is also an important means of preventing sensitive data leakage and dangerous data manipulation.

[0156] For example, the taint handling process in a data stream analysis engine is illustrated below.

[0157] For example, a data flow analysis engine identifies all possible sources of taint in a program and marks the data from these sources to trace their propagation paths in subsequent analysis. The engine can also track the propagation path of tainted data within the program based on taint propagation rules. This process includes analyzing how data is passed between variables, how it propagates through function calls, and how it affects program behavior through control flow. If tainted data reaches the sink, it may indicate a security vulnerability, requiring the tainted data to be neutralized. This could involve data encryption, verification, cleansing, or restrictions on its use to prevent sensitive data leakage and dangerous data manipulation, effectively improving the security and reliability of the software system.

[0158] The following is a specific implementation method for determining whether DSL rules can be directly converted into configuration files for a data stream analysis engine.

[0159] Taking the above-mentioned data stream analysis engine for taint processing as an example, the configuration file of the data stream analysis engine includes the taint source information and taint sink information.

[0160] Optionally, the configuration file of the aforementioned data stream analysis engine may also include at least one of the following: taint propagation rule information and sanitizer information.

[0161] In one possible implementation, after semantic analysis of the DSL rules, if the above information can be directly determined through the DSL rules, which can be understood as being able to directly convert the DSL rules into a configuration file for the data flow analysis engine, then step 330 below can be executed.

[0162] In another possible implementation, after semantic analysis of the DSL rules, if the above information cannot be directly determined through the DSL rules, it can be understood that the DSL rules cannot be directly converted into the configuration file of the data flow analysis engine, and then step 340 below can be executed.

[0163] Step 330: The DSL engine directly configures the data stream analysis engine according to the DSL rules.

[0164] In this embodiment of the application, if the DSL rules can be directly converted into the configuration file of the data stream analysis engine, the DSL engine can be configured according to the DSL rules.

[0165] For example, the following is a sample configuration file that directly converts DSL rules into a data stream analysis engine.

[0166] 1. The DSL rules for data flow analysis are as follows:

[0167] @RuleSetMessage(

[0168] RuleSetName = "SecH_Cxx_TestSourceSink",

[0169] Language = Cxx,

[0170] Type = Taint,

[0171] Engine = Cooddy,

[0172] ReportMsg = "RuleMsg test"

[0173] )

[0174] @Source(OutArgs = 0..$2, TaintFlags = UntrustedSource)

[0175] @TaintConfig(AlarmDescription = "mySourceFunction configed as tainted Source")

[0176] functionCall fc where fc.name == "mySourceFunction";

[0177] @Source(OutArgs = 0, TaintFlags = UntrustedSource)

[0178] @TaintConfig(AlarmDescription = "mySourceFunction configed as tainted Source")

[0179] functionDeclaration fc where fc.name == "mySourceDeclarationFunction";

[0180] @Cleanse(InArgs = 0)

[0181] functionCall fc1 where fc1.name == "myCleanseFunction";

[0182] @Passthrough(InArgs=1,OutArgs=0)

[0183] functionCall fc2 where fc2.name=="myPassThroughFunction";

[0184] @Passthrough(InArgs=0,OutArgs=return)

[0185] functionCall fc3 where fc3.name=="myPassThroughFunction2";

[0186] @Sink(InArgs=[0...],TaintFlags=UntrustedSink)

[0187] @TaintConfig(AlarmDescription="Tainted Sink")

[0188] functionCall fc4 where fc4.name match "(?i).*log.*";

[0189] 2. The configuration file received by the transformed data stream analysis engine is shown below:

[0190] Step 340: The DSL engine obtains the inspection results of the source code under test according to the DSL rules, and configures the data flow analysis engine based on the inspection results of the source code under test.

[0191] In this embodiment of the application, if the DSL rules cannot be directly converted into the configuration file of the data flow analysis engine, the DSL engine can obtain the inspection result of the source code under test based on the DSL rules without establishing a full CPG of the source code under test, as shown in Figure 2, and then configure the data flow analysis engine based on the inspection result of the source code under test.

[0192] Step 350: The DSL engine calls the data flow analysis engine to check the source code under test, obtain and output the data flow analysis results of the source code under test.

[0193] In this embodiment of the application, after configuring the data stream analysis engine based on DSL rules, the DSL engine can call the data stream analysis engine to perform data stream analysis on the source code under test, obtain and output the data stream analysis results of the source code under test.

[0194] For example, after receiving the configuration file sent by the DSL engine, the data flow analysis engine can perform data flow analysis on the received source code under test based on the configuration file, generating data flow analysis results for the source code under test. The data flow analysis engine can also feed back its generated data flow analysis results for the source code under test to the user through the DSL engine.

[0195] In the above technical solution, semantic analysis can be performed on DSL rules that require the participation of a data flow analysis engine. On the one hand, for DSL rules that can be directly converted into configuration files for the data flow analysis engine, the engine can be configured directly based on the DSL rules, improving the efficiency of data flow analysis. On the other hand, for configuration files that cannot be directly converted into configuration files for the data flow analysis engine, without needing to build a full CPG of the source code under test, the inspection results of the source code under test are obtained based on the DSL rules, and the data flow analysis engine is configured based on these inspection results. This also improves the efficiency of data flow analysis compared to existing technologies that require building a full CPG of the source code under test to obtain the inspection results and then configuring the data flow analysis engine based on those results.

[0196] The methods provided by the embodiments of this application have been described in detail above with reference to Figures 1 to 3. The embodiments of the apparatus of this application will now be described in detail below with reference to Figures 4 to 8. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be referred to the preceding method embodiments.

[0197] Figure 4 is a schematic block diagram of a code inspection device 400 provided in an embodiment of this application. The device 400 can be implemented by software, hardware, or a combination of both. The device 400 is applied to a DSL engine and includes: an acquisition module 410, a determination module 420, a query module 430, and an output module 440. The acquisition module 410 is used to acquire the source code to be tested and DSL rules; the determination module 420 is used to perform semantic analysis on the DSL rules to determine the target node and target edge for the DSL rule query; the determination module 420 is also used to acquire the target node and target edge from a graph database; the query module 430 is also used to generate an inspection result for the source code to be tested based on the position information of the target node and target edge in the source code to be tested, provided that the target node and target edge are already stored in the graph database, wherein the inspection result indicates the code position in the source code to be tested corresponding to the DSL rule; the output module 440 is used to output the inspection result of the source code to be tested.

[0198] Optionally, the acquisition module 410 is also used to acquire the position information of the target node and the target edge in the source code under test from the graph database.

[0199] Optionally, the device 400 further includes: a creation module for creating indexes for the target node and the target edge respectively; and a determination module 420 for comparing the indexes for the target node and the target edge with the indexes for nodes and edges stored in the graph database respectively, to determine whether the target node and the target edge are stored in the graph database.

[0200] Optionally, if the graph database does not contain an index for the target node, the determining module 420 is further configured to determine that the target node is not stored in the graph database. Or, if the graph database does not contain an index for the target edge, the determining module 420 is further configured to determine that the target edge is not stored in the graph database.

[0201] Optionally, if the target node and the target edge are not stored in the graph database, the device 400 further includes: a code parsing module and a persistence module, wherein the code parsing module is used to parse the source code to be tested and construct the target node and the target edge; the persistence module is used to store the target node and the target edge in the graph database.

[0202] Optionally, the DSL rule is a data flow analysis rule, and the device 400 further includes: a configuration module, used to configure the data flow analysis engine according to the inspection result of the source code under test, and generate a configuration file of the data flow analysis engine; a generation module, used to call the data flow analysis engine to perform data flow analysis on the source code under test, and generate the data flow analysis result of the source code under test; and an output module 440 is also used to output the data flow analysis result of the source code under test.

[0203] Optionally, the data stream analysis engine is used to taint the source code under test. The configuration file of the data stream analysis engine includes the following information: taint source information and taint convergence point information.

[0204] Optionally, the configuration file of the data stream analysis engine may also include at least one of the following: taint propagation rule information, harmless treatment information.

[0205] Figure 5 is a schematic block diagram of another code inspection device 500 provided in an embodiment of this application. This device 500 can be implemented by software, hardware, or a combination of both. The device 500 is applied to a DSL engine and includes: an acquisition module 510, a configuration module 520, a generation module 530, and an output module 540. The acquisition module 510 is used to acquire the source code to be tested and DSL rules, wherein the DSL rules are data flow analysis rules; the configuration module 520 is used to parse the DSL rules and convert them into a configuration file for the data flow analysis engine; the generation module 530 is used to call the data flow analysis engine to perform data flow analysis on the source code to be tested and generate the data flow analysis results of the source code to be tested; the output module 540 is used to output the data flow analysis results of the source code to be tested.

[0206] Optionally, the data stream analysis engine is used to taint the source code under test. The configuration file of the data stream analysis engine includes the following information: taint source information and taint convergence point information.

[0207] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the configuration file of the data stream analysis engine also includes at least one of the following: taint propagation rule information and harmless treatment information.

[0208] The device 400 or device 500 here may be embodied in the form of a functional module. The term "module" here can be implemented in software and / or hardware, without specific limitation. For example, a "module" can be a software program, a hardware circuit, or a combination of both that implements the above functions.

[0209] For example, the implementation of the modules in device 400 will be described in detail below using device 400 as an example. The implementation of the modules in device 500 is similar to that in device 400. For details, please refer to the implementation of the modules in device 400, which will not be repeated here.

[0210] As an example, the implementation of module 410 will be described below. Similarly, the implementation of other modules, such as module 420, module 430, module 440, module creation, code parsing, persistence, configuration, and generation, can refer to the implementation of module 410.

[0211] As an example of a software functional unit, the acquisition module 410 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, the acquisition module 410 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0212] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0213] As an example of a hardware functional unit, the acquisition module 410 may include at least one computing device, such as a server. Alternatively, the acquisition module 410 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0214] The multiple computing devices included in the acquisition module 410 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the acquisition module 410 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the acquisition module 410 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0215] Therefore, the modules of the various examples described in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0216] It should be noted that the device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the above methods. In actual 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. For example, the acquisition module 410 can be used to execute any step in the above methods, the determination module 420 can be used to execute any step in the above methods, the query module 430 can be used to execute any step in the above methods, the output module 440 can be used to execute any step in the above methods, the creation module can be used to execute any step in the above methods, the code parsing module can be used to execute any step in the above methods, the persistence module can be used to execute any step in the above methods, the configuration module can be used to execute any step in the above methods, and the generation module can be used to execute any step in the above methods. The steps implemented by the acquisition module 410, determination module 420, query module 430, output module 440, creation module, code parsing module, persistence module, configuration module, and generation module can be specified as needed. The acquisition module 410, determination module 420, query module 430, output module 440, creation module, code parsing module, persistence module, configuration module, and generation module respectively implement different steps in the above method to achieve all the functions of the above device.

[0217] Furthermore, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments above, which will not be repeated here.

[0218] The method provided in this application can be executed by a computing device, which can also be referred to as a computer system. It includes a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as processing units, memory, and memory control units; the functions and structure of this hardware will be described in detail later. The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software. Optionally, the computer system can be a handheld device such as a smartphone, or a terminal device such as a personal computer; this application does not particularly limit this, as long as the method provided in this application can be used. The executing entity of the method provided in this application can be a computing device, or a functional module within the computing device capable of calling and executing programs.

[0219] The following describes in detail a computing device provided in an embodiment of this application, with reference to Figure 6.

[0220] Figure 6 is a schematic diagram of the architecture of a computing device 1500 provided in an embodiment of this application. The computing device 1500 may be a server, a computer, or other device with computing capabilities. The computing device 1500 shown in Figure 6 includes at least one processor 1510 and a memory 1520.

[0221] It should be understood that this application does not limit the number of processors and memories in the computing device 1500.

[0222] The processor 1510 executes instructions in the memory 1520, causing the computing device 1500 to implement the method provided in this application. Alternatively, the processor 1510 executes instructions in the memory 1520, causing the computing device 1500 to implement the various functional modules provided in this application, thereby implementing the method provided in this application.

[0223] Optionally, the computing device 1500 also includes a communication interface 1530. The communication interface 1530 uses a transceiver module, such as, but not limited to, a network interface card or a transceiver, to enable communication between the computing device 1500 and other devices or communication networks.

[0224] Optionally, the computing device 1500 also includes a system bus 1540, wherein the processor 1510, memory 1520, and communication interface 1530 are respectively connected to the system bus 1540. The processor 1510 can access the memory 1520 through the system bus 1540; for example, the processor 1510 can perform data read / write or code execution in the memory 1520 through the system bus 1540. The system bus 1540 is a peripheral component interconnect express (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus 1540 is divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in Figure 6, but this does not mean that there is only one bus or one type of bus.

[0225] In one possible implementation, the processor 1510 primarily functions to interpret the instructions (or code) of a computer program and process data within the computer software. The instructions of the computer program and the data within the computer software can be stored in memory 1520 or cache 1516.

[0226] Optionally, processor 1510 may be an integrated circuit chip with signal processing capabilities. By way of example and not limitation, processor 1510 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Among these, a general-purpose processor is a microprocessor, etc. For example, processor 1510 may be a central processing unit (CPU).

[0227] Optionally, each processor 1510 includes at least one processing unit 1512 and a memory control unit 1514.

[0228] Optionally, the processing unit 1512, also known as the core, is the most important component of the processor. The processing unit 1512 is manufactured from single-crystal silicon using a specific production process. All calculations, command reception, command storage, and data processing are performed by the core. Each processing unit independently executes program instructions, utilizing parallel computing capabilities to accelerate program execution. Various processing units have fixed logical structures; for example, a processing unit includes logical units such as a Level 1 cache, a Level 2 cache, an execution unit, an instruction-level unit, and a bus interface.

[0229] In one implementation example, the memory control unit 1514 controls the data interaction between the memory 1520 and the processing unit 1512. Specifically, the memory control unit 1514 receives memory access requests from the processing unit 1512 and controls access to memory based on the memory access requests. By way of example and not limitation, the memory control unit is a device such as a memory management unit (MMU).

[0230] In one implementation example, each memory control unit 1514 addresses the memory 1520 via the system bus. An arbitrator (not shown in Figure 6) is configured on the system bus to handle and coordinate contention for access by multiple processing units 1512.

[0231] In one implementation example, the processing unit 1512 and the memory control unit 1514 are connected via internal chip connection lines, such as address lines, thereby enabling communication between the processing unit 1512 and the memory control unit 1514.

[0232] Optionally, each processor 1510 also includes a cache 1516, which is a buffer for data exchange (called a cache). When the processing unit 1512 needs to read data, it first looks for the required data in the cache. If the data is found, it is executed directly; otherwise, it looks for the data in memory. Since the cache operates much faster than memory, its purpose is to help the processing unit 1512 run faster.

[0233] The memory 1520 provides runtime space for processes in the computing device 1500. For example, the memory 1520 stores the computer program (specifically, the program code) used to generate the process. After the computer program is run by the processor to generate a process, the processor allocates corresponding storage space for the process in the memory 1520. Furthermore, the aforementioned storage space further includes text segments, initialized data segments, bit initialized data segments, stack segments, heap segments, etc. The memory 1520 stores data generated during the process's execution, such as intermediate data or process data, in the aforementioned process-specific storage space.

[0234] Optionally, the memory, also known as RAM, is used to temporarily store the data processed by the processor 1510, as well as data exchanged with external storage devices such as hard disks. As long as the computer is running, the processor 1510 will load the data that needs to be processed into RAM for processing, and after the processing is completed, the processing unit 1512 will send the result out.

[0235] By way of example and not limitation, memory 1520 is volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory is read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory is random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory 1520 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0236] The structure of the computing device 1500 listed above is merely illustrative and is not limited thereto. The computing device 1500 in this application includes various hardware components in existing computer systems. For example, the computing device 1500 also includes other memories besides memory 1520, such as disk storage. Those skilled in the art should understand that the computing device 1500 may also include other devices necessary for normal operation. Furthermore, depending on specific needs, those skilled in the art should understand that the computing device 1500 may also include hardware devices for implementing other additional functions. In addition, those skilled in the art should understand that the computing device 1500 may only include the devices necessary for implementing the embodiments of this application, and not necessarily all the devices shown in FIG. 6.

[0237] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device may be a server. In some embodiments, the computing device may also be a desktop computer, a laptop computer, or a smartphone, or other terminal device.

[0238] As shown in Figure 7, the computing device cluster includes at least one computing device 1500. The memory 1520 of one or more computing devices 1500 in the computing device cluster may store the same instructions for performing the above-described methods.

[0239] In some possible implementations, the memory 1520 of one or more computing devices 1500 in the computing device cluster may also each store a portion of the instructions for executing the above-described methods. In other words, a combination of one or more computing devices 1500 can jointly execute the instructions of the above-described methods.

[0240] It should be noted that the memory 1520 in different computing devices 1500 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the aforementioned device. That is, the instructions stored in the memory 1520 of different computing devices 1500 can implement the functions of one or more modules within the aforementioned device.

[0241] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 8 illustrates one possible implementation. As shown in Figure 8, two computing devices, 1500A and 1500B, are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device.

[0242] It should be understood that the functions of computing device 1500A shown in Figure 8 can also be performed by multiple computing devices 1500. Similarly, the functions of computing device 1500B can also be performed by multiple computing devices 1500.

[0243] In this embodiment, a computer program product containing instructions is also provided. The computer program product may be a software or program product containing instructions capable of running on a computing device or stored on any usable medium. When run on a computing device, it causes the computing device to perform the methods provided above, or causes the computing device to perform the functions of the apparatus provided above.

[0244] In this embodiment, a computer-readable storage medium is also provided. This computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that, when executed on a computing device, cause the computing device to perform the method described above.

[0245] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0246] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0247] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0248] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0249] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0250] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0251] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0252] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for code inspection, characterized in that, The method is applied to a domain-specific language DSL engine, and the method includes: Obtain the source code to be tested and the DSL rules; Perform semantic analysis on the DSL rules to determine the target node and target edge for the DSL rule query; If the target node and the target edge are already stored in the graph database, retrieve the target node and the target edge from the graph database; Based on the position information of the target node and the target edge in the source code to be tested, an inspection result of the source code to be tested is generated, wherein the inspection result is used to indicate the code position in the source code to be tested that corresponds to the DSL rule; Output the inspection results of the source code under test.

2. The method according to claim 1, characterized in that, If the target node and the target edge are not stored in the graph database. Before retrieving the target node and the target edge from the graph database, the method further includes: The source code to be tested is parsed to construct the target node and the target edge; The target node and the target edge are stored in the graph database.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The location information of the target node and the target edge in the source code under test is obtained from the graph database.

4. The method according to any one of claims 1 to 3, characterized in that, The graph database also stores indexes of nodes and edges already stored in the graph database, and the method further includes: Establish indices for the target node and the target edge; Based on the indexes of the target node and the target edge stored in the graph database, it is determined that the target node and the target edge have been stored in the graph database.

5. The method according to any one of claims 1 to 4, characterized in that, The DSL rules are data flow analysis rules, and the method further includes: Based on the inspection results of the source code under test, the data flow analysis engine is configured to generate the configuration file of the data flow analysis engine; The data flow analysis engine is invoked to perform data flow analysis on the source code under test, and the data flow analysis results of the source code under test are generated. Output the data flow analysis results of the source code under test.

6. The method according to claim 5, characterized in that, The data stream analysis engine is used to perform taint processing on the source code under test. The configuration file of the data stream analysis engine includes the following information: taint source information and taint convergence point information.

7. A method for code inspection, characterized in that, The method is applied to a domain-specific language DSL engine, and the method includes: Obtain the source code to be tested and the DSL rules, wherein the DSL rules are rules of the data flow analysis class; The DSL rules are parsed and converted into a configuration file for the data stream analysis engine; The data flow analysis engine is invoked to perform data flow analysis on the source code under test, and the data flow analysis results of the source code under test are generated. Output the data flow analysis results of the source code under test.

8. The method according to claim 7, characterized in that, The data stream analysis engine is used to perform taint processing on the source code under test. The configuration file of the data stream analysis engine includes the following information: taint source information and taint convergence point information.

9. A code checking apparatus, characterized in that, The apparatus is used in a domain-specific language DSL engine, and the apparatus includes: The acquisition module is used to acquire the source code to be tested and the DSL rules; The determination module is used to perform semantic analysis on the DSL rules to determine the target nodes and target edges of the DSL rule query. The determining module is further configured to retrieve the target node and the target edge from the graph database if the target node and the target edge are already stored in the graph database; The query module is further configured to generate an inspection result of the source code under test based on the position information of the target node and the target edge in the source code under test, wherein the inspection result is used to indicate the code position in the source code under test that corresponds to the DSL rule; The output module is used to output the inspection results of the source code under test.

10. The apparatus according to claim 9, characterized in that, If the target node and the target edge are not stored in the graph database, the device further includes: The code parsing module is used to parse the source code to be tested and construct the target node and the target edge; The persistence module is used to store the target node and the target edge in the graph database.

11. The apparatus according to claim 9 or 10, characterized in that, The acquisition module is further configured to acquire the position information of the target node and the target edge in the source code under test from the graph database.

12. The apparatus according to any one of claims 9 to 11, characterized in that, The graph database also stores indexes of nodes and edges already stored in the graph database, and the device further includes: A module is created to establish the indexes of the target node and the target edge; The determining module is further configured to determine that the target node and the target edge have been stored in the graph database based on the indexes of the target node and the target edge stored in the graph database.

13. The apparatus according to any one of claims 9 to 12, characterized in that, The DSL rules are data stream analysis rules, and the device further includes: The configuration module is used to configure the data flow analysis engine based on the inspection results of the source code under test, and generate the configuration file of the data flow analysis engine. The generation module is used to call the data flow analysis engine to perform data flow analysis on the source code under test and generate the data flow analysis results of the source code under test. The output module is also used to output the data flow analysis results of the source code under test.

14. The apparatus according to claim 13, characterized in that, The data stream analysis engine is used to perform taint processing on the source code under test. The configuration file of the data stream analysis engine includes the following information: taint source information and taint convergence point information.

15. A code checking apparatus, characterized in that, The apparatus is used in a domain-specific language DSL engine, and the apparatus includes: The acquisition module is used to acquire the source code to be tested and the DSL rules, wherein the DSL rules are rules of the data flow analysis class; A configuration module is used to parse the DSL rules and convert them into a configuration file for the data flow analysis engine. The generation module is used to call the data flow analysis engine to perform data flow analysis on the source code under test and generate the data flow analysis results of the source code under test. The output module is used to output the data flow analysis results of the source code under test.

16. The apparatus according to claim 15, characterized in that, The data stream analysis engine is used to perform taint processing on the source code under test. The configuration file of the data stream analysis engine includes the following information: taint source information and taint convergence point information.

17. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 8.

18. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster causes the computing device cluster to perform the method as described in any one of claims 1 to 8.

19. A computer-readable storage medium, characterized in that, It includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1 to 8.

Images