Code static analysis method and system based on Rete rule network

Abstract

The invention provides a code static analysis method and system based on a Rete rule network. The method comprises the steps of obtaining AST node fact data required by an inference service based on a source code AST object and a code compiler analysis result; according to a rule language, disassembling a code static analysis process into a plurality of sub-rules which can be described and reused, and constructing a reasoning service rule set; according to the reasoning service rule set, calling a rule interpreter to analyze and generate a Rete rule network corresponding to the reasoning service; according to the AST node fact data and the Rete rule network, calling a rule engine to execute mode matching, and if matching succeeds, executing a trigger operation function and updating the AST node fact data; and obtaining a code static analysis result according to the updated AST node fact data or self-defined reasoning result data after reasoning is completed. The method can be applied to the field of code static analysis, and the software automatic analysis efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of code static analysis, and in particular to a code static analysis method and system based on a Rete rule network. BACKGROUND

[0002] With the rapid growth of software system complexity, code static analysis technology has become the core means to ensure software quality and control technical debt. However, the existing mainstream parsing methods have great technical bottlenecks in complex scenarios, balance between analysis efficiency and accuracy, dynamic iteration support, etc. Specifically, traditional parsing methods are difficult to handle complex scenarios such as multi-layer recursive nesting and cross-project cross-file context analysis. Emerging AI-driven static analysis technology has certain potential, but is still unable to meet the requirements of code parsing accuracy, debuggability and interpretability due to the limitations of black box decision mechanism. In addition, in the agile delivery scenario, the above methods are prone to cause architecture governance lag due to rigid rule updates and high model training costs. SUMMARY

[0003] In order to at least solve one of the problems existing in the prior art, the present application provides a code static analysis method based on a Rete rule network, which can realize decoupling of complex code analysis logic and improve code static analysis efficiency.

[0004] The present application provides a code static analysis method based on a Rete rule network, which innovatively applies the Rete algorithm of the rule engine core to the field of code static analysis. First, the traditional static analysis process is disassembled and mapped into a plurality of reusable atomized sub-rules through a declarative rule language. Then, the inference business rule set is pre-built into a Rete rule network. Finally, the rule engine is called to complete pattern matching and static analysis business. The method realizes decoupling of complex analysis logic such as multi-level calling and recursive nesting through the rule engine, and quickly adapts to changes in analysis business requirements by using the dynamic combination mechanism of atomized sub-rules, thereby greatly improving the scalability and maintainability of software analysis.

[0005] In order to achieve the purpose of the present application, the present application provides a code static analysis method based on a Rete rule network, comprising:

[0006] Based on the source code AST object and the code compiler analysis result, the AST node fact data required for inference business is obtained;

[0007] According to the rule language, the code static analysis process is disassembled into a plurality of describable and reusable sub-rules, and an inference business rule set is constructed;

[0008] According to the inference business rule set, a rule interpreter is called to parse and generate a Rete rule network corresponding to the inference business;

[0009] According to the AST fact data and the Rete rule network, a rule engine is invoked to perform pattern matching, and if the matching is successful, a trigger operation function is executed and the AST node fact data is updated;

[0010] According to the updated AST node fact data or the custom reasoning result data after reasoning is completed, a code static analysis result is obtained.

[0011] Further, the specific implementation process of obtaining the AST node fact data comprises:

[0012] A code compiler is invoked to analyze project source code, and code analysis result data is obtained; wherein the code analysis result data comprises four types of mapping relationships: symbol definition and reference, type definition and reference, function definition and call, and interface definition and implementation;

[0013] Based on a depth-first strategy, all AST node metadata are recursively scanned from an abstract syntax tree (AST) object corresponding to each source code file; initial facts are generated according to the AST node metadata, and new attribute fields are added to the initial fact data by semantically mapping the code analysis result data, so as to generate structured AST node fact data adapted to the reasoning business requirements;

[0014] Wherein, the AST node fact data comprises two types of basic attributes and special attributes; the basic attributes are used to describe the basic information and syntax structure relationship of the AST node, and comprise ID, type, name, belonging key name, parent node ID and child node ID list; the special attributes are used to represent the dependency or reference relationship in the code analysis result, and comprise reference symbol source ID, reference type source ID, call function source ID and interface definition source ID.

[0015] Further, the code static analysis process is decomposed into a plurality of describable and reusable sub-rules according to a rule language, and a reasoning business rule set is constructed, comprising:

[0016] According to the static analysis business requirements, a traditional analysis process is decomposed and refined into a plurality of sub-processes describable by AST nodes;

[0017] The sub-processes are described as combinations of atomized operations such as identification, verification and extraction;

[0018] Based on the AST node fact data information, the atomized operations are described as atomized sub-rules using the rule language;

[0019] The collection of all sub-rules is the reasoning business rule set.

[0020] The inference business rule set is used to generate a Rete rule network; the combination of the atomized sub-rules reconfigures the traditional code static analysis logic; in addition, the rule trigger condition constraint mechanism can accurately control the timing process of rule inference.

[0021] Further, the rule language is defined as a structure body, and the structure body attributes include:

[0022] Rule ID, a unique identifier for classification management;

[0023] Rule name, used to briefly explain the rule function information;

[0024] Associated node set, used to define the nodes and verification conditions matched with the sub-rule, represented as an associated node list supporting tree-shaped nested structure;

