A source code security vulnerability identification method and device

Abstract

The application discloses a source code security vulnerability identification method and device, and relates to the field of electronic data processing, which comprises the following steps: obtaining a code attribute graph of a source code and dividing the code attribute graph into a plurality of graph blocks; calling a target graph block and a target graph block associated graph block to load into a memory; if an abnormal loading occurs, based on a loading network exception judgment result, evaluating the graph block and performing a corresponding operation; and judging whether a potential security vulnerability exists in a code segment. The application pre-processes the source code into a code attribute graph and divides the code attribute graph into graph blocks, thereby realizing modularized analysis. Based on hardware performance parameters, a cache strategy and a writing mode are dynamically adjusted, so that resource reasonable allocation is guaranteed. Multidimensional screening is performed on syntax nodes, a network state judgment and an automatic repair mechanism are introduced, and the overall process takes into account efficiency and fault tolerance, thereby providing an intelligent and high-robustness solution for a large-scale source code vulnerability identification task.

Description

Technical Field

[0001] This invention relates to the field of electronic data processing, specifically to a method and apparatus for identifying source code security vulnerabilities. Background Technology

[0002] As software systems become increasingly complex, security vulnerabilities in source code have gradually become a significant threat to system stability and information security. However, traditional methods lack sufficient fault tolerance for abnormal blocks, and the integrity and robustness of the overall detection task can be affected by the corruption of a single node or subgraph. Furthermore, traditional methods rely heavily on manual judgment and maintenance when identifying source code vulnerabilities, which is extremely time-consuming and labor-intensive. Therefore, intelligent identification of code security vulnerabilities has become a major research direction in current cybersecurity technology.

[0003] Existing technologies, such as the invention patent with announcement number CN117592061B, are source code security detection methods and devices that integrate code vulnerability features and attribute graphs. This involves constructing a CVE vulnerability keyword library, extracting features from known software vulnerability libraries and the vulnerable program to be detected, performing similarity judgments, capturing the semantic information of the program code, and constructing a semantic feature learning graph neural network model based on an attention mechanism (GNN) to focus on code syntax nodes with vulnerability feature keywords. The device includes a CVE vulnerability feature keyword library generation module, a code attribute graph vulnerability feature keyword marking module, a code structure semantic feature extraction module, and a vulnerability detection module.

[0004] Existing technologies, such as the invention patent with publication number CN111338692B, are vulnerability classification methods, devices, and electronic devices based on vulnerability codes, applied in the field of text classification technology. The method includes: acquiring vulnerability codes to be classified and related information of the vulnerability codes to be classified, and then identifying and analyzing the acquired vulnerability codes to be classified and related information based on a pre-trained neural network model to obtain vulnerability classification result information of the vulnerability codes.

[0005] As can be seen from the above solutions, the mainstream source code security vulnerability identification methods in existing technologies mainly include rule-based static analysis methods and pattern matching-based scanning tools. These methods can identify typical vulnerabilities to a certain extent by parsing the code syntax structure and combining it with a known vulnerability rule base for matching and detection. In addition, some deep learning-based source code semantic analysis methods have improved the ability to model code semantics to some extent, but they suffer from problems such as heavy memory load, low graph computation efficiency, and difficulty in cross-module analysis in large-scale code projects. Therefore, the need for a method that supports fine-grained management of large-scale code graphs while ensuring analysis efficiency has become an urgent technical problem to be solved in this field. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a method and apparatus for identifying source code security vulnerabilities. To achieve the above objectives, this invention employs the following technical solution: A method for identifying source code security vulnerabilities, comprising:

[0007] The source code is preprocessed to obtain a code attribute graph, which is then divided into several blocks.

[0008] Execute vulnerability detection tasks, obtain the target tile directory corresponding to the task and load the target tiles into memory, at the same time obtain the associated tiles of the target tiles and load them into memory, count the number of times each tile is loaded in real time, and cache the tiles whose loading count exceeds the preset loading threshold locally.

[0009] If a loading error occurs during tile loading, an error judgment is performed on the loading network. If the error judgment result is that the loading network is abnormal, the network is repaired and loading is re-executed. If the error judgment result is that the loading network is not abnormal, the tile is evaluated to determine whether it is a critical tile, and the corresponding operation is performed based on the critical tile evaluation result.

[0010] The loaded graph tiles are fed into a graph neural network to encode the syntax nodes and edges, extract vector features that can be used for classification, and then fed into a deep learning model to determine whether the code snippet has potential security vulnerabilities.

[0011] The present invention also provides an apparatus for implementing the above method.

[0012] Compared with the prior art, the embodiments of the present invention have at least the following beneficial effects:

[0013] (1) This invention provides a source code security vulnerability identification method, which effectively improves system operating efficiency and scalability through modular structure partitioning and resource-aware adaptive loading mechanism. By extracting and fusing abstract syntax trees, control flow graphs, and data flow graphs from the source code, a unified code attribute graph is constructed, and further divided into multiple logical graph blocks according to function-level units, so that the entire analysis process has clear structural boundaries and stronger modular organization. By introducing a graph block caching and loading count statistics mechanism, frequently accessed high-reusability graph blocks can be dynamically identified and cached first, reducing redundant I / O operations. At the same time, combined with the real-time performance parameters of the storage hardware, the cache size, writing method, and trigger threshold can be dynamically adjusted according to the current running state, thereby avoiding performance bottlenecks such as excessive system load or memory overflow, and significantly improving overall processing efficiency and system stability.

