Automatic bug patch migration method for large language model based on grammar and semantic enhancement

Abstract

The invention belongs to the technical field of software engineering, and particularly relates to a large language model automatic vulnerability patch migration method based on grammar and semantic enhancement. The method comprises the following steps: extracting semantic and grammatical signatures related to vulnerabilities from a patch function of an original branch, wherein the semantic and grammatical signatures comprise a signature before repair and a signature after repair; extracting a corresponding vulnerability function signature from the vulnerability function of the target vulnerability branch; generating a patch migration prompt by using the signature information; using an original-target patch function to finely adjust the data set and the large language model; generating an initial repair function through the fine-tuned large language model; detecting semantic anomaly, placeholder anomaly and grammar anomaly by adopting a heuristic check method; and iteratively optimizing the repair function according to a check result until conditions are met, and outputting a final repair function. The method can effectively improve the success rate of migration of the vulnerability patches among different code branches, reduce manual intervention and reduce security risks.

Description

Technical Field

[0001] The present invention belongs to the technical field of software engineering, and in particular relates to a vulnerability patch migration method. Background Art

[0002] In modern software development, branching provides an efficient way to manage feature development and organization within a single code repository. However, this practice can inadvertently propagate security vulnerabilities. When a new branch is created from a parent branch, the new branch may inherit the security vulnerability present in the parent branch. Even if the vulnerability is later fixed through a patch in the original branch, the target, unfixed branch still contains the vulnerability. To mitigate these risks, a straightforward and effective approach is to migrate security patches from the original branch to the target branch. However, due to the inherent differences between branches, many patches cannot be applied directly, resulting in patch migration delays and increased vulnerability exposure.

[0003] To reduce these risks, a direct and effective approach is to migrate security patches from the original branch to the target branch. However, due to the inherent differences between branches, many patches cannot be applied directly, resulting in patch migration delays and increased vulnerability exposure time [1][2][3][4][5]. Existing automated patch migration methods are mainly divided into pattern-based methods and large language model (LLM)-based methods. Pattern-based methods such as FixMorph [6] and TSBPORT [7] rely on predefined patch patterns to automatically migrate patches within local code blocks. FixMorph analyzes the grammatical differences between the original branch / version and the target branch / version to adapt and migrate the original branch / version patch to the target branch / version, but it often ignores the semantic information of the patch during the processing, which leads to merging failures. In addition, when merging patches, FixMorph needs to call Clang / LLVM to compile and analyze the target branch / version. This process is not only time-consuming but also limits its universality across different code bases. TSBPORT adapts and migrates the original branch / version patch by analyzing the semantic features of the patch of the original branch / version and the semantic features of the vulnerability of the target branch / version, thereby enhancing the adaptability to complex code changes. However, if the semantic features of the patch (or vulnerability) are not within the processing range of the predefined repair pattern, TSBPORT will also find it difficult to complete the patch merging. Large model-based methods (such as PPatHF

[11] ) implement patch merging at the function level by fine-tuning the large model. PPatHF first identifies and annotates the differences between the original branch / version and the target branch / version through static analysis, and then the large model generates patch code adapted to the target branch / version based on the original branch / version patch. Since PPatHF ignores the key semantic information related to the vulnerability, the generated patch may lack the necessary semantic details. Secondly, PPatHF relies on the historical submission patches of a specific project to fine-tune the large model, making it difficult to extend to other projects or programming languages. Finally, PPatHF lacks a correctness detection and correction mechanism for the generated patches, making the generated patches prone to syntactic or semantic errors. In summary, these methods face three challenges, which hinder their effectiveness and generalization. The first challenge is how to generate the correct merged patch when there are significant syntactic or semantic differences between the original branch / version and the target branch / version. Pattern matching-based methods are limited to predefined repair patterns. When the differences between branches / versions are too large, they often cannot accurately match the required repair patterns. Large model-based methods fail to fully consider those key code statements that have syntactic or semantic differences and are closely related to vulnerability repairs, resulting in a lack of necessary information for patch merging. The second challenge is how to efficiently detect and correct the correctness of the patch after it is generated. After the existing methods generate the patch, due to the lack of a mechanism to detect and correct the correctness of the patch merging, the generated patch may contain syntactic or semantic errors.The third challenge is how to efficiently generalize patch merging methods across multiple projects and languages. Pattern-matching-based methods are mostly designed in C / C++ and lack support for other languages. Large-model-based methods rely on project-level fine-tuning, resulting in high training costs and difficulty adapting quickly to new projects or languages. Summary of the Invention

