Software source code vulnerability detection method, device and system

Abstract

The invention relates to the technical field of code vulnerability detection, in particular to a software source code vulnerability detection method, device and system, and the method comprises the steps: obtaining an abstract syntax tree of a source code stream, and calculating the syntax depth of each statement in a source code; determining the data flow importance of each statement based on the connection condition of the corresponding edge of each statement in the data flow diagram of the statement in the source code; determining a correlation score of each statement; matching and identifying a high-risk statement in the source code, and determining a local window scale of the high-risk statement; for source codes in the local window of the high-risk statement, determining the attention weight of each token to obtain a context condensation vector of the local window, and screening from all the tokens of the local window to obtain a priority position list; and calculating a self-adaptive threshold value of the local window so as to judge the vulnerability probability of the code snippets in the local window, and performing sandbox verification on the high-risk vulnerability by utilizing the priority position list. Therefore, the source code vulnerability detection accuracy is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of code vulnerability detection, in particular to a software source code vulnerability detection method, device and system. BACKGROUND

[0002] Software source code vulnerability detection refers to a process of scanning, modeling and verifying source code or binary code by static testing, dynamic testing, symbolic execution or machine learning, etc. without running or running the program, so as to find security defects that may be exploited by attackers, including SQL injection, buffer overflow, command execution, privilege escalation, etc. The core goal is to locate the pre-aggregation, path or data flow that violates the security policy or has abnormal behavior in the code, and give risk level, repair suggestion and verification use case, so as to reduce the attack surface before software release and improve system security and reliability.

[0003] Static testing is to scan the source code to find vulnerabilities without running the program, which is fast and can intervene early, but has high false positives and cannot capture runtime vulnerabilities; dynamic testing can find runtime vulnerabilities with low false positives by fuzzing, dynamic taint or interactive IAST, but is slow and depends on hardware and simulation success rate. By pre-training a large model, a context semantic embedding is generated using a pre-trained encoder such as CodeBERT and RoBERTa, and a lightweight classification head can detect complex vulnerabilities across files and languages.

[0004] However, when the traditional pre-trained large model directly detects source code vulnerabilities, there is a problem of long-short contradiction of input. The standard input of the large model is 512 tokens, while the vulnerability often spans dozens of lines of code or even multiple files, and simple truncation will destroy the grammatical integrity and cause false negatives. There is also context noise redundancy, and the large model also gives attention to irrelevant statements, which dilutes the embedding vector with safe repeated code, making it difficult to determine the detection threshold and resulting in high false positives. Traditional methods use a uniform threshold for Web, firmware and CLI projects, which may result in false positives on the Web side and serious false negatives on the firmware side. SUMMARY

[0005] To solve the above technical problems, the purpose of the present application is to provide a software source code vulnerability detection method, device and system, and the technical solutions adopted are as follows: In a first aspect, the present application provides a software source code vulnerability detection method, which comprises the following steps: An abstract syntax tree of the source code stream is acquired, and a syntax depth of each statement in the source code is calculated; based on a connection of edges corresponding to each statement in a data flow graph of the source code, data flow importance of each statement is determined; An influence range of each statement in the source code in an execution process controlled by a conditional branch is analyzed, control dependency span of each statement is determined, and relevance scores of each statement are determined in combination with the syntax depth, the data flow importance, and components of each statement; High-risk statements in the source code are matched and recognized, and a local window scale of the high-risk statements is determined based on the relevance scores of the high-risk statements and a positional relationship of the high-risk statements in the abstract syntax tree; For source code in a local window of the high-risk statements, a distance of each token from a center of the window is analyzed, and position freshness of each token is determined; an attention weight of each token is determined by relevance of a word vector after coding of each token and an identifier vector corresponding to the local window, in combination with the relevance score of a statement where each token is located and the position freshness of each token, so as to acquire a context concise vector of the local window, and a priority position list is filtered and acquired from all tokens in the local window; An adaptive threshold of the local window is calculated based on the context concise vector of the local window, so as to determine a vulnerability probability of a code fragment in the local window, and a high-risk vulnerability is verified by a sandbox by using the priority position list.