[0025] Trigger operation function, used to predefine the function logic executed after matching the sub-rule;

[0026] An example of the above rule language structure body is an atomized sub-rule.

[0027] Further, the associated node is defined as a structure body supporting tree-shaped nested structure, and the structure body attributes include:

[0028] Node name, used to uniquely identify the elements in the associated node set;

[0029] Node type, used to generate type selection nodes in the Rete rule network;

[0030] Variable declaration, used to declare node attributes and their binding variable names;

[0031] Attribute verification condition, used to define node attribute verification rules, including single node attribute verification condition, cross-node attribute combination verification condition, and single node attribute custom function verification condition;

[0032] Nested attribute, used to describe the same organization structure as the abstract syntax tree (AST) when writing rules, the nested attribute corresponds to the key value of the parent node in the AST organization structure, and the nested attribute value is the associated node of the next level;

[0033] The single-node attribute verification condition refers to a verification condition of a single associated node attribute value (for example, an a attribute of an A node is equal to 1, denoted as A{a:{“=”,1}}), the cross-node attribute combination verification condition refers to a verification condition between two associated node attribute values (for example, an a attribute of an A node is equal to a b attribute of a B node, and the a attribute is denoted as “var1”, denoted as A{a:“var1”}, B{b:{“=”,“var1”}}); and the single-node attribute self-defined function verification condition refers to a self-defined function verification logic of a single associated node attribute value.

[0034] Specifically, the single-node attribute verification condition and the cross-node attribute combination verification condition can be represented as a structure body including two attributes of a condition operator and a verification attribute value, and the verification attribute value defines a value range boundary constraint of a verified attribute; and the single-node attribute self-defined function verification condition is represented as a self-defined function with a return value of a Boolean type, and the self-defined function can define attribute existence constraint, type constraint and regular expression constraint and the like.

[0035] Further, the node types in the Rete rule network and functions thereof include:

[0036] A root node is used to receive input AST fact data, check data fields and type attributes, and propagate the AST fact data to a next layer type selection node;

[0037] A type selection node is responsible for fact data preliminary screening, is used to receive incoming AST fact data, and according to a type attribute, the AST fact data is shunted and propagated to a next layer, all attribute nodes associated with the type selection node;

[0038] An attribute node is used to receive incoming AST fact data, and the AST fact data is propagated to a next layer, a condition node associated with the attribute node;

[0039] A condition node is responsible for single-node attribute condition verification, is used to receive incoming AST fact data, verifies and stores AST fact data satisfying a current node condition constraint, and if the AST fact data satisfies the condition, the AST fact data is propagated to a next layer, an Alpha node associated with the attribute node;

[0040] An Alpha node is used to receive incoming AST fact data, judges and stores AST fact data satisfying all condition node constraints of a previous layer, and if the AST fact data satisfies the condition, the AST fact data is propagated to a next layer, a Beta node associated with the Alpha node;

[0041] Beta node, responsible for multi-node combination condition verification, used for receiving incoming AST fact data, judging and storing AST fact data meeting all Alpha node or Beta node conditions of the previous layer, and if meeting, propagating the AST fact data to the Beta node of the next layer, and if the Beta node has no child node, completing a sub-rule matching and executing the trigger operation function.

[0042] Further, the specific implementation process of the rule engine includes:

[0043] The AST node fact data is input into the Rete rule network one by one, the rule engine is called to propagate the AST node fact data from the root node of the Rete rule network, if the AST node fact data propagates to the Beta node and has no subsequent child node, it is determined that a sub-rule matching is completed and the corresponding trigger operation function is executed;

[0044] The function logic predefined in the trigger operation function is executed, and the AST node fact data matched with the sub-rule is updated, wherein the input parameters of the trigger operation function are the Rete rule network, the associated AST node fact set and the variable binding relationship, and the output is the updated AST node fact data, and the function logic can process related custom reasoning process data;

[0045] The new AST node fact data is re-input into the Rete rule network, and the rule matching operation is repeatedly executed, if all the AST node fact data is input and no sub-rule matching is successful, the reasoning task is ended.

[0046] Further, the custom reasoning result data refers to all process data related to code static analysis involved in the function logic of the trigger operation function, including judgment results, identification results, organizational relationships and other reasoning conclusions.

[0047] The application provides a code static analysis system based on a Rete rule network, comprising the following modules:

[0048] An AST node fact data acquisition module is used to acquire AST node fact data required by reasoning business based on source code AST objects and code compiler analysis results;

[0049] A reasoning business rule set construction module is used to construct a reasoning business rule set by decomposing a code static analysis process into a plurality of describable and reusable sub-rules according to a rule language;

[0050] A rule network generation module is used to call a rule interpreter to parse and generate a Rete rule network corresponding to reasoning business according to the reasoning business rule set;

[0051] A pattern matching and updating module is configured to invoke a rule engine to perform pattern matching according to the AST node fact data and the Rete rule network, and perform a trigger operation function and update the AST node fact data if the pattern matching is successful.

[0052] An analysis result obtaining module is configured to obtain a code static analysis result according to the AST node fact data updated after reasoning is completed or custom reasoning result data.

[0053] By implementing the present application, the following beneficial effects can be achieved at least:

[0054] (1) The present application provides a code static analysis method based on a Rete rule network. The method obtains four types of key mapping relationships (declarations and references of symbols, types, functions and interfaces) through compiler-level AST analysis, generates AST fact data including basic attributes and special attributes by combining a depth-first strategy scanning, and provides an accurate and complete data analysis basis for static analysis. Then, a tree-shaped nested rule language is designed to decompose complex analysis logic into reusable atomized sub-rules (such as identification, verification and extraction operations), and the analysis process is accurately controlled through rule trigger conditions. Finally, the Rete rule network (root node, type selection, attribute, condition, Alpha and Beta) is used to perform hierarchical filtering and combined verification on the facts, and cross-node pattern matching is efficiently performed.

[0055] (2) The static analysis method provided by the present application is based on AST fact data and a rule engine, which changes the problem solving path in the traditional analysis method, describes the business process or code logic process as a fact-based reasoning process, and complex scenarios such as traditional hierarchical nesting and cross-project and cross-file context analysis can be converted into the above reasoning problem solving.

[0056] (3) Unlike the black box decision mechanism of AI, the method of the present application reconstructs the static analysis business through the combination of atomized sub-rules, which can support code breakpoint control rules triggering, so as to clearly and accurately view the input, output, trigger condition and rule network node state of each step in the business reasoning process. This feature ensures that the reasoning process is debuggable, the accuracy and interpretability of the reasoning result are ensured.

[0057] (4) According to the scheme provided by the present application, the basic rule set written for a specific programming language project only needs to increase business rules when the type of project is parsed again, without the need to write basic rules again, so as to achieve the effect of "one set of rules, multiple reuse". Compared with the time cost of AI model and data training, the predetermined analysis business can be completed more quickly. The method of the present application helps to improve the code analysis accuracy and efficiency, and provides a static code analysis engine with compiler-level precision and business-level flexibility for architecture management, security scanning and other scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0058] Figure 1 A flowchart of a code static analysis method based on a Rete rule network provided by an embodiment of the present application.

[0059] Figure 2 A construction flowchart of structured AST fact data in a code static analysis method based on a Rete rule network provided by an embodiment of the present application.

[0060] Figure 3 A construction flowchart of a Rete rule network in a code static analysis method based on a Rete rule network provided by an embodiment of the present application.

[0061] Figure 4 A Rete rule network in a code static analysis method based on a Rete rule network provided by an embodiment of the present application.

[0062] Figure 5 A local schematic diagram of a data flow analysis Rete rule network in a code static analysis method based on a Rete rule network provided by an embodiment of the present application. DETAILED DESCRIPTION

[0063] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work are within the protection scope of the present application.

[0064] As shown in Figure 1 A code static analysis method based on a Rete rule network provided by an embodiment of the present application includes the following steps:

[0065] Step S1, based on an AST object of source code and an analysis result of a code compiler, acquiring AST node fact data required by inference business;

[0066] Step S2, according to a rule language, decomposing a code static analysis process into a plurality of describable and reusable sub-rules, and constructing an inference business rule set;

[0067] Step S3, according to the inference business rule set, calling a rule interpreter to parse and generate a Rete rule network corresponding to the inference business;

[0068] Step S4, according to the AST node fact data and the Rete rule network, calling the rule engine to perform pattern matching, if the matching is successful, performing the trigger operation function and updating the AST node fact data;

[0069] Step S5, according to the updated AST node fact data or the custom reasoning result data after reasoning, obtaining the code static analysis result.

[0070] In a preferred embodiment, in step S1, referring to the AST node fact data construction flow diagram as shown in Figure 2 The step of obtaining the AST node fact data includes:

[0071] Step S1.1: using a code compiler to analyze the project source code file to obtain a code compiler analysis result.

[0072] The code compiler analysis result data includes at least four types of mapping relationships of symbol definition and reference, type definition and reference, function definition and call, and interface definition and implementation, respectively denoted as IdentMap, TypeMap, FuncMap, and InterfaceMap, and other mapping relationships can be added according to the analysis business in other embodiments.

[0073] The data structure of the above four types of mapping relationships is as follows:

[0074]

[0075] Among them, IdentMap, TypeMap, FuncMap, and InterfaceMap respectively represent the mapping relationship of symbol definition and reference to the symbol node ID, the mapping relationship of type definition and reference to the type node ID, the mapping relationship of function definition and call to the function node ID, and the mapping relationship of interface definition and implementation to the interface node ID.

[0076] Step S1.2: based on the depth-first strategy, recursively scanning the abstract syntax tree (AST) object corresponding to each source code file to obtain all AST node metadata, and then generating initial fact data containing basic attributes according to the AST node metadata; mapping the mapping relationship to a new attribute field SourceID added to the initial fact data to generate structured AST node fact data adapted to the reasoning business requirements.

[0077] The AST node fact data includes basic attributes and special attributes. The basic attributes are used to describe basic information and syntax structure relationship of the AST node, and include ID, type, name, belonging key name, parent node ID and child node ID list. The special attributes are used to represent dependency or reference relationship in the code compiler analysis result, and include reference symbol source ID, reference type source ID, call function source ID and interface definition source ID.

[0078] The data structure of the AST node fact data is as follows:

[0079]

[0080] The ID, Type and Name are used to describe basic information of the AST node, and the ParentID, ParentKey and ChildrenIDs are used to describe organization structure relationship of the AST node.

[0081] The complete data structure of the AST node fact data is as follows:

[0082]

[0083]

