Code vulnerability detection method, device and equipment

Abstract

The invention discloses a code vulnerability detection method, a code vulnerability rule configuration method, a static single assignment SSA code acquisition method, devices corresponding to the methods, and electronic equipment. The code vulnerability detection method comprises the following steps: acquiring a plurality of source code files and code vulnerability rules of an application program; generating an abstract syntax tree of the source code file, and obtaining a function call relationship; and traversing the abstract syntax tree, and obtaining a cross-function risk propagation path according to the function call relationship and the code vulnerability rule. By the adoption of the processing mode, the function calling relation and the abstract syntax tree are fused to conduct cross-function code vulnerability detection, cross-function vulnerability detection of context sensitivity, flow sensitivity and domain sensitivity is achieved, and vulnerability false report and missing report are avoided; therefore, the accuracy and recall rate of vulnerability detection can be effectively improved.

Description

Technical Field

[0001] This application relates to the field of information security technology, specifically to code vulnerability detection methods and devices, code vulnerability rule configuration methods and devices, static single-assignment SSA code acquisition methods and devices, and electronic devices. Background Technology

[0002] During the operation of a software system, if there are hidden risks in the code, hackers may take the opportunity to launch attacks, leading to problems such as the leakage of user information. Taking financial software as an example, once the code security is compromised, users' funds will be threatened, potentially causing significant economic losses and social impact. To ensure the stable and reliable operation of software systems, security checks on the code are particularly crucial. By conducting security checks on the code, hidden dangers and risks can be quickly identified, preventing serious consequences caused by code defects.

[0003] However, existing open-source code vulnerability detection tools suffer from high false negative rates due to a lack of cross-function tracing capabilities; while existing closed-source code vulnerability detection tools, although capable of cross-function tracing, generate both false positives and false negatives due to insufficient domain sensitivity. Therefore, existing code vulnerability detection tools struggle to meet the application's demand for high accuracy and recall in cross-function vulnerability detection. Summary of the Invention

[0004] This application provides a code vulnerability detection method to address the problem of low accuracy and recall rates in existing cross-function vulnerability detection technologies. This application also provides a code vulnerability detection device, a code vulnerability rule configuration method and device, a static single-assignment (SSA) code acquisition method and device, and an electronic device.

[0005] This application provides a code vulnerability detection method, including:

[0006] Obtain multiple source code files and code vulnerability rules of the application;

[0007] Generate an abstract syntax tree for the source code file and obtain the function call relationships;

[0008] Traverse the abstract syntax tree and obtain the risk propagation path across functions based on the function call relationships and the code vulnerability rules.

[0009] Optionally, obtaining the function call relationship includes:

[0010] Obtain the static single assignment (SSA) code of the application;

[0011] Based on the SSA code, obtain the function call relationships.

[0012] Optionally, obtaining the static single assignment (SSA) code of the application includes:

[0013] The program compilation command is executed to compile the application. The source code of the program compilation command includes compilation code and dependency analysis code, which compiles the source code file through the compilation code and obtains the package dependency information of the application through the dependency analysis code. Based on the package dependency information, an abstract syntax tree (SSA) of the source code file is generated. Based on the abstract syntax tree, SSA code is generated.

[0014] Optionally, obtaining the static single assignment (SSA) code of the application further includes:

[0015] Obtain the program compilation script, which includes dependency package installation information and the program compilation commands;

[0016] The program is run to compile the script, which enables the installation of dependency packages based on the dependency package installation information.

[0017] Optional, also includes:

[0018] Break the application into multiple subroutines;

[0019] The dependency package installation information includes the dependency package installation information of the subroutine;

[0020] The process of installing dependency packages based on the dependency package installation information includes:

[0021] Install the dependency packages according to the dependency package installation information of the subroutine.

[0022] Optional, also includes:

[0023] Set the environment variables corresponding to the package dependency information;

[0024] The step of generating the abstract syntax tree of the source code file based on the package dependency information includes:

[0025] The environment variables are used as input information for the abstract syntax tree generation tool, which then generates an abstract syntax tree.

[0026] Optional, also includes:

[0027] Obtain the correspondence between AST functions and SSA functions;

[0028] Based on the function correspondence, determine the call location of functions that are called across files.

[0029] Optional, also includes:

[0030] Based on the function identifier Token, obtain the correspondence between AST functions and SSA functions.

[0031] Optional, also includes:

[0032] Based on the SSA code, determine the type information of the abstract syntax tree nodes;

[0033] The process of traversing the abstract syntax tree and obtaining cross-function risk propagation paths based on the function call relationships and code vulnerability rules includes:

[0034] Traverse the abstract syntax tree and obtain the risk propagation path across functions based on the type information of the abstract syntax tree nodes, the function call relationship, and the code vulnerability rules.

[0035] Optional, also includes:

[0036] Store the abstract syntax tree data and SSA code data in memory;

[0037] Based on the SSA code, determine the type information of the abstract syntax tree nodes;

[0038] Frequently used query information is stored in the cache, and the frequently used query information includes at least one of the following: function call relationship, structure / interface inheritance relationship, and application framework identification information; the application framework identification information includes at least one of the following: application entry point, and routing graph.

[0039] Optionally, based on the SSA code, the function call relationship is obtained, including:

[0040] At the package granularity level, function call relationships are obtained in parallel based on the SSA code.

[0041] Optionally, generating an abstract syntax tree for the source code file includes:

[0042] At the package granularity level, abstract syntax trees of the source code files are generated in parallel.

[0043] Optionally, the same function may exhibit different pollution propagation behaviors in different calling scenarios.

[0044] Optionally, the source code includes structured variables, which include a first field and a second field;

[0045] The risk propagation path before the function call includes the first field;

[0046] The called function includes sensitive operations related to the first field.

[0047] Optional, also includes:

[0048] The source code includes structured variables, which consist of a first field and a second field;

[0049] The risk propagation path before the function call includes the first field;

[0050] The called function includes sensitive operations related to the second field.

[0051] Optionally, for branch conditions in the source code, vulnerability detection is performed on the code within the branch condition based on the risk propagation path before the branch.

[0052] For branch merging in the source code, the risk propagation paths in multiple program branches are merged according to the branch merging method.

[0053] Optionally, traversing the abstract syntax tree and obtaining cross-function risk propagation paths based on the function call relationships and the code vulnerability rules includes:

[0054] Record the correspondence between the function entry state and the function output state;

[0055] If the entry state of the function to be detected is the same as the recorded function entry state, then the corresponding function output result state is obtained according to the correspondence.

[0056] Optional, also includes:

[0057] Obtain the types of function input parameters affected by the risk source in the function calls within the risk propagation path;

[0058] If the type of the function input parameter is a type that does not have the ability to propagate risk, then the risk propagation path will be regarded as an invalid propagation path.

[0059] Optionally, obtaining the type of the function input parameter includes:

[0060] Obtain the static single assignment (SSA) code of the application;

[0061] Based on the SSA code, obtain the definition and usage chain of the SSA variables;

[0062] The type of the SSA function input parameter is obtained by using a binary search algorithm and a chain according to the definition.

[0063] Obtain the correspondence between the input parameters of the AST function and the input parameters of the SSA function;

[0064] Based on the correspondence of function input parameters and the type of SSA function input parameters, obtain the type of AST function input parameters affected by risk sources.

[0065] Optionally, obtaining the type of the function input parameter includes:

[0066] At the package granularity level, the types of the function input parameters are obtained in parallel.

[0067] Optional, also includes:

[0068] Merge risk propagation paths with the same risk points to form a code vulnerability report.

[0069] Optional, also includes:

[0070] Based on the source code, obtain the program entry point:

[0071] If there are multiple program entry points, the application is split into multiple subroutines, and code vulnerability detection is performed on multiple subroutines in parallel.

[0072] Optionally, the parallel code vulnerability detection of multiple subroutines includes:

[0073] Code vulnerability detection is performed in parallel on multiple combinations of subroutines and code vulnerability rules.

[0074] Optionally, the code vulnerability rules are written in a domain-specific language;

[0075] The code vulnerability rules are written in a domain-specific language;

[0076] The code vulnerability rules include the following rule items: risk source, purifier, and risk point;

[0077] The process of traversing the abstract syntax tree and obtaining cross-function risk propagation paths based on the function call relationships and code vulnerability rules includes:

[0078] Detect whether the source code contains the risk sources specified in the code vulnerability rules;

[0079] If the risk source is detected, then check whether the source code includes a purifier for the risk source;

[0080] If no purifier is detected for the risk source, then check whether the source code includes risk points related to the risk source.

[0081] If a risk point related to the risk source is detected, the propagation path from the risk source to the risk point is obtained.

[0082] Optionally, the risk source includes at least one of the following attributes: function return value, expression;

[0083] The value of the function return value attribute includes: the function return value obtained from the request body of the network request that contains user-controllable input;

[0084] The value of the expression attribute includes: the content of the request parameters of the network request is an expression that can be controlled by the user.

[0085] Optionally, the purifier includes one of the following attributes: function return value, function parameters;

[0086] The value of the function return value attribute includes: the name of the cleanup function;

[0087] The function parameter attributes include the following sub-attributes: the cleanup function name, the input parameter number of the cleanup function, and the input parameter corresponding to the input parameter number is the cleanup object.

[0088] Optionally, the risk point includes one of the following attributes: function return value, function parameters;

[0089] The value of the function return value attribute includes: the name of the risk function;

[0090] The function parameter attributes include sub-attributes: the name of the risk function, the input parameter number of the risk function, and the input parameter corresponding to the input parameter number involves sensitive operations.

[0091] Optionally, the code vulnerability rule may also include at least one of the following rule items: vulnerability type, rule description.

[0092] This application also provides a code vulnerability detection method, including:

[0093] The source code is checked to see if it contains risk sources listed in the code vulnerability rules; the code vulnerability rules also include purifiers and risk points.

[0094] If the risk source is detected, then check whether the source code includes the purifier targeting the risk source;

[0095] If no purifier is detected targeting the risk source, then the source code is checked to see if it includes the risk point related to the risk source.

[0096] If a risk point related to the risk source is detected, the propagation path from the risk source to the risk point is obtained.

[0097] This application also provides a method for configuring code vulnerability rules, including:

[0098] Identify the source code, cleanup functions, and risk functions for the risks.

[0099] Based on the risky source code, the cleanup function, and the risk function, code vulnerability rules written in a domain-specific language are generated. These rules are used to detect whether the source code contains the risky source code. If the risky source code is detected, the source code is checked to see if it contains the cleanup function targeting the risk source. If the cleanup function targeting the risk source is not detected, the source code is checked to see if it contains the risk function related to the risk source. If the risk function related to the risk source is detected, the propagation path from the risky source code to the risk function is obtained.