[0006] In one of the embodiments, the syntax depth is a ratio of a number of edges between each statement node in the abstract syntax tree and a root node to a maximum value of the number of edges in all statement nodes; The data flow importance is that a total number of in-edges and out-edges connected by edges of each statement in a data flow graph of the source code is counted as a degree of each statement, and the data flow importance of each statement is a ratio of the degree of each statement to a maximum value of degrees of all statements in the data flow graph.

[0007] In one of the embodiments, the control dependency span of each statement is determined by: A control flow graph (CFG) is generated by using the abstract syntax tree of the source code stream, a control dependency chain length of each statement is calculated by a control dependency algorithm, and the control dependency span of each statement is obtained by comparing the control dependency chain length of each statement to a maximum value of control dependency chain lengths of all statements.

[0008] In one of the embodiments, the relevance score of each statement is determined by: If there is a known dangerous function and instruction in any statement, an identifier sensitivity of the any statement is marked as 1, otherwise, the identifier sensitivity is marked as 0, and the relevance score of each statement is a fusion result of the syntax depth, the data flow importance, the control dependency span, and the identifier sensitivity.

[0009] In one embodiment, the local window size of the high-risk statement is determined, comprising: The window size expansion amount of the high-risk statement is calculated, and the expression is: ; wherein, is the window size expansion amount of the i-th high-risk statement, max[] is the maximum value function, ceil() is the rounding up function, is the relevance score of the i-th statement, is the preset expansion threshold, is the preset maximum expansion line number; The local window size of the high-risk statement is the sum of the preset initial candidate width and twice the window size expansion amount, wherein the high-risk statement is centered in the local window.

[0010] In one embodiment, the position freshness of each token is determined, comprising: The absolute value of the difference between the line number of each token and the center line number of the local window in which it is located is calculated, and the ratio of the absolute value to the total number of lines of the local window in which each token is located is calculated, denoted as the first ratio. The position freshness of each token is the difference between the natural number 1 and the first ratio.

[0011] In one embodiment, the attention weight of each token is determined, comprising: The [CLS] vector output by the projection mapping of the encoding of the first segment of the local window is obtained, the similarity between the word vector after encoding of each token and the query vector is calculated, the weighted sum result of the relevance score of the statement in which each token is located and its position freshness is calculated, and the attention weight of each token is the sum of the weighted sum result and the similarity, wherein the weight of the position freshness of each token is greater than the weight of the relevance score of the statement in which each token is located. The context condensation vector of the local window is obtained, and the priority position list is obtained from all tokens in the local window, comprising: calculating the product of the word vector after encoding of each token and its attention weight, and the normalized value of the product of all tokens in the local window is used to form the context condensation vector of the local window; all tokens in the local window are arranged in descending order according to their attention weights, and the first preset percentage of tokens are used to form the priority position list.

[0012] In one embodiment, the vulnerability probability of the code snippet in the local window is determined, comprising: The mean of the absolute values of all elements in the context condensation vector of the local window is calculated, the multiplication result of the normalized value of the mean and the maximum decrease of the preset threshold value is calculated, and the adaptive threshold value is the difference between the preset basic threshold value and the multiplication result. The vulnerability probability of code snippets within a local window is obtained using a neural network model. If the vulnerability probability is greater than or equal to the adaptive threshold of the local window, the code in the local window is marked as a high-risk vulnerability and sandbox verification is initiated; otherwise, it is marked as a low-risk vulnerability. The sandbox verification of high-risk vulnerabilities using a priority location list includes: injecting three payloads, representing low risk, medium risk, and high risk, in the order of the tokens in the priority location list as injection points; if an anomaly is triggered, it is confirmed as a high-risk vulnerability; otherwise, it is marked for manual review.

[0013] Secondly, embodiments of this application also provide a software source code vulnerability detection device, the device storing a computer program, which, when executed by a processor, implements the steps of any of the above-described software source code vulnerability detection methods.

[0014] Thirdly, embodiments of this application also provide a software source code vulnerability detection system, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of any of the methods described above.

