A similarity-based software vulnerability analysis method and related device

Abstract

The present application belongs to the technical field of embedded software testing, and particularly relates to a software vulnerability analysis method based on similarity and related equipment, wherein a benchmark code fragment set and a vulnerability rule set are first acquired, benchmark code fragments are generated based on a preset code resource pool and software to be analyzed, and information filtering is performed on the software to be analyzed to generate intermediate files to be analyzed; similarity analysis is performed on the intermediate files to be analyzed and the benchmark code fragment set, matched similar code fragments are extracted and marked; vulnerability detection is performed on the benchmark code fragment set according to the vulnerability rule set, benchmark vulnerability analysis results are generated; execution environment characteristic data of the similar code fragments in the software to be analyzed is extracted, the benchmark vulnerability analysis results are mapped to the similar code fragments, and vulnerability confirmation is completed in combination with the execution environment characteristics to obtain final target vulnerabilities. The present method can improve vulnerability detection accuracy and reduce redundant detection workload.

Description

Technical Field

[0001] This invention belongs to the field of embedded software testing technology, specifically relating to a software vulnerability analysis method and related equipment based on similarity. Background Technology

[0002] As software grows larger and more complex, the software development process involves multi-module collaboration and multi-person collaborative development, making software highly susceptible to security vulnerabilities. Software vulnerability analysis technology can intervene early in the software development process, analyze security flaws, and promptly patch vulnerabilities, improving software quality and security. However, current software vulnerability analysis faces the following challenges: Traditional static vulnerability analysis methods can be used throughout the entire software lifecycle to help developers discover problems in the software code early on, but static analysis relies on prior knowledge of vulnerabilities and has a high rate of false positives and false negatives. Furthermore, large-scale software abstraction and information extraction remain significant challenges. Dynamic vulnerability mining methods, such as fuzzing, analyze based on the actual software operation, offering high accuracy, but require collecting software runtime data and configuring the software runtime environment. This increases the complexity of vulnerability analysis, places high demands on vulnerability analysts, and makes implementation difficult. Dynamic vulnerability analysis also suffers from path explosion problems, severely impacting the efficiency and accuracy of software vulnerability analysis. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a software vulnerability analysis method and related equipment based on similarity to address the shortcomings of the prior art, so as to solve the technical problems of excessive workload and limited depth analysis when performing overall vulnerability analysis on large software projects.

[0004] The objective of this invention is achieved through the following technical solutions: In a first aspect, the present invention provides a software vulnerability analysis method based on similarity, comprising: A set of benchmark code snippets and a set of vulnerability rules are obtained, and information filtering is performed on the software to be analyzed to generate an intermediate file to be analyzed. The benchmark code snippets in the set of benchmark code snippets are obtained based on a preset code resource pool and the software to be analyzed. The intermediate file to be analyzed is compared with the set of benchmark code snippets. The target code snippet is extracted from the intermediate file to be analyzed and marked as a similar code snippet that matches the set of benchmark code snippets. Vulnerability detection is performed on the benchmark code snippet set according to the vulnerability rule set, and benchmark vulnerability analysis results are generated; The execution environment feature data of the similar code snippets in the software to be analyzed is extracted, and the benchmark vulnerability analysis results are mapped to the similar code snippets. The vulnerability is then confirmed in the software to be analyzed in combination with the execution environment feature data to obtain the final target vulnerability.

[0005] As a further improvement of the present invention, the acquisition of the benchmark code fragment set includes: Extract historical reused code snippets from a pre-defined code resource pool as the first baseline code snippet; Extract typical custom code snippets from the software to be analyzed, and use them as the second benchmark code snippets; The first benchmark code snippet and the second benchmark code snippet are merged to construct the benchmark code snippet set.

[0006] As a further improvement of the present invention, the step of extracting typical custom code snippets from the software to be analyzed as a second benchmark code snippet includes: The software to be analyzed is traversed to identify configuration code for the same type of hardware, underlying code with the same sub-functions but different implementation parameters, and public functions whose call frequency exceeds a preset threshold. The identified configuration code, underlying code, and public functions are extracted into independent code segments, which are used as the second base code segment.

[0007] As a further improvement of the present invention, the step of performing similarity analysis between the intermediate file to be analyzed and the benchmark code fragment set, and extracting the target code fragment from the intermediate file to be analyzed, includes: For the first benchmark code segment, the intermediate file to be analyzed is scanned by comparing the code line content. If the content consistency ratio between a certain code segment in the intermediate file to be analyzed and the first benchmark code segment reaches or exceeds the similarity threshold, the code segment is extracted as the target code segment. For the second benchmark code segment, through code semantic comparison and functional structure analysis, code blocks with the same data packaging mechanism or filtering algorithm are extracted from the intermediate file to be analyzed as target code segments.