[0100] This application also provides a method for obtaining static single assignment (SSA) code, comprising: executing a program compilation command to compile an application, wherein the source code of the program compilation command includes compilation code and dependency analysis code, such that the source code file is compiled by the compilation code, and the package dependency information of the application is obtained by the dependency analysis code; generating an abstract syntax tree (AST) of the source code file based on the package dependency information; and generating SSA code based on the AST.

[0101] This application also provides a code vulnerability detection device, including:

[0102] The source code acquisition unit is used to acquire multiple source code files of the application;

[0103] The detection rule acquisition unit is used to acquire code vulnerability rules;

[0104] Abstract syntax tree generation unit, used to generate the abstract syntax tree of the source code file;

[0105] The function call relationship acquisition unit is used to acquire function call relationships;

[0106] The path tracing unit is used to traverse the abstract syntax tree and obtain the risk propagation path across functions based on the function call relationship and the code vulnerability rules.

[0107] This application provides an electronic device, including:

[0108] Processor; and

[0109] A memory for storing a program for implementing the method described in any of the preceding methods, wherein the device is powered on and the program of the method is executed by the processor.

[0110] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the various methods described above.

[0111] This application also provides a computer program product including instructions that, when run on a computer, cause the computer to perform the various methods described above.

[0112] Compared with the prior art, this application has the following advantages:

[0113] The code vulnerability detection method provided in this application obtains multiple source code files and code vulnerability rules of an application; generates an abstract syntax tree (AST) of the source code files and obtains function call relationships; traverses the AST and obtains cross-function risk propagation paths based on the function call relationships and the code vulnerability rules. This approach integrates function call relationships with the AST for cross-function code vulnerability detection, achieving context-sensitive, flow-sensitive, and domain-sensitive cross-function vulnerability detection, avoiding false positives and false negatives; therefore, it can effectively improve the accuracy and recall rate of vulnerability detection.

[0114] The code vulnerability detection method provided in this application detects whether the source code includes a risk source from a code vulnerability rule. The code vulnerability rule also includes a purifier and a risk point. If the risk source is detected, the source code is checked to see if it includes a purifier targeting that risk source. If no purifier is detected, the source code is checked to see if it includes a risk point related to the risk source. If a risk point related to the risk source is detected, the propagation path from the risk source to the risk point is obtained. This approach, using DSL (Digital Subsystem for Detection) code vulnerability rules, adheres to the principle that rules are code, making the rule code closer to natural language. This better represents the state of vulnerability analysis, enhances code readability and maintainability, and significantly reduces the learning cost. Furthermore, since DSL code vulnerability rules do not contain complex query statements (such as query scripts), the scalability of the detection rules is enhanced. Users can extend the detection rules for specific application scenarios or new vulnerability patterns, enabling the detection of vulnerabilities in complex applications and adapting to dynamically changing threat scenarios.

[0115] The code vulnerability rule configuration method provided in this application determines the risky source code, the cleanup function, and the risk function; based on the risky source code, the cleanup function, and the risk function, it generates code vulnerability rules written in a domain-specific language to detect whether the source code includes the risky source code; if the risky source code is detected, it detects whether the source code includes the cleanup function targeting the risk source; if the cleanup function targeting the risk source is not detected, it detects whether the source code includes the risk function related to the risk source; if the risk function related to the risk source is detected, it obtains the propagation path from the risky source code to the risk function. This approach, using DSL (Domain-Specific Language) code vulnerability rules, adheres to the principle that rules are code, making the rule code closer to natural language, better representing the state of vulnerability analysis, enhancing code readability and maintainability, and minimizing learning costs. Furthermore, since DSL code vulnerability rules do not contain complex query statements (such as query scripts), the scalability of the detection rules is enhanced. Users can extend the detection rules for specific application scenarios or new vulnerability patterns, enabling the detection of vulnerabilities in complex applications and adapting to dynamically changing threat scenarios.

[0116] The static single assignment SSA code acquisition method provided in this application embodiment compiles an application by executing a program compilation command. The source code of the program compilation command includes compilation code and dependency analysis code. The compilation code compiles the source code file, and the dependency analysis code obtains the application's package dependency information. Based on the package dependency information, an abstract syntax tree (SSA) is generated from the source code file. Based on the SSA, SSA code is generated. This processing method enables the acquisition of the application's SSA code after compilation, thus effectively improving the performance of SSA code acquisition. Attached Figure Description

[0117] Figure 1 A flowchart illustrating an embodiment of the code vulnerability detection method provided in this application;

[0118] Figure 2 A schematic diagram of a cross-function tracing tree of an embodiment of the code vulnerability detection method provided in this application;

[0119] Figure 3 Another cross-function tracing tree diagram of an embodiment of the code vulnerability detection method provided in this application. Detailed Implementation

[0120] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0121] This application provides a code vulnerability detection method and apparatus, a code vulnerability rule configuration method and apparatus, a static single-assignment SSA code acquisition method and apparatus, and an electronic device. The various solutions are described in detail below in each embodiment.

[0122] First Embodiment

[0123] Please refer to Figure 1 This is a flowchart of the code vulnerability detection method of this application. In this embodiment, the method may include the following steps:

[0124] Step S101: Obtain multiple source code files and code vulnerability rules for the application.

[0125] The method provided in this application embodiment is used to detect security vulnerabilities in the source code of an application. It detects security vulnerabilities by marking untrusted data (risk sources / contamination sources) and tracing their propagation path to sensitive operations (risk points).

[0126] The application can be any application that needs to be tested for code vulnerabilities, including but not limited to: web applications (such as e-commerce shopping applications, chat tools, email clients, etc.), application software (such as office software, educational software, entertainment software, etc.), utility software (such as text editors, image processing, system maintenance, etc.), operating systems, etc.

[0127] From the perspective of analysis type, this method uses static analysis to detect vulnerabilities in the source code. It does not require executing the program itself, but rather examines and analyzes the program's source code.

[0128] From the perspective of execution timing, this method can be used to perform daily inspections of running applications, program release checks on applications to be run, and self-service checks on applications at any time, in order to support application code quality and security compliance goals.

[0129] From the perspective of the implementing entity, developers can perform code vulnerability detection on the source code of their applications by using code vulnerability detection plugins installed in their application development tools or by executing code vulnerability detection scripts via command line. Code detection providers can obtain the application's source code from the developer and perform code vulnerability detection on the source code using code detection equipment.

[0130] An application typically consists of multiple source code files, which are linked together by packages and class references to form a complete program. Each source code file contains one or more functions (methods), and functions within the same file can call each other, as can functions in different files.

[0131] Source code is the program code written by developers for an application. The method provided in this application supports source code in multiple programming languages. The programming languages ​​used to write the source code include, but are not limited to, statically typed, compiled languages, and can also be other object-oriented programming languages. Go (also known as Golang) is a typical statically typed, compiled language. In practical applications, statically typed, compiled languages ​​include, but are not limited to, Go; any statically typed, compiled language is acceptable. Other object-oriented programming languages ​​include C / C++, Objective-C, Java, and C#.

[0132] In recent years, statically typed, compiled languages ​​(such as Go) have been widely used in building web applications due to their efficiency, conciseness, and concurrency capabilities. After developing a web application written in such a language, security testing tools can be used to discover security risks in the source code, protecting the web application from various cyberattacks and ensuring user data security and the normal operation of the system.

[0133] Code vulnerability rules are the rules followed in vulnerability detection. In practice, mature rule forms in existing technologies can be adopted, such as rules based on query language (QL) or rule base extensions.

[0134] In the process of realizing this invention, the inventors also discovered that the rules in existing pre-built rule bases are fixed and lack the ability to customize detection for certain scenarios (such as e-commerce scenarios, map scenarios, etc.), requiring additional investment in rule adaptation. Furthermore, existing query-based rule writing is difficult, the documentation is complex, and it requires dedicated personnel for specialized analysis and customization, resulting in high costs for rule expansion.

[0135] In one example, the code vulnerability rules are written in a domain-specific language (DSL), where DSL is a computer language focused on code vulnerability detection. Code vulnerability rules written in DSL can include the following rule items: risk source, purifier, and risk point. Each rule item can define one or more attribute names, and attribute values ​​can be program code. Attribute names and values ​​are connected by operators, including but not limited to: assignment operators (such as =), list append operators (such as +=). The rule writing process resembles a script file. In addition, DSL code vulnerability rules can also include the following optional rule items: vulnerability type, vulnerability subtype, and rule description. Using DSL to organize code vulnerability rules adheres to the principle of "rule-as-code," making the rule code closer to natural language. This allows for better representation of the vulnerability analysis status, enhances code readability and maintainability, and has a very low learning curve. Furthermore, since the DSL organization code vulnerability rules do not include complex query statements (such as query statement scripts), the scalability of the detection rules is enhanced. Users can extend the detection rules for specific application scenarios or new vulnerability patterns, and can detect vulnerabilities in complex applications, adapting to dynamically changing threat scenarios.

[0136] When using DSL code vulnerability rules to perform vulnerability detection on source code, the DSL code vulnerability rules can be parsed into a programming language structure, or the various contents of the rules can be used directly. The process of code vulnerability detection based on DSL rules includes: detecting whether the source code contains a risk source; if a risk source is detected, detecting whether the source code contains a purifier targeting that risk source; if no purifier is detected, detecting whether the source code contains a risk point related to that risk source; if a risk point is detected, obtaining the propagation path from the risk source to the risk point, which is considered a vulnerability; if no risk point is detected or a purifier is detected, it means that the risk source will not flow into the risk point and will not cause a vulnerability.

[0137] The aforementioned rule item "Risk Source" defines the starting point for risk propagation. A risk source can be user-controlled input, command-line arguments, database data import, file content import, etc. User-controlled input can be content entered by the user on a webpage, such as the order number entered by the user on an order query page. The "Risk Source" rule item can identify user-controlled input in the source code. For example, in an e-commerce scenario, the attribute `source.functionReturn += "internal / user.GetPhoneNumber"` in the "Risk Source" rule item defines a pollution source specific to the web application, enabling rapid vertical rule development. User-controlled input in the source code can take many forms; two common forms are listed below:

[0138] A type of user-controllable input is contained in the request body of a network request. The URL parameters are obtained using a GET request. The source code for obtaining the user-controllable input is the code that retrieves the user-controllable input from the request body. For example, the user-controllable input can be retrieved from the request body using a GET function. In this case, the source of risk is the function return value.