[0015] This application has at least the following beneficial effects: This application improves statement structure sensitivity by calculating the syntactic depth of each statement based on an abstract syntax tree, quantifying the nesting degree and structural complexity of statements, thus helping to prioritize the location of hidden defects that are more easily overlooked due to complex structures. It also enhances the ability to identify data dependency vulnerabilities by determining the data flow importance of each statement and measuring the connection strength between statements and other nodes in the data flow graph. Determining the control dependency span enhances the accuracy of conditional branch impact measurement. Determining the relevance score of each statement improves the ranking accuracy of dangerous statements and enhances the ability to distinguish high-risk statements. Furthermore, by determining the local window scale of high-risk statements based on their relevance scores and their positional relationship in the abstract syntax tree, it helps to adaptively determine the scope of code analysis in terms of both syntax and context, enhancing the ability to select appropriate contexts under different coding styles or module boundaries. This avoids the problems of insufficient context or excessive interference caused by fixed windows, improving the accuracy of subsequent representation and judgment based on relevant context. This solves the distortion and noise problems caused by the "one-size-fits-all" window strategy. By automatically expanding or shrinking to obtain the smallest complete semantic block, the system can preserve the complete data flow while meeting the input constraints of large models, thus improving the adaptive ability of high-risk statement context selection. Furthermore, by introducing explicit weighted attention based on structural importance and positional freshness, the weight of high-risk statements is increased, which can effectively improve the signal-to-noise ratio of the context condensation vector, significantly reduce the false positive rate, and enhance the ability to assign greater weight to tokens that are close to high-risk statements and have stronger semantic relevance. This helps to suppress the interference of irrelevant tokens on the judgment and solves the semantic dilution problem caused by treating all tokens equally, thereby avoiding the situation where background noise reduces the accuracy of vulnerability identification. By dynamically adjusting the adaptive threshold, the system can achieve adaptive judgment of high-risk items and low-risk items during code vulnerability detection. This allows the judgment criteria to be dynamically adjusted with the context semantics and structural complexity, which helps to maintain a low false positive / false negative rate in high-noise or low-sample environments. This solves the performance degradation problem of fixed thresholds when applied across projects, thereby improving the detection rate of unknown risk vulnerabilities while maintaining lightweight performance. By utilizing a priority location list for sandbox verification, the ability to combine static suspicious results with a dynamic verification closed loop is enhanced. Driving a controlled sandbox verification process through the priority location list helps to reproduce and confirm high-risk vulnerabilities in an isolated environment, solving the problem of difficulty in determining the authenticity of static analysis results. At the same time, it avoids the risk of directly triggering potential dangers in the production environment, improving the credibility and security of the overall vulnerability remediation decision. Ultimately, this application improves the accuracy of source code vulnerability detection. Attached Figure Description

[0016] To more clearly illustrate the technical solutions and advantages in the embodiments of this application 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 only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating the steps of a software source code vulnerability detection method provided in one embodiment of this application; Figure 2 Flowchart for determining adaptive thresholds for code vulnerability detection. Detailed Implementation

[0018] To further illustrate the technical means and effects adopted by this application to achieve the intended inventive purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a software source code vulnerability detection method, apparatus, and system proposed in this application. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined in any suitable form.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0020] The following description, in conjunction with the accompanying drawings, details the specific scheme of the software source code vulnerability detection method, apparatus, and system provided in this application.

[0021] Please see Figure 1 The diagram illustrates a flowchart of a software source code vulnerability detection method according to an embodiment of this application. The method includes the following steps: S1: Obtain the abstract syntax tree of the source code flow and calculate the syntax depth of each statement in the source code; based on the connection of the corresponding edges of each statement in its data flow graph, determine the data flow importance of each statement.

[0022] This embodiment analyzes the original source code. The vulnerability trigger chain in the source code often spans multiple statements, branches, or functions. Traditional source code vulnerability detection directly truncates syntax units by using a fixed number of lines or a 512-token sliding window. This results in large models only obtaining incomplete control flow or data flow when performing source code vulnerability detection, thus missing logical defects or context-sensitive vulnerabilities.