[0008] As a further improvement of the present invention, the step of performing vulnerability detection on the benchmark code fragment set according to the vulnerability rule set and generating benchmark vulnerability analysis results includes: Based on the vulnerability rule set, a code scanning tool is used to perform a full-coverage static known vulnerability scan on the benchmark code snippet set to generate preliminary screening analysis results. Based on the initial screening analysis results, target baseline code segments with defined risk vulnerabilities were selected. The target benchmark code snippet is dynamically mined using fuzz testing and log monitoring methods, and the benchmark vulnerability analysis results are generated by combining the static scanning results and the dynamic mining results.

[0009] As a further improvement of the present invention, the step of extracting the execution environment feature data of the similar code fragment in the software to be analyzed, and mapping the benchmark vulnerability analysis results to the similar code fragment, includes: Extract the actual runtime scenario parameters and call chain of the similar code fragments in the software to be analyzed, and use them as the execution environment feature data; The vulnerability triggering conditions in the benchmark vulnerability analysis results are matched with the runtime scenario parameters and call chain. If the call chain meets the vulnerability triggering conditions, it is confirmed that there is a target vulnerability in the similar code snippet.

[0010] As a further improvement of the present invention, the step of performing information filtering processing on the software to be analyzed to generate intermediate files to be analyzed includes: Determine the file format of the software to be analyzed; if it is a compressed file, perform decompression. Traverse the decompressed software directory, delete non-code files, remove comments from code files, and output the intermediate file to be analyzed.

[0011] Secondly, the present invention provides a software vulnerability analysis system based on similarity, comprising: The preprocessing module is used to acquire a set of baseline code snippets and a set of vulnerability rules, and to perform information filtering on the software to be analyzed, generating intermediate files to be analyzed. The similarity matching module, which is communicatively connected to the preprocessing module, is used to receive the intermediate file to be analyzed and the set of benchmark code fragments, perform similarity analysis between the intermediate file to be analyzed and the set of benchmark code fragments, extract the target code fragment from the intermediate file to be analyzed, and mark the target code fragment as a similar code fragment. The benchmark analysis module is communicatively connected to the preprocessing module and is used to receive the benchmark code snippet set and the vulnerability rule set, perform vulnerability detection on the benchmark code snippet set according to the vulnerability rule set, and generate benchmark vulnerability analysis results. The vulnerability confirmation module is communicatively connected to the similarity matching module and the benchmark analysis module, respectively. It is used to receive the similar code fragments and the benchmark vulnerability analysis results, extract the execution environment feature data of the similar code fragments in the software to be analyzed, map the benchmark vulnerability analysis results to the similar code fragments, and confirm the vulnerability by combining the execution environment feature data to obtain the final target vulnerability.