[0084] The TypeInfo attribute is used to describe node type information, and the SourceID is used to represent dependency or reference relationship between AST node elements. The connotation referred by the SourceID is determined by the Type. If the fact node is an identifier, the SourceID refers to the node ID of the symbol definition place. If the fact node is a function call, the SourceID refers to the node ID of the function definition place. If the fact node is an interface implementation function, the SourceID refers to the node ID of the interface definition place.

[0085] In step S2, the code static analysis process is disassembled into a plurality of describable and reusable sub-rules according to a rule language, and a reasoning business rule set is constructed, including:

[0086] The traditional code static analysis process is disassembled and refined into a plurality of sub-processes describable by AST nodes according to static analysis business requirements;

[0087] The sub-processes are described as combinations of atomized operations such as identification, verification and extraction;

[0088] Based on the AST node fact data information, the atomized operations are described as atomized sub-rules using the rule language;

[0089] The set of all atomized sub-rules is the reasoning business rule set, and the reasoning business rule set is used to generate a Rete rule network.

[0090] The set of atomized sub-rules reconstructs the traditional code static analysis business logic. In a preferred embodiment, the execution timing of the business main flow and sub-flow is accurately controlled by setting the trigger conditions of the atomized sub-rules to customize the cause-effect relationship and the rule trigger sequence.

[0091] In a preferred embodiment, in step S2, referring to the following Javascript example code, the code uses axios to create a default HTTP request API (request), and encapsulates uploadRequest and requestWithProject based on the default API configuration. At this time, the code static analysis task is to scan all HTTP request related APIs, and the corresponding code is as follows:

[0092]

[0093] const requestWithProject=(options)=>request({...options,ProjectId:true}) Specifically, the above business of scanning request related APIs can be decomposed into the following two sub-flows:

[0094] (a) According to the imported dependency and built-in function call axios.create() to obtain the default API;

[0095] (b) According to the variable definition and request reference relationship, scan all encapsulated APIs;

[0096] Further, the above sub-flows can be described as a combination of atomized operations such as identification, verification, and extraction:

[0097] Sub-flow (a) can be described as:

[0098] a1: Verify that the import source of the ImportDeclaration node is “axios”, and mark the attribute isAxios of the symbol axios as true;

[0099] a2: Verify that the function definition source node of the CallExpression node isAxios attribute is true, and mark the attribute isAxiosCall of the function call node as true;

[0100] a3: Verify that the initialization definition of the VariableDeclarator node is a CallExpression node and the attribute isAxiosCall is true, and mark the defaultAPI attribute of the symbol definition as true; ]

[0102] Sub-process (b) can be described as:

[0103] b1: Verify that the function definition source node of the CallExpression node is true, and mark the attribute defaultAPICall of the function call node as true;

[0104] b2: Verify that the function body of the ArrowFunctionExpression node is a CallExpression node and the attribute defaultAPICall is true, and mark the returnAPI attribute of this arrow function as true;

[0105] b3: Verify that the initialization of the VariableDeclarator node is an ArrowFunctionExpression node and the attribute returnAPI is true, and mark the customAPI attribute of the symbol definition as true; ]

[0107] Based on the AST node factual data information, the atomization operation is described in the atomization sub-rule using a rule language, and the rule language is defined as a structure body, and the attributes of the structure body include:

[0108] Rule ID, a unique identifier for classification management;

[0109] Rule name, used to briefly explain the rule function information;

[0110] Associated node set, used to define the node and verification condition matching the atomization sub-rule, represented as an associated node list supporting tree nesting structure;

[0111] Trigger operation function, used to predefine the function logic executed after matching the atomization sub-rule;

[0112] An instance of the above rule language structure body is an atomization sub-rule.

[0113] Further, the associated node is defined as a structure body supporting tree nesting structure, and the attributes of the structure body include:

[0114] Node name, used to uniquely identify the elements in the associated node set;

[0115] Node type, used to generate type selection nodes in the Rete rule network;

[0116] Variable declaration, used to declare node attributes and their binding variable names;

[0117] Attribute verification condition, used to define node attribute verification rules, including single-node attribute verification condition, cross-node attribute combination verification condition, and single-node attribute custom function verification condition;

[0118] Nested attribute, used to describe the same organization structure as the abstract syntax tree (AST) when writing rules, the nested attribute corresponding to the key value of the parent node in the AST organization structure, and the nested attribute value being the associated node of the next level;

[0119] The single-node attribute verification condition refers to the verification condition of the attribute value of a single associated node (for example, the a attribute of node A is equal to 1, denoted as A{a:{“=”,1}}), the cross-node attribute combination verification condition refers to the verification condition between the attribute values of two associated nodes (for example, the a attribute of node A is equal to the b attribute of node B, denoted as A{a:“var1”}, B{b:{“=”,“var1”}}), and the single-node attribute custom function verification condition refers to the custom function verification logic of the attribute value of a single associated node.

[0120] Specifically, the single-node attribute verification condition and the cross-node attribute combination verification condition can be represented as a structure, which includes a condition operator and a verification attribute value, and the verification attribute value defines the value domain boundary constraint of the verified attribute; the single-node attribute custom function verification condition is represented as a custom function with a return value of a Boolean type, which can define attribute existence constraint, type constraint, and regular expression constraint, etc.

[0121] In a preferred embodiment, in step S2, the above-mentioned atomization operation a1 is described using a rule language, and the following atomization rule R1 can be obtained:

[0122]