[0023] Therefore, this embodiment first performs syntax analysis on the source code flow to generate an Abstract Syntax Tree (AST), a Data Flow Graph (DFG), and a Call Graph (CG). The generation of the AST, DFG, and CG are all existing well-known techniques, and the specific steps will not be elaborated further. The AST is represented by nodes, each node including node type, start and end row numbers, column numbers, and a list of child nodes; the DFG is represented by a triplet edge list, each triple including variables. exist The location is defined, in The location is used; the calling graph CG is represented by a list of edges, where each edge represents a point from the caller to the callee.

[0024] Secondly, the syntax depth of each statement in the source code is calculated. The specific calculation process is as follows: the ratio of the number of edges between each statement node and the root node in the abstract syntax tree to the maximum value of the number of edges in all statement nodes is used as the syntax depth of each statement. The syntax depth can quantify the nesting level of each statement in the abstract syntax tree. The greater the syntax depth, the more likely it is to be inside a critical control branch or complex expression, and the more likely it is to be highly related to the logic that triggers the vulnerability.

[0025] Furthermore, the data flow importance of each statement is calculated. Specifically, the total number of incoming and outgoing edges connecting each statement in the source code's data flow graph is counted, and this count is used as the degree of each statement. The data flow importance of each statement is the ratio of its degree to the maximum degree of all statements in the data flow graph. Data flow importance measures the degree to which each statement participates in the definition and use of variables. A higher degree indicates that it is more likely to be at the center of data propagation, and the greater the possibility of pollution or injection vulnerabilities.

[0026] S2, analyze the scope of influence of conditional branches during the execution of each statement in the source code, determine the control dependency span of each statement, and determine the relevance score of each statement by combining the syntax depth, the importance of the data flow, and the components of each statement.

[0027] Based on the scope of influence of conditional branches during the execution of each statement in the source code, the control dependency span of each statement is calculated. Specifically, a control flow graph (CFG) is generated using the abstract syntax tree of the source code flow. The length of the control dependency chain for each statement is calculated using a control dependency algorithm, and then divided by the maximum length of the control dependency chains of all statements to obtain the control dependency span of each statement. In this embodiment, the control dependency algorithm is the Ferrante algorithm. The control dependency span reflects the scope of influence of conditional branches on each statement. The longer the span, the more branches its execution is constrained by, and the easier it is for attackers to change the execution path with malicious input.

[0028] Analyze the components of each statement to see if it contains any known dangerous functions or instructions, such as eval, strcpy, or system. If any statement contains a known dangerous function or instruction, increase the prior probability of the vulnerability and mark the identifier sensitivity of that statement as 1; otherwise, mark it as 0.

[0029] The syntactic depth, data flow importance, control dependency span, and identifier sensitivity of each statement are fused together, and the fusion result is used as the relevance score of each statement.

[0030] It should be noted that fusion means combining multiple variables, which can be calculated by adding, averaging, weighted summing, etc. This embodiment does not limit this.

[0031] In this embodiment, in the absence of prior knowledge or training data, the contribution of the syntax depth, data flow importance, control dependency span, and identifier sensitivity to the vulnerability is considered equally important, and an equal-weighted average is performed to obtain the relevance score of each statement, thereby avoiding the introduction of arbitrary bias coefficients. That is, the average of the syntax depth, data flow importance, control dependency span, and identifier sensitivity of each statement is used as the relevance score of each statement.

[0032] In another embodiment, if the project is a web application, the weights of the syntax depth, the data flow importance, the control dependency span, and the identifier sensitivity are set to 0.2, 0.25, 0.15, and 0.4, respectively, and the weighted sum of the syntax depth, the data flow importance, the control dependency span, and the identifier sensitivity of each statement is used as the relevance score of each statement.

[0033] S3 identifies high-risk statements in the source code, determines the local window scale of the high-risk statements based on their relevance scores and their positional relationship in the abstract syntax tree.

[0034] Furthermore, potential risky statements in the source code are identified as high-risk statements through simple rule matching. In this embodiment, high-risk statements include: function names such as eval, exec, system, strcpy, memcpy, scanf, and gets; SQL concatenation symbols such as "+" or "." for concatenating SQL strings; dynamic code generation such as Reflection, Expression, and Function constructors; file path concatenation such as open(user_input + ".txt"); and deserialization operations such as pickle.loads and JSON.parse. Components of untrusted input are also considered high-risk statements.