[0139] Another type of user-controlled input is contained in the request parameters of a network request. Data in a form is submitted via a POST request, and the source code of the user-controlled input is obtained from the request parameters in the network request. In this case, the risk source is in the form of an expression.

[0140] In one example, the rule name for the rule item "Risk Source" can be represented by the keyword "source". Taking retrieving user-controlled input from the request body as an example, since the risk source is a function return value, the "Risk Source" rule item can have an attribute "Function Return Value", which can be represented by "FunctionReturn". Taking retrieving user-controlled input from request parameters as another example, since the risk source is an expression, the "Risk Source" rule item can have an attribute "Expression", which can be represented by "expression". Because risk sources can come from multiple sources, the operator can be a list append operator, allowing the "Function Return Value" attribute to include multiple function return values ​​and the "Expression" attribute to include multiple expressions. The list append operator can be represented by "+=".

[0141] For example, the "Risk Source" rule item in a rule written using DSL includes the following code:

[0142] source.functionReturn+="net / url\.Values\.Get";

[0143] source.expression+="net / http\.Request\.(Body|URL|PostForm|Form)";

[0144] `source.functionReturn +="io.read";` [This reads the contents of a file, such as reading an order-related configuration file.]

[0145] In the first line of rule code above, `source` is the keyword for the rule item "risk source," and `functionReturn` is the keyword for the attribute "function return value." The value of this attribute includes "net / url\.Values\.Get." This attribute value uses a regular expression based on the type information of the code elements, which can quickly match any part of the source code that retrieves the return value of a user-controllable input `get` function from the request body. A regular expression is a tool used to describe string patterns; in this embodiment, it is applied to match function return values. For example, for function calls like `r.URL.Query().Get("UserId")` or `r.URL.Query().Get("OrderId")` (where `UserId` represents the user identifier and `OrderId` represents the order identifier), by analyzing the type of the source code elements (i.e., the fully qualified path name of the source code element), the fully qualified path name of `xxx.Get` (such as `r.URL.Query()`) can be obtained as `net / url.Values.Get`. The first line of rule code above uses the function return value as the risk source, i.e., how to identify risk sources originating from the network request body.

[0146] In the second line of code above, `expression` is the keyword for the attribute "expression". The value of this attribute includes "net / http\.Request\.(Body|URL|PostForm|Form)". This attribute value is a regular expression that can match any expression in the source code that retrieves user-controllable input values ​​from request parameters. For example, for an expression like `r.Form["name"]` in the source code, type analysis can reveal that the full path of `xxx.Form` (such as `r.Form[]`) is `net / http.Request.Form`. The second line of code uses the expression as a risk source, i.e., how to identify risk sources from network request parameters.

[0147] It should be noted that the various keywords mentioned above can also be represented by other strings. For example, the rule name for the rule item "risk source" can be represented by the keyword "src". This application does not restrict the symbols used for keywords. Risk sources that exist in the form of function return values ​​or expressions can be not only user-controlled inputs, but also command-line parameters, database data reads, file content reads, etc.

[0148] In the aforementioned rule items, the purifier is a device that purifies the risk source, also known as a purification function. The purifier defines the situation where risk propagation is prematurely interrupted, i.e., the purification process during risk propagation. Purification functions can be Atoi (converting Accuicode to an integer), ParseInt (converting a string to an integer), etc. In practice, the rule item name for "purifier" can be represented by the keyword `sanitizer`. The purification function appears in the source code as a function return value; the "function return value" attribute can be set for the "purifier" rule item, and this attribute can be represented by `FunctionReturn`.

[0149] For example, the code for the "purifier" rule item in a rule written using DSL is:

[0150] sanitizer.functionReturn+="strconv\.ParseInt|strconv\\.Atoi|strconv\\.Parse Float|strconv.ParseBool";

[0151] In this line of rule code, `sanitizer` is the keyword for the rule item "sanitizer," and `functionReturn` is the keyword for the attribute "function return value," indicating that a function is used as the sanitizer. The attribute value is "strconv\\.ParseInt|strconv\.Atoi|strconv\\.ParseFloat|strconv.ParseBool." This attribute value is a regular expression that can include multiple sanitizer functions, such as `ParseInt`, `Atoi`, `ParseFloat`, and `ParseBool`. This allows matching any instance of a `ParseInt`, `Atoi`, `ParseFloat`, or `ParseBool` function in the source code. For example, matching a function with its fully qualified package path, such as `strconv.Atoi(id)`, indicates that this line of rule code uses a function as the sanitizer, i.e., how to determine whether a user-controlled input has been neutralized.

[0152] In practice, if the purification function has multiple input parameters, one of which is the purification object, then the "function parameter" attribute can be set for the rule item of the "purifier". The "function parameter" attribute can be represented by FunctionArg.

[0153] For example, the code for the "purifier" rule item in a rule written using DSL is:

[0154]

[0155] In the above rule code line, `functionArg` is the keyword for the attribute "function parameter", indicating that the function parameter is used as the purifier. `paramIndex`, as a sub-attribute, represents the index of the function parameter, i.e., which parameter in the purifier function is the purifier object. `paramIndex = 1` means the first parameter of the purifier function is the purifier object. If the source code outputs a purifier function whose first parameter is a risk source or data affected by a risk source, it means that the risk source has been purified. If the source code outputs a purifier function but does not pass the risk source or data affected by the risk source as its first parameter, it means that the risk source has not been purified. `pattern`, as a sub-attribute, includes a list of regular expressions containing the purifier function name.

[0156] In the above rule items, the risk point defines the endpoint of risk propagation, also known as the risk function. The risk function includes sensitive operations, including but not limited to database operations such as database queries and writes. In implementation, the rule item name for "risk point" can be represented by the keyword `sink`. The risk function appears as a function in the source code, and the rule item for "risk point" can have a "function parameter" attribute set, which can be represented by `FunctionArg`. For example, `sink.functionArg` defines that if a parameter of the risk function is contaminated, a risk point will be returned if a corresponding regular expression is matched. It is a composite structure, where `paramIndex` represents the case where the x-th parameter is contaminated, and `pattern` is a list of regular expressions.

[0157] For example, the code for the "Risk Point" rule item in a rule file written using DSL is as follows:

[0158]

[0159] In this line of rule code, `sink` is the keyword for the rule item "risk point," and `functionArg` is the keyword for the attribute "function parameter" of the rule item "risk point," indicating that the function parameter is used as the risk point. This attribute is a structure containing two fields: risk function and input parameter number. The input parameter number refers to the input parameter number of the risk function, which is "database / sql\\.DB\\.Query|github\\.com / jmoiron / sqlx\\.DB\\.Select." This attribute value is a regular expression that can match any database query function (such as Query or Select) in the source code. For example, it matches a function with its full package path, such as `DB.query(userInput)`. In this example, if the 0th parameter of the risk function is assigned a user-controllable variable (i.e., the risk source), a vulnerability is reported. This line of rule code uses the function parameter as the variable for the risk point; that is, how to determine if an unprocessed, user-controllable input will lead to the risk point and execute an unexpected operation.

[0160] For example, the code for the "Risk Point" rule item in a rule file written using DSL is as follows:

[0161] sink.functionReturn+="database / sql\\.DB\\.Query|github\\.com / jmoiron / sqlx\\.DB\\.Select";

[0162] In this rule code, `functionReturn` is the keyword for the attribute "function return value," indicating that a function is considered a risk point. The attribute value is "database / sql\\.DB\\.Query|github\\.com / jmoiron / sqlx\\.DB\\.Select." This attribute value is a regular expression that can include multiple risk functions, such as the Query function and the Select function, thus matching any instance of the Query or Select function in the source code.

[0163] Below is a complete example of a rule:

[0164]

[0165] In this DSL rule example, `SqlInjection` is the rule name, representing a rule for Structured Query Language (SCL) SQL injection vulnerabilities; `type` is the vulnerability type, such as SQL injection class, etc. `source` is the source of risk, `source.functionReturn` is the function return value property of `source`, and `source.expression` is the expression property of `source`. `sanitizer` is the sanitizer, `sanitizer.functionArg` is the function parameter property of `sanitizer`, and `paramIndex` is the index of the input parameter of the sanitizer function. `paramIndex` represents the case where the x-th parameter is contaminated. In the rule code above, `paramIndex = 1` means that if the first parameter of the sanitizer function is a user-controllable variable (i.e., the source of risk), then the source of risk is sanitized; if the first parameter of the sanitizer function is not a user-controllable variable, then the source of risk is not sanitized. `patter` is the list of regular expressions for the sanitizer function. The sink is the risk point, sink.functionArg is the function parameter attribute of the sink, and paramIndex is the index of the input parameter of the risk function. If the 0th parameter of the risk function is a user-controllable variable (i.e., the risk source), a vulnerability is reported. If the 0th parameter of the risk function is not a user-controllable variable, no vulnerability is reported.

[0166] In one example, the method provided in this application embodiment may further include the following step: validating the rule format of the code vulnerability rule. After writing the rule, the user can call the rule verification device to verify whether the rule format is correct. The verification result includes error message information and repair suggestion information. The user can debug the rule according to the verification result until the rule conforms to the prescribed format. Using this processing method, DSL code vulnerability rules that meet the format requirements can be written quickly; therefore, it can effectively improve the user experience.

[0167] Step S103: Generate the abstract syntax tree of the source code file and obtain the function call relationship.

[0168] To perform cross-function taint analysis on source code, a clear understanding of the code structure and call relationships is crucial. The method provided in this application understands the code structure through the abstract syntax tree (AST) of the source code file. When a function call is encountered during traversal of the AST, the location of the called function is determined based on the function call relationship, and recursive analysis is performed to achieve cross-function taint analysis. Therefore, it is necessary to generate an AST based on the source code file and obtain the function call relationships.

[0169] An Abstract Syntax Tree (AST) is a tree-like representation of the abstract syntactic structure of source code. It represents the syntactic structure of the source code in a tree-like format, where each node represents a syntactic unit in the source code, such as an expression, statement, or declaration. Nodes can contain other nodes as child nodes. For example, an expression node may contain multiple child nodes, each representing a part of the expression (such as operands or operators). Edges in the AST represent parent-child relationships, i.e., how a node connects to its parent node. The root node is the topmost node of the entire AST, typically representing the entire source code file. An application project usually consists of multiple source code files, and a corresponding AST is generated for each source file. By accessing the root node of the AST and traversing the AST to access specific nodes and child nodes, the syntactic structure of the source code can be parsed, allowing for an understanding of the code's structure and logic.