[0014] (2) This invention improves the targeting and robustness of vulnerability detection by introducing a multi-dimensional parameter syntax node screening mechanism and critical path judgment logic. During the syntax node screening process, static attributes and dynamic behavioral characteristics are comprehensively considered. Database verification parameters are used for bidirectional comparison and correction coupling to accurately screen critical nodes with potential vulnerability semantics, thereby improving the semantic density of the graph structure expression and the model recognition efficiency. In the abnormal loading handling stage, multiple parameters such as function call level, call frequency, number of shared variables, and propagation path are introduced to evaluate the importance of graph blocks, automatically determining whether they belong to a critical path, and accordingly performing skip, placeholder, or repair loading operations, effectively avoiding unnecessary fault propagation and ensuring the robust execution of the main process.

[0015] (3) This invention enhances system resilience and fault tolerance through the synergy of anomaly identification and automatic repair strategies. When anomalies occur during tile loading, a rapid diagnosis is performed using network status parameters and a lookup table to distinguish whether the network loading is abnormal, and the anomaly type can be further refined. Based on a preset mapping strategy of "anomaly type - repair method - repair parameters", the most suitable repair method and corresponding parameters can be automatically selected to complete the adaptive network recovery and tile reloading process. In addition, for the repair process of critical tiles, a repair embedding factor mechanism is introduced to achieve dynamic coupling between repair strength and tile importance, thereby improving system recovery efficiency while ensuring detection integrity. If the repair still fails, placeholder information is automatically output to ensure that the model input structure is not destroyed, effectively improving the continuity of vulnerability detection tasks and the system's self-healing ability.

[0016] Of course, any product implementing this invention does not necessarily need to achieve all of the above advantages at the same time. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0018] Figure 2 This is a schematic diagram of the method logic of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In the description of this invention, it should be understood that the terms "opening", "upper", "lower", "thickness", "top", "middle", "length", "inner", "around", etc., which indicate orientation or positional relationship, are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the components or elements referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as limiting this invention.

[0021] Please see Figure 1 and Figure 2 As shown, this embodiment of the invention provides a method for identifying source code security vulnerabilities, including:

[0022] The source code is preprocessed to obtain a code attribute graph, which is then divided into several blocks.

[0023] The source code undergoes lexical analysis and syntax parsing to extract the abstract syntax tree, control flow graph, and data flow graph, and a code property graph is constructed. The specific process includes:

[0024] The ANTLR tool is used to convert code text into meaningful lexical units (tokens), including keywords, identifiers, constants, operators, delimiters, etc. The tokens are then combined into an abstract syntax tree (AST) according to the language grammar rules (such as EBNF). The grammar nodes of the tree represent the grammatical structure, and the edges represent the structural relationships.

[0025] Based on the statement blocks and control statements in the AST, the LLVM IR tool is used to divide the data into basic blocks, determine the jump paths in the control structure, such as conditional jumps, loop back edges, and exception branches, and construct a control flow graph composed of syntax nodes (basic blocks) and edges (jump relationships). The output control flow graph (CFG) is as follows: syntax nodes are basic blocks, and edges are control jump paths.

[0026] Traverse the AST and CFG, use the LLVM passes tool to analyze the definition (def) and use (use) of each variable, construct directed edges from the "variable definition point" to the "variable use point", and output the data flow graph DFG: the syntax nodes are variable-related statements, and the edges are data dependencies (e.g., x=a+b;→print(x); there is a def-use edge for x).

[0027] The Joern tool was used to standardize the naming and encoding of syntax nodes. All syntax nodes in AST, CFG, and DFG were assigned a unified ID and attributes. The syntax node sets were merged, and all syntax nodes, variable syntax nodes, and control syntax nodes in the three types of graphs were integrated into a global graph. The types of the three types of edges were preserved and labeled. Attribute labels (such as type, scope, function, and whether it is an entry point) were added to each syntax node. A heterogeneous graph was constructed to support multiple types of syntax nodes and multiple edge relationships.

[0028] In the code attribute graph, each function is identified as a code unit, denoted as a function-level unit. Information about each function-level unit is collected, including filenames and internal function definitions. For each function-level unit, its abstract syntax tree is traversed to extract the corresponding syntax nodes. After filtering the syntax nodes, a syntax structure subgraph for each function-level unit is constructed. The specific process includes:

[0029] Traverse the constructed set of CPG syntax nodes, find syntax nodes with function definition attributes, extract meta-information such as the file name of the function, function name, and function start and end positions, and treat each function definition syntax node as a function-level unit.

[0030] Starting from each function-level unit, traverse the AST subtree downwards, collect all its subordinate syntax nodes, including variable declarations, control statements, expressions, and function calls, and exclude invalid or redundant structures such as empty syntax nodes, comment syntax nodes, and macro syntax nodes, and output the set of syntax nodes for each function-level unit.

[0031] The specific process for filtering syntax nodes is as follows:

[0032] Obtain the quantization parameters of the attribute value distribution for each syntax node, including frequency statistics, length distribution, and information entropy.

[0033] It should be noted that the frequency count (Statistical Frequency) represents the number of times a function or tile appears in the current function or tile. Joern is used to count the frequency of each syntax node in the CPG.

[0034] Length distribution represents the statistical distribution of character length or structural depth within a syntax node. It is used to assess the complexity or unusual characteristics of syntax node content (such as whether variable names are unusually short or expressions are unusually deeply nested). It is obtained by extracting the character length of each syntax node using Joern.

