A software vulnerability static analysis method based on rule modeling and related equipment

Abstract

The application belongs to the technical field of embedded software testing, and particularly relates to a software vulnerability static analysis method based on rule modeling and related equipment. First, a predefined software vulnerability rule is acquired, and a target vulnerability rule model containing a data processing model and a control logic model is constructed; then, information filtering is performed on source files and configuration files of a target software, invalid and redundant contents are removed, and a code file to be scanned is obtained; subsequently, two types of sub-models in the rule model are called, line-by-line scanning is performed on the code file to be scanned, and rule violation code segments violating rule requirements in the code file to be scanned are accurately identified; if a rule violation segment is detected, a vulnerability analysis result containing vulnerability positioning and risk description is automatically generated and output according to the specific position of the rule violation segment in the source file. The scheme can be adapted to a multi-language development scene, and safety detection is placed in the coding stage.

Description

Technical Field

[0001] This invention belongs to the field of embedded software testing technology, specifically involving a rule-based modeling-based static analysis method for software vulnerabilities and related equipment. Background Technology

[0002] Static vulnerability analysis is a technique that runs throughout the entire software development lifecycle, helping software developers discover software vulnerabilities early on, and it has wide applications in the software development process. Rules are derived from existing mature design concepts and engineering experience, analyzing the causes of vulnerabilities that have occurred or have a high frequency of occurrence, and describing the correct methods. Performing vulnerability analysis on software during the development process based on known vulnerabilities can achieve a safe left-shift in the software development process, which is of great significance for improving software quality. Traditional static vulnerability analysis abstracts the source code into a syntax tree, extracts information such as data flow and control flow to form intermediate files for analysis. However, syntax trees can only represent software structure information, data flow only represents data information, and control flow only represents task collaboration and function call relationships. No intermediate file can completely represent all the information in the source code, and it also lacks configuration files, such as compilation files, symbol tables, and software resource configuration information, resulting in incomplete information during static vulnerability analysis. Furthermore, as software functions become increasingly complex and large-scale, intermediate representation of the source code requires significant resources, leading to low efficiency in large-scale static vulnerability analysis. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a software vulnerability static analysis method and related equipment based on rule modeling to address the shortcomings of the prior art, thereby solving the technical problems of inconsistent vulnerability judgment standards, high scanning redundancy, easy omission of row-level vulnerabilities, and time-consuming vulnerability location in the prior art.

[0004] The objective of this invention is achieved through the following technical solutions: In a first aspect, the present invention provides a method for static analysis of software vulnerabilities based on rule modeling, comprising: Obtain predefined software vulnerability rules, and construct a rule model corresponding to the target vulnerability based on the software vulnerability rules. The rule model includes a data processing model and a control logic model. Obtain the source files and configuration files of the software to be analyzed, perform information filtering on the source files and configuration files of the software to be analyzed, and obtain the code files to be scanned; Using the data processing model and the control logic model, the code file to be scanned is scanned line by line to identify whether there are any illegal code segments in the code file that violate the rule model; If the allegedly illegal code fragment exists, the vulnerability analysis results will be generated and output based on the location of the allegedly illegal code fragment in the source file.

[0005] As a further improvement of the present invention, the step of constructing a rule model corresponding to the target vulnerability based on the software vulnerability rules includes: Keyword features are extracted from the software vulnerability rules, and a trusted data model for representing legitimate code behavior and a tainted data model for representing illegal code behavior are constructed respectively, serving as the data processing model. The scope of code blocks constrained by the software vulnerability rules and the exemption conditions are analyzed, and a block control logic model and a special case control logic model are constructed respectively. The special case control logic model is used to identify and exempt compliant code under preset conditions by combining the context or cross-file reference relationship.