[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 similarity-based software vulnerability analysis method 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 regarding the similarity-based software vulnerability analysis method.

[0014] The beneficial effects of this invention are as follows: This invention provides a software vulnerability analysis method based on similarity. It obtains a set of benchmark code fragments and a set of vulnerability rules based on a preset code resource pool and the software to be analyzed. Information filtering is performed on the software to be analyzed to generate intermediate files for analysis, effectively filtering out non-functional code and irrelevant files, reducing data redundancy in subsequent processing. Similarity analysis is performed between the intermediate files and the benchmark code fragment set to extract target code fragments from the intermediate files. These target code fragments are then marked as similar code fragments matching the benchmark code fragment set, achieving convergence of the target code range and avoiding the waste of computational power caused by performing indiscriminate scanning of the entire code set. Vulnerability detection is performed on the benchmark code fragment set according to the vulnerability rule set to generate benchmark vulnerability analysis results, transforming large-scale software vulnerability mining into targeted detection of highly cohesive benchmark code fragments, significantly reducing the computational complexity of vulnerability analysis. Execution environment feature data of similar code fragments in the software to be analyzed is extracted, and the benchmark vulnerability analysis results are mapped to similar code fragments. Vulnerability confirmation is then performed in the software to be analyzed in conjunction with the execution environment feature data to obtain the final target vulnerability. This eliminates the technical defects of false vulnerability reports caused by deviating from actual operating conditions, ensuring the accuracy of vulnerability confirmation results. Therefore, this invention improves vulnerability detection accuracy while reducing computing resource consumption. 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 similarity-based software vulnerability analysis structure diagram in an embodiment of the present invention; Figure 2This is a flowchart of software vulnerability analysis based on similarity in an embodiment of the present invention; Figure 3 This is an internal structural diagram 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 software vulnerability analysis method based on similarity, employing a three-layer architecture, such as... Figure 1 As shown. From bottom to top, the bottom layer is a resource pool of similar software benchmark code snippets and a vulnerability rule set; the second layer analyzes the benchmark code snippets used in the software to be analyzed and extracts and marks similar code snippets for each benchmark code snippet, while using multiple vulnerability analysis methods to perform vulnerability analysis on the benchmark code snippets; the top layer confirms the vulnerability analysis results in the similar code snippets and performs vulnerability remediation.

[0020] The process of the software vulnerability analysis method based on similarity is as follows: Figure 2 As shown, the following is a detailed implementation of the method steps.

[0021] S1. Obtain the benchmark code snippet set and vulnerability rule set, and perform information filtering on the software to be analyzed to generate intermediate files to be analyzed. The benchmark code snippets in the benchmark code snippet set are obtained based on the preset code resource pool and the software to be analyzed.

[0022] In this step, the benchmark code snippet set is a collection of code snippets used for similarity comparison and vulnerability analysis. Benchmark code snippets are code units extracted from complete software code that have relatively independent functions and well-defined code boundaries. Code units can be functions, statement blocks, driver configuration procedures, data processing procedures, data packaging procedures, data parsing procedures, filtering algorithms, control parameter adjustment procedures, or common functions.

[0023] The benchmark code snippets in the benchmark code snippet set include a first benchmark code snippet and a second benchmark code snippet. The first benchmark code snippet is derived from a pre-defined code resource pool, and the second benchmark code snippet is derived from typical custom code snippets in the software to be analyzed.

[0024] A code resource pool is used to store historically reused code snippets generated during software development. These snippets may include startup code, operating system interface code, hardware driver code, communication processing code, data processing code, control code, and common functions. The code resource pool also stores the corresponding function tags, applicable hardware types, applicable software types, development languages, version information, historical vulnerability records, and fix records for each code snippet. Specifically, as an example, a code resource pool is established. The code resource pool stores startup code, operating system interface code, hardware driver code, communication and data processing code, data filtering code, control parameter adjustment code, and common functions generated during software development. Each code resource can be associated with function tags, applicable hardware types, applicable software engineering, development languages, version information, historical vulnerability records, and fix records.

[0025] When extracting historical reused code snippets from the code resource pool, filtering is performed based on code functionality, historical reuse count, applicable hardware type, code integrity, vulnerability analysis status, and remediation status. Code snippets that have completed known vulnerability scanning and vulnerability remediation verification are directly used as baseline code snippets; code snippets that have not yet completed detection using the current vulnerability rule set are used as baseline code snippets to be detected.

[0026] Typical custom code snippets in the software under analysis refer to code snippets written for the hardware configuration, functional requirements, or runtime environment of the software under analysis, and that are representative of the software under analysis. Typical custom code snippets may include configuration code for the same type of hardware, low-level code with the same sub-functions but different implementation parameters, and public functions whose call frequency exceeds a preset threshold.

[0027] Configuration code for similar hardware can include processor peripheral configuration, communication interface configuration, timer configuration, memory configuration, sensor configuration, and device initialization configuration. Low-level code with the same sub-functions but different implementation parameters can include communication data packaging code, communication data parsing code, data filtering code, and control parameter adjustment code. Common functions with a call frequency exceeding a preset threshold reflect the widespread use of the code across multiple functional modules. If vulnerabilities exist in this type of code, they could affect multiple software modules; therefore, it is suitable to include it in a benchmark code snippet set.

[0028] Merging historical reused code snippets from the code resource pool with typical customized code snippets from the software under analysis involves uniformly organizing, deduplicating, classifying, and associating the two types of code snippets to form a baseline code snippet set. During the fusion process, code snippets with the same functionality but different applicable parameters can be retained, and functional correspondences, version correspondences, and hardware compatibility relationships can be established between the code snippets.

[0029] A vulnerability rule set defines the objects, detection conditions, triggering characteristics, risk types, and judgment criteria for vulnerability detection. The vulnerability rule set adopts industry-standard rules for software development and is customized based on the functional characteristics, operational requirements, hardware environment, programming language, and security level of the software to be analyzed. Specifically, the vulnerability rule set includes input validation rules, boundary checking rules, dangerous function call rules, access control rules, resource release rules, exception handling rules, data processing rules, communication security rules, and hardware access security rules. Each vulnerability rule can be associated with a rule name, scope of application, risk level, vulnerability characteristics, triggering conditions, and remediation suggestions.

[0030] Information filtering of the software to be analyzed refers to converting it into intermediate data suitable for subsequent similarity analysis. First, the file format of the software to be analyzed is determined. If the software is a compressed file, it is decompressed to obtain the original software directory and the original file set.

[0031] After decompression, traverse the decompressed software directory and delete non-code files unrelated to vulnerability analysis. Non-code files can include image files, audio files, video files, documentation, compiled files, log files, cache files, temporary files, and version control files.

[0032] After retaining the code files, remove comments, blank lines, and other information that does not participate in code execution and is irrelevant to vulnerability analysis. During information filtering, the mapping relationship between the original file path, file name, original statement line number, and filtered statement line number can be saved simultaneously.

[0033] The intermediate file to be analyzed is a code data file formed after file screening, content filtering, and position mapping. The intermediate file retains valid code statements, function boundaries, statement block relationships, file paths, file names, and line number mapping information. This file is used for subsequent code content comparison, code semantic analysis, and functional structure analysis.

[0034] S2. Perform similarity analysis between the intermediate file to be analyzed and the benchmark code snippet set, extract the target code snippet from the intermediate file to be analyzed, and mark the target code snippet as a similar code snippet that matches the benchmark code snippet set.

[0035] In this step, similarity analysis is used to determine whether the code snippets in the intermediate file to be analyzed have consistency or similarity with the benchmark code snippets in the benchmark code snippet set in terms of code content, code semantics, functional structure, or calling characteristics.

[0036] For the first baseline code snippet derived from the code resource pool, a line-by-line comparison method is used for scanning. First, the first baseline code snippet and the intermediate file to be analyzed are divided into code segments according to function boundaries, statement block boundaries, or preset code windows. Then, code keywords, function calls, variable usage, operators, constants, statement order, and control structures are compared.

[0037] For reusable code where variable names, function names, code format, or some parameters have changed, variable normalization, format normalization, and parameter position identification can be performed before comparison to reduce the impact of non-functional differences on similarity judgment.

[0038] When the content similarity ratio between a code segment in the intermediate file to be analyzed and the first benchmark code segment reaches or exceeds the similarity threshold, the code segment is extracted as the target code segment and marked as a similar code segment. In some embodiments, when a code segment in the software to be analyzed has more than 80% of its lines of code identical to the benchmark code segment, the similarity threshold can be set to 80%.

[0039] The content consistency ratio can be determined based on the ratio between the number of consistent code lines and the total number of valid code lines in the baseline code segment. For comment information and blank line information, the calculation is based on the valid code lines after information filtering. For pre-identified variable parameter positions, parameter semantic comparison can be performed separately, and differences in parameter values ​​are not directly identified as differences in code functionality.

[0040] For the second baseline code segment derived from the software to be analyzed, similar code segments are extracted using code semantic comparison and functional structure analysis. Code semantic comparison is used to determine whether different code expressions achieve the same or similar data processing functions. Functional structure analysis is used to determine whether the input data, processing procedures, output data, control flow, and function call relationships of the code segments have the same or similar characteristics.

[0041] By comparing code semantics and analyzing functional structure, code blocks with the same data packaging mechanism, data parsing mechanism, filtering algorithm, or control parameter adjustment function are extracted from the intermediate files to be analyzed. Even if such code differs in variable names, function names, specific parameters, and statement expressions, as long as their input-output relationship, data flow relationship, control flow relationship, and functional goal are the same or similar, they can be identified as similar code fragments.

[0042] For public functions whose call frequency exceeds a preset threshold, further analysis is conducted on the caller, call conditions, input parameters, return value handling, exception handling methods, and data usage after the call. Through this analysis, it is determined whether the public function performs the same function in different call scenarios and whether the corresponding vulnerability might be triggered in different call chains.

[0043] After extracting the target code snippet, a similarity tag is created for it. This similarity tag can include the base code snippet identifier, similarity type, similarity value, corresponding file path, file name, code start position, code end position, function category, and code version. The similarity tag is used to establish the correspondence between the base code snippet and similar code snippets, providing an index for subsequent mapping of baseline vulnerability analysis results and vulnerability confirmation.

[0044] S3. Perform vulnerability detection on the baseline code snippet set according to the vulnerability rule set, and generate baseline vulnerability analysis results.

[0045] In this step, the benchmark vulnerability analysis results are a comprehensive analysis of the benchmark code snippet set after static vulnerability scanning and dynamic vulnerability discovery.

[0046] Benchmark code snippets typically have a small code size, relatively clear functional boundaries, and high functional cohesion, thus allowing for full-coverage vulnerability testing for each benchmark code snippet.

[0047] Based on a vulnerability rule set, a full-coverage static scan of known vulnerabilities is performed on a set of baseline code snippets using code scanning tools. A full-coverage static scan refers to a complete examination of valid lines of code, functions, statement blocks, data flow, control flow, and function call relationships within the baseline code snippets.

[0048] Code scanning tools can be commercial static analysis tools, rule-driven scanning tools, or dedicated scanning programs built based on vulnerability rule sets. Static known vulnerability scanning can identify vulnerabilities such as missing input validation, array out-of-bounds errors, abnormal pointer usage, unreleased resources, dangerous function calls, integer overflows, missing permission checks, missing exception handling, and other vulnerabilities that can be identified through code characteristics and rule conditions.

[0049] After the static scan is completed, an initial screening analysis result is generated. The initial screening analysis result may include the baseline code snippet identifier, vulnerability rule name, risk type, risk location, risk level, trigger characteristics, associated code lines, and static scan conclusions.

[0050] Based on the initial screening analysis results, target baseline code segments with identified risks are selected. Risk-prone vulnerabilities can be determined based on risk level, vulnerability rule type, static scan reliability, code execution path, device importance, and the scope of vulnerability impact.

[0051] For benchmark code snippets with high risk levels, involving critical functions, or having explicit execution paths, fuzzing is used for dynamic vulnerability discovery. Fuzzing involves inputting mutated test data into the target benchmark code snippet to cover boundary conditions, abnormal inputs, and special execution paths.

[0052] Test data includes random data, boundary data, malformed data, excessively long data, empty data, and structured variant data generated based on the code input interface. The method of generating test data can be determined based on the code input parameter type, interface protocol, data length limit, and historical running data.

[0053] During dynamic testing, a log monitoring method is used to record the runtime status of the target benchmark code segment. The log monitoring content can include function call records, input and output data, exception branches, error codes, memory access status, resource usage, program crash information, and device response status.

[0054] The results of static scanning are correlated and merged with those of dynamic data mining. When static scanning identifies a risk, and dynamic testing can trigger abnormal behavior when the corresponding input and invocation conditions are met, the confirmation level of that risk can be increased. When static scanning identifies a risk but dynamic testing fails to trigger the corresponding anomaly, the risk and its triggering conditions can be retained and marked as a risk to be confirmed.

[0055] The baseline vulnerability analysis results are formed by combining static scanning results and dynamic mining results. The baseline vulnerability analysis results may include vulnerability type, vulnerability rule, vulnerability location, triggering conditions, triggering input, triggering path, impact scope, risk level, dynamic verification status, and remediation suggestions.

[0056] For historically reused code snippets in the code resource pool, if vulnerability analysis results and remediation records already exist, these records can be used as the basis for analysis, and supplementary analysis can be performed based on the current vulnerability rule set. For customized code snippets extracted from the software to be analyzed, both static and dynamic analysis are performed simultaneously based on the current vulnerability rule set.

[0057] S4. Extract the execution environment feature data of similar code snippets in the software to be analyzed, map the baseline vulnerability analysis results to similar code snippets, and combine the execution environment feature data to confirm vulnerabilities in the software to be analyzed, so as to obtain the final target vulnerability.

[0058] In this step, the execution environment characteristic data is used to describe the actual operating conditions and calling relationships of similar code snippets in the software to be analyzed.

[0059] It should be noted that the execution environment characteristic data includes actual runtime scenario parameters, input data source, input data range, call frequency, call conditions, device type, processor architecture, operating system environment, thread environment, task priority, memory resources, network status, configuration parameters, call chain, and related external file content. Actual runtime scenario parameters represent the actual functions performed by similar code snippets and their runtime conditions. Actual runtime scenario parameters can include the startup phase, device initialization phase, data acquisition phase, communication phase, control phase, exception handling phase, and system shutdown phase. The call chain represents the call relationship from the entry function, the upper-level calling function, to the similar code snippet, as well as the relationship between similar code snippets calling other functions, accessing external resources, or reading / writing devices. The call chain can include the caller, the called function, parameter passing relationships, return value processing relationships, conditional branching relationships, and exception handling relationships.

[0060] When extracting execution environment feature data, the file location and code range of similar code fragments in the software to be analyzed are determined based on similarity tags. Then, the actual running scenario parameters and call chain are obtained through static call relationship analysis, configuration file analysis, software running log analysis, and dynamic debugging.

[0061] Mapping benchmark vulnerability analysis results to similar code snippets refers to mapping the vulnerability rules, vulnerability types, vulnerability locations, vulnerability levels, vulnerability triggering conditions, and triggering paths in the benchmark code snippets to similar code snippets in the software to be analyzed, based on the similarity markers established between the benchmark code snippets and similar code snippets.

[0062] The mapping process is implemented based on the correspondence between code lines, statement blocks, function structures, data flows, and call relationships. For code segments where variable names, function names, or parameter names change, mapping can be performed based on code semantics and functional structure.

[0063] After mapping the vulnerability analysis results, the vulnerability triggering conditions in the baseline vulnerability analysis results are matched with the actual running scenario parameters and call chains in the execution environment characteristic data.

[0064] Vulnerability triggering conditions may include specific input data, specific device status, specific call order, specific configuration parameters, specific permission status, specific resource conditions, and specific exception handling paths.

[0065] When the call chain of similar code snippets meets the vulnerability triggering conditions, and the parameters of the actual running scenario are within the applicable range of the vulnerability triggering conditions, it is confirmed that there is a target vulnerability in the similar code snippets.

[0066] When a similar code snippet is similar to a baseline code snippet, but its actual runtime parameters do not meet the vulnerability triggering conditions, or the call chain cannot reach the vulnerability triggering path, the target vulnerability is not directly confirmed. Instead, the code snippet is marked as a similar but unconfirmed vulnerability.

[0067] The final target vulnerability can include the vulnerability name, vulnerability type, vulnerability level, location of similar code snippets, corresponding baseline code snippets, actual operating environment, vulnerability triggering conditions, call chain, confirmation basis, and remediation suggestions. The target vulnerability can also be associated with file paths, file names, code start locations, code end locations, and code context within the software being analyzed.

[0068] Taking a similar serial port driver as an example, the software vulnerability analysis is as follows: The resource library already contains two reference codes for RS422 serial ports for reuse in software development. One is the serial port initialization, data transmission, and reception driver code in RS422 serial port polling mode, and the other is the serial port initialization, data transmission, and reception driver code in interrupt mode. After analyzing the software, customized reference code snippets can be obtained, along with functions for packaging and parsing communication data on different communication lines, and fault detection functions during software startup and operation.

[0069] The baseline code snippet and the software to be analyzed are preprocessed to remove files and content irrelevant to the vulnerability analysis, such as comments and spaces.

[0070] Serial ports are commonly used in embedded software, primarily for software startup program embedding and display, operating system board-level configuration to support operating system startup, and hardware driver configuration to enable communication between the application software and the software. The serial port driver code in the resource library is compared line-by-line with the source code in the startup program, operating system board-level configuration, and driver configuration. If the number of lines with identical content exceeds 80% of the total number of lines in the baseline code, the code is considered similar, and similar code is stored in a table or linked list.

[0071] Customized communication data packaging and parsing are primarily configured in the driver software. Depending on project needs, the driver software configures communication data packaging and parsing functions for multiple communication buses such as serial ports, 1553 buses, and CAN buses. Although the same communication bus transmits different data, and the communication hardware differs, resulting in variations in data packet content and length, common fields for data packaging and parsing, such as heartbeat data, data length, data header, data end marker, and data packet verification information, use the same methods. This means the data transmission protocol is consistent, and the data packaging and parsing functions in different software modules are similar, thus they are saved as similar code. Additionally, other serial port driver configurations used in embedded software, such as the 16c552 serial port configuration, may differ in register configuration and code lines, but they can be categorized as similar serial port code based on their function.

[0072] Vulnerability analysis was performed on the benchmark code snippets. Commercial tools were used to scan all benchmark code snippets for violations of GJB8114 rules. Fuzz testing was conducted on various data packets constructed by data communication packet assembly and parsing functions. The use of arrays and pointers in the benchmark code snippets was dynamically monitored to analyze for data out-of-bounds errors and memory leaks. The lines of code operating on large data spaces in the benchmark code snippets, such as the space operation functions memset and memcpy, were analyzed in depth to identify potential space overlap or memory overlap vulnerabilities. Different vulnerability analysis methods were flexibly adopted according to the characteristics of the software.

[0073] Based on the vulnerability analysis of the RS422 driver code and data communication process, we confirmed whether similar vulnerabilities existed in code similar to the benchmark code and fixed them. The confirmation process required considering the software context and operating scenario. For example, if a vulnerability existed where variable output formatting was incorrect, it was directly modified synchronously in similar software. Vulnerabilities such as the driver software's loop for querying hardware status without a maximum loop count required analysis of the usage scenario. In the software startup program, a serial port loop is set to wait for HMI input; a maximum loop count is not needed here. However, when communicating between devices in the driver software, considering the high real-time requirements of embedded software, a maximum waiting time for serial port data reception needs to be set to avoid excessively long loop wait times and prevent infinite loops caused by hardware status errors. Other vulnerabilities were analyzed, confirmed, and fixed individually as needed.

[0074] The above implementation method completes a software vulnerability analysis method based on baseline similarity, which performs vulnerability analysis on reusable code and customized benchmark code respectively, and confirms vulnerabilities in other similar code as appropriate.

[0075] Example 2 This embodiment provides a software vulnerability analysis system based on similarity, which specifically includes the following modules: The preprocessing module is used to acquire a set of baseline code snippets and a set of vulnerability rules, and to perform information filtering on the software to be analyzed, generating intermediate files to be analyzed. The similarity matching module, which is connected to the preprocessing module, is used to receive the intermediate file to be analyzed and the set of benchmark code fragments, perform similarity analysis between the intermediate file to be analyzed and the set of benchmark code fragments, extract the target code fragment from the intermediate file to be analyzed, and mark the target code fragment as a similar code fragment. The benchmark analysis module, which communicates with the preprocessing module, is used to receive the benchmark code snippet set and the vulnerability rule set, perform vulnerability detection on the benchmark code snippet set according to the vulnerability rule set, and generate benchmark vulnerability analysis results. The vulnerability confirmation module communicates with the similarity matching module and the benchmark analysis module respectively. It is used to receive similar code snippets and benchmark vulnerability analysis results, extract the execution environment feature data of similar code snippets in the software to be analyzed, map the benchmark vulnerability analysis results to similar code snippets, and combine the execution environment feature data to confirm the vulnerability and obtain the final target vulnerability.

[0076] For specific limitations regarding the similarity-based software vulnerability analysis system, please refer to the limitations of the similarity-based software vulnerability analysis method described above. The corresponding technical effects can be obtained equally and will not be repeated here. Each module in the aforementioned similarity-based software vulnerability analysis system 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.

[0077] Example 3 Figure 3 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 3 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 stored 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 similarity-based software vulnerability analysis method. 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 mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0078] As will be understood by those skilled in the art, computer equipment Figure 3 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.