[0035] Information entropy is derived by modeling the uncertainty of the distribution of a certain type of attribute value using the entropy function from information theory. It measures the randomness or diversity of syntactic attribute values; high entropy indicates a more dispersed distribution, while low entropy indicates a concentrated or homogeneous distribution. It is calculated by establishing a frequency distribution for a specific attribute using Python and NumPy.

[0036] Obtain the dynamic change parameters of the attributes of each syntax node, including the lifespan, the amount of change in syntax node weight, and the number of cross-block migrations.

[0037] It should be noted that the Lifetime Span refers to the span of code from the first definition of a syntax node to its last reference or use. It reflects the continued influence of a syntax node within the semantic path. The span is calculated using Joern and data flow edge analysis tools.

[0038] Node weight drift refers to the magnitude of change in the weights of a syntax node during graph propagation or model learning (similar to the activation values ​​of an embedding vector in a neural network) across different stages or contexts. It is used to quantify the stability of syntax nodes; nodes exhibiting dramatic changes may be functional syntax nodes or key control points. It is obtained using DGL tools.

[0039] Cross-Block Transition Count refers to the number of other blocks in which a given syntax node is indirectly or directly referenced or called. It reflects the node's "cross-unit propagation capability" and is used to identify global coupling points such as shared variables and public functions. It is obtained through analysis using a graph index table.

[0040] Extract attribute value distribution quantization verification parameters from the database, including frequency statistics verification value, length distribution verification value, and information entropy verification value.

[0041] Extract dynamic attribute change quantification verification parameters from the database, including lifecycle verification span, syntax node weight change verification amount, and cross-block migration verification count.

[0042] The attribute value distribution quantization parameters of each syntax node are compared one-to-one with the attribute value distribution quantization verification parameters. The attribute dynamic change quantization parameters of each syntax node are also compared one-to-one with the attribute dynamic change quantization verification parameters. The comparison results are then corrected and coupled to obtain the attribute feature quantization values ​​of each syntax node. Specifically, this includes:

[0043] ;

[0044] in, For the first The quantized value of the attribute features of each syntax node. For the first Frequency statistics of each syntax node For the first The length distribution values ​​of each syntax node For the first The information entropy value of each syntax node. For the first The lifecycle span of a syntax node. For the first The change in the weight of each syntax node. For the first Number of cross-block migrations for each syntax node This is a frequency statistics check value. For length distribution check values, This is the information entropy verification value. To validate the lifecycle span, This is the validation value for changes in the weight of syntax nodes. Number of cross-block migration checks Weighting factors for frequency statistics, Weighting factors for the length distribution values, Weighting factors for information entropy values, Weighted factors based on lifecycle span, Weighting factors for the changes in the weights of syntax nodes. The weighted factor for the number of cross-block migrations. Number the syntax nodes. , This represents the total number of syntax nodes.

[0045] It should be noted that, in order to reasonably measure the contribution of different grammatical node attributes to the comprehensive feature score, the system introduces six weighting factors, corresponding to two main categories: static distribution features and dynamic behavioral features. The role of the weighting factors is to unify multi-source heterogeneous features into quantitative indicators, making the obtained quantitative values ​​of grammatical node attribute features more accurate.

[0046] Regarding static attributes, the frequency statistics weighting factor controls the influence of the frequency of grammatical nodes on the scoring model. This factor adjusts the weight distribution to ensure that high frequency does not lead to misjudgment of semantic core. The length distribution weighting factor adjusts the degree to which the complexity of grammatical node attribute length reflects importance, preventing abnormally short or long structures from being overemphasized or ignored. The information entropy weighting factor measures the contribution of the diversity of grammatical node attribute values ​​to the semantic complexity score.

[0047] Regarding dynamic behavior, the lifecycle span weighting factor controls the contribution of the syntax node's active time during the code execution cycle to its criticality. The syntax node weight change weighting factor is used to adjust the degree of influence of changes in the semantic embedding of the syntax node, reflecting the syntax node's sensitivity to or representational ability to contextual changes. The cross-block migration count weighting factor adjusts the contribution of the syntax node to the global coupling evaluation when it is referenced by multiple blocks or functions. Overall, the weighting factors strengthen or weaken the role of specific parameters in the calculation of attribute feature quantification values.

[0048] It's also important to note that the quantification parameters for the attribute value distribution of each syntax node, including frequency statistics, length distribution, and information entropy, are correlated. While these three parameters appear independent in static source code analysis, they exhibit significant correlation and complementarity in actual analysis. Frequency statistics reflect the frequency of a syntax node's appearance in the block, representing the commonality or reusability of its structure. Typically, high-frequency syntax nodes are repeatedly used in the program and have strong basic semantic support. Length distribution focuses on the structural complexity of the syntax node's ontological attributes, such as the character length of variable names or expressions, reflecting the conciseness or excessive verbosity of the code. Information entropy assesses the diversity of syntax node attribute values ​​from a global distribution perspective. Unlike frequency, it doesn't measure the frequency of a single value but focuses on the overall uncertainty and dispersion of the distribution. High information entropy usually means that the syntax node assumes a more complex semantic or behavioral role. These three parameters are not linearly correlated statistically but exhibit a weakly correlated structural coupling. These three parameters together constitute a three-dimensional evaluation system of structural commonness, content complexity, and distribution diversity, which has good complementarity and non-redundancy.