[0006] As a further improvement of the present invention, the step of using the data processing model and the control logic model to scan the code file to be scanned line by line includes: When scanning the target statement block in the code file to be scanned, the integrity of the code structure of the target statement block is determined by the statement block control logic model. When the target statement block is complete, the trusted data model and the taint data model are used to perform feature comparison on the target code lines within the target statement block; If the target code line does not include trusted data as defined by the trusted data model, but contains tainted data as defined by the tainted data model, then the special case control logic model is used to determine whether the target code line meets the exemption condition. If the exemption conditions are not met, the target code is determined to be a violation code segment that violates the rule model.

[0007] As a further improvement of the present invention, the multiple trusted data in the trusted data model are logically ORed, and if any of the trusted data is included, it is determined that there is no vulnerability. The multiple tainted data in the tainted data model are logically ANDed, and when all the tainted data are included, the process of judging the exemption condition is initiated.

[0008] As a further improvement of the present invention, before performing line-by-line scanning of the code file to be scanned using the data processing model and the control logic model, the method further includes: Obtain the engineering configuration characteristics of the software to be analyzed, wherein the engineering configuration characteristics include at least one of the following: software critical level, software operating scenario, software type, development language, and processor chip architecture; Based on the aforementioned engineering configuration features, a preset vulnerability rule model library is matched and filtered to obtain a subset of target rule models that are compatible with the current software to be analyzed. The subset of the target rule model is used as the basis for determining whether to perform the line-by-line code scanning and statement block analysis.

[0009] As a further improvement of the present invention, the step of obtaining the source files and configuration files of the software to be analyzed, and performing information filtering processing on the source files and configuration files of the software to be analyzed, includes: Determine whether the software to be analyzed is in a compressed format; if so, decompress it to obtain the original file set. Remove interfering files from the original file set that are irrelevant to the static vulnerability analysis, and retain the source files and the configuration files; The comment information and blank line information in the source file are filtered out, and the filtered text data is used as the intermediate file to be scanned.

[0010] As a further improvement of the present invention, the step of generating vulnerability analysis results based on the location information of the vulnerable code fragment in the source file includes: Extract the name of the rule that was violated corresponding to the vulnerable code snippet; Obtain the file path, file name, and specific line number of the vulnerable code snippet in the source file; The rule name, file path, file name, and statement line number are encapsulated in JSON data format to output structured target vulnerability analysis results.

[0011] Secondly, the present invention provides a rule-based modeling-based static analysis system for software vulnerabilities, comprising: The rule modeling module is used to obtain predefined software vulnerability rules and construct a rule model corresponding to the target vulnerability based on the software vulnerability rules. The rule model includes a data processing model and a control logic model. The software preprocessing module is used to obtain the source files and configuration files of the software to be analyzed, and to perform information filtering on the source files and configuration files of the software to be analyzed to obtain the code files to be scanned. The software vulnerability static analysis module is used to scan the code file to be scanned line by line using the data processing model and the control logic model, and to identify whether there are any illegal code segments in the code file to be scanned that violate the rule model. The vulnerability analysis result display module is used to generate vulnerability analysis results based on the location information of the vulnerable code fragment in the source file when the vulnerable code fragment is identified.

[0012] Thirdly, the present invention provides a computer device, comprising: a processor and a computer-readable storage medium; A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program that, when executed by the processor, implements the rule-based modeling-based static analysis method for software vulnerabilities as described above.

[0013] Fourthly, the present invention provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed as described above for static analysis of software vulnerabilities based on rule modeling.