[0079] 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.

[0080] 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.

[0081] In summary, the embodiments of this application provide a software vulnerability analysis method, system, computer device, and storage medium based on similarity. The method obtains historical reused code fragments from a preset code resource pool and extracts typical customized code fragments from the software to be analyzed. The two types of code fragments are merged to form a baseline code fragment set, while simultaneously obtaining a vulnerability rule set. The software to be analyzed is decompressed, non-code files are deleted, and irrelevant information is filtered to generate an intermediate file for analysis.

[0082] Furthermore, a similarity analysis is performed between the intermediate files to be analyzed and the benchmark code snippet set. For historically reused code snippets, similar code snippets are identified by comparing line content; for typical customized code snippets, code semantic comparison and functional structure analysis are used to identify code snippets with the same or similar functions, and a correspondence between benchmark code snippets and similar code snippets is established.

[0083] Based on the vulnerability rule set, a full-coverage static known vulnerability scan is performed on the benchmark code snippet set. Fuzz testing and log monitoring are then applied to the selected high-risk benchmark code snippets. The static scan results and dynamic mining results are merged to form the benchmark vulnerability analysis results. Finally, the actual runtime scenario parameters and call chains of similar code snippets in the software under analysis are extracted. The vulnerability triggering conditions in the benchmark vulnerability analysis results are matched with the execution environment characteristic data. When the call chain and runtime scenario are confirmed to meet the triggering conditions, the existence of a target vulnerability in the similar code snippet is determined.