[0049] The dynamic changes in the attributes of each syntax node are quantified by parameters including lifespan, weight change, and number of cross-block transitions. These parameters are interconnected and, in source code graph modeling and dynamic feature analysis, collectively describe the active characteristics and evolutionary behavior of syntax nodes in the code execution path, semantic propagation process, and cross-function scope, exhibiting correlation and information complementarity. Lifespan represents the active range of a syntax node in the program structure; the greater the logical distance between definition and reference, the stronger the continuity of the syntax node in the control flow, typically assuming a more complex or global semantic role. Weight change originates from the dynamic update of the syntax node embedding vector during graph neural network training, reflecting the semantic sensitivity and learning intensity of the syntax node in the context. If a syntax node exhibits significant embedding changes in different contexts or iteration stages, it usually indicates that it has participated in critical path propagation or exhibits semantic instability. There is an inherent relationship among these three factors. For example, syntax nodes with long lifecycles tend to have a higher probability of cross-block migration because they survive longer in multiple control structures and are easily referenced by different function call chains. On the other hand, syntax nodes that frequently migrate across blocks have more diverse semantic environments and are therefore more likely to exhibit higher weight changes in graph neural networks. In other words, lifecycle span represents activity in the time dimension, weight changes represent dynamic fluctuations in the semantic dimension, and the number of cross-block migrations reflects the dependency and extensibility in the structural dimension.

[0050] The attribute feature quantization value of each syntax node is compared with the attribute feature quantization threshold pre-stored in the database. If the attribute feature quantization value of a syntax node is greater than or equal to the attribute feature quantization threshold, then the syntax node is included in the syntax structure subgraph construction set.

[0051] If the attribute feature quantization value of a certain syntax node is less than the attribute feature quantization threshold, then the syntax node is included in the ordinary syntax set and does not participate in the construction of the syntax structure subgraph of the function-level unit.

[0052] Extract the edge relationships in the syntax structure subgraph of each function-level unit, and retain the connection edges between syntax nodes within each function-level unit, including control dependency edges, data dependency edges, and syntax structure edges.

[0053] It should be noted that control dependency edges express control paths (such as if control statements), and the extraction method is to identify control syntax nodes from the AST and establish edges between the control structure and the syntax nodes it affects; data dependency edges express data relationships of variable def-use (such as x=1; y=x+1, indicating that x and y have a dependency relationship), and the extraction method is to perform variable scope analysis on the syntax nodes and establish def-use edges between variable definition syntax nodes and variable usage syntax nodes; syntax structure edges express syntax nesting and hierarchy, and the extraction method is to traverse the AST subtree and construct directed edges between parent and child syntax structures.

[0054] For cross-unit call relationships within each function-level unit, cross-block edges are established, linking the source syntax node and the target syntax node. Specifically, this includes:

[0055] For cross-function calls within a function (i.e., one function calls another), the graphs of the two functions cannot be directly merged. Cross-tile edges are marked with a reference marker on the syntax node where the call occurred, indicating the unique identifier of the target function. When subsequent analysis requires the complete path or data propagation, the tiles corresponding to the called function are loaded and stitched together.

[0056] Export and store the syntax structure subgraphs of each function-level unit as tiles in a standard graph data format.

[0057] After the structure is built, the tiles for each function are exported as standard graph data formats for easy storage, loading, and subsequent use. Common standard graph data formats include JSON graph format (suitable for structured storage and parsing), GraphML (suitable for graph databases such as Neo4j), or edge lists (suitable for graph computation frameworks such as DGL). Each tile file contains function identifiers, a list of syntax nodes, edge relationships and their types, and cross-tile references.

[0058] Execute vulnerability detection tasks, obtain the target tile directory corresponding to the task and load the target tiles into memory, at the same time obtain the associated tiles of the target tiles and load them into memory, count the number of times each tile is loaded in real time, and cache the tiles whose loading count exceeds the preset loading threshold locally.

[0059] The target tile directory refers to the location of the main function or main module analyzed by the current vulnerability detection task within the graph database or tile storage structure. The specific retrieval process is as follows:

[0060] When performing vulnerability detection tasks, the task input information is parsed, and one or more target function names are used as entry points (such as the function parse_json() in "src / utils / parse_json.c").

[0061] Each tile has a unique identifier. A mapping relationship between the unique identifier and the function name is established through an index table. By inputting the function name, the target tile can be quickly located.

[0062] Related tiles refer to other tiles that have a direct or indirect dependency on the current target tile. They can be obtained as follows:

[0063] Starting from the core function node in the target tile, perform a search to obtain the called and caller functions adjacent to the core function node in the target tile at a preset depth. Input the names of each obtained function node into a unique identifier-function name mapping relationship to obtain the associated tiles.

[0064] Loaded into memory, specifically including:

[0065] Obtain real-time performance parameters of the storage hardware, including real-time available memory, real-time disk write rate, and real-time memory swap frequency.

[0066] It's important to note that real-time available memory refers to the amount of physical memory that is currently unused and can be immediately used for program execution or cache allocation. This parameter includes truly free memory as well as reclaimable cache pages. During tile loading, temporary subgraph objects need to be built in memory and graph computation algorithms need to be run. Insufficient real-time available memory may cause loading failure.

[0067] Real-time disk write rate refers to the actual speed at which the system writes data to the disk (usually an SSD / HDD) per unit of time, commonly measured in MB / s. It reflects the current disk I / O bandwidth usage. Operations such as tile export, logging, error reporting, and cache writing to disk all rely on disk write capability. A low write rate indicates that the disk is currently under high load or experiencing congestion.

[0068] Memory swapping frequency refers to the frequency at which data pages are swapped out of memory to the swap partition or restored from the swap partition to memory. Frequent swapping activity indicates high physical memory pressure. A high swapping frequency usually means that the storage hardware is "running at full capacity," passively moving data to disk to maintain memory load, which can cause "memory thrashing" in severe cases.