[0014] The beneficial effects of this invention are as follows: This invention provides a static analysis method for software vulnerabilities based on rule modeling. By acquiring predefined software vulnerability rules and constructing a target vulnerability rule model that includes a data processing model and a control logic model, the vulnerability judgment logic is solidified into a standardized executable unit, avoiding judgment bias caused by manual rule sorting. At the same time, it achieves global consistency of vulnerability judgment standards and improves rule reusability. By filtering the source files and configuration files of the software to be analyzed to obtain the code files to be scanned, redundant content unrelated to vulnerability judgment is eliminated, reducing the invalid computational load of subsequent scanning stages. The data processing model and control logic model are used to perform line-by-line scanning of the code files to be scanned to identify illegal code fragments, achieving precise rule matching at the line-level, avoiding the omission of line-level hidden illegal code. Based on the corresponding position of the illegal code fragment in the source file, vulnerability analysis results are generated and output, directly locking the precise code location of the vulnerability, reducing the redundant workload of developers' secondary backtracking and investigation. This invention ultimately simultaneously improves the accuracy of vulnerability scanning, scanning execution efficiency, and vulnerability location accuracy. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of rule modeling in the rule-based static analysis method for software vulnerabilities according to an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating preferred vulnerability analysis rules in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the implementation of static analysis of software vulnerabilities in an embodiment of the present invention; Figure 4 This is a schematic diagram of the modeling of example rules in an embodiment of the present invention; Figure 5 This is a schematic diagram of the internal structure of a computer device in an embodiment of the present invention. Detailed Implementation

[0017] To make the objectives and technical solutions of this invention clearer and easier to understand, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. The specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention.

[0018] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings and specific embodiments. The described embodiments are only some embodiments of the present invention, and not all embodiments.

[0019] Example 1 This invention provides a rule-based modeling-based static analysis method for software vulnerabilities. It employs rule-based modeling for static analysis, with one rule corresponding to one vulnerability. The model size is controllable, and source code information is directly scanned for analysis based on the rule model, completely preserving all information in the source code. The analysis process includes compilation information, configuration files, object code, and other relevant configuration file information corresponding to the source code, providing comprehensive analysis data through a full-coverage file scan. The source code does not require conversion to intermediate representations, resulting in low resource consumption. It has low requirements for source code integrity, allowing static vulnerability analysis even on code snippets. Vulnerability analysis results accurately locate file statement lines, achieving high precision. Furthermore, the model has the advantage of continuous updating, effectively contributing to improved software quality during software development. The overall processing method is as follows: Figure 3 As shown, the specific implementation method is as follows.

[0020] S1. Obtain predefined software vulnerability rules and construct a rule model corresponding to the target vulnerability based on the software vulnerability rules. The rule model includes a data processing model and a control logic model, such as... Figure 1 As shown.

[0021] In this embodiment, the predefined software vulnerability rules are a pre-established set of software security detection rules. Each software vulnerability rule corresponds to a target vulnerability and describes the conditions under which the target vulnerability occurs, the code characteristics involved, the applicable statement block range, compliant code examples, non-compliant code examples, and special exemption conditions. Code in the software that violates a certain software vulnerability rule is determined to potentially contain the target vulnerability corresponding to that software vulnerability rule.

[0022] Retrieving predefined software vulnerability rules is accomplished through rule configuration files, rule databases, or rule management modules. Rule content can include rule name, vulnerability type, vulnerability level, applicable software type, applicable programming language, applicable processor chip architecture, trusted data, tainted data, code block scope, and special case judgment conditions.

[0023] Constructing a rule model corresponding to a target vulnerability based on software vulnerability rules refers to converting software vulnerability rules in natural language, example, or configuration form into a structured judgment model that can be executed by a static analysis program. Specifically, key features are extracted from the software vulnerability rules to construct a trusted data model representing legitimate code behavior and a tainted data model representing illegitimate code behavior, serving as data processing models. The scope of code statement blocks and exemption conditions constrained by the software vulnerability rules are analyzed to construct statement block control logic models and special case control logic models, serving as control logic models. The special case control logic model is used to identify and exempt compliant code under preset conditions by combining contextual information or cross-file reference relationships.

[0024] In this embodiment, the data processing model is used to describe the data characteristics and their processing relationships in the code. The data processing model includes a trusted data model and a tainted data model. The trusted data model is used to characterize legitimate code behavior. Trusted data can be data that has undergone security verification, data processed by authorized interfaces, data conforming to a specified format, or data transformed by trusted functions, such as... Figure 4 As shown, or other compliance data explicitly listed in the rules. When scanning code, if a target line of code or target block contains trusted data that meets the conditions, the code can be determined as not having the corresponding vulnerability according to the rule configuration, or proceed to the subsequent compliance judgment process. The tainted data model is used to characterize non-compliant code behaviors that may cause vulnerabilities. Tainted data can be unvalidated external input, unauthorized data sources, function calls with dangerous attributes, risky configuration parameters, or other risk characteristics explicitly listed in the rules. When scanning code, if a target line of code or target block contains tainted data that meets the conditions, it is necessary to combine the trusted data model and the control logic model to further determine whether it constitutes a vulnerability.