[0035] In the abstract syntax tree of the source code flow, taking high-risk statements as the center, the initial candidate width of the local window for high-risk statements is set to 3 rows, namely the row containing the high-risk statement, the row before the high-risk statement, and the row after the high-risk statement. Next, the expansion amount of the local window size is calculated using the relevance score of the high-risk statement and a preset expansion threshold, with the following formula: In the formula, Let `max[]` be the window size expansion amount for the i-th high-risk statement, `max[]` be the maximum value function to avoid negative expansion amounts, and `ceil()` be the floor function. The relevance score for the i-th statement is... The preset extension threshold ranges from 0.2 to 0.6; in this embodiment, it is set to 0.4. The maximum number of rows to be expanded is preset, ranging from 8 to 30 rows; in this embodiment, it is set to 15 rows. The implementer can set the initial candidate width according to the actual situation; this embodiment does not impose any restrictions on this.

[0036] Furthermore, within the abstract syntax tree (AST), the local window for high-risk statements is expanded according to the syntax boundary rules. Specifically, taking the i-th high-risk statement as an example, with the i-th high-risk statement as the center, the local window is extended to both ends based on the initial candidate width and the AST node boundaries. If an incomplete statement, expression, or block is encountered during the expansion process, it continues to expand outwards until a complete statement, a complete if / else / for / while block, or a function boundary is reached, ensuring that semantics are not interrupted. If the rows of two local windows overlap by more than 50%, they are merged into one window.

[0037] Secondly, if a high-risk statement exists within a function, and that function is identified as an externally reachable function by the call graph CG (e.g., web routing, CLI command processing, firmware interrupt service routines), then when called, the local window of the high-risk statement is extended upwards to the caller of the function. First, the set of callers of the function is obtained in the call graph CG. For each call edge, if the caller and function are not in the same file, the edge is ignored. If they are in the same file, the entire caller function is merged into the local window of the high-risk statement, but not exceeding the maximum extension line. .

[0038] At this point, the dimensions of the local windows for each high-risk statement in the source code can be obtained.

[0039] S4. For the source code within the local window of high-risk statements, analyze the distance between each token and the center of the window to determine the positional freshness of each token; by the correlation between the word vector encoded by each token and the identifier vector corresponding to the local window, and by combining the relevance score of the statement in which each token is located with its positional freshness, determine the attention weight of each token to obtain the contextual condensation vector of the local window, and filter out the priority position list from all tokens in the local window.

[0040] Since the length of the local window for different high-risk statements varies and may exceed 512 tokens, this embodiment segments the local window of the high-risk statement, dividing the code within the local window into several semantically complete sub-segments to meet the input constraints of the large model. At the same time, some boundaries are reserved for alignment. This avoids syntax errors caused by truncating parentheses, strings, or comments, and preserves the overlapping information between segments so that subsequent embedding vectors can be seamlessly spliced. As a result, the context information of the entire source code file is fully encoded, providing a semantically complete input for generating accurate condensed vectors.

[0041] Therefore, this embodiment performs segmented lexicalization on the source code within a local window of each high-risk statement, and calculates the embedding vector of the lexical units through a semantic encoder. Specifically: After performing lexicalization on the source code within the local window, tokens are read sequentially starting from the first line of the local window until the cumulative length is less than 512 tokens by one complete word, ensuring that syntactic units are not truncated. The segmentation point is then backtracked until the nearest sentence boundary is found as the starting point for the next segment, and 512 tokens are read sequentially again. This process is repeated until the end of the local window has fewer than 512 tokens, at which point all of them are considered as one segment, completing the segmentation of the source code within the local window. During segmentation within the local window, each segment is checked before splitting to ensure it falls within a string, comment, or parentheses. If so, it continues to extend until the pairing ends, preventing broken parentheses or truncated strings from introducing incorrect embeddings.