[0004] The purpose of the present invention is to provide an LLM automated vulnerability patch migration method based on semantic and grammatical enhancement, so as to effectively migrate security patches from the original branch to the target branch, improve the success rate and accuracy of patch migration, and reduce the risk of vulnerability exposure.

[0005] The LLM automated vulnerability patch migration method provided by the present invention comprises extracting vulnerability-related semantic and grammatical signatures from the patch function of the original branch, including pre-patch signatures and post-patch signatures; extracting corresponding vulnerability function signatures from the vulnerability function of the target vulnerability branch; generating patch migration prompts using the signature information; fine-tuning a large language model using the original-target patch function pair dataset; generating an initial repair function using the fine-tuned large language model; using a heuristic checking method to detect semantic anomalies, placeholder anomalies, and grammatical anomalies; and iteratively optimizing the repair function according to the inspection results until conditions are met and a final repair function is output.

[0006] The method of the present invention can also be divided into an offline training phase and an online migration phase; the online migration phase is divided into three steps: signature extraction, prompt generation, and function generation;

[0007] The present invention first uses semantic slicing and syntax completion technology to construct a function signature centered on vulnerability-related statements, performing data dependency and control flow analysis through code property graphs. It then collects source-target patch function pairs from multiple open source repositories to form a training dataset.

[0008] During the offline training phase, semantic and grammatical signatures are extracted from the collected patch-function pairs, and fine-tuning hints consistent with the transfer task are constructed to supervise fine-tune the large language model.

[0009] During the online migration phase, the patch function to be migrated and the target vulnerable function are input. First, the semantic and syntactic signatures of the pre- and post-patch functions and the vulnerable function are extracted respectively. Then, migration hints are generated based on the signature information to guide the fine-tuned large language model to generate the initial repair function. Finally, a heuristic checking mechanism is used to identify semantic, placeholder, and syntactic anomalies, and the repair function is iteratively optimized until the migration requirements are met.

[0010] The specific steps are as follows:

[0011] (1) Extract vulnerability-related semantics and grammatical signatures from the patch function of the original branch; including: using semantic slicing technology to construct a function signature with vulnerability-related statements as nodes and data dependencies and control flows as edges. Using static analysis tools, given the patch function and the vulnerability function, a code property graph is generated; based on the code property graph, deleted and newly added statements are identified and located. These statements can be divided into control flow-related and data dependency-related statements according to their types; then, based on the identified key statements, the semantics and grammatical signatures of the function are constructed. In the signature, each node corresponds to a vulnerability-related statement, and the edges in the graph represent the control flow and data dependency relationships between statements. Specifically, it includes the following sub-steps:

[0012] (1) Based on the static analysis tool Joern[9], the control flow information and data dependencies contained in the code are analyzed. The pre-patch and post-patch functions are normalized, comments, tabs, and whitespace characters are removed, and the git diff command is used to identify the set of deleted statements and the set of newly added statements.

[0013] (2) Based on the generated code attribute graph, data dependency slicing and control flow slicing are performed on deleted statements and newly added statements respectively. Data dependency slicing extracts statements that have data dependencies with the target statement through forward and backward tracing, and the slicing depth is set as a configurable parameter. Control flow slicing understands the execution flow of the vulnerability and repair statement by extracting the direct control statement and the direct post-control statement of the target statement.