[0025] The processing logic for trusted and tainted data can include logical AND and logical OR operations. Multiple trusted data can be ORed; if the target code contains any trusted data, it can be determined that the corresponding vulnerability does not exist according to the rules. Multiple tainted data can be ANDed; only when the target code contains all tainted data will the special case control logic be invoked. Trusted and tainted data cannot both be empty simultaneously; otherwise, a valid vulnerability determination condition cannot be formed.

[0026] The control logic model describes the code structure, statement block scope, and special applicable conditions. The control logic model includes the statement block control logic model and the special case control logic model.

[0027] The statement block control logic model describes the scope of code statement blocks constrained by software vulnerability rules and determines whether the code to be analyzed constitutes a complete target statement block. Target statement blocks can include conditional statement blocks, loop statement blocks, function statement blocks, exception handling statement blocks, configuration statement blocks, macro definition statement blocks, and other code structures composed of multiple lines of code. By judging the start and end positions, nesting relationships, and code structure integrity of statement blocks, it avoids misjudgments based solely on individual lines of code.

[0028] The special case control logic model is used to describe the exemption conditions in the target vulnerability rules. The special case control logic model can combine the context of the target code, the surrounding code, function call relationships, variable passing relationships, conditional branch relationships, and cross-file reference relationships to identify code that, under preset conditions, has risk characteristics but is actually a design requirement or compliant use method, and exempt such code from the vulnerability results.

[0029] The rule model can be built with one rule corresponding to one vulnerability. For each software vulnerability rule, a data processing model and a control logic model are built separately, and the rule name, rule level, scope of application, and judgment conditions are associated and saved.

[0030] S2. Obtain the source files and configuration files of the software to be analyzed, perform information filtering on the source files and configuration files of the software to be analyzed, and obtain the code files to be scanned; Specifically, the software to be analyzed can be an uncompressed software project or a compressed software package. When the software to be analyzed is in a compressed format, it is first decompressed to obtain the original set of files. The compressed format can include project archives, software distribution packages, or other sets of files that can contain source code files and configuration files.

[0031] The decompression process includes identifying the compression format, creating a temporary analysis directory, extracting the original files from the compressed file, and recording the path information of the original files. This decompression process allows subsequent analysis modules to access source files and configuration files according to their file paths.

[0032] After obtaining the original file set, remove interfering files that are irrelevant to the static vulnerability analysis. Interfering files can include compiled files, temporary files, cache files, log files, version control files, documentation files, icon files, media files, and other files that do not participate in the software's runtime logic or do not contain analyzable code. Removing interfering files reduces the amount of data required for subsequent scans.

[0033] After retaining the source files and configuration files, information filtering is performed on them. This filtering process may include removing comments and blank lines, and filtering out declarations, formatting control information, or duplicate content irrelevant to vulnerability analysis based on configured rules. Comments typically do not participate in the actual software execution logic, and blank lines usually do not contain valid code characteristics; filtering these types of information can reduce invalid scans.

[0034] The filtered text data serves as the code file to be scanned. The code file to be scanned retains the original file path, file name, and line-by-line correspondence of the source file, so that after discovering illegal code snippets, the scan location can be mapped back to the actual location in the source file.

[0035] The processing flow in this step includes decompressing compressed files, filtering irrelevant files, and filtering file content. By performing unified preprocessing before scanning, we provide code files that are consistent in format, valid in content, and easy to locate for subsequent rule matching and line-by-line scanning.

[0036] S3. Using the data processing model and the control logic model, the code file to be scanned is scanned line by line to identify whether there are any illegal code segments in the code file that violate the rule model.