[0069] Extract the maximum performance parameters of the storage hardware from the database, including minimum available memory, maximum disk write rate, and maximum memory swap frequency.

[0070] The storage hardware's real-time performance parameters are compared with its maximum performance capacity parameters. If any of the following conditions are met, such as real-time available memory being less than or equal to minimum available memory, real-time disk write rate being greater than or equal to maximum disk write rate, or real-time memory swapping frequency being greater than or equal to maximum memory swapping frequency, the storage process demand adjustment procedure is initiated.

[0071] If none of the three conditions are met, the data will be loaded directly into memory.

[0072] This design achieves dynamic perception and adaptive adjustment of the underlying resource status during tile loading by comparing the real-time performance parameters of the storage hardware with preset maximum capacity parameters. Its core function is to pre-assess the memory and I / O load of the storage hardware before loading tiles, thereby avoiding loading failures, performance degradation, or abnormal system interruptions due to resource constraints. Specifically, it extracts three hardware capacity thresholds from the database: minimum available memory, maximum disk write rate, and maximum memory swap frequency, and obtains the available memory, disk write rate, and memory swap frequency of the storage hardware in real time. If the current available memory is detected to be lower than the minimum memory threshold, it indicates that the storage hardware may face the risk of insufficient memory; if the disk write rate exceeds the maximum capacity value, it indicates that the I / O channel is congested; and an abnormally high memory swap frequency is a clear signal of excessive pressure on the storage hardware.

[0073] When any of the above conditions is triggered, the system will immediately enter the "stored procedure demand adjustment process" to protect the main process from interruption and ensure the overall system stability and successful completion of the detection task. If all three indicators are within the safe range, the target tile can be directly loaded into memory for subsequent analysis tasks. Through this mechanism, the system can flexibly adjust resource usage strategies when facing different operating environments and load states, achieving a highly available and elastic vulnerability detection process.

[0074] The stored procedure requirement adjustment process includes:

[0075] Extract the difference between the real-time performance parameters and the maximum performance capacity parameters of the storage hardware that meets the conditions. Based on the memory difference between the real-time available memory and the minimum available memory, input the difference into the pre-stored memory difference-cache size upper limit mapping set in the database to obtain the cache size upper limit of the storage hardware and apply it.

[0076] Based on the difference between the real-time disk write rate and the maximum disk write rate, the difference is entered into a pre-stored mapping set of rate difference-write method in the database for mapping matching to obtain the memory-mapped write method, and then applied.

[0077] It should be noted that the writing methods in this embodiment of the invention include synchronous writing, asynchronous writing, and degraded writing. When the disk load is high, a more moderate writing method is selected to reduce I / O pressure, such as asynchronous writing and degraded writing.

[0078] Based on the difference between the real-time memory swap frequency and the maximum memory swap frequency, the swap frequency difference is entered into a pre-stored mapping set in the database that is a minimum trigger tile size for memory mapping. The mapping is then matched to obtain the minimum tile size that triggers memory mapping and applied.

[0079] It should be noted that a high memory swapping frequency indicates frequent use of virtual memory. By adjusting the memory mapping trigger threshold, larger tiles can be prioritized for memory mapping, thereby reducing frequent memory swapping and improving stability.

[0080] If a loading error occurs during tile loading, an error judgment is performed on the loading network. If the error judgment result is that the loading network is abnormal, the network is repaired and loading is re-executed. If the error judgment result is that the loading network is not abnormal, the tile is evaluated to determine whether it is a critical tile, and the corresponding operation is performed based on the critical tile evaluation result.

[0081] Perform anomaly detection on network loading, specifically including:

[0082] Obtain network status parameters of the loaded network, including network connection latency, packet loss rate, response time, and bandwidth utilization.

[0083] The network status parameter lookup table is retrieved from the database. The network status parameters of the loaded network are matched with the anomaly judgment conditions of each network status parameter in the network status parameter lookup table to obtain the corresponding anomaly judgment results of the loaded network. Table 1 below shows the network status parameter lookup table involved in the embodiment of the present invention.

[0084] Table 1 Network Status Parameter Comparison Table

[0085]

[0086] If a certain network state parameter of the loaded network meets the corresponding anomaly judgment condition in the network state parameter lookup table, then the anomaly judgment result of the loaded network is that the loaded network is abnormal.

[0087] If none of the network state parameters of the loaded network meet the corresponding anomaly judgment conditions in the network state parameter lookup table, then the anomaly judgment result of the loaded network is an anomaly of the unloaded network.

[0088] After repair, the loading process will be re-executed, specifically including:

[0089] The network state parameters that meet the anomaly judgment conditions in the network state parameter lookup table are statistically loaded and recorded as network anomaly state parameters. The anomaly representation type corresponding to each network anomaly state parameter is extracted.

[0090] Based on each anomaly representation type, an index is performed in the mapping set table of anomaly representation type-repair method, as shown in Table 2 below, which is the mapping set table involved in the embodiment of the present invention. The repair method corresponding to each anomaly representation type is obtained. At the same time, the difference between the network anomaly state parameter and the preset threshold in the corresponding anomaly judgment condition is obtained and put into the mapping set of the difference-repair parameter of the corresponding repair method for mapping matching to obtain the repair parameter of the repair method corresponding to the anomaly representation type. After the loaded network is repaired, the loading is re-executed.

[0091] Table 2 Mapping Set Table

[0092]