[0123]

[0124] Wherein, the atomization rule uniquely identified as R1, the rule name can briefly summarize the function of the atomization operation a1: get-axios indicates to obtain the axios identifier; The atomization rule R1 involves 3 AST nodes, including the import definition node ImportDeclaration, the import item node ImportDefaultSpecifier and the identifier node Identifier, which are bound to unique node names A, B and C, respectively; The description method of the atomization rule R1 adopts the same tree-shaped nested structure as the AST object, and the specifiers and local are the nested attributes corresponding to the key values in the actual AST one by one. This feature can support quick rule writing without investing more effort to check the syntax structure relationship between AST nodes.

[0125] Further, the A and B nodes in the atomization rule R1 declare two variables $a1 and $b1 through the ID attribute. The above variables correspond to the ID attribute in the fact data of the AST node and can be used to define specific attribute verification conditions, such as ParentID: {"==","$a1"}; Specifically, the Source: {"==","axios"} in the atomization rule R1 is a single-node attribute verification condition, indicating that the import source of the ImportDeclaration node is the dependency package "axios"; The ParentID: {"==","$a1"} in R1 is a cross-node attribute combination verification condition, the connotation of which can be referred to the following expression: ImportDefaultSpecifier ["ParentID"] = ImportDeclaration ["ID"]; In addition, if an attribute existence constraint needs to be added to verify whether the PartentID attribute field exists, a custom function condition can be defined as follows: ParentID: {"==",function(attrValue){return bool}}, the input is the attribute value attrValue, and after the custom verification logic processing, the result of bool type is returned.

[0126] Continue to describe the atomization operations a2, a3, b1, b2 and b3 using the above rule language, the inference business rule set corresponding to the inference scanning API business can be obtained.

[0127] In step S3, the node types and their functions in the Rete rule network include:

[0128] The root node is used to receive the input AST node fact data, check the data field and type attribute, and propagate the AST node fact data to the next layer of type selection nodes;

[0129] Type selection node, for being responsible for the preliminary screening of AST node fact data, for receiving incoming AST node fact data, and for shunting the AST node fact data to the next layer, all attribute nodes associated with the type selection node, according to the type attribute;

[0130] Attribute node, for receiving incoming AST node fact data, and for propagating the AST node fact data to the next layer, the condition node associated with the attribute node;

[0131] Condition node, for being responsible for single-node attribute condition verification, for receiving incoming AST node fact data, verifying and storing AST node fact data satisfying the current node condition constraint, and for propagating the AST node fact data to the next layer, the Alpha node associated with the attribute node, if satisfied;

[0132] Alpha node, for receiving incoming AST node fact data, judging and storing AST node fact data satisfying all condition node constraints of the previous layer, and for propagating the AST node fact data to the next layer, the Beta node associated with the Alpha node, if satisfied;

[0133] Beta node, for being responsible for multi-node combined condition verification, for receiving incoming AST node fact data, judging and storing AST node fact data satisfying all Alpha node or Beta node conditions of the previous layer, and for propagating the AST node fact data to the next layer, the Beta node, if satisfied; if the Beta node has no child node, a sub-rule matching is completed and the trigger operation function is executed.

[0134] In a preferred embodiment, in step S3, with reference to the construction flowchart of the Rete rule network as shown in Figure 3 , the specific implementation process is as follows:

[0135] Detecting whether the current rule has a nested relationship, if not, directly entering the next step; if yes, scanning all AST nodes through depth-first traversal, automatically generating parentKey in the scanning process, and processing the addition of the three types of verification conditions mentioned above in the AST node;

[0136] Traversing all AST node fact data, judging whether the added type node contains the current AST type, if yes, directly entering the next step; otherwise, adding the type node corresponding to the AST node fact data, and adding it to the child nodes of the root node;

[0137] Traverse the three types of verification conditions, i.e., single-node attribute verification condition, cross-node attribute combination verification condition, and single-node attribute custom function verification condition, to determine whether the attribute node of this type has been added. If yes, go to the next step directly; otherwise, add the attribute node of this type and add it to the child node of the node of this type.

[0138] Continue to determine whether the condition node of this attribute has been added. If yes, go to the next step directly; otherwise, add the condition node of this attribute and add it to the child node of the attribute node.

[0139] After all types of nodes and attribute nodes are added, obtain all verification conditions of the current AST node, determine whether the same Alpha node (belonging to different rules but having the same AST node type and attribute conditions) exists, if yes, go to the next step directly; otherwise, add the Alpha node corresponding to the AST node and add it to the child node of the required matching condition node.

[0140] After the Alpha node is added, obtain the cross-node attribute combination verification condition of the current rule, determine whether the same Beta node (belonging to different rules but having the same cross-node attribute combination verification condition) exists, if yes, go to the next step directly; otherwise, add the Beta node corresponding to the cross-node attribute combination verification condition and add it to the child node of the required Alpha node.

[0141] Output the Rete rule network, which is a tree, and the root node, type selection node, attribute node, condition node, Alpha node, and Beta node from top to bottom.

[0142] In a preferred embodiment, a Go language Rete rule network is generated with reference to Figure 4 The Rete rule network contains four type nodes: SelectorExpr, Ident, CallExpr, and Assignstmt. The Ident identifier node includes two attributes: Name and ParentID. The condition node associated with the Name attribute is R1-cond1, which represents the single-node attribute verification condition {Name=="func"}. The condition nodes associated with the ParentID attribute, i.e., {ParentID:"$a1"} and {ParentID:"$c1"}, represent variable declaration. The Alpha node corresponding to Ident is AMemory1 node, which is used to store the AST fact node satisfying the above two attribute conditions.