[0037] Specifically, when scanning the target statement block in the code file to be scanned, the integrity of the code structure of the target statement block is determined by the statement block control logic model. When the target statement block is complete, the target code line within the target statement block is compared using the trusted data model and the tainted data model. If the target code line does not include trusted data defined by the trusted data model, but contains tainted data defined by the tainted data model, the target code line is judged to meet the exemption conditions in combination with the special case control logic model. If the exemption conditions are not met, the target code behavior is determined to be a violation code segment that violates the rule model.

[0038] Line-by-line scanning refers to reading code lines sequentially according to the file order of the code files to be scanned, and then determining vulnerabilities by combining the statement block in which the target code line is located, the context, and cross-file references. For each software vulnerability rule, files can be checked one by one, and a coverage analysis can be performed on the code lines and related statement blocks in each file.

[0039] During line-by-line scanning, the target statement block to which the target code line belongs is first identified through the statement block control logic model, and the code structure integrity of the target statement block is determined. Code structure integrity can include whether the statement block has complete start and end boundaries, whether the nesting relationship is complete, whether the conditional branches are complete, whether the function calls or configuration items are complete, and whether cross-line statements have been completely read.

[0040] When the target statement block is incomplete, continue reading subsequent lines of code until a complete statement block is formed, or mark the current statement block as undeterminable according to the rules. By first checking the completeness of the statement block, incorrect judgments can be prevented due to code line truncation, cross-line statements, or unclosed nested structures.

[0041] When the target statement block is complete, the target code lines within the target statement block are compared using trusted data models and tainted data models. Feature comparison can include keyword matching, function name matching, variable name matching, parameter form matching, data source matching, configuration item matching, and code structure matching.

[0042] When the target code line contains trusted data as defined by the trusted data model, it can be determined according to the rules that there is no corresponding vulnerability. When multiple trusted data are used in a logical OR operation, as long as the target code line or target statement block contains any trusted data, the code can be considered to meet the trusted conditions and will not enter the vulnerability assessment, or it can enter other compliant branches according to the rules.

[0043] When the target code line does not include trusted data as defined by the trusted data model, but contains tainted data as defined by the tainted data model, it indicates that the target code line has risk characteristics related to the target vulnerability. When multiple tainted data are ANDed together, the exemption condition judgment process will only proceed if the target code line or target statement block simultaneously contains all tainted data.

[0044] When a target line of code simultaneously meets the tainted data condition and other rule constraints, the special case control logic model is used to determine whether the target line of code meets the exemption condition. The exemption condition can be determined based on the context, adjacent lines of code, the function in which it is located, the call chain, the source of variables, conditional branches, configuration file content, and cross-file references.

[0045] If the target code line meets the preset exemption conditions, it is considered compliant code and no corresponding vulnerability result is generated. If the target code line does not meet the exemption conditions, it is determined that the target code behavior violates the rule model, and the corresponding code line or related consecutive code lines are identified as illegal code segments.

[0046] A violation code snippet can be a single line of code or a complete block of statements composed of multiple lines of code. When identifying a violation code snippet, the rule name, the source file containing the violation code snippet, the source file path, the source file name, the statement line number, and necessary context information can be recorded.

[0047] In the static analysis of software vulnerabilities, the rule model library can be matched and filtered based on the engineering configuration characteristics of the software to be analyzed. Engineering configuration characteristics include at least one of the following: software criticality level, software operating scenario, software type, programming language, and processor chip architecture. For example... Figure 2 The software types shown can include bootloaders, operating system software, driver software, testing software, and application software. Software vulnerability rules can be categorized into high-risk, medium-risk, and low-risk rules based on vulnerability severity.

[0048] Based on the software's criticality level, operating scenario, operating requirements, software type, programming language, and processor chip architecture, a preset vulnerability rule model library is matched to obtain a subset of target rule models adapted to the software being analyzed. This subset of target rule models serves as the basis for subsequent line-by-line code scanning and statement block analysis. Rules irrelevant to the current software type, operating scenario, or development environment may be excluded from the current analysis task.