[0170] In practice, a parser can be used to generate the Abstract Syntax Tree (AST) corresponding to the source code file. Taking Go as an example, the step of generating the AST corresponding to the source code file can be implemented as follows: use the go / ast package in Go's standard library to extract the AST from the source code.

[0171] An application project typically consists of multiple packages, each containing one or more source code files. Packages are structures used to organize and manage related classes or interfaces; they are defined by their package names. Placing classes or interfaces in different packages allows for better code organization, avoids naming conflicts, and improves code maintainability. In one example, generating the abstract syntax tree (AST) of the source code files can be achieved by generating the AST in parallel at the package level. For instance, using the G programming language, Go can be used to generate the AST in parallel at the package level. This approach effectively improves AST generation efficiency, thereby enhancing code vulnerability detection efficiency.

[0172] An application's source code includes multiple functions (methods). Functions within the same source file can call each other, known as intra-file function calls; functions in different source files can also call each other, known as cross-file function calls (inter-file function calls) or cross-module function calls. This application implements cross-function code vulnerability detection based on function call relationships. Function call relationships can include intra-file function calls and inter-file function calls. Inter-file function calls can include inter-file function calls within the same package and inter-file function calls across packages (cross-package function calls). In practice, function call relationships can be stored in a local cache or a global cache to improve the speed of querying function call relationships, thereby improving the speed of vulnerability detection.

[0173] In one example, obtaining function call relationships can be achieved by generating function call relationships based on source code. For instance, using the `go-callvis` tool, you can specify the Go file or package to analyze via command-line arguments to generate function and package call relationships within a Go project.

[0174] In another example, obtaining function call relationships may include the following sub-steps:

[0175] Step S201: Obtain the static single assignment (SSA) code of the application.

[0176] In practical applications, when functions from different source files call each other, especially cross-package function calls, it may be impossible to obtain the fully qualified name of code elements (such as functions and variables) based on the source code. That is, the fully qualified name of the function with its package cannot be obtained. This makes it difficult to accurately determine the location of code elements, thus hindering the accurate determination of accurate function call relationships. The fully qualified name with package (full path name) consists of the package name, class name, and code element name. The type information of the code element (with package path) consists of the package name and class name. The package path is used to locate code elements within a package and class combination.

[0177] To obtain highly accurate function call relationships, the method provided in this application utilizes the static single-assignment (SSA) code of the application. The SSA code is intermediate code obtained by compiling the application's source code and complete package dependencies; each variable is assigned a value only once, facilitating program analysis.

[0178] Step S203: Obtain the function call relationship based on the SSA code.

[0179] In one example, the step of obtaining the function call relationship based on the SSA code can be implemented as follows: using a call chain analyzer, an SSA-form call chain is generated based on the SSA code, which can reflect the function call relationship.

[0180] Taking Go as an example, a call chain analyzer could be Gocyto, a static single-assignment call graph specifically designed to construct and visualize Go programs. An SSA function call graph is a directed graph representation of function (method) call relationships in SSA code, where nodes represent SSA functions and edges represent call relationships. Call graphs support cross-function data flow analysis, and this application uses call graphs to trace risk propagation paths across functions. With Gocyto, the structure of Go programs can be explored and understood more intuitively, especially the complex call relationships between packages and functions. From packages to types, and then to global variables and their associated functions, Gocyto's graph data is clearly hierarchical and easy to understand.

[0181] In another example, Rapid Type Analysis (RTA) can be used to generate function call graphs based on SSA code. This method infers possible function call targets by using the type information of code elements, which can better balance analysis accuracy and efficiency.

[0182] The method provided in this application obtains function call relationships through steps S201 to S203. This processing method enables the acquisition of type information of code elements based on SSA code, thus effectively improving the accuracy of function call relationships.

[0183] An application project typically comprises multiple packages, each containing one or more source code files. In one example, step S203 can be implemented as follows: at the package level, function call relationships are obtained in parallel based on the SSA code. For example, using the Go programming language, GoCrunch can be used to obtain function call relationships in parallel based on the SSA code at the package level. This approach can effectively improve the efficiency of function call relationship generation, thereby improving code vulnerability detection efficiency.

[0184] In one example, the method provided in this application embodiment may further include the following steps: determining the type information of the abstract syntax tree node based on the SSA code; traversing the abstract syntax tree and obtaining the risk propagation path across functions based on the type information, the function call relationship, and the code vulnerability rules. The type information may consist of package name and class name. This processing method enables the tracking of risk propagation paths based on the type information of code elements, thus effectively improving the accuracy of code vulnerability detection.

[0185] In one example, the method provided in this application embodiment may further include the following steps: storing Abstract Syntax Tree (AST) data and SSA code data in memory, and storing frequently used query information in a cache. The type information of AST nodes is parsed from the SSA code. Frequently used query information (relationships between frequently queried AST nodes) includes, but is not limited to: function call relationships, structure / interface inheritance relationships, and application framework identification information (including application entry points, routing graphs, etc.). Essentially, these caches store some special AST nodes. Such caches can be managed using LRU (Least Recently Used) to reduce the number of repeated memory queries. This global caching mechanism reduces pointer reference overhead; removes dependencies on external data sources; and, combined with the memory management characteristics of programming languages, achieves a smaller memory footprint (e.g., 8GB). This reduces resource consumption, enabling lightweight code vulnerability detection. Therefore, it effectively reduces detection costs and improves detection efficiency, effectively balancing high efficiency and high precision / recall. Taking Go-language web applications as an example, for Go web application projects with less than 100,000 lines of code, code vulnerability detection can be completed within 20 minutes and with less than 8GB of memory usage, meeting the requirements of Go web applications for lightweight, high accuracy, and fast response. Since each application consumes fewer resources for code vulnerability detection and supports parallel vulnerability detection across multiple applications, it can meet the needs of rapid vulnerability detection for large-scale, highly complex codebases.

[0186] In one example, step S201 above, namely obtaining the static single assignment (SSA) code of the application, can be implemented as follows: by compiling the application, the SSA code generated during the compilation process is obtained. This approach can effectively improve the efficiency of SSA code acquisition.

[0187] In another example, step S201 above, namely obtaining the static single assignment (SSA) code of the application, can be implemented as follows: Execute a program compilation command to compile the application. The source code of the program compilation command includes compilation code and dependency analysis code, such that the source code file is compiled using the compilation code, and the package dependency information of the application is obtained using the dependency analysis code; an abstract syntax tree (AST) of the source code file is generated based on the package dependency information; and SSA code is generated based on the AST. In the prior art, some programming language program compilation commands generate SSA code during the compilation process, and automatically delete the SSA code after compilation. To obtain the application's SSA code, dependency analysis code can be added to the source code of the program compilation command to obtain the application's package dependency information. After obtaining the package dependency information, an AST of the source code file can be generated based on the package dependency information; and SSA code is generated based on the AST. This approach ensures that the application's SSA code can still be obtained even when the compilation command automatically deletes the SSA code.

[0188] In one example, obtaining the static single assignment (SSA) code of the application may include the following steps: setting environment variables corresponding to the package dependency information; generating the abstract syntax tree (AST) of the source code file based on the package dependency information can be implemented as follows: using the environment variables as input information to an AST generation tool, and generating the AST using the AST generation tool. This approach modifies existing AST generation tools by changing their input information to environment variables corresponding to the package dependency information. This allows for the simultaneous generation of the AST and the acquisition of type information for code elements, enabling the generation of SSA code based on this AST; therefore, it effectively improves the efficiency of SSA code acquisition.

[0189] Taking a Go application as an example, an environment variable (such as DRIVER_INPUT_FILE) is set to represent the result of dependency analysis during the program compilation process. The program compilation command is `go build`, and the source file corresponding to this command can be `build.go`. This file includes a compilation function (`run Build`), which contains compilation code used to compile the application. A dependency analysis function (such as `hook RunList`) is added to the `build.go` file. This function contains dependency analysis code used to obtain the application's package dependency information and store it in the file corresponding to the environment variable. In practice, the dependency analysis function can be added at the end of the compilation function (i.e., after all dependencies are installed and the application has been compiled). The dependency analysis code includes the `go list` command. In the compilation information, the dependency-related information comes from the `go list` command, which is a native Go command used to obtain all dependencies in the application project and can run independently. Calling the function corresponding to the `go list` command can obtain complete dependency information and import the results into the file corresponding to the environment variable `DRIVER_INPUT_FILE`. Next, run the abstract syntax tree (AST) generator (e.g., golang.org / x / tools / go / packages). Replace the output of the `go list` command as input to this generator with the environment variable `DRIVER_INPUT_FILE`. This ensures that the generator's input depends on the complete installation and compilation of the `golist` process, rather than the output of running `go list` independently. To achieve this, the AST generator needs to be modified to change the way its input parameters are obtained. After obtaining the AST, run the SSA code generator (e.g., golang.org / x / tools / go / ssa) to parse the AST into SSA code.

[0190] Applications are developed as projects, which typically include not only source code but also package dependencies. Package dependencies refer to the fact that an application project may depend on another application project or library to complete its functionality. For example, a web application may depend on multiple libraries to handle HTTP requests, render templates, perform database operations, etc. Compiling an application requires first introducing these dependencies into the project so that the relevant functions can be called in the code. However, in practical applications, code vulnerability detection agencies may not be able to obtain some of the application project's dependency packages. In the absence of project dependency packages, in order to construct complete and accurate code element type information through program compilation, the method provided in this application embodiment may further include the following steps: constructing the application project's dependencies. Only after constructing the project dependencies can the application project be compiled, and complete type information and SSA information can be obtained through program compilation.

[0191] Taking Go as an example, application project dependencies are automatically organized using two modes: go.mod and GOPATH. The go.mod mode is the officially promoted mode since 2020, while the GOPATH mode was the preferred mode in earlier Go versions (<1.18). In one example, building application project dependencies might include the following steps:

[0192] Step S301: Scan the root directory (main folder) of the application project. If the root directory contains a go.mod file, generate a third-party directory (vendor directory) in the root directory of the project through the go.mod file, and store the third-party packages that the project depends on in the third-party directory.

[0193] The `go.mod` file marks the application project's dependencies and their versions, and is placed in the application project's root directory. In practice, you can execute `go mod tidy` and `go mod vendor` to create a third-party directory in the root directory, where you will store the third-party packages that the project depends on.