[0014] (3) Based on Tree-sitter

[10] , an abstract syntax tree is constructed to perform syntax completion on the sliced ​​code fragments. By traversing the parent nodes of the syntax tree, control statements and substatements are extracted; program exit points and jump points in the control block are extracted; and curly brace pairing of control statements is completed to ensure syntax integrity.

[0015] (4) Based on the slicing statement and syntax completion statement, the complete signature of the function is constructed and other statements are replaced with placeholders to reduce the interference of irrelevant information.

[0016] (2) Collect source-target patch function pairs from multiple open source repositories as training datasets; including collecting vulnerability information and their corresponding patch submissions from the CVE / NVD database; expanding the patch collection from the GitHub repository and identifying related patches through code similarity and submission information matching; constructing time series patch pairs to ensure the quality and diversity of training data.

[0017] It includes the following sub-steps:

[0018] (1) Collect vulnerability information from the CVE / NVD database for a certain period of time (generally 3-6 months, for example, from January 2014 to May 2024), filter vulnerabilities related to C language projects, and obtain corresponding GitHub commit references;

[0019] (2) Based on the collected commits, all commits in the corresponding repository are scanned and the patch set is expanded through four criteria: the patch code is exactly the same, the edit distance similarity is greater than 0.5 and the commit information is the same, the commit information references the SHA value of the collected commit, and the commit information references the collected CVE number.

[0020] (3) Sort all commits by timestamp and select the earliest and latest commits for each vulnerability to form a patch pair. Use the CodeLLama release time as the split point to ensure no data leakage between the training and test sets.

[0021] (3) During the offline training phase, semantic and grammatical signatures are extracted from the collected patch function pairs, fine-tuning hints are constructed that are consistent with the transfer task, and supervised fine-tuning of the large language model is performed. The specific process is as follows:

[0022] First, prepare the dataset required for fine-tuning:

[0023] Use the original-target patch function pairs collected in step (2) as the fine-tuning dataset;

[0024] Generate corresponding semantic and syntactic signatures for these patch function pairs using the method in step (1);

[0025] Build a prompt template containing task description, constraint instructions, and input format to ensure the consistency of fine-tuning tasks and transfer tasks;

[0026] LoRA technology is used to perform supervised fine-tuning of pre-trained large language models to reduce computational cost and improve performance.

[0027] (4) During the online migration phase, the patch function to be migrated and the target vulnerable function are input. Function signatures are first extracted and migration hints are generated. The fine-tuned large language model is then used to generate the initial repair function. Anomalies are identified through a heuristic inspection mechanism, and iterative improvements are made, ultimately outputting a repair function that meets the requirements.

[0028] It includes the following sub-steps:

[0029] (1) Take the patch function to be migrated (including pre-patch function and post-patch function) and the target vulnerability function as input, and use the method in step (1) to extract their semantic and syntactic signatures respectively.

[0030] (2) Based on the mapping relationship between the deleted statements and the statements in the vulnerable function, the corresponding vulnerable statements in the vulnerable function are identified through grammatical similarity calculation and dependency analysis, and corresponding slicing and grammatical completion are performed.

[0031] (3) Using the predefined hint template, combined with the patch signature and the vulnerable function signature, a migration hint containing task description, constraint instructions, and specific input is generated.

[0032] (4) Use the fine-tuned large language model to process the transfer prompts and generate the initial repair function signature.

[0033] (5) Three types of anomalies are identified through a heuristic checking mechanism: semantic anomalies (over-repair or under-repair), placeholder anomalies (placeholders are incorrectly added, deleted, or moved), and syntax anomalies (syntax errors detected by Clang-tidy).

[0034] (6) Based on the detected anomaly type, corresponding improvement prompts are generated to guide the large language model to perform iterative optimization until no anomalies are detected or the maximum number of iterations is reached.