[0143] In the atomization rule R1, two cross-node attribute combination verification conditions are included, corresponding to R1-Beta0 and R1-Beta1 nodes respectively, the R1-Beta0 node obtains the AST node fact data transmitted from the two Alpha nodes AMemory2 and AMemory0, and performs the following cross-node attribute combination verification condition verification: CallExpr ["ID"] = SelectorExpr ["ParentID"], and if the verification is successful, the AST node fact data is continuously transmitted to the next Beta node R1-Beta1.

[0144] In step S4, according to the AST node fact data and the Rete rule network, a rule engine is called to perform pattern matching, and if the matching is successful, a trigger operation function is executed and the AST node fact data is updated, and the specific implementation process of the rule engine includes:

[0145] The AST node fact data is input into the Rete rule network one by one, and the rule engine is called to propagate the AST node fact data from the root node of the Rete rule network, and if the AST node fact data propagates to the Beta node and has no subsequent child node, it is determined that a sub-rule matching is completed and the corresponding trigger operation function is executed;

[0146] The function logic predefined in the trigger operation function is executed, and the AST node fact data matched with the sub-rule is updated; wherein the input parameters of the trigger operation function are the Rete rule network, the associated AST node fact set, and the variable binding relationship, and the output is the updated AST node fact data; the function logic can process related custom reasoning process data;

[0147] The updated AST node fact data is input into the Rete rule network again, and the rule matching operation is continued to be repeated, and if all the AST node fact data is input and no sub-rule matching is successful, the reasoning task is ended.

[0148] In a preferred embodiment, in step S4, referring to the Rete rule network as shown in Figure 4 The specific implementation process of the rule engine performing pattern matching is as follows:

[0149] The AST node fact data set constructed in step S1 is input into the Rete rule network constructed in step S3 one by one, and propagated downward from the root node, and if the input fact node is Ident1;

[0150] The root node, the type of the input Ident1 fact data and the type attribute are checked, and if the check is passed, it is propagated to the next layer (Ident) Type1 type selection node; if the check fails, the downward propagation is stopped;

[0151] Type selection node, after receiving the incoming Ident1, it is propagated to all attribute nodes Name (Attr1), ParentID (Attr2) in the next layer respectively;

[0152] Attribute node, after receiving the incoming Ident1, it is propagated to all condition nodes R1-Cond1, R1-Cond2, R1-Cond9 in the next layer respectively;

[0153] Condition node, R1-Cond1 node obtains the Name attribute value in the fact data, judges whether it is equal to "func", if true, records Ident1 in the current condition node cache, and propagates it to the next layer Alpha node AMemory1, if false, stops the downward propagation; R1-Cond2 and R1-Cond9 nodes are only variable declarations, which can be directly propagated to AMemory1 and AMemory5;

[0154] Alpha node, AMemory1 judges whether the incoming Ident satisfies all the condition node constraints in the last layer according to the matching cache data of the upper condition node, if yes, records Ident1 in the current AMemory1 node cache, and propagates it to the next layer R1-Beta1 node;

[0155] Beta node, R1-Beta1 receives the new fact when it is incoming, obtains the associated AST node set from the matching cache data of the upper AMemory1 node and R1-Beta0 node, judges the cross-node attribute combination verification condition SelectorExpr ["ID"] = Ident ["ParentID"] according to the attribute values of the nodes, if yes, completes the matching of the atomization rule R1 and executes the corresponding trigger operation function.

[0156] Specifically, the trigger operation function refers to the Action function in the atomization rule R1 in step S2, which predefines a series of functional logic, for example as follows:

[0157]

[0158] In the above example code, first, the AST node data A of the matching rule is obtained, then the new attribute field isAxios is added to node A according to the current rule conclusion, and finally the new fact is re-added to the Rete rule network to continue the subsequent rule chain matching process; in addition, the Action function can also execute the generation of reasoning logs, record custom reasoning result data and other custom processing logic.

[0159] In step S5, the code static analysis result is obtained according to the updated AST node fact data or the custom reasoning result data after reasoning is completed.

[0160] Specifically, the final fact data after reasoning is completed is obtained, and the final code static analysis result is generated according to the marked field information therein.

[0161] The custom reasoning result data refers to all process data related to code static analysis and involved in the function logic of the triggering operation function, including judgment results, identification results, organizational relationships and other reasoning conclusions.

[0162] The foregoing embodiments of the present application provide a code static analysis method based on a Rete rule network, and the core process thereof is as follows: AST objects and code compiler analysis data are fused to generate structured fact data containing basic attributes and special attributes; a code static analysis process is decomposed into reusable sub-rules, and a tree-shaped nested rule language is used to realize mapping of syntax to an AST organizational structure; a rule interpreter generates a Rete rule network including 7 layers of nodes by analyzing a rule set; and a rule engine completes triggering and execution of a rule chain through incremental loop reasoning, thereby realizing a full-process closed loop from fact generation, process decomposition, rule description, rule network construction, incremental reasoning to result integration, and providing an extensible code analysis paradigm for the field of code static analysis.