[0049] Through rule optimization, different rule configurations are selected for different types of software. For example, for operating system software, rules related to system calls, access control, memory access, and configuration security can be prioritized; for driver software, rules related to hardware access, register operations, and boundary checks can be prioritized; and for application software, rules related to input validation, authentication, access control, and sensitive data processing can be prioritized.

[0050] S4. If a violation code segment exists, generate and output the vulnerability analysis results based on the location of the violation code segment in the source file.

[0051] The system determines whether a violation code segment is identified during line-by-line scanning and block analysis. If no violation code segment is identified, it can output an analysis status indicating that no corresponding vulnerability exists, or it can output no vulnerability record. If a violation code segment is identified, it generates a vulnerability analysis result corresponding to that violation code segment.

[0052] The vulnerability analysis results should include at least the rule name violated by the violating code snippet, the file path and file name of the violating code snippet, and the specific line number. The rule name indicates the vulnerability rule corresponding to the violating code snippet. The file path indicates the storage location of the violating code snippet within the software project being analyzed. The file name indicates the name of the source file or configuration file where the vulnerability occurs. The line number indicates the specific location of the violating code snippet within the source file.

[0053] When generating vulnerability analysis results, the path mapping and line number mapping between the code file to be scanned and the source file are used to restore the analyzed location in the filtered code file to its actual location in the source file. Even if comments and blank lines are deleted during the scan, the original line number of the violating code segment in the source file can still be determined through the line number mapping record.

[0054] The vulnerability analysis results are encapsulated in JSON data format. The result structure in this embodiment can be represented as follows: Result{ "rule_name": "file1name_Result":{ "file_path": "file_name": "file_line": } "file2name_Result":{ "file_path": "file_name": "file_line": } ... } Here, `rule_name` represents the name of the vulnerable rule, `file_path` represents the path to the vulnerable file, `file_name` represents the name of the vulnerable file, and `file_line` represents the line of code in the vulnerable file. The analysis results are output to a text file according to the specified format.

[0055] Based on the method of this embodiment, taking the high-risk rule in the C language "prohibiting the definition of variables in header files included by multiple .c files" as an example, the following explanation and verification process will be provided: 1. Rule Modeling: Defining variables in header files can lead to conflicts, data inconsistencies, and function call errors when that header file is included by multiple .c files. C language rules stipulate that variables should not be defined in header files. Header files are primarily used to declare interfaces (functions, structs, etc.) and should not contain concrete implementations or global variable definitions. Global variables defined in .c files can be declared in header files using `extern`. Therefore, modeling this rule is as follows: Figure 4 As shown.

[0056] In this analysis, trusted data is analyzed using OR operations, meaning that if a single piece of trusted data is present, the vulnerability described in this rule is considered nonexistent. Tainted data is analyzed using AND operations, meaning that if all data is present, a vulnerability is considered to exist. Header files may contain blocks of statements such as structures, unions, and function declarations, which may also contain nested blocks. Variable definitions within these blocks are permitted and not considered vulnerabilities; therefore, the content within these blocks is not analyzed for trusted or tainted data. However, the nesting and completeness of these blocks need to be analyzed to avoid false positives. Finally, a special case analysis is performed: if a variable is defined in a header file but only referenced by one .c file, it is considered nonexistent, and such header files do not require vulnerability analysis under this rule. 2. File preprocessing: Retain the header files in the software, filter other files, filter out header files that are only referenced once, and delete comments, blank lines and other static analysis-irrelevant information in the files; 3. Static Software Vulnerability Analysis: Select all rules, C language settings, and software type configuration information, and begin automated static vulnerability analysis. Scan the header files to be analyzed one by one according to the rule-based model method.

[0057] 4. Vulnerability Analysis Result Display Module: The inspection results are displayed in JSON format as follows: Result{ "rule_name": "Prevents defining variables in header files that are included by multiple .c files." "file_path":"\include\drv" "file_name":"app.h" "file_line": "Line 10 violates the rule" } The above implementation method completes a static analysis of a vulnerability described by a rule.