[0035] (7) Restore the code block corresponding to the placeholder and generate a complete repair function as the final output.

[0036] The technical features of the present invention mainly include:

[0037] (1) By constructing function signatures through semantic slicing and syntax completion techniques, with vulnerability-related statements as the core, we achieve accurate modeling of patch behavior, avoiding the problem of key information loss in traditional methods. By constructing a fine-tuning dataset that is exactly the same as the migration task, we significantly improve the performance of large language models on the patch migration task.

[0038] (2) During the migration process, an iterative inspection and improvement mechanism is adopted to automatically identify and correct semantic, placeholder and grammatical anomalies to ensure the correctness of the migration results.

[0039] (3) This method supports patch migration across projects, branches, and programming languages, and has good generalization capabilities. It adopts a hybrid strategy that combines heuristic rules with a large language model, ensuring accuracy while taking into account efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 The figure illustrates the flow chart of the method for automatic vulnerability patch migration based on a large language model with enhanced syntax and semantics according to the present invention.

[0041] Figure 2 Migrate hint template for patches. DETAILED DESCRIPTION

[0042] The following is a method for automatically migrating a given software vulnerability patch from the original branch to the target branch. The main process is described in Figure 1 , as follows:

[0043] (1) Patch function semantics and syntax signature extraction: After inputting the patch function of the original branch, first perform the patch function f pre And the patched function f post Perform standardization to remove all comments, tabs, and blank characters. Use the gitdiff command to identify the deleted statement set S_del and the newly added statement set S add . Using Joern tools for f pre and f post Generate a Code Property Graph (CPG) and then perform function semantic slicing. In the data dependency slicing phase, del and S add Each statement in the forward and backward data dependency slice is performed to track the data dependency relationship of the statement. The slice depth is set to 3 layers to obtain the data dependency statement set S pre_data and S post_data In the control flow slicing stage, extract S del and S add The direct control statement and the direct post-control statement of each statement in the control flow statement set S are obtained. pre_ctrl and S post_ctrl . Then the patch statement syntax completion is performed, and the abstract syntax tree (AST) is constructed using Tree-sitter to ensure the grammatical integrity of the slice code. The syntax completion process includes control clause completion, that is, traversing the parent node of AST, extracting control statements (such as if, else, switch, while) and their sub-statements; exit point and jump point completion, that is, extracting break, return and goto statements in the control block; and control statement bracket completion, that is, completing the corresponding braces for the extracted control statements and their sub-statements. Finally, the function signature Sig before patching is obtained pre And the patched function signature Sig post .

[0044] (2) Extraction of semantic and grammatical signatures of vulnerability functions: Extract the vulnerability function f in the target branch. vul To process, first generate its code property graph CPG vul , and then perform vulnerability statement mapping and slicing. In the statement mapping phase, S del Each delete statement in f vulThe statements in are mapped and the grammatical similarity is calculated using the Levenshtein distance with a threshold of 0.55. If the similarity exceeds the threshold, a mapping relationship is established. In order to verify the accuracy of the mapping, the candidate mapping statements are sliced ​​for forward and backward data dependencies and control dependencies, and the statement with the highest similarity score is selected as the final mapping. If no mapping statement that meets the conditions is found, the dominant and post-dominant statements are iteratively processed until the entry and exit points of the function are reached. Through the same grammatical completion process as the patch statement, the vulnerability function signature Sig is finally obtained. vul .

[0045] (3) Patch migration prompt word generation: Generate patch migration prompt words using a predefined prompt word template, which contains three core components. The task description part defines the specific requirements of the migration task and specifies the programming language type. The constraint instruction part contains four key constraints, namely C1 requires LLM to adapt the patch as needed, C2 ensures that only the relevant parts of the patch are modified without destroying the original function, C3 maintains the integrity of the placeholder and does not delete or move it, and C4 avoids filling in missing parts in the code to prevent syntax errors. The input format part converts the patch signature into diff format and uses it as the input of LLM together with the vulnerable function signature. For specific prompt words, see Figure 2 .