[0093] If a loading error still occurs during the loading process, a warning will be issued.

[0094] To determine whether a tile is a critical tile, the specific processing conditions are as follows:

[0095] Obtain the function call layer number, function call allocation frequency, number of shared variables, and number of core variable propagation paths for this plot.

[0096] It's important to note that the function call depth refers to the maximum depth of the function contained in this block within the entire program's call graph; that is, the length of the deepest call chain from the main function (e.g., main) to this function. A deeper depth generally indicates that the function is more dependent on other function calls.

[0097] Function Dispatch Frequency (SDF) represents the frequency with which a function in a given block is called or scheduled by other functions during program execution. It can be derived from static call counts or runtime profiling statistics.

[0098] The Shared Variable Count indicates how many variables (such as global variables, static variables, and objects passed by reference / pointer) are used or modified by functions or statement blocks within this block and shared with other blocks. The Shared Variable Count indicates the degree of data coupling between this block and external blocks. It is obtained by analyzing the Abstract Syntax Tree (AST) and scope table to identify nodes that use global variables, static variables, or reference variables from external modules; constructing a Data Flow Dependency Graph (DFG) for these variables; and counting the number of variables accessed by all modules outside this function.

[0099] Key Variable Propagation Paths (KPPPaths) represent the number of valid paths taken by core variables involved in a block, such as configuration items, user input, and key state variables, from definition to use, especially cross-function and cross-block propagation paths. It describes the breadth and complexity of variable propagation throughout the program.

[0100] Extract the minimum number of call layers, minimum call frequency, minimum number of shared variables, and minimum number of propagation paths of core variables of key functions from the database.

[0101] The function call layer number, function call allocation frequency, number of shared variables, and number of core variable propagation paths of this tile are compared one by one with the minimum call layer number, minimum call allocation frequency, minimum number of shared variables, and minimum number of core variable propagation paths of the key function. The comparison results are then corrected and coupled to obtain the key tile score for this tile, specifically including:

[0102] ;

[0103] in, Scoring the key tiles of the map. The function call level of the tile. Assign frequencies to function calls on tiles. The number of shared variables for the tile. The core variable of the plot is the number of propagation paths. This represents the minimum call level for the critical function. Assign the minimum call frequency to critical functions. The minimum number of shared variables for a key function. Minimum number of paths for propagation of core variables in critical functions. Add a weighting factor to the number of function call levels. Assign frequency weighting factors to function calls. Weighting factor for the number of shared variables. The weighted factor for the number of propagation paths of the core variable.

[0104] It should be noted that the core function of the weighting factors—function call layer weighting factor, function call allocation frequency weighting factor, shared variable quantity weighting factor, and key variable propagation path weighting factor—is to introduce adjustable strategy bias weights to various tile attributes. The function call layer weighting factor measures the weight strength of the "depth" of a function within the call path in the criticality assessment. The function call allocation frequency weighting factor represents the proportion of the influence of function call frequency on the overall risk score. The shared variable quantity weighting factor reflects the weight of the degree to which a tile shares data with other tiles in the risk analysis. The key variable propagation path weighting factor measures the influence coefficient of the number of propagation paths for key variables (such as configuration, input, and state variables) in the key path score.

[0105] It's also worth noting that there's a correlation between the parameters of function call depth, function call frequency, number of shared variables, and number of core variable propagation paths in the call graph. Function call depth and function call frequency together characterize the structural position and behavioral frequency of a function within the call graph. Frequently called functions often participate in multiple contexts and may rely more heavily on shared variables (such as global variables or cross-function state variables) to maintain state consistency. This indicates that high-frequency functions have a larger potential area of ​​side effects. Functions located deeper in the graph are often where key variables are ultimately processed or converged; therefore, variable propagation paths tend to concentrate in these deeper graph tiles.

[0106] If the critical tile score of a tile is greater than or equal to the preset critical tile score threshold in the database, then the critical tile evaluation result of the tile is a critical tile.

[0107] If the critical tile score of a tile is less than the preset critical tile score threshold in the database, then the critical tile evaluation result of the tile is a non-critical tile.

[0108] Based on the key tile evaluation results, corresponding operations are performed, specifically including:

[0109] If the key block evaluation result of the map block is a key block, then the key block score of the map block is extracted, and the difference between the key block score and the key block score threshold is calculated to obtain the key block score difference of the map block. This difference is then mapped and matched with the pre-stored key block score difference minus the repair embedding factor in the database to obtain the repair embedding factor of the map block. The repair embedding factor is then applied to the automatic repair algorithm to repair the map block. After the repair is completed, the loading is re-executed. If a loading error still occurs during the loading process, an early warning is issued.

[0110] It should be noted that, in this embodiment of the invention, the automatic repair algorithm is a graph structure completion algorithm. Its principle is to infer and fill in the missing edges and nodes of the graph based on existing nodes and edges. The repair embedding factor is an adjustable parameter used to control the degree of information filling and the tightness of structure fitting in the repair algorithm. When performing graph repair, this factor is passed as a hyperparameter to the model. If the repair embedding factor is high, a more lenient approach to graph structure completion will be adopted, such as allowing the insertion of fuzzy nodes and the reconstruction of weakly connected edges. If the factor is low, it tends to strictly maintain the original structure, with the repair operation aiming for minimal perturbation and prioritizing accuracy.

[0111] If the evaluation result of a key plot of a graph is a non-key plot, the loading process of that plot is skipped, and it is output to the graph neural network as a placeholder.