[0058] Example 2 This embodiment provides a rule-based modeling-based static analysis system for software vulnerabilities, which specifically includes the following modules: The rule modeling module is used to obtain predefined software vulnerability rules and construct a rule model corresponding to the target vulnerability based on the software vulnerability rules. The rule model includes a data processing model and a control logic model. The software preprocessing module is used to obtain the source files and configuration files of the software to be analyzed, and to perform information filtering on the source files and configuration files of the software to be analyzed to obtain the code files to be scanned. The software vulnerability static analysis module is used to scan the code file to be scanned line by line using the data processing model and the control logic model, and to identify whether there are any illegal code segments in the code file to be scanned that violate the rule model. The vulnerability analysis result display module is used to generate vulnerability analysis results based on the location information of the vulnerable code fragment in the source file when the vulnerable code fragment is identified.

[0059] Specific limitations regarding the rule-based modeling-based static analysis system for software vulnerabilities can be found in the limitations of the rule-based modeling-based static analysis method described above; the corresponding technical effects are equivalent and will not be repeated here. Each module in the aforementioned rule-based modeling-based static analysis system for software vulnerabilities can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0060] Example 3 Figure 5 An internal structural diagram of a computer device is shown in one embodiment. This computer device may specifically be a terminal or a server. Figure 5 As shown, the computer device includes a processor, memory, network interface, display, camera, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a rule-based modeling method for static analysis of software vulnerabilities. The display screen can be an LCD screen or an e-ink display. The input device can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0061] As will be understood by those skilled in the art, computer equipment Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. Specific computing devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0062] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0063] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0064] In summary, the software vulnerability static analysis method, system, computer device, and storage medium based on rule modeling provided in this application identify trusted and tainted data through a data processing model, determine code structural integrity through a statement block control logic model, and perform exemption judgments by combining contextual information and cross-file reference relationships through a special case control logic model. This improves the accuracy of vulnerability identification while reducing false positives. Filtering a subset of target rule models based on engineering configuration features reduces ineffective analysis caused by inapplicable rules, improving the efficiency of static vulnerability analysis. By saving the location mapping relationship between the code file to be scanned and the source file, and outputting the rule name, file path, file name, and statement line number in JSON data format, precise vulnerability location and structured utilization of analysis results can be achieved. Filtering a subset of suitable target rule models based on the engineering configuration features of the software to be analyzed reduces the analysis overhead caused by irrelevant rules, and achieves precise location of vulnerable files and statement line numbers through structured vulnerability analysis results, improving the automation, efficiency, and usability of software vulnerability static analysis.

[0065] The various embodiments in this specification are described in a progressive manner. For directly identical or similar parts of the embodiments, refer to each other. Each embodiment focuses on its differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. It should be noted that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0066] The above-described embodiments are merely preferred embodiments of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various improvements and substitutions without departing from the principles of the present invention, and these improvements and substitutions should also be considered within the scope of protection of the present invention. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A static analysis method for software vulnerabilities based on rule-based modeling, characterized in that, include: Obtain predefined software vulnerability rules, and construct a rule model corresponding to the target vulnerability based on the software vulnerability rules. The rule model includes a data processing model and a control logic model. Obtain the source files and configuration files of the software to be analyzed, perform information filtering on the source files and configuration files of the software to be analyzed, and obtain the code files to be scanned; Using the data processing model and the control logic model, the code file to be scanned is scanned line by line to identify whether there are any illegal code segments in the code file that violate the rule model; If the allegedly illegal code fragment exists, the vulnerability analysis results will be generated and output based on the location of the allegedly illegal code fragment in the source file.