[0042] Finally, the source code within the local window of each high-risk statement is divided into several segments. In this embodiment, the trained CodeBERT model is used to encode the source code segment by segment, and a 768-dimensional vector is output for each token in each segment. The training of the CodeBERT model is a well-known existing technique, and this embodiment does not impose any restrictions on it.

[0043] Furthermore, each token is treated as an encoding unit, and the relevance score of the row containing each token is used as the structural importance of each token, meaning that tokens in the same row have the same structural importance. The [CLS] vector output after encoding the first segment of the high-risk statement local window is taken as the global semantic anchor point, with a dimension of 768. It is mapped to the query space through a linear projection layer to obtain the query vector q. The obtained query vector q is then subjected to L2 normalization to make it a unit vector.

[0044] The freshness of each token within a local window is calculated using the following expression: ,in, The freshness of the position of the j-th token within the local window of the high-risk statement. This indicates the row number of the j-th token within the local window containing the high-risk statement. This indicates the center row number within the local window containing the high-risk statement. This represents the maximum line difference within the local window containing high-risk statements, i.e., the total number of lines in the local window, and the position freshness. The larger the value, the closer it is to the center line of the local window, i.e., the line containing the high-risk statement. This is intended to ensure that the attention mechanism gives higher weight to tokens that are physically closer to the high-risk statement. This is denoted as the first ratio.

[0045] For the vector encoded by the j-th token within the local window of the high-risk statement First, calculate the cosine similarity between it and the query vector q, then calculate the structural importance. and location freshness A weighted summation is performed, and the result is added to the cosine similarity to obtain the attention weight of the j-th token within the high-risk statement local window. In this weighted summation, the weight of positional freshness is greater than the weight of structural importance. In this embodiment, the weight of structural importance is set to 0.4, and the weight of positional freshness is set to 0.6. Implementers can set these weights according to their actual needs; this embodiment does not impose any restrictions.

[0046] It should be noted that the cosine similarity reflects the similarity between the token-encoded vector and the query vector. Implementers may choose other feasible similarity calculation methods, and this embodiment does not impose any restrictions on this.

[0047] Finally, the attention weights of all tokens within the local window of high-risk statements are normalized using softmax to ensure that tokens that are closer to the center, have a more critical structure, and are more semantically relevant receive greater weights.

[0048] The vectors encoded by all tokens within the same local window are weighted and summed according to their corresponding attention weights to obtain the aggregated vector of the local window. Then, LayerNorm and L2 normalization are performed to finally output the fixed 768-dimensional context condensation vector of the local window. All tokens within the local window are sorted in descending order of attention weight. In this embodiment, the top 10% of tokens are output as a priority list. The number of tokens in the priority position list can be set by the implementer according to the actual situation; this embodiment does not impose any restrictions on this.

[0049] This embodiment compresses variable-length and noisy source code windows into fixed-dimensional vectors through contextual condensation, thereby assigning high weights to key statements and reducing the weights of irrelevant statements to near zero. This preserves the complete semantics while removing redundancy and generating contextual features.

[0050] S5 calculates the adaptive threshold of the local window based on the context condensation vector of the local window to determine the vulnerability probability of the code segment within the local window, and uses the priority position list to perform sandbox verification of high-risk vulnerabilities.

[0051] Furthermore, this embodiment refines the context vector of the local window of the high-risk statement. Mapped to single scalar context strength And based on context strength Basic judgment threshold Adaptive adjustment yields adaptive threshold With adaptive threshold and the score of the basic large model The comparison is performed to output the vulnerability assessment result of the high-risk statement's local window, specifically: Calculate the context condensation vector of the local window of the high-risk statement. The mean of the absolute values ​​of all elements in the matrix, then normalized to 0-1 using the Sigmoid function, is mapped to the context strength. This quantifies the vulnerability of code segments within a local window. Then, a base threshold is selected based on the project type. Using the tolerance for false positives and false negatives as a standard, the Web base threshold is set to 0.9 and the firmware base threshold is set to 0.85 in this embodiment. The adaptive threshold is then calculated. The specific expression is: ,in, This represents the maximum decrease in the threshold value, ranging from 0.1 to 0.3. In this embodiment... The value is set to 0.15. Implementers can set this value according to their specific needs. The flowchart for determining the adaptive threshold for code vulnerability detection is as follows: Figure 2 As shown.