[0046] (4) LLM fine-tuning: A dataset of original-target patch function pairs containing 4,618 function-level patch pairs for 2,842 CVEs is constructed for the supervised fine-tuning task of LLM. In the patch pair signature generation phase, the signature Sig is extracted from the original patch function pair. o_pre 、Sig o_post and Sig t_pre , and the target signature Sig as the expected output t_post The fine-tuning prompt generation phase uses the same prompt template as the patch migration to generate fine-tuning prompt words. In the open source LLM fine-tuning phase, the LoRA (Low Rank Adaptation) technology is used to efficiently fine-tune the CodeLlama-13B model, setting lora_r to 16, lora_alpha to 32, batch size to 8, learning rate to 3e-4, training for 10 epochs, and using the AdamW optimizer to minimize the loss function until convergence.

[0047] (5) Repair function generation: The repair function is generated using the fine-tuned LLM. The process includes two stages: initial signature generation and iterative check optimization. In the initial signature generation stage, the prompt word and the fine-tuned LLM are used to generate the initial repair signature Sig 0 fix. During the heuristic checking phase, the system detects three possible types of anomalies. Semantic anomaly (A1) detects over-repair or under-repair problems by calculating the edit distance, with the over-repair threshold set to 0.3 and the under-repair threshold set to 0.5. Placeholder anomaly (A2) checks whether the placeholder is incorrectly added, deleted, or moved, and verifies the correctness of its position by anchoring the left and right sibling nodes of the placeholder. Syntactic anomaly (A3) uses the Clang-tidy tool to detect syntax errors after restoring the complete function, ignoring errors that already exist in the original vulnerable function to reduce false positives. In the iterative optimization phase, corresponding optimization hints are generated based on the detected anomaly type to guide LLM to perform targeted optimization. The process continues until no anomalies are detected or the context limit of 4096 tokens is reached.

[0048] Experimental verification:

[0049] A comprehensive evaluation was conducted on a dataset of 1,359 vulnerable functions containing 694 CVEs, using exact match (EM) and success rate (Succ) as the main evaluation metrics, while CodeBLEU was used to evaluate the similarity between failure cases and the correct patch. The experiment compared seven state-of-the-art methods, including pattern-based methods FixMorph and TSBPORT, LLM-based method PPatHF, and advanced large language models GPT-3.5, GPT-4o, CodeLlama, and StarCoder. The results show that Mystique achieved a success rate of 92.4% at the CVE level, an improvement of 12.3% over the best-performing baseline method TSBPORT. At the same time, Mystique's failure rate was only 4.6%, significantly lower than other methods, and it achieved the highest score of 0.921 on the CodeBLEU metric, indicating that even failure cases are closer to the correct patch. The specific results are shown in Table 1 below, where Mystique is the tool corresponding to the present invention.

[0050] Table 1: Patch migration effectiveness experimental results

[0051] tool EM Succ CodeBLEU CodeLlama 48.7％ 49.2％ 0.878 GPT-4o 70.3％ 71.6％ 0.859 TSBPORT 80.3％ 82.3％ 0.919 PPatHF 36.5％ 38.5％ 0.876 Mystique 90.5％ 92.4％ 0.921

[0052] References

[0053] [1].Durumeric,Z.,Li,F.,Kasten,J.,Amann,J.,Beekman,J.,Payer,M.,Weaver,N.,Adrian,D.,Paxson,V.,Bailey,M.and Halderman,J.A.,2014,November.The matterof heartbleed.In Proceedings ofthe 2014conference on internet measurementconference(pp.475-488).

