Evolutionary software vulnerability detection method based on large language model
By integrating inter-process slicing and core set replay methods, combined with incremental learning and deployment feedback, the accuracy problem of cross-function vulnerability detection was solved, enabling continuous evolution of the model and self-improvement of the detection tool, and reducing false positives and false negatives.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANJING UNIV
- Filing Date
- 2026-04-20
- Publication Date
- 2026-06-05
AI Technical Summary
Existing software vulnerability detection methods based on large language models cannot effectively handle complex vulnerabilities that propagate across functions. When learning new vulnerability types, the models are prone to forgetting existing detection capabilities, and the detection tools lack a systematic feedback and exploitation mechanism after deployment, resulting in a lack of improvement methods for false positives and false negatives.
We employ a method based on large language models, involving inter-process slicing and core set replay. By analyzing static programs, we identify suspicious operations in the source code, construct cross-function vulnerability propagation paths, and utilize incremental learning and deployment feedback-driven data refining techniques to form a closed-loop evolution mechanism for continuous model improvement.
It achieves effective detection of cross-function vulnerabilities. The model retains its existing capabilities when learning new vulnerability types, and the tool is continuously improved after deployment based on user feedback, reducing false positives and false negatives and improving detection accuracy.
Smart Images
Figure CN122153918A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software security and artificial intelligence, specifically to software vulnerability detection technology based on large language models, inter-process static program analysis technology, incremental learning technology, and training data refinement technology, belonging to the field of software engineering. Background Technology
[0002] Software vulnerabilities refer to security flaws in program code, including null pointer dereferences, resource leaks, and double frees. These flaws share the common characteristic that the program may cause exceptions, crashes, or security issues during runtime due to improper handling of the state of specific variables or resources. Many vulnerabilities involve cross-function data propagation; that is, an unsafe state is introduced in one function and propagates to other functions through parameter passing or return values, ultimately triggering the vulnerability. Because the propagation path of cross-function vulnerabilities is scattered across multiple functions, analyzing only a single function is insufficient to discover such vulnerabilities. By using inter-procedural static analysis techniques to trace the propagation relationships of variables across functions, a code context covering the complete vulnerability propagation path can be constructed, thereby supporting the detection of cross-function vulnerabilities.
[0003] Currently, existing methods for software vulnerability detection based on large language models are mainly geared towards single-function samples and cannot handle complex vulnerabilities that propagate across functions. When learning new vulnerability types, the models tend to forget their existing detection capabilities. Detection tools lack a systematic feedback and utilization mechanism for false positives and false negatives after actual deployment, leading to the further reinforcement of harmful data patterns in the core area through repeated playback. Summary of the Invention
[0004] The purpose of this invention is to propose a software vulnerability detection method based on inter-process slicing and core set replay of a large language model, aiming to solve the problems of cross-function vulnerability detection, continuous model evolution, and self-improvement based on deployment feedback.
[0005] To achieve the above-mentioned objectives, the present invention is implemented through the following technical solution: An evolvable software vulnerability detection method based on a large language model, comprising the following steps: (The method utilizes inter-process slicing and core set replay based on the large language model for software vulnerability detection.) Step 1: Identify Source statements in the program source code through static program analysis. The Source statements are program statements that may introduce unsafe states.
[0006] Step 1.1: Scan the source code using predefined regular expression patterns to match resource acquisition operations, resource release operations, and pointer dereference operations, locate all possible suspicious operations, and associate them with specific statements.
[0007] Step 1.2: Determine the Source statement based on the vulnerability type. For a null pointer exception, the Source is an assignment statement that may cause the pointer to be NULL; for a resource leak, the Source is a resource acquisition statement; for a double free, the Source is a resource release statement.
[0008] Its beneficial effect is that it can automatically locate source statements with multiple vulnerability types through regular expression pattern matching, and supports unified identification of multiple vulnerability types such as null pointer exception, resource leakage, and double release.
[0009] Step 2: Based on call graph traversal and data dependency analysis, perform function-level inter-procedural slicing on each Source statement to build a cross-function code context that covers the complete vulnerability propagation path.
[0010] Step 2.1: Determine the function containing the Source statement and extract the set of variables that have data dependencies on Source, including variables that are propagated to other functions through parameter passing and return values.
[0011] Step 2.2: Traverse the call graph using a breadth-first search, with the search depth controlled by a threshold. Simultaneously search both the caller function and the callee function to construct a set of candidate functions.
[0012] Step 2.3: For each function in the candidate function set, check whether there is an intersection between its variable set and the Source data dependency variable set. If there is an intersection, keep all the code of the function; otherwise, discard the entire function.
[0013] Step 2.4: Adopt a conservative strategy for pointer scenarios. When two pointers may point to the same memory region, it is assumed that there is a data dependency between them, including three cases: pointer write propagation, parameter passing, and return value propagation.
[0014] Step 2.5: When the total length of the slice results exceeds the model context window, discard them gradually from farthest to closest according to the call graph distance between the function and the Source, while always retaining the function containing the Source.
[0015] Its advantages include performing inter-procedural slicing at the function level, preserving complete function code to provide a coherent semantic context, lower computational overhead than statement-level slicing, and support for complete coverage of cross-function vulnerability propagation paths.
[0016] Step 3: Input the constructed cross-function code context into the large language model with efficient parameter fine-tuning according to the structured input format for inference. The model determines whether there is a vulnerability propagation path from Source to Sink and outputs the specific propagation path information.
[0017] Step 3.1: Design the model input into two parts: the first part is the natural language task instruction, which specifies the type of vulnerability to be detected; the second part is the code context after inter-process slicing, where the Source statement is explicitly marked with comment tags.
[0018] Step 3.2: The model output has two cases: if a vulnerability is determined to exist, the model provides the code path from Source to Sink; if no vulnerability is determined to exist, a negative conclusion is output.
[0019] Step 3.3: Adapt the pre-trained code large language model using efficient parameter fine-tuning technology, and learn specific knowledge of vulnerability detection through a low-rank adapter.
[0020] Its beneficial effect is that, through a structured input and output format, large language models can output interpretable vulnerability propagation paths, rather than just vulnerability labels, making it easier for developers to understand and verify the detection results.
[0021] Step 4: When it is necessary to expand the detection of new vulnerability types, a core set is selected from the old vulnerability training data to form a core set through an incremental learning method based on the core set. This core set is then mixed with the new vulnerability type data for replay training, so that the model can maintain its ability to detect existing types while learning new vulnerability types.
[0022] Step 4.1: Perform K-step fine-tuning independently on each sample in the old dataset. Starting from the unified initial parameters, accumulate multiple gradient updates to obtain the parameter change vector.
[0023] Step 4.2: Project the high-dimensional parameter variation vector into the low-dimensional space using a random projection matrix.
[0024] Step 4.3: Define the mixing distance while considering the direction and magnitude of the parameter change vector, and use an agglomerative hierarchical clustering algorithm to group the samples.
[0025] Step 4.4: Randomly sample one sample from each cluster to form a core set, mix the core set with the new dataset, and continue training starting from the old adapter parameters.
[0026] Its beneficial effect is that by selecting a core set based on parameter variation characteristics, a small amount of representative old data can effectively alleviate catastrophic forgetting, enabling the model to maintain its ability to detect existing types while learning new vulnerability types, and reducing storage and computational overhead.
[0027] Step 5: During the actual deployment and use of the tool, collect user-confirmed false positive and false negative samples as feedback data. Based on the model behavior signals, refine the constructed core set, filter out harmful samples in the core set that cause false positives and false negatives, and supplement the core set with quality-verified feedback data. Use the refined core set and new data to replay the training to update the model.
[0028] Step 5.1: Continuously collect user-confirmed false alarm samples and false negative samples as a feedback dataset.
[0029] Step 5.2: Input the feedback data into the current model inference to obtain the prediction results and perplexity; samples with perplexity below the threshold but incorrect predictions are classified into the error-related set, and samples with perplexity not below the threshold are classified into the unfamiliar pattern candidate set.
[0030] Step 5.3: Reuse the hierarchical clustering method in Step 4 to group the core set, map the error signals to the clusters of the core set, and calculate the harmful density of each cluster.
[0031] Step 5.4: Perform hierarchical filtering on the core set based on harmful density: all clusters with low harmful density are retained; clusters with medium harmful density are downsampled according to weight; all clusters with high harmful density are filtered out to remove harmful old knowledge.
[0032] Step 5.5: Perform quality verification on the samples in the unfamiliar pattern candidate set, add the verified feedback samples to the filtered core set, construct a refined core set, and use the refined core set to mix with new data to replay and train and update the model.
[0033] Its beneficial effect is that by using actual deployment feedback to drive the continuous refinement of the core set, the tool can both expand new vulnerability types and correct existing errors in each iteration, forming a closed-loop evolution mechanism of "deployment-feedback-refinement-update", without the need for manual re-labeling of all training data. Attached Figure Description
[0034] Figure 1 This is an overall framework diagram of the vulnerability detection tool based on the evolvable software vulnerability detection method of the present invention, which is based on a large language model.
[0035] Figure 2 This is a flowchart illustrating the vulnerability context construction and detection process of the evolvable software vulnerability detection method based on a large language model according to the present invention.
[0036] Figure 3 This is a flowchart illustrating the incremental learning and refinement process based on the core set in the evolvable software vulnerability detection method based on a large language model, as described in this invention. Detailed Implementation
[0037] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0038] The key technologies used in this invention include inter-process program slicing, large language model fine-tuning, replay strategies in incremental learning, and data refinement. A call graph is constructed to reflect the call relationships between functions, and data dependency analysis is used to track the path information of variables propagating across functions. Efficient parameter fine-tuning techniques adapt the pre-trained large language model to the vulnerability detection task. A core set replay strategy mitigates catastrophic forgetting of existing knowledge when the model expands to new vulnerability types. Data refinement techniques based on model behavior signals identify and filter harmful data patterns in the core set.
[0039] This invention presents a software vulnerability detection method based on a large language model that integrates inter-process slicing and core set replay. First, a cross-function vulnerability context is constructed through inter-process slicing and input into a large language model for detection, outputting the vulnerability propagation path from Source to Sink. Then, by selecting a core set based on parameter variation characteristics and training through hybrid replay, the model maintains its existing detection capabilities when expanding to new vulnerability types. Finally, during actual tool deployment, the core set is refined using user-confirmed false positives and false negatives feedback, forming a closed-loop evolution mechanism of "deployment—feedback—refinement—update".
[0040] The evolvable software vulnerability detection method based on a large language model in this embodiment is a software vulnerability detection method based on inter-process slicing and core set playback of a large language model. The overall framework is as follows: Figure 1 As shown, the specific steps are as follows: Step 1: Identify Source statements in the program's source code through static program analysis. Parse the program source code into an abstract syntax tree and construct a call graph. Scan the source code using predefined regular expression patterns to match three types of operations: resource acquisition operations, resource release operations, and pointer dereference operations, locating all possible suspicious operations and associating them with specific statements.
[0041] Step 1.1: Scan the source code using predefined regular expression patterns to match resource acquisition operations (including malloc, calloc, new, fopen, etc.), resource release operations (including free, delete, fclose, etc.), and pointer dereference operations (including *p, p->field, p[i], etc.), locate all possible suspicious operations, and associate them with specific statements.
[0042] Step 1.2: Determine the Source statement based on the vulnerability type. For Null Pointer Exception (NPE), Source is an assignment statement that may cause the pointer to be NULL, and Sink is a dereference operation that has not been null-checked; for Resource Leak, Source is a resource acquisition statement, and Sink is a function exit that lacks a release operation; for DoubleFree, Source is the first release statement, and Sink is the second release of the same resource.
[0043] Step 2: Based on call graph traversal and data dependency analysis, perform function-level inter-procedural slicing for each Source statement to construct a cross-function code context covering the complete vulnerability propagation path. The execution process of inter-procedural slicing is as follows: Figure 2 As shown.
[0044] Step 2.1: Determine the function f0 where the Source statement is located, and extract the set of variables DepVars that have data dependencies on Source. This set spans function boundaries and includes variables that are associated with other functions through parameter passing, return value propagation, and pointer aliases.
[0045] Step 2.2: Traverse the call graph starting from f0 using a breadth-first search, simultaneously searching for both the caller and the callee. The search depth is controlled by a threshold D, and a set of candidate functions is constructed.
[0046] Step 2.3: For each function in the candidate function set, check if its variable set intersects with DepVars. If an intersection exists, retain all the code of the function; otherwise, discard the entire function.
[0047] Step 2.4: Adopt a conservative strategy for pointer scenarios: When two pointers may point to the same memory region, it is considered that there is a data dependency, including three cases: pointer write propagation, parameter passing, and return value propagation.
[0048] Step 2.5: When the total length of the code of the retained functions exceeds the model context window, the functions are gradually discarded from farthest to closest according to the call graph distance between the functions and the Source, while the function containing the Source is always retained.
[0049] Step 3: Input the constructed cross-function code context into the large language model, which has been efficiently fine-tuned with parameters, according to the structured input format, for inference.
[0050] Step 3.1: Design the model input into two parts: the first part is the natural language task instruction, which specifies the type of vulnerability to be detected; the second part is the code context after inter-process slicing, where the Source statement is explicitly marked with comment tags.
[0051] Step 3.2: The model output is divided into two cases: if a vulnerability is determined to exist, the code path from Source to Sink is given, and the key statements in the propagation process are listed; if no vulnerability is determined to exist, a negative conclusion is output.
[0052] Step 3.3: Adapt the pre-trained code large language model using efficient parameter fine-tuning technology, and learn specific knowledge of vulnerability detection through a low-rank adapter.
[0053] Step 4: When new vulnerability types need to be added, update the model using an incremental learning method based on the core set. Figure 3 The process shown in the first half selects a core set from the old data and performs mixed training.
[0054] Step 4.1: Parameter Change Feature Extraction. For each sample in the old dataset, perform K-step fine-tuning independently. Starting from a unified initial parameter, accumulate gradient updates over multiple steps to obtain the parameter change Δφᵢ = θ_K − θ0, which is then flattened into a one-dimensional vector. Multi-step accumulation smooths out random noise and more stably captures the influence of samples on the model.
[0055] Step 4.2: Random Projection Dimensionality Reduction. A random projection matrix is generated using the Rademacher distribution to project the high-dimensional parameter variation vector into a low-dimensional space. The distance is approximately preserved based on the Johnson-Lindenstrauss lemma.
[0056] Step 4.3: Hybrid Distance Metric and Hierarchical Clustering. Define the hybrid distance d(uᵢ, uⱼ) = (1−cos(uᵢ,uⱼ))·‖uᵢ−uⱼ‖2, considering both the direction and magnitude of the parameter change vector. Cosine distance compares only the direction and ignores the magnitude, Euclidean distance compares only the endpoints and ignores the direction, while hybrid distance captures both direction and magnitude information through a product. An agglomerative hierarchical clustering algorithm (AGNES, Average Connectivity Criterion) is used to divide the samples into K clusters.
[0057] Step 4.4: Core Set Sampling and Model Update. Randomly sample one sample from each cluster to form a core set. Mix the core set with the new dataset, continue training from the old adapter parameters, and update the model.
[0058] Step 5: During the actual deployment and use of the tool, collect user-confirmed false positive and false negative samples as feedback data, and refine the constructed core set based on model behavior signals. For example... Figure 3 The lower half is shown.
[0059] Step 5.1: During the actual deployment and use of the tool, collect user-confirmed false positive and false negative samples as feedback data, refine the constructed core set based on model behavior signals, filter out harmful samples in the core set that cause false positives and false negatives, and supplement the core set with quality-verified feedback data.
[0060] Step 5.2: Feedback Collection and Signal Extraction. Continuously collect user-confirmed false positive and false negative samples to form a feedback dataset. Input the feedback data into the current model for inference to obtain prediction results and perplexity. Samples with perplexity below the threshold τ but incorrect predictions are categorized into the error-related set S_err, indicating the presence of harmful data patterns that systematically mislead the model in the core set. Samples with perplexity not lower than τ are categorized into the unfamiliar pattern candidate set S_unk, indicating that the tool currently lacks knowledge of these vulnerability patterns.
[0061] Step 5.3: Core Set Clustering Hierarchical Filtering. The hierarchical clustering method from Step 4 is reused to group the core set, mapping the error signals in S_err to the clusters of the core set, and calculating the harmful density ρᵢ for each cluster.
[0062] Step 5.4: Stratified processing based on harmful density: all clusters with ρᵢ < ρ_low are retained; clusters with ρ_low ≤ ρᵢ < ρ_high are downsampled according to the weight wᵢ = 1−ρᵢ; all clusters with ρᵢ ≥ ρ_high are filtered out to remove harmful old knowledge that leads to false alarms and false negatives.
[0063] Step 5:5: Refining the Core Set and Updating the Model. The feedback samples in S_unk are quality-verified, and the verified samples are added to the filtered core set to construct the refined core set. The refined core set is then used in conjunction with new vulnerability type data for replay training and model updates. The model is then redeployed to begin the next "deployment-feedback-refinement-update" cycle.
[0064] Step 5 above can be repeated throughout the tool's lifecycle. In each iteration, false positives and false negatives exposed by the tool are collected as feedback data, used to locate harmful patterns in the core set and refine it. The refined core set is then mixed with new data to train and update the model, making the tool more accurate in each iteration. This mechanism does not require manual relabeling of all training data; continuous improvement is driven only by user confirmation or correction of the tool's output.
[0065] The above descriptions are embodiments of the present invention, but the specific embodiments described herein are merely illustrative and not intended to limit the invention. Any omissions, modifications, or equivalent substitutions made within the scope of the claims of this invention without departing from the principles and spirit of the invention should be included within the scope of protection of the claims.
Claims
1. An evolvable software vulnerability detection method based on a large language model, comprising the following steps: Step 1: Identify Source statements in the program source code through static program analysis. The Source statements are program statements that may introduce unsafe states, including resource acquisition operations and pointer nulling operations. Step 2: Based on call graph traversal and data dependency analysis, perform function-level inter-procedural slicing on each Source statement to build a cross-function code context that covers the complete vulnerability propagation path; Step 3: Input the constructed cross-function code context into the large language model that has been efficiently fine-tuned by parameters according to the structured input format. The model will determine whether there is a vulnerability propagation path from Source to Sink and output the specific propagation path information. Step 4: When it is necessary to expand the detection of new vulnerability types, a core set is selected from the old vulnerability training data to form a core set through an incremental learning method based on the core set. This core set is then mixed with the new vulnerability type data for replay training, so that the model can maintain its ability to detect existing types while learning new vulnerability types. Step 5: During the actual deployment and use of the tool, collect user-confirmed false positive and false negative samples as feedback data. Based on the model behavior signals, refine the constructed core set, filter out harmful samples in the core set that cause false positives and false negatives, and supplement the core set with quality-verified feedback data. Use the refined core set and new data to replay the training to update the model, forming a closed-loop evolution mechanism of "deployment-feedback-refinement-update".
2. The method according to claim 1, characterized in that, Step 1 is described in detail as follows: Step 1.1: Scan the source code using predefined regular expression patterns to match resource acquisition operations, resource release operations, and pointer dereference operations, locate all possible suspicious operations, and associate them with specific statements; Step 1.2: Determine the Source statement based on the vulnerability type. For Null Pointer Exception (NPE), the Source is an assignment statement that may cause the pointer to be NULL; for Resource Leak, the Source is a resource acquisition statement; for Double Free, the Source statement is a resource release statement.
3. The method according to claim 1, characterized in that, Step 2 is described in detail below: Step 2.1: Determine the function f0 where the Source statement is located, and extract the set of variables that have data dependencies on Source, including variables that are propagated to other functions through parameter passing and return values; Step 2.2: Traverse the call graph using a breadth-first search, with the search depth controlled by a threshold D. Simultaneously search both the caller function and the callee function to construct a set of candidate functions. Step 2.3: For each function in the candidate function set, check if there is an intersection between its variable set and the Source data dependency variable set; if there is an intersection, keep all the code of the function; if there is no intersection, discard the entire function. Step 2.4: Adopt a conservative strategy for pointer scenarios. When two pointers may point to the same memory region, it is assumed that there is a data dependency between them, including three cases: pointer write propagation, parameter passing, and return value propagation. Step 2.5: When the total length of the slice results exceeds the model context window, discard them gradually from farthest to closest according to the call graph distance between the function and the Source, while always retaining the function containing the Source.
4. The method according to claim 1, characterized in that, Step 3 is described in detail below: Step 3.1: Design the model input into two parts: the first part is the natural language task instruction, which specifies the type of vulnerability to be detected; the second part is the code context after inter-process slicing, where the Source statements are explicitly marked with comment tags. Step 3.2: The model output has two cases: if a vulnerability is determined to exist, the model provides the code path from Source to Sink; if no vulnerability is determined to exist, a negative conclusion is output. Step 3.3: Adapt the pre-trained code large language model using efficient parameter fine-tuning technology, and learn specific knowledge of vulnerability detection through a low-rank adapter.
5. The method according to claim 1, characterized in that, Step 4 is described in detail below: Step 4.1: Parameter change feature extraction - Perform K-step fine-tuning independently on each sample in the old dataset. Starting from the unified initial parameters, accumulate multiple gradient updates to obtain the parameter change Δφᵢ = θ_K − θ0, which is flattened into a one-dimensional vector; Step 4.2: Random Projection Dimensionality Reduction - A random projection matrix is generated using the Rademacher distribution, which projects the high-dimensional parameter variation vector into a low-dimensional space. The Johnson-Lindenstrauss lemma ensures that the distance before and after projection is approximately preserved. Step 4.3: Hybrid Distance Metric and Hierarchical Clustering – Define the hybrid distance d(uᵢ, uⱼ) = (1−cos(uᵢ,uⱼ))·‖uᵢ−uⱼ‖2. Considering both the direction and magnitude of the parameter change vector, the agglomerative hierarchical clustering algorithm (AGNES, average connectivity criterion) is used to group the samples. Step 4.4: Core set sampling and model update - Randomly sample one sample from each cluster to form a core set, mix the core set with the new dataset, and continue training starting from the old adapter parameters.
6. The method according to claim 1, characterized in that, Step 5 is described in detail below: Step 5.1: During the actual deployment and use of the tool, continuously collect false alarm samples and false negative samples confirmed by users as feedback datasets; Step 5.2: Input the feedback data into the current model inference to obtain the prediction results and perplexity; samples with perplexity below the threshold τ but with incorrect predictions are classified into the error-related set S_err, and samples with perplexity not less than τ are classified into the unfamiliar pattern candidate set S_unk; Step 5.3: Reuse the hierarchical clustering method in Step 4 to group the core set, map the error signals in S_err to the clusters of the core set, and calculate the harmful density ρᵢ of each cluster; Step 5.4: Perform hierarchical filtering on the core set based on harmful density: all clusters with harmful density below ρ_low are retained; clusters with harmful density between ρ_low and ρ_high are downsampled according to the weight wᵢ = 1−ρᵢ; all clusters with harmful density above ρ_high are filtered out to remove harmful old knowledge that leads to false alarms and false negatives. Step 5.5: Perform quality verification on the samples in S_unk, add the verified feedback samples to the filtered core set, construct a refined core set, and use the refined core set to mix with new data to replay and train the updated model.
7. The method according to claim 3, characterized in that: Inter-procedural slicing is performed at the function level, preserving the complete function code to provide a coherent semantic context. The computational overhead is lower than that of statement-level slicing, making it suitable for large-scale codebases.
8. The method according to claim 5, characterized in that: Using the accumulated parameter changes from multi-step fine-tuning instead of single-step gradients as sample features can smooth out random noise and more stably capture the impact of samples on the model.
9. The method according to claim 6, characterized in that: Core set refinement directly applies to the existing core set rather than the full set of old data. It uses false positives and false negatives collected during actual tool deployment as a signal source. Through a closed-loop mechanism of "deployment detection - feedback collection - core set refinement - hybrid replay to update the model - redeployment", the tool can both expand new vulnerability types and correct existing errors in each iteration, achieving self-improvement and continuous evolution.