[0112] Placeholder methods are used to maintain the structural integrity and dimensionality consistency of the graph neural network input. Specific forms include:

[0113] Empty node and edge sets are generated, creating an empty subgraph with a structure corresponding to the original graph tiles (e.g., 0 nodes, 0 edges, or only node IDs without attribute values). This ensures dimension alignment during graph convolution and does not affect the overall computation process. Placeholder graph tiles are labeled for identification and tracking by subsequent model interpretation layers or anomaly analysis modules.

[0114] The loaded graph tiles are fed into a graph neural network to encode the syntax nodes and edges, extract vector features that can be used for classification, and then fed into a deep learning model to determine whether the code snippet has potential security vulnerabilities.

[0115] After the graph tiles are loaded, they are fed into a graph neural network for vectorized encoding of nodes and edges to extract feature representations that can be used for security vulnerability identification.

[0116] All syntax nodes in the graph are standardized, including uniformly encoding the syntax type, variable category, scope position, and other attributes of each node, to generate an initial node vector representation.

[0117] At the same time, the type of each edge is labeled, including syntactic structure edges, data dependency edges, and control dependency edges, so that they can be used as input factors for relational semantics during subsequent propagation in the graph neural network.

[0118] Based on graph neural network frameworks (such as GCN, GAT, or GGNN), the graph structure undergoes multiple rounds of iterative propagation. In each round, a node updates its vector by incorporating information from its neighbors and its own attributes. This process is typically accomplished jointly using aggregation functions (such as averaging or weighted attention) and update functions (such as multilayer perceptrons). After multiple rounds of iteration, each node's embedding vector will contain its local contextual structure and semantic information.

[0119] After node representation learning is completed, the vectors of all nodes are aggregated at the graph level to generate a global vector representation of a graph patch. The aggregation method used in this embodiment is global average pooling, and this vector can be considered as the semantic representation of the graph patch in a high-dimensional space. This graph patch vector is then input into a deep learning classifier, such as a multilayer perceptron (MLP), bidirectional LSTM, or a Transformer-based structure, to determine whether the code snippet contains potential security vulnerabilities.

[0120] Ultimately, the deep learning model outputs a result that includes whether a vulnerability exists, the specific type of vulnerability (such as buffer overflow, XSS, SQL injection, etc.), a vulnerability confidence score, and optional code line markers.

[0121] In this embodiment, the present invention provides an apparatus to implement the above-described method.

[0122] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0123] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to specific implementation methods. Clearly, many modifications and variations can be made based on the content of this specification. The selection and detailed description of these embodiments in this specification are intended to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. Any modifications or variations that do not deviate from the structure of the invention or exceed the scope defined by the invention should fall within the protection scope of the invention.

Claims

1. A method for identifying source code security vulnerabilities, characterized in that, include: The source code is preprocessed to obtain a code attribute graph, which is then divided into several blocks. Execute vulnerability detection tasks, obtain the target tile directory corresponding to the task and load the target tiles into memory, at the same time obtain the associated tiles of the target tiles and load them into memory, count the number of times each tile is loaded in real time, and cache the tiles whose loading count exceeds the preset loading threshold locally; If a loading error occurs during tile loading, the loading network is checked for error. If the error check result is that the loading network is abnormal, the network is repaired and loading is re-executed. If the error check result is that the loading network is not abnormal, the tile is evaluated to determine whether it is a critical tile, and the corresponding operation is performed based on the critical tile evaluation result. The loaded graph tiles are fed into a graph neural network to encode the syntax nodes and edges, extract vector features that can be used for classification, and then fed into a deep learning model to determine whether the code snippet has potential security vulnerabilities. The specific processing conditions for evaluating whether a map block is a critical map block are as follows: Obtain the function call layer number, function call allocation frequency, number of shared variables, and number of core variable propagation paths for this plot; Extract the minimum number of call layers, minimum call frequency, minimum number of shared variables, and minimum number of propagation paths of core variables of key functions from the database. The function call layer, function call allocation frequency, number of shared variables, and number of core variable propagation paths of the plot are compared one by one with the minimum call layer, minimum call allocation frequency, minimum number of shared variables, and minimum number of core variable propagation paths of the key function. The comparison results are then corrected and coupled to obtain the key plot score of the plot. If the critical tile score of a tile is greater than or equal to the preset critical tile score threshold in the database, then the critical tile evaluation result of the tile is a critical tile; If the critical tile score of a tile is less than the preset critical tile score threshold in the database, then the critical tile evaluation result of the tile is a non-critical tile. The operation based on the key tile evaluation results specifically includes: If the key block evaluation result of the map block is a key block, then the key block score of the map block is extracted, and the difference between the key block score and the key block score threshold is obtained. This difference is then mapped and matched with the pre-stored key block score difference minus the repair embedding factor in the database to obtain the repair embedding factor of the map block. The repair embedding factor is then applied to the automatic repair algorithm to repair the map block. After the repair is completed, the loading is re-executed. If a loading error still occurs during the loading process, an early warning is issued. If the evaluation result of a key plot of a graph is a non-key plot, the loading process of that plot is skipped, and it is output to the graph neural network as a placeholder.