[0052] Context strength of the same code in different projects, different versions, or different contexts It will change, leading to an adaptive threshold. Fluctuation up and down, basic threshold It provides a benchmark for project types, allowing the judgment threshold to be adjusted in real time according to the vulnerability of the code, thereby achieving an adaptive effect of loose thresholds for low-risk scenarios and tight thresholds for high-risk scenarios.

[0053] Furthermore, this embodiment uses the Devign model to obtain the original vulnerability probability of the source code in the local window of high-risk statements, i.e., the model's base score. The value ranges from 0 to 1, and is then compared with the adaptive threshold corresponding to the local window. If... The code snippet marks the source code within a local window as a high-risk vulnerability and initiates sandbox verification; otherwise, it is marked as a low-risk vulnerability. The Devign model's code vulnerability detection is a well-known existing technology, and its specific process will not be elaborated upon.

[0054] Generate a priority location list for high-risk vulnerabilities. A priority-driven dynamic verification plan is used, and verification is performed in an isolated environment, specifically as follows: For code snippets within a local window of a high-risk vulnerability, they are injected sequentially as injection points according to the token order in the priority position list. Three payloads are injected in sequence. In this embodiment, the three payloads are (1) low risk: verify whether the user input is concatenated into the shell command and can terminate the original command; (2) medium risk: confirm that the vulnerability can be used to read the core information of the system; (3) high risk: test whether the vulnerability can be used to establish a reverse shell and realize remote code execution (RCE). The specific payload is dynamically generated by the sandbox module according to the target language and injection context. Each payload only changes the command content and keeps the quotation marks and parentheses closed in the same way as the original statement to ensure that the syntax is legal.

[0055] It should be noted that the sandbox configuration during sandbox verification is as follows: 0.5 CPU cores, 512MB of memory to prevent exhaustion of the host machine, network in isolation mode, maximum time limit of 5 seconds, and a maximum of 3 rounds. The payload is injected round by round within the sandbox container, and anomalies are monitored, including return codes, log keywords, file system changes, and network connections. If any anomaly is triggered, it is confirmed as a high-risk vulnerability. If no anomalies are triggered and the rounds are exhausted, it is marked as a vulnerability requiring manual review, thus achieving vulnerability detection in the source code. Sandbox verification is a well-known existing technology, and the specific process will not be elaborated upon.

[0056] Based on the same inventive concept as the above method, this application also provides a software source code vulnerability detection device, the device storing a computer program, which, when executed by a processor, implements the steps of any of the above-described software source code vulnerability detection methods.

[0057] Based on the same inventive concept as the above methods, this application also provides a software source code vulnerability detection system, including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of any one of the above-described software source code vulnerability detection methods.

[0058] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments of this specification have been described above. Additionally, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0059] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0060] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for detecting software source code vulnerabilities, characterized in that, The method includes the following steps: Obtain the abstract syntax tree of the source code flow and calculate the syntax depth of each statement in the source code; determine the data flow importance of each statement based on the connection of the corresponding edges in its data flow graph. Analyze the scope of influence of conditional branches on the execution of each statement in the source code, determine the control dependency span of each statement, and determine the relevance score of each statement by combining the syntax depth, the importance of the data flow, and the components of each statement. High-risk statements in the source code are matched and identified. Based on the relevance score of the high-risk statements and their position in the abstract syntax tree, the local window scale of the high-risk statements is determined. For the source code within the local window of high-risk statements, analyze the distance between each token and the center of the window to determine the positional freshness of each token; by the correlation between the word vector encoded by each token and the identifier vector corresponding to the local window, and by combining the relevance score of the statement in which each token is located and its positional freshness, determine the attention weight of each token to obtain the contextual condensation vector of the local window, and filter out the priority position list from all tokens in the local window. An adaptive threshold for a local window is calculated based on the context condensation vector of the local window to determine the vulnerability probability of code snippets within the local window, and a priority position list is used to perform sandbox verification of high-risk vulnerabilities.