[0084] Compared to technical solutions that perform complete vulnerability analysis line by line on the entire software, this application reduces the repeated detection of the same or similar code by using a baseline code fragment reuse mechanism, thereby reducing the workload of large-scale software vulnerability analysis.

[0085] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. 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.

[0086] 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 software vulnerability analysis method based on similarity, characterized in that, include: A set of benchmark code snippets and a set of vulnerability rules are obtained, and information filtering is performed on the software to be analyzed to generate an intermediate file to be analyzed. The benchmark code snippets in the set of benchmark code snippets are obtained based on a preset code resource pool and the software to be analyzed. The intermediate file to be analyzed is compared with the set of benchmark code snippets. The target code snippet is extracted from the intermediate file to be analyzed and marked as a similar code snippet that matches the set of benchmark code snippets. Vulnerability detection is performed on the benchmark code snippet set according to the vulnerability rule set, and benchmark vulnerability analysis results are generated. The execution environment feature data of the similar code snippets in the software to be analyzed is extracted, and the benchmark vulnerability analysis results are mapped to the similar code snippets. The vulnerability is then confirmed in the software to be analyzed in combination with the execution environment feature data to obtain the final target vulnerability.

2. The software vulnerability analysis method based on similarity according to claim 1, characterized in that, The acquisition of the benchmark code snippet set includes: Extract historical reused code snippets from a pre-defined code resource pool as the first baseline code snippet; Extract typical custom code snippets from the software to be analyzed, and use them as the second benchmark code snippets; The first benchmark code snippet and the second benchmark code snippet are merged to construct the benchmark code snippet set.