[0163] In a preferred embodiment, a code static analysis system based on a Rete rule network is provided for implementing the method described in the foregoing embodiments, and the system includes the following modules:

[0164] An AST node fact data acquisition module is configured to acquire AST node fact data required by reasoning business based on source code AST objects and code compiler analysis results;

[0165] A reasoning business rule set construction module is configured to decompose a code static analysis process into a plurality of describable and reusable sub-rules according to a rule language, and construct a reasoning business rule set;

[0166] A rule network generation module is configured to call a rule interpreter to analyze and generate a Rete rule network corresponding to reasoning business according to the reasoning business rule set;

[0167] A pattern matching and updating module is configured to call a rule engine to perform pattern matching according to the AST node fact data and the Rete rule network, and if the matching is successful, a triggering operation function is executed and the AST node fact data is updated;

[0168] An analysis result acquisition module is configured to acquire a code static analysis result according to updated AST node fact data or custom reasoning result data after reasoning is completed.

[0169] In a preferred embodiment, a Rete rule network-based data flow analysis is performed:

[0170] This embodiment selects a front-end Javascript project as the research object, converts it into AST fact data after compilation, and realizes cross-file data flow analysis by writing three types of rule sets (including 18 information aggregation rules, 11 connotation information reasoning rules, and 16 connotation information propagation rules). The specific contents of the three types of rules are as follows:

[0171] Information aggregation rules are used to aggregate the information of identifier nodes or literal nodes to various import and export, definition, and expression nodes at the upper level.

[0172] Connotation information reasoning rules are used to identify initial data literals (numbers, strings, Boolean values, and null values), special identifiers (undefined, Infinity, and NaN), and generate complete class or object data information according to the organization structure of classes or objects.

[0173] Connotation information propagation rules are used to simulate the propagation process of data in different code statements, including variable definition statements, class or object definition statements, assignment statements, function call statements, and import and export statements.

[0174] Further, a rule interpreter is called to parse and generate the Rete rule network corresponding to the above rule sets, as shown in the local diagram of the data flow analysis Rete rule network, which contains a total of 45 rules, 29 type nodes, 133 attribute nodes, 213 condition nodes, 297 Alpha nodes, and 188 Beta nodes. Figure 5

[0175] Further, the AST node fact data is input into the above Rete rule network for reasoning, and the analysis performance under different rule sets and fact sizes is tested. The test results are as follows:

[0176] Number of rules Number of facts / statement Number of rule network nodes Inference time consuming / s 29 41961 654 4.993 45 41961 860 6.168 45 53793 860 7.581

[0177] ​In summary, this embodiment constructs a JavaScript cross-file data flow analysis system through three types of rule sets (45 rules), and generates a Rete rule network containing 860 nodes through a rule interpreter. Referring to the test data in the above table, when the number of rules increases by 55% (16 rules) and the network size expands by 31%, the reasoning time only increases by 23.5%; when the number of rules is fixed and the number of facts increases from 41961 to 53793 (+28.2%), the reasoning time only increases from 6.168s to 7.581s (+22.9%); the performance test shows that the code static analysis method based on the Rete rule network has near-linear expansion capability (non-exponential expansion), and has strong engineering landing feasibility and practicability.

[0178] The specific embodiments described above further illustrate the purposes, technical solutions and beneficial effects of the present application. It should be understood that the above description is only a specific embodiment of the present application and is not intended to limit the protection scope of the present application. It is particularly pointed out that any modification, equivalent replacement, improvement, etc. made by those skilled in the art within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A code static analysis method based on Rete rule networks, characterized in that, include: Based on the source code AST object and code compiler analysis results, obtain the AST node fact data required for inference business; Based on the rule language, the static analysis process of the code is broken down into multiple describable and reusable sub-rules to construct a set of inference business rules; Based on the inference business rule set, the rule interpreter is invoked to parse and generate the Rete rule network corresponding to the inference business; Based on the AST node fact data and the Rete rule network, the rule engine is invoked to perform pattern matching. If the matching is successful, the trigger operation function is executed and the AST node fact data is updated. Obtain the static analysis results of the code based on the updated AST node fact data or custom inference result data.

2. The code static analysis method based on Rete rule networks according to claim 1, characterized in that, The specific implementation process for obtaining AST node fact data includes: Call the code compiler to analyze the project's source code files and obtain the code compiler analysis results; The AST objects corresponding to each source code file are recursively scanned based on a depth-first strategy to obtain all AST node metadata. Initial fact data is generated based on the AST node metadata. Then, the code compiler analysis results are semantically mapped to new attribute fields and added to the initial fact data to generate structured AST node fact data that adapts to the inference business requirements.

3. The code static analysis method based on Rete rule networks according to claim 1, characterized in that, AST node fact data includes two categories: basic attributes and proprietary attributes. Basic attributes are used to describe the basic information and syntactic structure relationships of AST nodes. Specific attributes are used to represent dependencies or references in the compiler analysis results of the code.

4. The code static analysis method based on Rete rule networks according to claim 1, characterized in that, The process of decomposing the static code analysis process into multiple describable and reusable sub-rules based on the rule language is used to construct a set of inference business rules, including: Based on the business requirements of static analysis, the traditional code static analysis process is broken down and refined into multiple sub-processes that can be described by available AST nodes. The sub-process is described as a combination of atomic operations; Based on the factual data of AST nodes, atomic operations are described as atomic sub-rules using a rule language. The set of all atomized sub-rules constitutes the inference business rule set, which is used to generate the Rete rule network.