2. The software vulnerability static analysis method based on rule modeling according to claim 1, characterized in that, The step of constructing a rule model corresponding to the target vulnerability based on the software vulnerability rules includes: Keyword features are extracted from the software vulnerability rules, and a trusted data model for representing legitimate code behavior and a tainted data model for representing illegal code behavior are constructed respectively, serving as the data processing model; The scope of code blocks constrained by the software vulnerability rules and the exemption conditions are analyzed, and a block control logic model and a special case control logic model are constructed respectively. The special case control logic model is used to identify and exempt compliant code under preset conditions by combining the context or cross-file reference relationship.

3. The software vulnerability static analysis method based on rule modeling according to claim 2, characterized in that, The step of scanning the code file to be scanned line by line using the data processing model and the control logic model includes: When scanning the target statement block in the code file to be scanned, the integrity of the code structure of the target statement block is determined by the statement block control logic model. When the target statement block is complete, the trusted data model and the taint data model are used to perform feature comparison on the target code lines within the target statement block; If the target code line does not include trusted data as defined by the trusted data model, but contains tainted data as defined by the tainted data model, then the special case control logic model is used to determine whether the target code line meets the exemption condition. If the exemption conditions are not met, the target code is determined to be a violation code segment that violates the rule model.

4. The software vulnerability static analysis method based on rule modeling according to claim 3, characterized in that, The trusted data in the trusted data model are logically ORed with each other. If any of the trusted data is included, it is determined that there is no vulnerability. The multiple tainted data in the tainted data model are logically ANDed, and when all the tainted data are included, the process of judging the exemption condition is initiated.

5. The software vulnerability static analysis method based on rule modeling according to claim 1, characterized in that, Before performing line-by-line scanning of the code file to be scanned using the data processing model and the control logic model, the process further includes: Obtain the engineering configuration characteristics of the software to be analyzed, wherein the engineering configuration characteristics include at least one of the following: software critical level, software operating scenario, software type, development language, and processor chip architecture; Based on the aforementioned engineering configuration features, a preset vulnerability rule model library is matched and filtered to obtain a subset of target rule models that are compatible with the current software to be analyzed. The subset of the target rule model is used as the basis for determining whether to perform the line-by-line code scanning and statement block analysis.

6. The software vulnerability static analysis method based on rule modeling according to claim 1, characterized in that, The process of obtaining the source files and configuration files of the software to be analyzed, and performing information filtering on the source files and configuration files of the software to be analyzed, includes: Determine whether the software to be analyzed is in a compressed format; if so, decompress it to obtain the original file set. Remove interfering files from the original file set that are irrelevant to the static vulnerability analysis, and retain the source files and the configuration files; The comment information and blank line information in the source file are filtered out, and the filtered text data is used as the intermediate file to be scanned.

7. The software vulnerability static analysis method based on rule modeling according to claim 1, characterized in that, The step of generating vulnerability analysis results based on the location information of the vulnerable code fragment in the source file includes: Extract the name of the rule that was violated corresponding to the vulnerable code snippet; Obtain the file path, file name, and specific line number of the vulnerable code snippet in the source file; The rule name, file path, file name, and statement line number are encapsulated in JSON data format to output structured target vulnerability analysis results.

8. A rule-based modeling-based static analysis system for software vulnerabilities, characterized in that, include: The rule modeling module is used to obtain predefined software vulnerability rules and construct a rule model corresponding to the target vulnerability based on the software vulnerability rules. The rule model includes a data processing model and a control logic model. The software preprocessing module is used to obtain the source files and configuration files of the software to be analyzed, and to perform information filtering on the source files and configuration files of the software to be analyzed to obtain the code files to be scanned. The software vulnerability static analysis module is used to scan the code file to be scanned line by line using the data processing model and the control logic model, and to identify whether there are any illegal code segments in the code file to be scanned that violate the rule model. The vulnerability analysis result display module is used to generate vulnerability analysis results based on the location information of the vulnerable code fragment in the source file when the vulnerable code fragment is identified.

9. A computer device, characterized in that, include: Processor and computer-readable storage media; A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements the rule-based modeling-based static analysis method for software vulnerabilities as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and executed by the rule-based modeling static analysis method for software vulnerabilities as described in any one of claims 1 to 7.

Images