3. The software vulnerability analysis method based on similarity according to claim 2, characterized in that, The step of extracting typical custom code snippets from the software to be analyzed as the second benchmark code snippet includes: The software to be analyzed is traversed to identify configuration code for the same type of hardware, underlying code with the same sub-functions but different implementation parameters, and public functions whose call frequency exceeds a preset threshold. The identified configuration code, underlying code, and public functions are extracted into independent code segments, which are used as the second base code segment.

4. The software vulnerability analysis method based on similarity according to claim 1, characterized in that, The step of performing similarity analysis between the intermediate file to be analyzed and the benchmark code fragment set, and extracting the target code fragment from the intermediate file to be analyzed, includes: For the first benchmark code segment, the intermediate file to be analyzed is scanned by comparing the code line content. If the content consistency ratio between a certain code segment in the intermediate file to be analyzed and the first benchmark code segment reaches or exceeds the similarity threshold, the code segment is extracted as the target code segment. For the second benchmark code segment, through code semantic comparison and functional structure analysis, code blocks with the same data packaging mechanism or filtering algorithm are extracted from the intermediate file to be analyzed as target code segments.

5. The software vulnerability analysis method based on similarity according to claim 1, characterized in that, The step of performing vulnerability detection on the benchmark code snippet set according to the vulnerability rule set and generating benchmark vulnerability analysis results includes: Based on the vulnerability rule set, a code scanning tool is used to perform a full-coverage static known vulnerability scan on the benchmark code snippet set to generate preliminary screening analysis results. Based on the initial screening analysis results, target baseline code segments with defined risk vulnerabilities were selected. The target benchmark code snippet is dynamically mined using fuzz testing and log monitoring methods, and the benchmark vulnerability analysis results are generated by combining the static scanning results and the dynamic mining results.