[0194] Step S302: If the root directory includes src, pkg, and bin folders, then set the root directory as GOPATH. Under this setting, Go Modules need to be disabled. Specifically, this can be achieved by setting the environment variable GO11MODULE=off.

[0195] This approach enables automatic adaptation to both go.mod and GOPATH modes, achieving automated multi-mode dynamic dependency installation. Because it can automatically install project dependencies, it can compile the application project without requiring the complete source code. The compilation process obtains complete type information and SSA information, thus achieving weak code integrity. When compiling the application project (e.g., using go build ld), it first searches for dependencies in third-party directories; if not found, it then searches in the GOPATH directory.

[0196] In one example, the method provided in this application embodiment may further include the following steps: splitting the application into multiple subroutines; and building project dependencies for the subroutines. For example, for a codebase containing several microservice modules, analyze it independently according to service boundaries to avoid dependency conflicts.

[0197] In practical applications, application projects may include custom dependency installation processes and dependency installation folders. For example, some applications may build a temporary directory and use it as the GOPATH; dependency packages may be stored in a private repository and cannot be provided to code vulnerability detection parties; or the application's native code may be incomplete and rely on the `gogenerate` directive. For these types of applications, it is impossible to automate the construction of project dependencies.

[0198] In one example, step S201 above, namely obtaining the static single assignment (SSA) code of the application, can be implemented as follows: Obtain the program compilation script, which includes dependency package installation information and the program compilation command; run the program compilation script to install dependencies according to the dependency package installation information. The dependency package installation information can be provided by the developer. The program compilation script can obtain project dependency information based on the dependency package installation information and can install dependencies according to the custom dependency package installation information provided by the developer. For example, for projects that depend on private repository code, the GOPATH environment variable can be dynamically set through a user build script to successfully obtain compilation information and intermediate information. This custom dependency installation method enables the construction of project dependencies for applications that include custom installation processes and installation folders, thereby achieving weak code integrity dependencies.

[0199] In practice, the program compilation script can be named `build.sh`. Furthermore, the program compilation script can include a code completion segment. By executing this segment, missing code can be automatically generated for applications with incomplete native code, thus successfully obtaining compilation information and obtaining SSA code. Taking the G language as an example, the code completion segment can use the `gogenerate` command to complete incomplete native application code. During custom dependency installation, dependencies can also be installed for the automatically generated code.

[0200] In one example, the method provided in this application embodiment may further include the following steps: splitting the application into multiple subroutines; the dependency package installation information includes the dependency package installation information of the subroutines; the step of installing dependency packages according to the dependency package installation information includes: installing dependency packages according to the dependency package installation information of the subroutines. This approach can effectively avoid dependency conflicts.

[0201] Step S105: Traverse the abstract syntax tree and obtain the risk propagation path across functions based on the function call relationship and the code vulnerability rules.