2. The source code security vulnerability identification method according to claim 1, characterized in that: The process of preprocessing the source code to obtain a code attribute map, and then dividing the code attribute map into several blocks, is as follows: Lexical analysis and syntax parsing are performed on the source code to extract the abstract syntax tree, control flow graph, and data flow graph, and a code property graph is constructed. In the code property graph, each function is identified as a code unit and denoted as a function-level unit. Information of each function-level unit is collected, including file name and internal function definition. For each function-level unit, its abstract syntax tree is traversed, the corresponding syntax nodes are extracted, and after filtering the syntax nodes, the syntax structure subgraph of each function-level unit is constructed. Extract the edge relationships in the syntax structure subgraph of each function-level unit, and retain the connection edges between syntax nodes within each function-level unit, including control dependency edges, data dependency edges, and syntax structure edges; For cross-unit call relationships within each function-level unit, establish cross-block edges to link the calling source syntax node with the called target syntax node; Export and store the syntax structure subgraphs of each function-level unit as tiles in a standard graph data format.

3. The source code security vulnerability identification method according to claim 2, characterized in that: The specific process of filtering syntax nodes is as follows: Obtain the quantization parameters of the attribute value distribution for each syntax node, including frequency statistics, length distribution, and information entropy. Obtain the dynamic change parameters of the attributes of each syntax node, including the lifespan, the amount of change in the weight of the syntax node, and the number of cross-block migrations; Extract attribute value distribution quantization verification parameters from the database, including frequency statistics verification value, length distribution verification value, and information entropy verification value; Extract dynamic attribute change quantification verification parameters from the database, including lifecycle verification span, syntax node weight change verification amount, and cross-block migration verification count; The attribute value distribution quantization parameter of each syntax node is compared one by one with the attribute value distribution quantization verification parameter. The attribute dynamic change quantization parameter of each syntax node is compared one by one with the attribute dynamic change quantization verification parameter. The comparison results of each parameter are corrected and coupled to obtain the attribute feature quantization value of each syntax node. The attribute feature quantization value of each syntax node is compared with the attribute feature quantization threshold pre-stored in the database. If the attribute feature quantization value of a syntax node is greater than or equal to the attribute feature quantization threshold, then the syntax node is included in the syntax structure subgraph construction set. If the attribute feature quantization value of a certain syntax node is less than the attribute feature quantization threshold, then the syntax node is included in the ordinary syntax set and does not participate in the construction of the syntax structure subgraph of the function-level unit.

4. The source code security vulnerability identification method according to claim 1, characterized in that: The loading into memory specifically includes: Obtain real-time performance parameters of the storage hardware, including real-time available memory, real-time disk write rate, and real-time memory swap frequency; Extract the maximum performance parameters of the storage hardware from the database, including minimum available memory, maximum disk write rate, and maximum memory swap frequency; The real-time performance parameters of the storage hardware are compared with the maximum performance capacity parameters. If any of the following conditions are met, such as real-time available memory being less than or equal to minimum available memory, real-time disk write rate being greater than or equal to maximum disk write rate, or real-time memory exchange frequency being greater than or equal to maximum memory exchange frequency, the storage process demand adjustment process will be initiated. If none of the three conditions are met, the data will be loaded directly into memory.

5. The source code security vulnerability identification method according to claim 4, characterized in that: The process for adjusting the demand for entering a stored procedure specifically includes: Extract the difference between the real-time performance parameters and the maximum performance capacity parameters of the storage hardware that meets the conditions. Based on the memory difference between the real-time available memory and the minimum available memory, input the difference into the memory difference-cache size upper limit mapping set pre-stored in the database to obtain the cache size upper limit of the storage hardware and apply it. Based on the difference between the real-time disk write rate and the maximum disk write rate, the difference is entered into a pre-stored mapping set of rate difference-write method in the database for mapping matching to obtain the memory-mapped write method, and then applied. Based on the difference between the real-time memory swap frequency and the maximum memory swap frequency, the swap frequency difference is entered into a pre-stored mapping set in the database that is a minimum trigger tile size for memory mapping. The mapping is then matched to obtain the minimum tile size that triggers memory mapping and applied.

6. The source code security vulnerability identification method according to claim 1, characterized in that: The anomaly detection for the loaded network specifically includes: Obtain network status parameters of the loaded network, including network connection latency, packet loss rate, response time, and bandwidth utilization. Retrieve the network status parameter lookup table from the database, match the network status parameters of the loaded network with the anomaly judgment conditions of each network status parameter in the network status parameter lookup table, and obtain the corresponding anomaly judgment results of the loaded network. If a certain network state parameter of the loaded network meets the corresponding abnormal judgment condition in the network state parameter lookup table, then the abnormal judgment result of the loaded network is that the loaded network is abnormal. If none of the network state parameters of the loaded network meet the corresponding anomaly judgment conditions in the network state parameter lookup table, then the anomaly judgment result of the loaded network is an anomaly of the unloaded network.

7. The source code security vulnerability identification method according to claim 1, characterized in that: The reloading process after network repair specifically includes: The network state parameters that meet the anomaly judgment conditions in the network state parameter lookup table are statistically loaded and recorded as network anomaly state parameters. The anomaly representation type corresponding to each network anomaly state parameter is extracted. Based on each anomaly representation type, an index is performed in the mapping set table of anomaly representation type-repair method to obtain the repair method corresponding to each anomaly representation type. At the same time, the difference between the network anomaly state parameter and the preset threshold in the corresponding anomaly judgment condition is obtained and put into the mapping set of the difference-repair parameter of the corresponding repair method for mapping matching to obtain the repair parameter of the repair method corresponding to the anomaly representation type. After the loaded network is repaired, the loading is re-executed. If a loading error still occurs during the loading process, a warning will be issued.

8. An apparatus for identifying source code security vulnerabilities using any one of claims 1-7, characterized in that: The device has one or more programs, which are executed by one or more processors to implement the above method.

Images