6. The software vulnerability analysis method based on similarity according to claim 5, characterized in that, The step of extracting the execution environment feature data of the similar code fragments in the software to be analyzed, and mapping the benchmark vulnerability analysis results to the similar code fragments, includes: Extract the actual runtime scenario parameters and call chain of the similar code fragments in the software to be analyzed, and use them as the execution environment feature data; The vulnerability triggering conditions in the benchmark vulnerability analysis results are matched with the runtime scenario parameters and call chain. If the call chain meets the vulnerability triggering conditions, it is confirmed that there is a target vulnerability in the similar code snippet.

7. The software vulnerability analysis method based on similarity according to claim 1, characterized in that, The process of filtering information in the software to be analyzed to generate intermediate files for analysis includes: Determine the file format of the software to be analyzed; if it is a compressed file, perform decompression. Traverse the decompressed software directory, delete non-code files, remove comments from code files, and output the intermediate file to be analyzed.

8. A software vulnerability analysis system based on similarity, characterized in that, include: The preprocessing module is used to acquire a set of baseline code snippets and a set of vulnerability rules, and to perform information filtering on the software to be analyzed, generating intermediate files to be analyzed. The similarity matching module, which is communicatively connected to the preprocessing module, is used to receive the intermediate file to be analyzed and the set of benchmark code fragments, perform similarity analysis between the intermediate file to be analyzed and the set of benchmark code fragments, extract the target code fragment from the intermediate file to be analyzed, and mark the target code fragment as a similar code fragment. The benchmark analysis module is communicatively connected to the preprocessing module and is used to receive the benchmark code snippet set and the vulnerability rule set, perform vulnerability detection on the benchmark code snippet set according to the vulnerability rule set, and generate benchmark vulnerability analysis results. The vulnerability confirmation module is communicatively connected to the similarity matching module and the benchmark analysis module, respectively. It is used to receive the similar code fragments and the benchmark vulnerability analysis results, extract the execution environment feature data of the similar code fragments in the software to be analyzed, map the benchmark vulnerability analysis results to the similar code fragments, and confirm the vulnerability by combining the execution environment feature data to obtain the final target vulnerability.

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 that, when executed by the processor, implements the similarity-based software vulnerability analysis method 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 as described in any one of claims 1 to 7.

Images