2. The software source code vulnerability detection method as described in claim 1, characterized in that, The grammatical depth is the ratio of the number of edges between each statement node and the root node in the abstract syntax tree to the maximum value of the number of edges among all statement nodes. The importance of the data flow is defined as follows: in the data flow graph of the source code, the total number of incoming and outgoing edges connected to each statement is counted, which is taken as the degree of each statement. The importance of the data flow of each statement is the ratio of the degree of each statement to the maximum degree of all statements in the data flow graph.

3. The software source code vulnerability detection method as described in claim 1, characterized in that, Determining the control dependency span of each statement includes: The control flow graph (CFG) is generated using the abstract syntax tree of the source code flow. The length of the control dependency chain of each statement is calculated using the control dependency algorithm. The length of the control dependency chain of each statement is then compared with the maximum length of the control dependency chain of all statements to obtain the control dependency span of each statement.

4. The software source code vulnerability detection method as described in claim 1, characterized in that, The determination of the relevance score for each statement includes: If any statement contains known dangerous functions and instructions, the identifier sensitivity of that statement is marked as 1; otherwise, it is marked as 0. The relevance score of each statement is the fusion result of the syntax depth, the data flow importance, the control dependency span, and the identifier sensitivity.

5. The software source code vulnerability detection method as described in claim 1, characterized in that, Determine the local window size for high-risk statements, including: The expression for calculating the window size expansion amount of high-risk statements is: In the formula, Let `max[]` be the window size expansion amount for the i-th high-risk statement, `max[]` be the maximum value function, and `ceil()` be the floor function. The relevance score for the i-th statement is... The preset expansion threshold, The maximum number of rows to expand is preset; The local window size for high-risk statements is the sum of the preset initial candidate width and twice the window size expansion, with the high-risk statement as the center within the local window.

6. The software source code vulnerability detection method as described in claim 1, characterized in that, Determining the location freshness of each token includes: Calculate the absolute value of the difference between the row number of each token and the center row number of its local window. Calculate the ratio of the absolute value of the difference to the total number of rows in the local window of each token, and denot it as the first ratio. The freshness of each token's position is the difference between the natural number 1 and the first ratio.

7. The software source code vulnerability detection method as described in claim 1, characterized in that, Determining the attention weight of each token includes: The [CLS] vector output after encoding the first segment of the local window is projected and mapped to obtain the query vector. The similarity between the word vector encoded by each token and the query vector is calculated. The weighted sum of the relevance score of the sentence containing each token and its positional freshness is calculated. The attention weight of each token is the sum of the weighted sum and the similarity. The weight of the positional freshness of each token is greater than the weight of the relevance score of the sentence containing each token. The step of obtaining the context condensation vector of the local window and filtering the priority position list from all tokens in the local window includes: calculating the product of the word vector encoded by each token and its attention weight, and forming the context condensation vector of the local window by the normalized value of the product of all tokens in the local window; arranging all tokens in the local window in descending order according to their attention weight, and forming the priority position list by the first preset percentage of tokens.

8. The software source code vulnerability detection method as described in claim 1, characterized in that, The determination of the vulnerability probability of code snippets within a local window includes: Calculate the mean of the absolute values ​​of all elements in the context condensation vector of the local window, calculate the normalized value of the mean and multiply it by the maximum decrease of the preset threshold, where the adaptive threshold is the difference between the preset base threshold and the multiplication result. The vulnerability probability of code snippets within a local window is obtained using a neural network model. If the vulnerability probability is greater than or equal to the adaptive threshold of the local window, the code in the local window is marked as a high-risk vulnerability and sandbox verification is initiated; otherwise, it is marked as a low-risk vulnerability. The sandbox verification of high-risk vulnerabilities using a priority location list includes: injecting three payloads, representing low risk, medium risk, and high risk, in the order of the tokens in the priority location list as injection points; if an anomaly is triggered, it is confirmed as a high-risk vulnerability; otherwise, it is marked for manual review.

9. A software source code vulnerability detection device, the device storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the software source code vulnerability detection method as described in any one of claims 1-8.

10. A software source code vulnerability detection system, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1-8.

Images