[0202] This step, based on code vulnerability rules and combined with the abstract syntax tree and function call relationships of the source code, checks whether the source code of various types of applications contains security vulnerabilities. Taking web applications as an example, the categories of security vulnerabilities that pose a threat to web applications include, but are not limited to: 1. Injection attacks (such as SQL injection, command injection, etc., where attackers manipulate the database or execute malicious commands by injecting malicious code into input fields); 2. Cross-site scripting attacks (XSS, which involve injecting malicious scripts into the target website to steal information or perform other malicious operations on the user's browser); 3. Authentication and session management vulnerabilities (which may lead to the theft of user identities or abuse of privileges); 4. Sensitive information leakage (which exposes important data such as passwords and credit card information).

[0203] The method provided in this application embodiment enables context-sensitive cross-function vulnerability detection. Code vulnerability detection begins at the code detection entry point (which can be the program entry point or any user-specified code location). Based on code vulnerability rules, the source code is analyzed in AST traversal order, proceeding downwards sequentially for vulnerability detection. During the detection process, if a function call is encountered, the function call target is determined according to the function call relationship. The source code (abstract syntax tree) of the called function is searched in the application project, and code vulnerability detection continues on the called function. If the called function is a white-box function whose source code can be found, vulnerability detection is transferred to the source code of the called function. After the called function detection is completed, the detection returns to the function call point to continue vulnerability detection. If the called function is a system built-in function (such as append, copy), the system built-in function can be modeled and specially processed, and propagation is performed according to function semantics. If the called function is a black-box function whose source code cannot be found, the black-box function is skipped, and vulnerability detection continues. If the parameters or objects of the black-box function are contaminated, the returned results will also be contaminated. In practice, depth-first search (DFS) can be used to traverse from the risk source to the risk point, thereby quickly finding the risk point and obtaining the tracking tree; or breadth-first search (BFS) can be used to traverse the AST.

[0204] Context sensitivity enables vulnerability detection to consider the function call context (such as parameter values ​​and call chains). The same function may exhibit different pollution propagation behaviors in different call scenarios. For example, in an order query scenario, parameter 1 of function A is affected by a risk source, and the call chain of function A is a path for the risk source to propagate; therefore, function A has the ability to propagate pollution. However, in an order generation scenario, parameter 1 of function A is not affected by a risk source, and the call chain of function A is not a path for the risk source to propagate; therefore, function A will not cause pollution propagation.

[0205] like Figure 2As shown, it displays the taint tracking tree generated after performing cross-function vulnerability analysis on the e-commerce order query code of the web application 'test'. This tracking tree includes a bottom-up propagation path from the source of the risk to the point of risk, and the propagation path includes the following propagation nodes:

[0206] Node 1: According to the code vulnerability rules, the risk source "r.URL.Query().Get("id")" is matched in the source file main.go. This risk source is the user-controllable input id (order number) obtained from the request body of the network request. It belongs to the function return value type of risk source. The risk source is in the getOrder function and is located on line 13 of the source file main.go.

[0207] Node 2: In the getOrder function, the return value of the Get function (user-controllable input id) is assigned to the variable orderID on line 13;

[0208] Node 3: The getOrder function calls the buildQuery function on line 14, passing the variable orderID as an input parameter to the buildQuery function; within the buildQuery function, the variable orderID is passed as an input parameter to the buildQuery function on line 19 (cross-function).

[0209] Node 4: On line 20, the buildQuery function returns a database query statement built based on orderID. Since the variable orderID is user-controllable, this query statement is also user-controllable.

[0210] Node 5: In the getOrder function, the return value of the buildQuery function (the SQL statement that the user can control) is assigned to the variable query on line 14, which shows that the variable query is also user-controllable;

[0211] Node 6: The getOrder function calls the executeQuery function on line 24, passing the user-controllable variable query as the second parameter of the executeQuery function (cross-function).

[0212] Node 7: In the executeQuery function, according to the code vulnerability rules, the risky function db.Query() is matched on line 25. The user-controllable variable query is used as the input parameter of the db.Query function. Since the harmless processing of the user-controllable input through the purifier was not detected before, a vulnerability was identified.

[0213] Among the nodes mentioned above, node 1 is a risk source, node 7 is a risk point, and nodes 2 to 6 are ordinary nodes.

[0214] In one example, step S105 further includes the following sub-steps: recording the correspondence between the entry state and the output state of the detected function; if the input parameter state of the function to be detected is the same as the recorded entry state of the function, then the corresponding output state is obtained according to the correspondence. Entry states include, but are not limited to: function input parameter pollution state, structure field pollution state. Output state includes, but is not limited to: function return value (return) pollution state, parameter reference pollution state, structure field pollution. This processing method allows recording the correspondence between multiple entry states and corresponding output states of the same function. When performing vulnerability detection on the same function again, the next entry state is matched with the recorded multiple entry states to obtain the output state corresponding to the matched entry state, and the output state is quickly returned. This eliminates the need to perform vulnerability detection on the function's internal code again, avoiding repeated analysis of the same function calls, thereby effectively improving vulnerability detection efficiency.

[0215] In one example, the method provided in this application embodiment may further include the following steps: merging risk propagation paths with the same risk points to form a code vulnerability report. Specifically, risk points can be extracted from each risk propagation path (tracking tree), and multiple risk propagation paths with the same risk points can be merged to generate a defect report. This approach organizes risk propagation paths by risk points, allowing code vulnerability detection personnel to intuitively view all propagation paths leading to a single risk point; therefore, it effectively improves the user experience.

[0216] The method provided in this application can also achieve field-sensitive cross-function vulnerability detection, thereby effectively reducing false positives and false negatives. Field-sensitivity refers to the ability to distinguish the pollution states of different data fields. For structure-type variables, the pollution propagation path of each member field can be tracked independently; for container types (such as Map / Dictionary), the data flow state of each key-value pair can be monitored separately. For example, in the User information structure, the system will track the pollution markers of the user.name and user.age fields separately. Even though these two fields belong to the same structure, their security states will not interfere with each other.

[0217] In one example, the source code includes structured variables, which may contain multiple fields, including a first field and a second field. The risk propagation path before the function call includes the first field. The called function includes sensitive operations related to the first field. The structured variable can be a struct or a container structure; a struct contains multiple fields, and a container structure contains multiple keys. This approach allows for differentiated analysis of struct fields and container keys through refined modeling, enabling domain-sensitive cross-function vulnerability detection and avoiding false negatives. Therefore, it can effectively reduce the false negative rate and improve vulnerability detection accuracy.

[0218] like Figure 3 As shown, this illustrates the taint tracking tree generated after performing cross-function vulnerability analysis on the e-commerce order query code of the web application 'test'. The tracking tree demonstrates domain-sensitive vulnerability detection, reducing false negatives. The tree includes a bottom-up taint propagation path from the source of the vulnerability to the point of vulnerability, containing the following propagation nodes:

[0219] Node 1: According to the code vulnerability rules, two risk sources were matched in the source file main.go: "r.URL.Query().Get("orderId")" and "r.URL.Query().Get("userId")". These two risk sources are the user-controlled input orderId (order number) and userId (user ID) obtained from the request body of the network request, respectively. Both belong to the function return value category and are located in the getOrder function, on lines 27 and 28 of the source file main.go. Since the subsequent match found that line 30 uses the purifier Atoi to neutralize userId, rather than matching the purifier to neutralize orderId, the tracing tree only includes the propagation path of orderId, and node 1 is located on line 27 of the source file.

[0220] Node 2: In the getOrder function, Get(“orderId”) is assigned to the variable orderId on line 27;

[0221] Node 3: In the getOrder function, the variable orderId (a user-controllable variable) is assigned to the field OrderId (a user-controllable variable) of the structure Order on line 36, and the variable userId (a user-uncontrollable variable) is assigned to the field UserId (a user-uncontrollable variable) of the structure Order on line 37. Node 3 is located on line 36 of the source file.

[0222] Node 4, the getOrder function assigns the structure Order to the variable order on line 34;

[0223] Node 5: On line 39, the getOrder function calls the buildQuery function, passing the structure variable order as the input parameter of the buildQuery function. On line 44, the input parameter of the buildQuery function is the structure variable order (cross-function).

[0224] Node 6, on line 45, the buildQuery function returns a database query statement built based on orderID, which calls the GetOrderId function of the structure variable order. On line 17, the GetOrderId function assigns the structure variable order to the variable o (which is user-controllable).

[0225] Node 7, line 18: The GetOrderId function returns the OrderId field (a user-controllable variable) of the structure variable o;

[0226] Node 8, line 45: The buildQuery function returns a database query statement (a user-controllable SQL statement) built based on the domain OrderId;

[0227] Node 9, on line 39, the getOrder function assigns the return value of the buildQuery function (the user-controllable SQL statement) to the variable query (a user-controllable variable);

[0228] Node 10, on line 40, the getOrder function calls the executeQuery function, passing the user-controllable variable query as the second parameter of the executeQuery function; on line 48, the executeQuery function passes the user-controllable variable query as the second parameter (across functions);

[0229] Node 11: In line 49, the executeQuery function matches the risky function db.Query() according to the code vulnerability rules. The user-controllable variable query is used as the input parameter of the db.Query function. Since the user-controllable query was not previously rendered harmless through the purifier, a vulnerability was identified.

[0230] In the above nodes, node 1 is a risk source, node 11 is a risk point, and nodes 2 through 10 are ordinary nodes. This example demonstrates that domain sensitivity can prevent false negatives.

[0231] In another example, the source code includes structured variables, which may include multiple fields, including a first field and a second field; the risk propagation path before the function call includes the first field; and the called function includes sensitive operations related to the second field. This approach enables domain-sensitive cross-function vulnerability detection, avoiding false positives and thus effectively reducing the false positive rate and improving vulnerability detection accuracy.

[0232] For example, when the source code contains structure variables (such as instances of the User type), a fine-grained domain-level data flow model is established. Suppose that before a function call occurs, the risk propagation path only involves the `name` field of the User structure, and the called function contains a sensitive operation on the `name` field (such as SQL concatenation). In this case, the detection device will accurately identify the vulnerability path. Conversely, if the risk only exists in the `age` field and the sensitive operation acts on the `name` field, the system can correctly exclude false positives. This domain-level pollution state tracking mechanism is also applicable to key-value pair analysis of container structures; for example, it can accurately distinguish the different pollution states of `map["username"]` and `map["password"]`.

[0233] By employing the method provided in this application, which tracks the data flow according to the AST traversal order and handles the pollution state during branching and merging, flow-sensitive vulnerability detection can be achieved. Flow-sensitive refers to the ability to consider the program execution order (such as the order of variable assignment) during vulnerability detection. For example, Figure 3 In the `getOrder` function, the variable `orderId` has a different pollution state before and after assignment. Before assignment, `orderId` is unpolluted. After assigning the risk source `Get("orderId")` to `orderId`, its pollution state becomes polluted. Analyzing the source code according to the order of AST traversal reveals that the order of AST traversal has flow sensitivity capabilities.

[0234] In one example, step S105 includes: for branch conditions in the source code, performing vulnerability detection on the code within the branch condition based on the risk propagation path before the branch; for branch merging in the source code, merging the risk propagation paths in multiple program branches according to the branch merging method. Data flow is tracked according to the AST traversal order, and the taint status during branching and merging is processed. For branch conditions in the source code, the current taint analysis environment is split before entering the branch, and during branch merging, the taint analysis environment in the branch is merged according to the merging condition. For example, if the branch condition is: if expression A is true, then function 1 is executed; otherwise, function 2 is executed; then the taint analysis environment before entering function 1 or 2 will be passed to function 1 or 2. If the branch merging method is the intersection of the return values ​​of functions 3, 4, and 5, then the taint analysis environment after branch merging includes the intersection of the taint analysis environments of functions 3, 4, and 5. This processing method enables flow-sensitive vulnerability detection.

[0235] In one example, the method provided in this application embodiment further includes the following steps: obtaining program entry points based on the source code; if multiple program entry points exist, the application is split into multiple subroutines, and code vulnerability detection is performed on the multiple subroutines in parallel. Taking Go language source code as an example, GoCross can be used to perform parallel code vulnerability detection on multiple subroutines. This approach can effectively improve the efficiency of cross-function vulnerability detection.

[0236] In one example, the method provided in this application further includes the following step: performing code vulnerability detection on multiple combinations of subroutines and code vulnerability rules in parallel. An application can be divided into multiple subroutines, and code vulnerability detection can be performed based on multiple code vulnerability rules. Combining subroutines with code vulnerability rules and performing code vulnerability detection on multiple combinations in parallel can further improve the efficiency of cross-function vulnerability detection.

[0237] In one example, step S105 can be implemented as follows: traverse the abstract syntax tree (AST) of the first source code file, and obtain the first propagation path of the risk source according to the code vulnerability rules; if the first propagation path includes cross-file function calls, determine the cross-file function based on the function call relationship; traverse the AST of the cross-file function to obtain the second propagation path of the risk source in the called function. An application project typically includes multiple source code files, each with its own AST. Functions in different source files can call each other, i.e., cross-file function calls. This application refers to the source file containing the caller function as the first source code file and the source file containing the callee function as the second source code file. Cross-file function vulnerability analysis is performed by analyzing the AST of each source file. This approach enables cross-file function vulnerability detection.

[0238] In one example, the method provided in this application embodiment may further include the following steps: obtaining the correspondence between AST functions and SSA functions; and determining the call location of the function called across files based on the function correspondence. An AST function refers to a function definition node (ast.FuncDef) in the AST, and an SSA function refers to a function object (ssa.Function) in the SSA representation. This approach allows, after tracing code vulnerabilities in the called function, to return to the function call location and continue tracing downwards. For example, function A in source file 1 includes the code x:=B(). After tracing code vulnerabilities in function B, the return value of function B can be automatically associated with the pollution state of variable x in function A.

[0239] In practice, the correspondence between AST functions and SSA functions can be obtained based on the source file to which the function belongs and the function name. In one example, the correspondence between AST functions and SSA functions is obtained based on the function identifier. In practice, the source code is decomposed into a series of tokens, and a bidirectional mapping relationship is established between AST functions and SSA functions based on the same identifier (Token), which can achieve information alignment at the function level.

[0240] In one example, a dictionary is used to store the indices of identifier tokens to function objects; based on these indices, the correspondence between the AST function and the SSA function is obtained. This approach makes the time complexity of the bidirectional association operation between the AST function and the SSA function constant (O(1)).

[0241] In one example, the method provided in this application further includes the following steps: obtaining the type of function input parameters affected by the risk source in the function call in the risk propagation path; if the type of the function input parameter is a type that does not have risk propagation capability, then the risk propagation path is considered an invalid propagation path. During vulnerability detection of source code, if an identified risk propagation path includes a function call, and the input parameter of the called function is user-controllable, but the type of the user-controllable function input parameter is a type that does not have risk propagation capability, then the risk propagation path is filtered out, and no vulnerability is generated. A type that does not have risk propagation capability is a parameter type that is harmless to the program, such as a format string. For example, for the `fmt.Sprintf` function, it is explicitly stated that the first parameter format string does not propagate pollution, while subsequent parameters propagate pollution. This processing method allows invalid risk propagation paths to be filtered out based on the type of the function input parameter, thus improving the accuracy of cross-function vulnerability detection.

[0242] In one example, obtaining the type of the function input parameter includes the following steps: obtaining the static single assignment (SSA) code of the application; obtaining the definition and usage chain of SSA variables based on the SSA code; obtaining the type of the SSA function input parameter based on the definition and usage chain using a binary search algorithm; obtaining the correspondence between the AST function input and the SSA function input; and obtaining the type of the AST function input parameter affected by the risk source based on the correspondence and the type of the SSA function input parameter. The SSA code can optimize the compilation process, and the definition and usage chain of variables can be generated efficiently based on the SSA code. This approach makes the time complexity of obtaining the function input parameter type O(logN), where N is the number of variables. This time complexity is far less than the complexity of finding the function input parameter type using a linear scan method, achieving efficient filtering of invalid paths; therefore, it can effectively improve the efficiency of cross-function vulnerability detection.

[0243] An application project typically consists of multiple packages, each containing one or more source code files. In one example, obtaining the type of a function's input parameter can be achieved by retrieving the function's input parameter type in parallel at the package level. For instance, using the G programming language, Go can be used to retrieve the function's input parameter type in parallel at the package level.

[0244] In one example, the method provided in this application embodiment may further include the following steps: determining the type information of the abstract syntax tree node based on the SSA code; step S105 can be implemented as follows: traversing the abstract syntax tree, and obtaining the risk propagation path across functions based on the type information, the function call relationship, and the code vulnerability rules. This approach allows for accurate determination of the AST node type information, thereby achieving more accurate risk propagation path tracking.

[0245] In one example, the code vulnerability rule adopts the aforementioned DSL rule; traversing the abstract syntax tree and obtaining the cross-function risk propagation path based on the type information, the function call relationship, and the code vulnerability rule includes: detecting whether the source code contains the risk source, purifier, and / or risk point from the code vulnerability rule based on the type information of the code element. For example, when using the code vulnerability rule written with the aforementioned DSL for detection, the type information of the code element can be matched with the type information of the regular expression in the rule item of the code vulnerability rule. If the match is successful, it indicates that a risk source, purifier, or risk point has been identified. For example, the type information of the get function in the source code can be matched with the type information in the value of the function return value attribute of the risk source, "get function in regular expression form". If the match is successful, it indicates that a risk source has been identified.

[0246] As can be seen from the above embodiments, the code vulnerability detection method provided in this application obtains multiple source code files and code vulnerability rules of an application; generates an abstract syntax tree (AST) of the source code files and obtains function call relationships; traverses the AST and obtains cross-function risk propagation paths based on the function call relationships and the code vulnerability rules. This approach integrates function call relationships with the AST for cross-function code vulnerability detection, achieving context-sensitive, flow-sensitive, and domain-sensitive cross-function vulnerability detection, avoiding false positives and false negatives; therefore, it can effectively improve the accuracy and recall rate of vulnerability detection.

[0247] Second Embodiment

[0248] In the above embodiments, a code vulnerability detection method is provided. Correspondingly, this application also provides a code vulnerability detection device. This device corresponds to the embodiments of the above method. Since the device embodiments are basically similar to the method embodiments, the description is relatively simple, and relevant parts can be referred to in the description of the method embodiments. The device embodiments described below are merely illustrative.

[0249] This application also provides a code vulnerability detection device, comprising: a source code acquisition unit for acquiring multiple source code files of an application; a detection rule acquisition unit for acquiring code vulnerability rules; an abstract syntax tree generation unit for generating an abstract syntax tree of the source code files; a function call relationship acquisition unit for acquiring function call relationships; and a path tracing unit for traversing the abstract syntax tree and acquiring cross-function risk propagation paths based on the function call relationships and the code vulnerability rules.

[0250] In one example, obtaining the function call relationship includes: obtaining the static single assignment (SSA) code of the application; and obtaining the function call relationship based on the SSA code.

[0251] In one example, obtaining the static single assignment (SSA) code of the application includes: executing a program compilation command to compile the application, wherein the source code of the program compilation command includes compilation code and dependency analysis code, such that the source code file is compiled by the compilation code, and the package dependency information of the application is obtained by the dependency analysis code; generating an abstract syntax tree (AST) of the source code file based on the package dependency information; and generating SSA code based on the AST.

[0252] In one example, obtaining the static single assignment (SSA) code of the application further includes:

[0253] Obtain the program compilation script, which includes dependency package installation information and the program compilation commands;

[0254] The program is run to compile the script, which enables the installation of dependency packages based on the dependency package installation information.

[0255] In one example, the apparatus further includes: a program splitting unit for splitting the application into multiple subroutines; the dependency package installation information includes dependency package installation information of the subroutines; the dependency package installation based on the dependency package installation information includes: installing dependency packages based on the dependency package installation information of the subroutines.

[0256] In one example, the apparatus further includes: an environment variable setting unit for setting environment variables corresponding to the package dependency information; the step of generating an abstract syntax tree for the source code file based on the package dependency information includes: using the environment variables as input information for an abstract syntax tree generation tool, and generating an abstract syntax tree through the abstract syntax tree generation tool.

[0257] In one example, the apparatus further includes: a function correspondence acquisition unit, used to acquire the correspondence between Abstract Syntax Tree (AST) functions and SSA functions; and a function call location determination unit, used to determine the call location of functions called across files based on the function correspondence.

[0258] In one example, the function mapping unit is specifically used to obtain the mapping between AST functions and SSA functions based on the function identifier Token.

[0259] In one example, the apparatus further includes: a type information determination unit, configured to determine the type information of the abstract syntax tree node based on the SSA code; the step of traversing the abstract syntax tree and obtaining the cross-function risk propagation path based on the function call relationship and the code vulnerability rule includes: traversing the abstract syntax tree and obtaining the cross-function risk propagation path based on the type information, the function call relationship and the code vulnerability rule.

[0260] In one example, the apparatus further includes: a data storage unit for storing abstract syntax tree data and SSA code data in memory; a type information determination unit for determining the type information of abstract syntax tree nodes based on the SSA code; and a caching unit for storing frequently used query information in a cache, wherein the frequently used query information includes at least one of the following: function call relationships, structure / interface inheritance relationships, and application framework identification information; wherein the application framework identification information includes at least one of the following: application entry point and routing graph.

[0261] In one example, obtaining function call relationships based on the SSA code includes: obtaining function call relationships in parallel based on the SSA code at the package granularity level.

[0262] In one example, generating the abstract syntax tree of the source code file includes: generating the abstract syntax tree of the source code file in parallel at the package granularity level.

[0263] In one example, the same function exhibits different pollution propagation behaviors in different calling scenarios.

[0264] In one example, the source code includes a structured variable with a first field and a second field; the risk propagation path before the function call includes the first field; and the called function includes sensitive operations related to the first field.

[0265] In one example, the source code includes a structured variable with a first field and a second field; the risk propagation path before the function call includes the first field; and the called function includes sensitive operations related to the second field.

[0266] In one example, for a branch condition in the source code, vulnerability detection is performed on the code within the branch condition based on the risk propagation path before the branch; for branch merging in the source code, the risk propagation paths in multiple program branches are merged according to the branch merging method.

[0267] In one example, traversing the abstract syntax tree and obtaining the cross-function risk propagation path based on the function call relationship and the code vulnerability rules includes: recording the correspondence between function entry state and function output result state; if the entry state of the function to be detected is the same as the recorded function entry state, then obtaining the corresponding function output result state based on the correspondence.

[0268] In one example, the apparatus further includes: a function input parameter type acquisition unit, used to acquire the type of function input parameters of function calls in the risk propagation path that are affected by the risk source; and a path filtering unit, used to treat the risk propagation path as an invalid propagation path if the type of the function input parameter is a type that does not have risk propagation capability.

[0269] In one example, obtaining the type of the function input parameter includes: obtaining the static single assignment (SSA) code of the application; obtaining the definition usage chain of the SSA variable based on the SSA code; obtaining the type of the SSA function input parameter based on the definition usage chain using a binary search algorithm; obtaining the correspondence between the AST function input parameter and the SSA function input parameter; and obtaining the type of the AST function input parameter affected by the risk source based on the correspondence of the function input parameters and the type of the SSA function input parameter.

[0270] In one example, obtaining the type of the function input parameter includes: obtaining the type of the function input parameter in parallel at the package granularity level.

[0271] In one example, the apparatus further includes a path merging unit for merging risk propagation paths with the same risk points to form a code vulnerability report.

[0272] In one example, the apparatus further includes: a program entry point acquisition unit, configured to acquire a program entry point based on the source code; and a parallel detection unit, configured to split the application into multiple subroutines if multiple program entry points exist, and perform code vulnerability detection on the multiple subroutines in parallel.

[0273] In one example, the parallel code vulnerability detection of multiple subroutines includes: performing code vulnerability detection on multiple combinations of subroutines and code vulnerability rules in parallel.

[0274] In one example, the code vulnerability rules are written in a domain-specific language; the code vulnerability rules include the following rule items: risk source, purifier, and risk point; traversing the abstract syntax tree and obtaining the cross-function risk propagation path based on the function call relationship and the code vulnerability rules includes: detecting whether the source code includes the risk source in the code vulnerability rules; if the risk source is detected, detecting whether the source code includes a purifier for the risk source; if no purifier for the risk source is detected, detecting whether the source code includes a risk point related to the risk source; if a risk point related to the risk source is detected, obtaining the propagation path from the risk source to the risk point.

[0275] In one example, based on the type information of the code elements, it is detected whether the source code includes the risk sources, purifiers, and / or risk points in the code vulnerability rules.

[0276] In one example, the risk source includes at least one of the following attributes: function return value, expression; the value of the function return value attribute includes: a function return value obtained from the request body of the network request that is a user-controllable input; the value of the expression attribute includes: the content included in the request parameters of the network request is a user-controllable input expression.

[0277] In one example, the purifier includes one of the following attributes: function return value, function parameters; the value of the function return value attribute includes: purifier function name; the function parameter attribute includes sub-attributes: purifier function name, input parameter number of the purifier function, wherein the input parameter corresponding to the input parameter number is the purifier object.

[0278] In one example, the risk point includes one of the following attributes: function return value, function parameters; the value of the function return value attribute includes: risk function name; the function parameter attribute includes sub-attributes: risk function name, input parameter number of the risk function, and the input parameter corresponding to the input parameter number involves a sensitive operation.

[0279] In one example, the code vulnerability rule also includes at least one of the following rule items: vulnerability type, rule description.

[0280] Third Embodiment

[0281] In the above embodiments, a code vulnerability detection method is provided. Correspondingly, this application also provides a code vulnerability detection method. This method corresponds to the embodiments of the above methods, so it is described simply. For relevant details, please refer to the description of the method embodiment one. The method embodiments described below are merely illustrative.

[0282] The code vulnerability detection method in this embodiment includes the following steps:

[0283] Step S401: Detect whether the source code includes risk sources in the code vulnerability rules; the code vulnerability rules also include purifiers and risk points.

[0284] Step S403: If the risk source is detected, check whether the source code includes the purifier for the risk source.

[0285] Step S405: If no purifier is detected targeting the risk source, then check whether the source code includes the risk point related to the risk source.

[0286] Step S407: If the risk point related to the risk source is detected, the propagation path from the risk source to the risk point is obtained.

[0287] The code vulnerability detection method provided in this application, through the processing steps S401 to S407, utilizes the DSL organization's code vulnerability rules. Adhering to the principle that rules are code, the rule code is closer to natural language, better representing the state of vulnerability analysis, enhancing code readability and maintainability, and minimizing the learning cost. Furthermore, since the DSL organization's code vulnerability rules do not contain complex query statements (such as query scripts), the scalability of the detection rules is enhanced. Users can extend the detection rules for specific application scenarios or new vulnerability patterns, enabling the detection of vulnerabilities in complex applications and adapting to dynamically changing threat scenarios.

[0288] Fourth embodiment

[0289] In the above embodiments, a code vulnerability rule-making method is provided. Correspondingly, this application also provides a code vulnerability rule-making apparatus. This apparatus corresponds to the embodiments of the above method. Since the apparatus embodiments are basically similar to the method embodiments, the description is relatively simple, and relevant parts can be referred to in the description of the method embodiments. The apparatus embodiments described below are merely illustrative.

[0290] The code vulnerability detection device of this embodiment includes: a risk source detection unit, used to detect whether the source code includes a risk source in the code vulnerability rules; the code vulnerability rules also include a purifier and a risk point; a purifier detection unit, used to detect whether the source code includes a purifier for the risk source if the risk source is detected; a risk point detection unit, used to detect whether the source code includes a risk point related to the risk source if the purifier for the risk source is not detected; and a path acquisition unit, used to acquire a propagation path from the risk source to the risk point if the risk point related to the risk source is detected.

[0291] Fifth embodiment

[0292] In the above embodiments, a code vulnerability detection method is provided. Correspondingly, this application also provides a code vulnerability rule configuration method. This method corresponds to the embodiments of the above methods, so it is described simply. For relevant details, please refer to the description of the method embodiment one. The method embodiments described below are merely illustrative.

[0293] The code vulnerability rule configuration method in this embodiment includes the following steps:

[0294] Step S501: Determine the source code of the risk, the cleanup function, and the risk function;

[0295] Step S503: Based on the risky source code, the cleanup function, and the risk function, generate code vulnerability rules written in a domain-specific language to detect whether the source code includes the risky source code; if the risky source code is detected, detect whether the source code includes the cleanup function targeting the risk source; if the cleanup function targeting the risk source is not detected, detect whether the source code includes the risk function related to the risk source; if the risk function related to the risk source is detected, obtain the propagation path from the risky source code to the risk function.

[0296] The code vulnerability rule configuration method provided in this application, through steps S501 to S503, enables the adoption of DSL organization code vulnerability rules. Adhering to the principle that rules are code, the rule code is closer to natural language, better representing the state of vulnerability analysis, enhancing code readability and maintainability, and minimizing the learning cost. Furthermore, since DSL organization code vulnerability rules do not contain complex query statements (such as query scripts), the scalability of detection rules is enhanced. Users can extend detection rules for specific application scenarios or new vulnerability patterns, enabling the detection of vulnerabilities in complex applications and adapting to dynamically changing threat scenarios.

[0297] Sixth Embodiment

[0298] In the above embodiments, a method for configuring code vulnerability rules is provided. Correspondingly, this application also provides a device for configuring code vulnerability rules. This device corresponds to the embodiments of the method described above. Since the device embodiments are basically similar to the method embodiments, the description is relatively simple, and relevant parts can be referred to in the description of the method embodiments. The device embodiments described below are merely illustrative.

[0299] The code vulnerability rule apparatus of this embodiment includes: a rule item determination unit, used to determine risky source code, a cleanup function, and a risky function; and a rule generation unit, used to generate code vulnerability rules written in a domain-specific language based on the risky source code, the cleanup function, and the risky function, so as to detect whether the source code includes the risky source code according to the code vulnerability rules; if the risky source code is detected, then detect whether the source code includes the cleanup function for the risky source; if the cleanup function for the risky source is not detected, then detect whether the source code includes the risky function related to the risky source; if the risky function related to the risky source is detected, then obtain the propagation path from the risky source code to the risky function.

[0300] Seventh Embodiment

[0301] In the above embodiments, a code vulnerability detection method is provided. Correspondingly, this application also provides a static single-assignment SSA code acquisition method. This method corresponds to the embodiments of the above methods, so it is described relatively simply. For relevant details, please refer to the description of the method embodiment one. The method embodiments described below are merely illustrative.

[0302] The static single assignment (SSA) code acquisition method of this embodiment includes the following steps: executing a program compilation command to compile the application program, wherein the source code of the program compilation command includes compilation code and dependency analysis code, such that the source code file is compiled by the compilation code, and the package dependency information of the application is obtained by the dependency analysis code; generating an abstract syntax tree of the source code file based on the package dependency information; and generating SSA code based on the abstract syntax tree.

[0303] The static single assignment SSA code acquisition method provided in this application embodiment compiles an application by executing a program compilation command. The source code of the program compilation command includes compilation code and dependency analysis code. The compilation code compiles the source code file, and the dependency analysis code obtains the application's package dependency information. Based on the package dependency information, an abstract syntax tree (SSA) is generated from the source code file. Based on the SSA, SSA code is generated. This processing method enables the acquisition of the application's SSA code after compilation, thus effectively improving the performance of SSA code acquisition.

[0304] Eighth embodiment

[0305] In the above embodiments, a method for obtaining static single-assignment SSA code is provided. Correspondingly, this application also provides a device for obtaining static single-assignment SSA code. This device corresponds to the embodiments of the above method. Since the device embodiments are basically similar to the method embodiments, the description is relatively simple, and relevant parts can be referred to in the description of the method embodiments. The device embodiments described below are merely illustrative.

[0306] The static single assignment (SSA) code acquisition device of this embodiment includes: a program compilation unit, used to execute program compilation commands to compile an application program, wherein the source code of the program compilation commands includes compilation code and dependency analysis code, such that the source code file is compiled by the compilation code, and the package dependency information of the application is obtained by the dependency analysis code; an abstract syntax tree of the source code file is generated according to the package dependency information; and SSA code is generated according to the abstract syntax tree.

[0307] Ninth Embodiment

[0308] In the above embodiments, a code vulnerability detection method is provided. Correspondingly, this application also provides an electronic device. This device corresponds to the embodiments of the above method. Since the device embodiment is basically similar to the method embodiment, it is described simply, and relevant details can be found in the description of the method embodiment. The device embodiment described below is merely illustrative.

[0309] The electronic device of this embodiment includes: a memory and a processor; the memory is used to store a program for implementing the method, and the device is powered on and runs the program of the above-described content risk identification method through the processor.

[0310] Memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0311] In specific implementations, the electronic device may also include one or more of the following components: a power supply component, an input / output (I / O) interface, and a communication component. The power supply component provides power to various components of the electronic device. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device. The I / O interface provides an interface between the processor 503 and peripheral interface modules, which may be a keyboard, click wheel, buttons, etc. The communication component is configured to facilitate wired or wireless communication between the electronic device and user devices (such as smartphones, tablets, etc.).