[0054] [2].Kim,Seulbae,Seunghoon Woo,Heejo Lee,and Hakjoo Oh."Vuddy:Ascalable approach for vulnerable code clone discovery."In 2017IEEE symposiumon security and privacy(SP),pp.595-614.IEEE,2017.

[0055] [3].Mary,C."Shellshock attack on linux systems-bash."InternationalResearch Journal of Engineering and Technology 2,no.8(2015):1322-1325.

[0056] [4].Woo,Seunghoon,Sunghan Park,Seulbae Kim,Heejo Lee,and Hakjoo Oh."CENTRIS:A precise and scalable approach for identifying modified open-sourcesoftware reuse."In 2021IEEE / ACM 43rd International Conference on SoftwareEngineering(ICSE),pp.860-872.IEEE,2021.

[0057] [5].Xiao,Yang,Bihuan Chen,Chendong Yu,Zhengzi Xu,Zimu Yuan,Feng Li,Binghong Liu et al."{MVP}:Detecting vulnerabilities using{Patch-Enhanced}vulnerability signatures."In 29th USENIX Security Symposium(USENIX Security20),pp.1165-1182.2020.

[0058] [6].R.Shariffdeen,X.Gao,G.J.Duck,S.H.Tan,J.Lawall,and A.Roychoudhury,“Automated patch backporting in Linux(experience paper),”presented at theISSTA’21:30th ACM SIGSOFT International Symposium on Software Testing andAnalysis,in ISSTA’21.Virtual Denmark:ACM,Jul.2021,pp.633–645.doi:10.1145 / 3460319.3464821.

[0059] [7].S.Yang,Y.Xiao,Z.Xu,C.Sun,C.Ji,and Y.Zhang,“Enhancing OSS PatchBackporting with Semantics,”in Proceedings of the 2023ACM SIGSAC Conferenceon Computer and Communications Security,in CCS’23.New York,NY,USA:Associationfor Computing Machinery,Nov.2023,pp.2366–2380.doi:10.1145 / 3576915.3623188.

[0060] [8].S.Pan,Y.Wang,Z.Liu,X.Hu,X.Xia,and S.Li,“Automating Zero-ShotPatch Porting for Hard Forks,”in Proceedings ofthe 33rdACM SIGSOFTInternational Symposium on Software Testing and Analysis,in ISSTA 2024.NewYork,NY,USA:Association for Computing Machinery,Sep.2024,pp.363–375.doi:10.1145 / 3650212.3652134.

[0061] [9].“Joern-The Bug Hunter’s Workbench.”Accessed:Jun.09,2025.[Online].Available:https: / / joern.io / .

[0062]

[10] .“Tree-sitter.”Accessed:Jun.09,2025.[Online].Available:https: / / tree-sitter.github.io / tree-sitter / 。

Claims

1. An LLM automated vulnerability patch migration method based on semantic and grammatical enhancement, characterized in that: The specific steps are: (1) Extracting vulnerability-related semantic and syntactic signatures from the patch function of the original branch; this includes: using semantic slicing technology to construct a function signature with vulnerability-related statements as nodes and data dependencies and control flow as edges; using static analysis tools, given the patch function and the vulnerable function, generating a code property graph; based on the code property graph, identifying and locating deleted and newly added statements, which are classified as control flow-related and data dependency-related based on type; then, constructing the function's semantic and syntactic signature based on the identified key statements; in the signature, each node corresponds to a vulnerability-related statement, and the edges in the graph represent the control flow and data dependency relationships between statements; (2) Collecting source-target patch function pairs from multiple open source repositories as a training dataset; including collecting vulnerability information and corresponding patch submissions from the CVE / NVD database; expanding the patch collection from the GitHub repository and identifying related patches through code similarity and submission information matching; constructing a time series of patch pairs to ensure the quality and diversity of the training data; (3) During the offline training phase, semantic and grammatical signatures are extracted from the collected patch function pairs, fine-tuning hints consistent with the transfer task are constructed, and supervised fine-tuning of the large language model is performed; (4) During the online migration phase, the patch function to be migrated and the target vulnerability function are input. First, the function signature is extracted and a migration prompt is generated. Then, the fine-tuned large language model is used to generate the initial repair function. Anomalies are identified through a heuristic inspection mechanism and iterative improvements are made, and finally a repair function that meets the requirements is output.