5. The code static analysis method based on Rete rule networks according to claim 4, characterized in that, The rule language is defined as a structure, and the structure attributes include: Rule ID, a unique identifier used for category management; The rule name is used to briefly describe the rule's function. The associated node set is used to define the nodes that match the sub-rule and the validation conditions. It is represented as a list of associated nodes that supports a nested tree structure. Trigger operation function, used to predefine the functional logic to be executed after matching the sub-rule; An instance of the structure of the rule language is an atomic sub-rule.

6. The code static analysis method based on Rete rule networks according to claim 5, characterized in that, An associated node is defined as a structure that supports a nested tree structure. The properties of this structure include: The node name is used to uniquely identify an element in a set of associated nodes. Node type, used to generate type selection nodes in the Rete rule network; Variable declaration, used to declare node attributes and their bound variable names; Attribute validation conditions are used to define node attribute validation rules, including single-node attribute validation conditions, cross-node attribute combination validation conditions, and single-node attribute custom function validation conditions. Nested attributes are used to describe the same organizational structure as the Abstract Syntax Tree (AST) when writing rules. The nested attributes correspond to the key values ​​of the parent nodes in the AST organizational structure, and the nested attribute values ​​are the associated nodes at the next level. The single-node attribute validation condition refers to the validation condition for a single associated node attribute value; the cross-node attribute combination validation condition refers to the validation condition between two associated node attribute values; and the single-node attribute custom function validation condition refers to the custom function validation logic for a single associated node attribute value. The single-node attribute verification condition and the cross-node attribute combination verification condition can be represented as a structure. The structure includes two attributes: a condition operator and a verification attribute value. The verification attribute value defines the value domain boundary constraint of the verified attribute. The single-node attribute custom function verification condition is represented as a custom function that returns a boolean value. Custom constraint logic such as attribute existence constraint, type constraint, and regular expression constraint can be defined.

7. The code static analysis method based on Rete rule networks according to claim 1, characterized in that, The node types and their functions in the Rete rule network include: The root node is used to receive the input AST fact data, validate the data fields and type attributes, and propagate the AST node fact data to the next level type selection node; The type selection node is responsible for the initial screening of fact data in the AST nodes. It receives the incoming AST fact data and distributes it to the next layer of all attribute nodes associated with the type selection node based on the type attribute. Attribute nodes are used to receive incoming AST node fact data and propagate the AST node fact data to the next layer, the condition nodes associated with the attribute nodes; Condition nodes are responsible for verifying the attribute conditions of a single node. They receive incoming AST node fact data, verify and store AST fact data that satisfies the current node's condition constraints, and if satisfied, propagate the AST fact data to the next layer, the Alpha node associated with the attribute node. Alpha node is used to receive incoming AST node fact data, determine and store AST node fact data that satisfies the constraints of all condition nodes in the upper layer, and if satisfied, propagate the AST node fact data to the next layer, the Beta node associated with Alpha node. Beta nodes are responsible for verifying the combined conditions of multiple nodes. They receive incoming AST node fact data, determine and store AST node fact data that satisfies the conditions of all Alpha or Beta nodes in the previous layer. If satisfied, they propagate the AST node fact data to the Beta nodes in the next layer. If the Beta node has no child nodes, it completes a sub-rule matching and executes the trigger operation function.

8. The code static analysis method based on Rete rule networks according to claim 1, characterized in that, The specific implementation process of the rule engine includes: The fact data of the AST nodes are input into the Rete rule network one by one. The rule engine is called to propagate the fact data of the AST nodes starting from the root node of the Rete rule network. If the fact data of the AST nodes propagates to the Beta node and there are no subsequent child nodes, it is determined that a sub-rule matching is completed and the corresponding trigger operation function is executed. The predefined functional logic in the trigger operation function is executed to update the AST node fact data that matches the sub-rule; wherein, the input parameters of the trigger operation function are the Rete rule network, the associated AST node fact set, and the variable binding relationship, and the output is the updated AST node fact data; the functional logic can process related custom inference process data; The new AST node fact data is re-input into the Rete rule network, and the rule matching operation is repeated. If all AST node fact data is input and no sub-rule is successfully matched, the inference task ends.

9. A code static analysis method based on Rete rule networks according to any one of claims 1-8, characterized in that, The custom reasoning result data refers to all process data related to the static analysis of the code and involved in the functional logic of the trigger operation function, including reasoning conclusions such as judgment results, identification results, and organizational relationships.

10. A code static analysis system based on Rete rule networks, characterized in that, The system for implementing the method of any one of claims 1-9 includes the following modules: The AST node fact data acquisition module is used to acquire the AST node fact data required for inference operations based on the source code AST object and the code compiler analysis results. The reasoning business rule set construction module is used to decompose the static code analysis process into multiple describable and reusable sub-rules according to the rule language, and construct the reasoning business rule set. The rule network generation module is used to call the rule interpreter to parse and generate the Rete rule network corresponding to the inference business based on the inference business rule set; The pattern matching and update module is used to call the rule engine to perform pattern matching based on the AST node fact data and the Rete rule network. If the matching is successful, the trigger operation function is executed and the AST node fact data is updated. The analysis result acquisition module is used to obtain the static analysis results of the code based on the updated AST node fact data or custom inference result data.

Images