[0312] Tenth Embodiment

[0313] This application also provides a computer-readable storage medium. Since the embodiments of the computer-readable storage medium are substantially similar to the method embodiments, the description is relatively simple; relevant details can be found in the description of the method embodiments. The computer-readable storage medium embodiments described below are merely illustrative.

[0314] In this embodiment, a non-transitory computer-readable storage medium including instructions is provided, such as a memory including instructions, which can be executed by a processor of an electronic device to complete the content risk identification method provided by this disclosure. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0315] It should be noted that the embodiments of this application may involve the use of user data. In practical applications, user-specific personal data may be used in the scheme described herein within the scope permitted by applicable laws and regulations, provided that it complies with the applicable laws and regulations of the country (e.g., with the user's explicit consent, with the user being properly notified, etc.).

[0316] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

[0317] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0318] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0319] 1. Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0320] 2. Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

Claims

1. A code vulnerability detection method, characterized in that, include: Obtain multiple source code files and code vulnerability rules of the application; Generate an abstract syntax tree for the source code file and obtain the function call relationships; Traverse the abstract syntax tree and obtain the risk propagation path across functions based on the function call relationships and the code vulnerability rules.

2. The method according to claim 1, characterized in that, The process of obtaining function call relationships includes: Obtain the static single assignment (SSA) code of the application; Based on the SSA code, obtain the function call relationship.