2. The method according to claim 1, characterized in that Step (1) specifically includes the following sub-steps: (1) Based on the static analysis tool Joern, the control flow information and data dependency contained in the code are analyzed; the pre-patch function and the post-patch function are normalized, comments, tabs, and whitespace characters are removed, and the git diff command is used to identify the deleted statement set and the newly added statement set; (2) Based on the generated code attribute graph, data dependency slicing and control flow slicing are performed on deleted statements and newly added statements respectively; Data dependency slicing extracts statements that have data dependencies with the target statement through forward and backward tracing. The slicing depth is set as a configurable parameter. Control flow slicing extracts the direct controlling statements and direct subsequent controlling statements of the target statement to understand the execution flow of the vulnerability and repair statements; (3) Build an abstract syntax tree based on Tree-sitter to complete the syntax of the sliced ​​code fragments; extract control statements and substatements by traversing the parent nodes of the syntax tree; extract program exit points and jump points in the control block; Complete the curly braces pairing of control statements to ensure grammatical integrity; (4) Based on the slicing statement and syntax completion statement, the complete signature of the function is constructed and other statements are replaced with placeholders to reduce the interference of irrelevant information.

3. The method according to claim 2, characterized in that Step (2) specifically includes the following sub-steps: (1) Collect vulnerability information from the CVE / NVD database for a certain period of time, filter out vulnerabilities related to C language projects, and obtain corresponding GitHub commit references; (2) Based on the collected commits, all commits in the corresponding repository are scanned and the patch set is expanded by four criteria: the patch code is exactly the same, the edit distance similarity is greater than 0.5 and the commit information is the same, the commit information references the SHA value of the collected commit, and the commit information references the collected CVE number; (3) Sort all commits by timestamp and select the earliest and latest commits for each vulnerability to form a patch pair; use the CodeLLama release time as the split point to ensure that there is no data leakage between the training set and the test set.

4. The method according to claim 3, characterized in that Step (3) specifically includes the following sub-steps: First, prepare the dataset required for fine-tuning: Use the original-target patch function pairs collected in step (2) as the fine-tuning dataset; Generate corresponding semantic and syntactic signatures for these patch function pairs using the method in step (1); Build a prompt template containing task description, constraint instructions, and input format to ensure the consistency of fine-tuning tasks and transfer tasks; LoRA technology is used to perform supervised fine-tuning of pre-trained large language models to reduce computational cost and improve performance.

5. The method according to claim 1, wherein Step (4) specifically includes the following sub-steps: (1) Take the patch function to be migrated, including the pre-patch function and the post-patch function, and the target vulnerability function as input, and use the method in step (1) to extract their semantic and syntactic signatures respectively; (2) Based on the mapping relationship between the deleted statements and the statements in the vulnerable function, the corresponding vulnerable statements in the vulnerable function are identified through grammatical similarity calculation and dependency analysis, and corresponding slicing and grammatical completion are performed; (3) Using the predefined prompt template, combined with the patch signature and the vulnerable function signature, a migration prompt containing task description, constraint instructions, and specific input is generated; (4) Use the fine-tuned large language model to process the transfer prompts and generate the initial repair function signature; (5) Identify three types of anomalies through heuristic checking mechanisms: semantic anomalies, placeholder anomalies, and grammatical anomalies; (6) Based on the detected anomaly type, corresponding improvement prompts are generated to guide the large language model to perform iterative optimization until no anomalies are detected or the maximum number of iterations is reached; (7) Restore the code block corresponding to the placeholder and generate a complete repair function as the final output.

Images