3. The method according to claim 2, characterized in that, The step of obtaining the static single assignment (SSA) code of the application includes: The program compilation command is executed to compile the application. The source code of the program compilation command includes compilation code and dependency analysis code, which compiles the source code file through the compilation code and obtains the package dependency information of the application through the dependency analysis code. Based on the package dependency information, an abstract syntax tree (SSA) of the source code file is generated. Based on the abstract syntax tree, SSA code is generated.

4. The method according to claim 3, characterized in that, The step of obtaining the static single assignment (SSA) code of the application also includes: Obtain the program compilation script, which includes dependency package installation information and the program compilation commands; The program is run to compile the script, which enables the installation of dependency packages based on the dependency package installation information.

5. The method according to claim 3, characterized in that, Also includes: Set the environment variables corresponding to the package dependency information; The step of generating the abstract syntax tree of the source code file based on the package dependency information includes: The environment variables are used as input information for the abstract syntax tree generation tool, which then generates an abstract syntax tree.

6. The method according to claim 2, characterized in that, Also includes: Based on the SSA code, determine the type information of the abstract syntax tree nodes; The process of traversing the abstract syntax tree and obtaining cross-function risk propagation paths based on the function call relationships and code vulnerability rules includes: Traverse the abstract syntax tree and obtain the risk propagation path across functions based on the type information, the function call relationship, and the code vulnerability rules.

7. The method according to claim 1, characterized in that, The source code includes structured variables, which consist of a first field and a second field; The risk propagation path before the function call includes the first field; The called function includes sensitive operations related to the first field.

8. The method according to claim 1, characterized in that, Also includes: The source code includes structured variables, which consist of a first field and a second field; The risk propagation path before the function call includes the first field; The called function includes sensitive operations related to the second field.

9. The method according to claim 1, characterized in that, The code vulnerability rules are written in a domain-specific language; The code vulnerability rules include the following rule items: risk source, purifier, and risk point; The process of traversing the abstract syntax tree and obtaining cross-function risk propagation paths based on the function call relationships and code vulnerability rules includes: Detect whether the source code contains the risk sources specified in the code vulnerability rules; If the risk source is detected, then check whether the source code includes a purifier for the risk source; If no purifier is detected for the risk source, then check whether the source code includes risk points related to the risk source. If a risk point related to the risk source is detected, the propagation path from the risk source to the risk point is obtained.

10. A code vulnerability detection method, characterized in that, include: Check whether the source code contains risk sources listed in the code vulnerability rules; The code vulnerability rules also include purifiers and risk points; If the risk source is detected, then check whether the source code includes the purifier targeting the risk source; If no purifier is detected targeting the risk source, then the source code is checked to see if it includes the risk point related to the risk source. If a risk point related to the risk source is detected, the propagation path from the risk source to the risk point is obtained.

11. A method for configuring code vulnerability rules, characterized in that, include: Identify the source code, cleanup functions, and risk functions for the risks. Based on the risky source code, cleanup function, and risk function, code vulnerability rules written in a domain-specific language are generated to detect whether the source code includes the risky source code. If the risky source code is detected, then it is checked whether the source code includes the cleanup function for the risk source; if the cleanup function for the risk source is not detected, then it is checked whether the source code includes the risk function related to the risk source. If the risk function associated with the risk source is detected, the propagation path from the risk source code to the risk function is obtained.

12. A method for obtaining static single-assignment SSA code, characterized in that, include: The program compilation command is executed to compile the application program. The source code of the program compilation command includes compilation code and dependency analysis code, so that the source code file is compiled by the compilation code and the package dependency information of the application is obtained by the dependency analysis code; and an abstract syntax tree of the source code file is generated based on the package dependency information. Based on the abstract syntax tree, generate SSA code.

13. A code vulnerability detection device, characterized in that, include: The source code acquisition unit is used to acquire multiple source code files of the application; The detection rule acquisition unit is used to acquire code vulnerability rules; Abstract syntax tree generation unit, used to generate the abstract syntax tree of the source code file; The function call relationship acquisition unit is used to acquire function call relationships; The path tracing unit is used to traverse the abstract syntax tree and obtain the risk propagation path across functions based on the function call relationship and the code vulnerability rules.

14. An electronic device, characterized in that, include: processor; as well as A memory for storing a program for implementing the method according to any one of claims 1 to 12, wherein the device is powered on and the program for running the method is executed by the processor.

Images