Training method of vulnerability repair code recognition model, and code recognition method and device

Abstract

The invention provides a training method of a vulnerability repair code recognition model and a code recognition method and device.The training method comprises the steps that a historical vulnerability and code feature associated data engine is constructed and operated, and a training data set is obtained from the data engine; performing code decomposition of different levels on the code submission sample to obtain a code decomposition result, and performing code embedding processing on the code decomposition result to obtain an embedded vector; performing feature extraction on the embedded vector to obtain a feature vector, and performing feature fusion processing on the feature vector to obtain a fused feature vector; and training a to-be-trained vulnerability repair code recognition model based on the fusion feature vector to obtain the vulnerability repair code recognition model. Therefore, through multi-level code decomposition and feature fusion, the code recognition accuracy and efficiency of the vulnerability repair code recognition model are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a training method, code recognition method and apparatus for a vulnerability patching code recognition model. Background Technology

[0002] With the widespread adoption of open-source software across various fields, many systems are becoming increasingly reliant on it, leading to more prominent security risks. A significant challenge for users is the potential security vulnerabilities in third-party libraries. These vulnerabilities can be maliciously exploited, resulting in decreased system security and even data breaches and financial losses. To address this challenge, Software Composition Analysis (SCA) tools have emerged, whose primary responsibility is to analyze and identify potential vulnerabilities in systems.

[0003] After identifying a vulnerability, determining whether a remediation plan exists and implementing corresponding remediation measures becomes crucial. Currently, mainstream vulnerability remediation verification methods primarily rely on further analysis using vulnerability scanners and software composition analysis tools. This process typically includes version information verification, return information feature matching, manual configuration verification, and code walkthroughs. However, existing technologies have many shortcomings in practical applications.

[0004] First, existing tools have a high false positive rate, especially when the version information in the configuration file is tampered with, which can cause unnecessary confusion for users when dealing with vulnerabilities. Second, the remediation and verification processes are inefficient and costly in terms of manpower. Without sufficient contextual information, vulnerability remediation decisions often require manual intervention, increasing workload and complexity. This is particularly problematic in large enterprises where limited security professionals struggle to handle the massive number of hosts, applications, and components. Furthermore, individual factors can lead to false remediation, bypassing traditional vulnerability detection mechanisms. Third, existing technologies cannot effectively discover unknown or undisclosed vulnerabilities. Frequent updates to open-source software and the intertwining of vulnerability remediation with daily development mean that code changes are often complex and noisy. This noise can interfere with the vulnerability remediation analysis process, causing potential risks to be overlooked. Finally, existing solutions lack the ability to automatically extend analysis and prediction, and cannot adaptively adjust data marts to achieve efficient and rapid automated extended testing to identify potential security risks.

[0005] In summary, existing technologies suffer from high false positive rates and low efficiency in identifying vulnerability patching code. Summary of the Invention

[0006] This application provides a training method, code recognition method, and apparatus for a vulnerability patching code recognition model, in order to solve the problems of high false alarm rate and low efficiency in the prior art when recognizing vulnerability patching code.

[0007] To solve the above-mentioned technical problems, this application is implemented as follows:

[0008] In a first aspect, embodiments of this application provide a method for training a vulnerability patching code identification model, comprising:

[0009] A historical vulnerability and code feature association data engine is built and run, and a training dataset is obtained from the data engine; wherein, the training dataset includes multiple labeled code submission samples, and the labels are used to identify whether the code submission samples are used for vulnerability remediation;

[0010] The code submission sample is decomposed at different levels to obtain code decomposition results, which include: line code, block code, file code, and project code;

[0011] The code decomposition results are subjected to code embedding processing to obtain an embedding vector;

[0012] Feature extraction is performed on the embedded vector to obtain feature vectors, which include: row-level feature vectors, block-level feature vectors, file-level feature vectors, and project-level feature vectors.

[0013] The feature vectors are subjected to feature fusion processing to obtain fused feature vectors;

[0014] The vulnerability patching code identification model is trained based on the fused feature vectors to obtain the vulnerability patching code identification model.

[0015] Optionally, a historical vulnerability and code feature association data engine is built and run, and a training dataset is obtained from the data engine, including:

[0016] The code feature information is crawled from the code hosting platform, wherein the code feature information includes at least one of the following: change records, commit logs, version information, and code change descriptions;

[0017] Historical vulnerability information is crawled from official vulnerability platforms, including at least one of the following: general vulnerability disclosure CVE number, vulnerability description, affected versions, impact level, and remediation plan;

[0018] The code feature information and the historical vulnerability information are associated, and the data engine is constructed based on the associated code feature information and the historical vulnerability information. The data engine is then run to identify code submission samples used to fix vulnerabilities and other code submission samples from the data engine.

[0019] Based on the code submission samples used to fix the vulnerabilities, code security features are determined, wherein the code security features include at least one of the following: sensitive function calls, error handling logic, input validation, permissions and access control, code injection and encryption / decryption;

[0020] Based on the code submission samples used to fix vulnerabilities and the code security features, a positive sample dataset strongly correlated with the vulnerabilities is determined, and based on the remaining code submissions, a negative sample dataset not correlated with the vulnerabilities is determined.

[0021] The training dataset is composed of the positive sample dataset and the negative sample dataset.

[0022] Optionally, the code submission sample is decomposed at different levels to obtain the following code decomposition results:

[0023] The code submission sample is broken down into lines of code, resulting in a sequence of code lines composed of all modified lines of code arranged in order.

[0024] The code submission sample is decomposed into code blocks, resulting in code modification blocks consisting of consecutively modified lines of code.

[0025] The code submission sample is decomposed into file code to obtain the independent modification content of the file corresponding to the code submission sample;

[0026] The code submission sample is decomposed into project code to obtain all the modifications to the project corresponding to the code submission sample.

[0027] Optionally, the code decomposition results are subjected to code embedding processing to obtain embedding vectors, including:

[0028] The CodeBERT model uses a bidirectional code encoder to represent the code decomposition results, which are then transformed into high-dimensional vector representations.

[0029] The high-dimensional vector representation is processed using either context-dependent or context-independent representation to obtain the embedded vector;

[0030] Specifically, for the first type of code, the context-dependent representation is used, and the modifications in the first type of code are input into the CodeBERT model to obtain the corresponding fused embedding vector; wherein, the first type of code includes the file code and the project code;

[0031] For the second type of code, the context-free representation is used. The modifications in the second type of code are input into the CodeBERT model to obtain new code vectors and deleted code vectors. The new code vectors and deleted code vectors are then concatenated into a concatenated embedding vector. The second type of code includes line code, block code, and file code. The modifications include new content and deleted content. The new content corresponds to the new code vector, and the deleted content corresponds to the deleted code vector. The embedding vector includes the fused embedding vector and the concatenated embedding vector.

[0032] Optionally, before converting the code decomposition results into a high-dimensional vector representation using the CodeBERT model, the method further includes:

[0033] The code decomposition results are preprocessed using a preset model adaptive selector to obtain preprocessed code decomposition results. The preprocessing includes compression filtering, trimming, and merging.

[0034] Optionally, feature extraction is performed on the embedded vector to obtain a feature vector, including:

[0035] Using a Bidirectional Long Short-Term Memory (BiLSTM) network model, sequence feature extraction is performed on the row-level concatenated embedding vector obtained by the context-free representation, and the row-level feature vector is output.

[0036] Using a convolutional neural network (CNN) model, local pattern features are extracted from the block-level concatenated embedding vector obtained by the context-free representation, and the block-level feature vector is output.

[0037] Using the Fully Connected Network (FCN) model, global correlation feature extraction is performed on the file-level fused embedding vector obtained by the context-dependent representation and the file-level concatenated embedding vector obtained by the context-independent representation, and the file-level feature vector is output.

[0038] Using the fully connected network (FCN) model, global correlation feature extraction is performed on the fused embedding vector at the engineering level obtained by the context dependency representation, and the engineering-level feature vector is output.

[0039] Optionally, the feature vector is subjected to feature fusion processing to obtain a fused feature vector, including:

[0040] Construct a feature fusion layer, which includes a fully connected layer;

[0041] A dual-modal fusion path is adopted, and the file-level feature vector and the project-level feature vector are input into the fully connected layer in the feature fusion layer for processing to obtain the first fused feature vector;

[0042] Using a single-modal fusion path, the row-level feature vector, the block-level feature vector, and the file-level feature vector are first concatenated, and then the concatenated feature vector is input into the fully connected layer in the feature fusion layer for processing to obtain the second fused feature vector;

[0043] The first fusion feature vector and the second fusion feature vector are jointly determined as the fusion feature vector.

[0044] Secondly, embodiments of this application provide a code recognition method based on a vulnerability patching code recognition model, the method comprising:

[0045] The code to be detected is input into the vulnerability repair code recognition model; the raw probability output by the vulnerability repair code recognition model is obtained; wherein, the vulnerability repair code recognition model is trained using the method described in the first aspect; the raw probability is used to represent the probability that the code to be detected is code used for vulnerability repair;

[0046] Obtain the line number of the code to be detected;

[0047] Based on the number of lines of code, the final score is determined according to the preset perception adjustment mechanism and the original probability;

[0048] The final score is used to determine whether the code to be detected is code used for vulnerability patching.

[0049] Optionally, based on the number of lines of code, and according to a preset perception adjustment mechanism and the original probability, the final score is determined as follows:

[0050] From the historical training database of the vulnerability repair code identification model, obtain all code submission samples used for vulnerability repair, and determine the maximum number of lines of code in all code submission samples used for vulnerability repair.

[0051] The adjustment value is determined based on the maximum number of lines of code and the number of lines of code;

[0052] The final score is determined based on the adjusted value and the original probability; wherein, when the calculated result of the final score is less than zero, the final score is set to zero.

[0053] Optionally, determining whether the code to be detected is code used for vulnerability remediation based on the final score includes:

[0054] When the final score is greater than or equal to a preset threshold, the code to be detected is determined to be code used for vulnerability repair.

[0055] When the final score is less than the preset threshold, it is determined that the code to be detected is not code used for vulnerability repair.

[0056] Optionally, after determining that the code to be detected is code used for vulnerability remediation when the final score is greater than or equal to a preset threshold, the method further includes:

[0057] The code to be detected is matched with known vulnerabilities in a publicly available vulnerability database;

[0058] If no known vulnerability corresponding to the code under test is found in the publicly available vulnerability database, the code under test is identified as code used to fix potential undisclosed vulnerabilities.

[0059] Thirdly, embodiments of this application provide a training apparatus for a vulnerability patching code identification model, the apparatus comprising:

[0060] A building module is used to build and run a historical vulnerability and code feature association data engine, and obtain a training dataset from the data engine; wherein, the training dataset includes multiple labeled code submission samples, and the labels are used to identify whether the code submission samples are used for vulnerability remediation;

[0061] The first execution module is used to perform code decomposition at different levels on the code submission sample to obtain code decomposition results, which include: line code, block code, file code, and project code;

[0062] The code decomposition results are subjected to code embedding processing to obtain an embedding vector;

[0063] Feature extraction is performed on the embedded vector to obtain feature vectors, which include: row-level feature vectors, block-level feature vectors, file-level feature vectors, and project-level feature vectors.

[0064] The feature vectors are subjected to feature fusion processing to obtain fused feature vectors;

[0065] The vulnerability patching code identification model is trained based on the fused feature vectors to obtain the vulnerability patching code identification model.

[0066] Fourthly, embodiments of this application provide a code recognition device based on a vulnerability patching code recognition model, the device comprising:

[0067] An input module is used to input the code to be detected into a vulnerability patching code recognition model; to obtain the raw probability output by the vulnerability patching code recognition model; wherein, the vulnerability patching code recognition model is trained using the method described in the first aspect; the raw probability is used to represent the probability that the code to be detected is code used for vulnerability patching;

[0068] The second execution module is used to obtain the line number of the code to be detected;

[0069] Based on the number of lines of code, the final score is determined according to the preset perception adjustment mechanism and the original probability;

[0070] The final score is used to determine whether the code to be detected is code used for vulnerability patching.

[0071] Fifthly, embodiments of this application provide a network device, including: a processor, a memory, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the steps of a training method for a vulnerability patching code identification model as described in the first aspect, or, when the program is executed by the processor, it implements the steps of a code identification method based on a vulnerability patching code identification model as described in the second aspect.

[0072] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of a training method for a vulnerability patching code identification model as described in the first aspect, or, when the computer program is executed by the processor, it implements the steps of a code identification method based on a vulnerability patching code identification model as described in the second aspect.

[0073] In a seventh aspect, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of a training method for a vulnerability patching code identification model as described in the first aspect, or, when executed by the processor, implement the steps of a code identification method based on a vulnerability patching code identification model as described in the second aspect.

[0074] In summary, the method described in this application, by constructing a historical vulnerability and code feature association data engine, ensures that the training dataset originates from real vulnerability repair scenarios, thus providing the model with a high-quality, clearly labeled sample foundation. Based on this, multi-level code decomposition of code submission samples at the line, block, file, and project levels enables the model to comprehensively capture detailed features of code changes at different granularities. Furthermore, code embedding processing transforms abstract code elements into numerical embedding vectors, providing a semantically rich representation foundation for subsequent feature extraction. Multi-level feature vectors at the line, block, file, and project levels are then extracted from these embedding vectors, enabling the model to simultaneously learn local code logic and global project context information. Subsequently, these heterogeneous multi-level feature vectors are fused, effectively integrating feature information from different dimensions and enhancing the model's comprehensive representation ability of complex vulnerability repair patterns. Finally, the fused feature vectors are used to train the model, enabling it to more accurately learn the inherent patterns of vulnerability repair code. In conclusion, through multi-level feature extraction and fusion, the code recognition accuracy and efficiency of the vulnerability repair code identification model are significantly improved. Attached Figure Description

[0075] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0076] Figure 1 A flowchart illustrating a training method for a vulnerability remediation code identification model provided in this application embodiment;

[0077] Figure 2 A flowchart illustrating a code recognition method based on a vulnerability patching code recognition model provided in this application embodiment;

[0078] Figure 3 A flowchart illustrating a vulnerability patching code identification method provided in this application embodiment;

[0079] Figure 4 A schematic diagram illustrating an automated engine for constructing historical vulnerability and code feature association data, provided in an embodiment of this application;

[0080] Figure 5 This application provides a schematic diagram of multi-level polymorphism code decomposition.

[0081] Figure 6 A schematic diagram illustrating a code modification provided in an embodiment of this application;

[0082] Figure 7A file-level code breakdown diagram provided for an embodiment of this application;

[0083] Figure 8 This application provides a block-level code decomposition diagram.

[0084] Figure 9 A line-level code decomposition diagram provided for an embodiment of this application;

[0085] Figure 10 A schematic diagram illustrating code embedding as provided in an embodiment of this application;

[0086] Figure 11 A schematic diagram illustrating seven submission embedding settings provided in an embodiment of this application;

[0087] Figure 12 This is a schematic diagram illustrating a method for compressing and filtering code changes, provided as an embodiment of this application.

[0088] Figure 13 This application provides a schematic diagram of a code modification compression and filtering method as described in an embodiment.

[0089] Figure 14 A schematic diagram illustrating feature extraction and fusion provided in an embodiment of this application;

[0090] Figure 15 This is a schematic diagram of code for a dual-modal fusion method provided in an embodiment of this application;

[0091] Figure 16 This application provides a schematic diagram of code for a single-modal fusion method.

[0092] Figure 17 A schematic diagram illustrating the performance data of a model provided in this application on Java and Python as the form increases;

[0093] Figure 18 A schematic diagram illustrating the performance data of a model with and without an imperceptible adjustment mechanism in Java and Python, provided in an embodiment of this application;

[0094] Figure 19 A structural block diagram of a training device for a vulnerability repair code recognition model provided in an embodiment of this application;

[0095] Figure 20 A structural block diagram of a code recognition device based on a vulnerability repair code recognition model provided in this application embodiment;

[0096] Figure 21 This is a structural block diagram of a network device provided in an embodiment of this application. Detailed Implementation

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

[0098] Figure 1 This paper illustrates a training method for a vulnerability remediation code identification model according to an embodiment of this application, such as... Figure 1 As shown, the method includes:

[0099] Step S101: Build and run a historical vulnerability and code feature association data engine, and obtain a training dataset from the data engine;

[0100] The training dataset includes multiple labeled code submission samples, with the labels indicating whether the code submission samples are used for vulnerability patching.

[0101] Step S102: Perform code decomposition at different levels on the submitted code samples to obtain the code decomposition results;

[0102] The code breakdown results include: line code, block code, file code, and project code;

[0103] Step S103: Perform code embedding processing on the code decomposition results to obtain the embedding vector;

[0104] Step S104: Extract features from the embedded vector to obtain the feature vector;

[0105] The feature vectors include: row-level feature vectors, block-level feature vectors, file-level feature vectors, and project-level feature vectors.

[0106] Step S105: Perform feature fusion processing on the feature vectors to obtain fused feature vectors;

[0107] Step S106: Train the vulnerability repair code identification model to be trained based on the fused feature vector to obtain the vulnerability repair code identification model.

[0108] It should be noted that the core of the vulnerability repair code identification model training method proposed in this application lies in systematically learning and extracting deep features that can characterize vulnerability repair behavior from historical code data through a structured multi-stage processing flow.

[0109] This method begins by building and running a dedicated historical vulnerability and code feature association data engine. This engine integrates information from code hosting platforms and official vulnerability databases to obtain a high-quality training dataset. Each code submission sample in this dataset is clearly labeled to indicate whether it is used for vulnerability remediation, laying a reliable data foundation for subsequent supervised learning. Next, the obtained code submission samples undergo refined multi-level code decomposition, breaking down their content into code decomposition results at different granularities, such as line code, block code, file code, and project code. This aims to comprehensively cover everything from micro-level line changes to macro-level project modifications. Then, these different levels of code decomposition results are processed by code embedding, using tools such as bidirectional code encoder representation models to transform them into numerical embedding vectors, thereby capturing the semantic information of the code. Based on this, specialized feature extraction is performed on the embedding vectors at different levels, generating line-level, block-level, file-level, and project-level feature vectors respectively. This focuses on extracting key patterns related to vulnerability remediation at their respective granularities, such as line-level sequence patterns, block-level local structure patterns, and file- and project-level global context patterns. Subsequently, these heterogeneous feature vectors extracted from different dimensions are subjected to feature fusion processing. A specific fusion strategy is used to integrate them into a unified, more informative fused feature vector. Finally, this fused feature vector is used to train the vulnerability patching code recognition model, optimizing the model parameters to accurately identify vulnerability patching patterns in code submissions.

[0110] Overall, this training method effectively improves the accuracy and robustness of the final trained vulnerability patching code identification model in distinguishing between vulnerability patching code and non-vulnerability patching code through a coherent design from data construction, multi-level decomposition, semantic embedding, hierarchical feature extraction to feature fusion.

[0111] In one possible implementation, a historical vulnerability and code feature association data engine is constructed and run. The training dataset is obtained from the data engine by: crawling code feature information from a code hosting platform, where the code feature information includes at least one of the following: change history, commit logs, version information, and code change descriptions; crawling historical vulnerability information from an official vulnerability platform, where the historical vulnerability information includes at least one of the following: common vulnerability disclosure CVE number, vulnerability description, affected version, impact level, and remediation plan; associating the code feature information and historical vulnerability information, constructing and running the data engine based on the associated code feature information and historical vulnerability information, and identifying code submission samples used to fix vulnerabilities and other code submission samples from the data engine; determining code security features based on the code submission samples used to fix vulnerabilities, where the code security features include at least one of the following: sensitive function calls, error handling logic, input validation, permissions and access control, code injection, and encryption / decryption; determining a positive sample dataset strongly correlated with the fixed vulnerabilities based on the code submission samples used to fix vulnerabilities and the code security features, and determining a negative sample dataset related to non-fixed vulnerabilities based on the remaining code submissions; and the training dataset is composed of the positive sample dataset and the negative sample dataset.

[0112] It's important to note that the method first automatically crawls code signature information from code hosting platforms. This information includes key metadata such as change logs, commit logs, version information, and code change descriptions, used to characterize the behavior and content of the code submissions themselves. Simultaneously, the method crawls historical vulnerability information from official vulnerability platforms. This information typically includes core elements such as Common Vulnerabilities and Exposures (CVE) numbers, vulnerability descriptions, affected versions, impact levels, and remediation plans, providing authoritative evidence for accurate vulnerability identification. The core operation then involves correlating and integrating the code signature information and historical vulnerability information from different sources. Based on this correlated information, a structured data engine is constructed. During runtime, this data engine intelligently filters and identifies code submission samples explicitly used for vulnerability remediation, as well as other code submission samples unrelated to vulnerability remediation, serving as a comparison.

[0113] To further improve the quality and representativeness of the samples, we conducted in-depth analysis of the identified code submissions used to fix vulnerabilities, identifying their inherent code security features, such as sensitive function calls, error handling logic, input validation, permissions and access control, code injection, and encryption / decryption—patterns closely related to software security. Finally, by comprehensively utilizing the code submissions used to fix vulnerabilities and their associated code security features, we determined a high-quality positive sample dataset strongly correlated with vulnerability fixes. Simultaneously, we constructed a corresponding negative sample dataset using the remaining code submissions identified as unrelated to vulnerability fixes. This training dataset, composed of both positive and negative sample datasets, provides a highly discriminative and representative learning foundation for subsequent model training due to its reliable data sources, clear correlation logic, and enhancement through code security feature enhancement.

[0114] Overall, this approach effectively ensures the quality and relevance of the training dataset through a series of interconnected steps, including multi-source data collection, intelligent association, security feature enhancement, and positive and negative sample construction. This lays a solid data foundation for training a high-performance vulnerability remediation code identification model.

[0115] In one possible implementation, code submission samples are decomposed at different levels, yielding code decomposition results including:

[0116] The code submission sample is broken down into lines of code, resulting in a sequence of code lines composed of all modified lines of code arranged in order.

[0117] The code submission sample is broken down into code blocks, resulting in code modification blocks consisting of consecutively modified lines of code.

[0118] The code submission sample is broken down into file code, and the independent modification content of the file corresponding to the code submission sample is obtained.

[0119] The code submission sample is broken down into project code, resulting in all the modifications made to the project corresponding to the code submission sample.

[0120] It should be noted that, in one specific implementation described in this application, decomposing the code submission sample at different levels is a key step. The purpose is to systematically analyze the hierarchical structure of code changes from multiple dimensions. This method does not treat the code submission sample as an indivisible whole, but rather deconstructs its content according to different levels of abstraction and logical units through specific decomposition operations.

[0121] The specific decomposition process includes: breaking down the code commit sample into line-level code, resulting in a sequence of lines of code arranged strictly in the order they appear in the source file, which helps capture the linear sequence of code changes; further, breaking down the code commit sample into block code, where block code is not an arbitrary combination of lines of code, but specifically refers to code modification blocks naturally formed by lines of code that are continuously modified in context, which helps understand changes to code segments with inherent logical connections; on this basis, breaking down the code commit sample into file code, that is, obtaining the independent modification content of each file corresponding to the code commit sample, thereby examining the completeness and independence of changes at the file level; finally, breaking down the code commit sample into project code, which means summarizing and examining all the modifications involved in the project corresponding to the code commit sample from the global perspective of the entire project, in order to grasp the overall scale and scope of the changes. Through this series of decomposition operations from micro to macro, the final code decomposition results—namely, line code, block code, file code, and project code—provide standardized data representations with different granularities and perspectives for subsequent embedding and feature extraction processes.

[0122] Overall, this refined, multi-level code decomposition strategy enables the model to learn rich information about code changes in both local details and global context, laying a solid foundation for comprehensively and accurately identifying patterns unique to vulnerability fix code.

[0123] In one possible implementation, the code decomposition results are subjected to code embedding processing to obtain embedding vectors, including:

[0124] The code decomposition results are transformed into high-dimensional vector representations using the CodeBERT (Code Bidirectional Encoder Representations from Transformers) model.

[0125] The high-dimensional vector representation is processed using either context-dependent or context-independent representation to obtain the embedded vector;

[0126] For the first type of code, a context-dependent representation is used. The modifications in the first type of code are input into the CodeBERT model to obtain the corresponding fused embedding vector. The first type of code includes file code and project code.

[0127] For the second type of code, a context-free representation is used. The modifications in the second type of code are input into the CodeBERT model to obtain the newly added code vector and the deleted code vector. The newly added code vector and the deleted code vector are then concatenated into a concatenated embedding vector. The second type of code includes line code, block code, and file code. The modifications include newly added content and deleted content. The newly added content corresponds to the newly added code vector, and the deleted content corresponds to the deleted code vector. The embedding vector includes the fused embedding vector and the concatenated embedding vector.

[0128] It should be noted that, in one specific implementation described in this application, code embedding of the code decomposition results is a crucial step in transforming abstract code into a machine-understandable numerical representation. The core of this method is using the CodeBERT model as a powerful semantic understanding tool to convert code decomposition results at different levels (such as line code, block code, file code, and project code) into high-dimensional vector representations. To more accurately capture the semantic information of code at different granularities, this method employs differentiated processing strategies for the generated high-dimensional vector representations, specifically divided into context-dependent representation and context-independent representation.

[0129] For the first type of code, namely file code and project code, a context-dependent representation is adopted. The processing method is to treat the modifications (including additions and deletions) in the first type of code as a complete context and input them into the CodeBERT model. This allows the model to encode based on the inherent relationship between code elements and finally output a fused embedding vector that can reflect the overall semantics.

[0130] For the second type of code, including line code, block code, and file code, a context-free representation is used. The processing logic involves distinguishing between added and deleted content in this second type of code, and inputting them separately into the CodeBERT model to independently obtain a new code vector representing the semantics of added code and a deleted code vector representing the semantics of deleted code. Finally, these two vectors are concatenated to form a concatenated embedding vector that simultaneously contains both added and deleted information. Through this refined processing, the final set of embedding vectors includes fused embedding vectors and concatenated embedding vectors suitable for different scenarios.

[0131] Overall, this code embedding processing method, by combining the powerful CodeBERT model with targeted context representation strategies, successfully transforms code syntax and semantic information of different granularities into high-quality numerical vectors, providing rich and highly discriminative input features for subsequent feature extraction modules. This significantly enhances the model's ability to understand the intent of code modification and lays a solid semantic foundation for accurately identifying vulnerability repair code.

[0132] In one possible implementation, before converting the code decomposition results into a high-dimensional vector representation using the CodeBERT model, the method further includes: preprocessing the code decomposition results using a preset model adaptive selector to obtain preprocessed code decomposition results, wherein the preprocessing includes: compression filtering, pruning, and merging.

[0133] It should be noted that, in one specific implementation described in this application, before the core step of converting the code decomposition result into a high-dimensional vector representation using the CodeBERT model, an important preprocessing step is introduced. This step aims to optimize the incoming code decomposition result using a preset model adaptive selector, with the purpose of improving the quality and efficiency of subsequent code embedding processing. This preprocessing includes several targeted strategies such as compression filtering, pruning, and merging.

[0134] Specifically, compression and filtering primarily target and eliminate redundant or irrelevant information (such as redundant spaces, comments, or semantically unrelated symbols) in the code to focus on the core code logic. Trimming is used when code snippets are too long for the model's processing capacity, intelligently truncating or sampling them to ensure key information is preserved while meeting the model's input length limits. Merging, on the other hand, may rationally integrate logically related but physically separated small code snippets to form more meaningful analysis units. After this series of preprocessing operations, the original code decomposition results are transformed into cleaner, more organized, and easier-to-understand preprocessed code decomposition results.

[0135] Overall, this preprocessing step, acting as a pre-optimizer, effectively reduces noise interference and optimizes data structure and information density by actively cleaning and reshaping the input data. This lays a solid data foundation for the subsequent CodeBERT model to generate high-dimensional vector representations more stably and accurately, indirectly improving the robustness of the entire process and the feature learning performance of the final model.

[0136] In one possible implementation, feature extraction is performed on the embedding vector to obtain the feature vector, including:

[0137] The BiLSTM (Bidirectional Long Short-Term Memory network) model is used to extract sequence features from the row-level concatenated embedding vectors obtained by using context-free representation, and output row-level feature vectors.

[0138] Using a CNN (Convolutional Neural Network) model, local pattern features are extracted from the block-level concatenated embedding vector obtained by using context-free representation, and the block-level feature vector is output.

[0139] Using the FCN (Fully Connected Network) model, global correlation feature extraction is performed on the file-level fused embedding vector obtained by context-dependent representation and the file-level concatenated embedding vector obtained by context-independent representation, and the output file-level feature vector is generated.

[0140] Using the FCN model, global correlation feature extraction is performed on the engineering-level fused embedding vector obtained by context-dependent representation, and the engineering-level feature vector is output.

[0141] It should be noted that, in one specific implementation described in this application, feature extraction of the embedding vector is a crucial step. The goal is to extract the most discriminative high-order features from code embedding representations of different granularities. This method does not employ a single model; instead, it specifically selects the most suitable neural network architecture for targeted processing based on the inherent characteristics of embedding vectors at different levels.

[0142] Specifically, for line-level concatenated embedding vectors, which essentially represent sequential data of line modifications, the method uses a BiLSTM model to capture long-distance dependencies and contextual sequence patterns between lines, thus outputting line-level feature vectors containing sequential features. For block-level concatenated embedding vectors, which represent code blocks composed of consecutive lines, the method uses a CNN model to scan and extract local syntactic or structural patterns (such as specific function call patterns), thus outputting block-level feature vectors that characterize key local features. For file-level information, the method uses an FCN model, processing both the file-level fused embedding vector obtained using context-dependent representation and the file-level concatenated embedding vector obtained using context-independent representation. This aims to fuse the overall semantics of the file and internal addition / deletion details for global correlation feature extraction, ultimately outputting a comprehensive file-level feature vector. For the highest level of abstraction, the engineering-level fused embedding vector, the FCN model is also used, focusing on extracting high-level, generalized global correlation features from a project-wide perspective and outputting an engineering-level feature vector.

[0143] Overall, this feature extraction process precisely matches embedding vectors at four different levels—line, block, file, and project—with deep learning models such as BiLSTM, CNN, and FCN, which have different characteristics. This maximizes the extraction of multi-level and complementary deep features from code change data, providing a rich and high-quality feature representation foundation for the final feature fusion and accurate classification.

[0144] In one possible implementation, feature fusion processing of the feature vectors to obtain a fused feature vector includes: constructing a feature fusion layer, which contains a fully connected layer; using a dual-modal fusion path, inputting the file-level feature vector and the project-level feature vector into the fully connected layer of the feature fusion layer for processing to obtain a first fused feature vector; using a single-modal fusion path, first concatenating the row-level feature vector, block-level feature vector, and file-level feature vector, and then inputting the concatenated feature vector into the fully connected layer of the feature fusion layer for processing to obtain a second fused feature vector; and finally, using the first fused feature vector and the second fused feature vector together to determine the fused feature vector.

[0145] It should be noted that, in one specific implementation described in this application, feature fusion processing of the feature vectors is a key step in integrating multi-level feature information. This method first constructs a dedicated feature fusion layer, which contains fully connected layers for nonlinear transformation and combination of features. Regarding the fusion strategy, this method designs two parallel fusion paths: one is a dual-modal fusion path, which inputs both file-level and project-level feature vectors into the fully connected layer of the feature fusion layer for processing. This aims to fuse the features of two high-level modalities: global information within the file and global information across the project scope, thereby obtaining a first fused feature vector that reflects the cross-file project-level context.

[0146] The second approach is the single-modal fusion path. This path first directly concatenates three feature vectors of different granularities: line-level feature vectors representing micro-level code line changes, block-level feature vectors representing local code block patterns, and file-level feature vectors, to form a comprehensive feature vector. This concatenated feature vector is then fed into a fully connected layer in the feature fusion layer for deep integration. The purpose is to uniformly encode information from multiple levels, from lines of code to blocks of code to the internal structure of files, that all belong to the code change detail modalities, thereby obtaining a second fused feature vector that can meticulously characterize code modification patterns.

[0147] Finally, the first fusion feature vector obtained through the dual-modal fusion path and the second fusion feature vector obtained through the single-modal fusion path are jointly determined as the final set of fusion feature vectors.

[0148] Overall, this feature fusion processing method cleverly integrates high-level global context information and low-level specific modification details by constructing a feature fusion layer with dual paths. This results in a final fused feature vector that combines macroscopic vision with microscopic precision, providing more comprehensive and richer input features for vulnerability repair code identification models. This significantly enhances the model's ability to comprehensively judge complex vulnerability repair patterns.

[0149] In summary, the method described in this application, by constructing a historical vulnerability and code feature association data engine, ensures that the training dataset originates from real vulnerability repair scenarios, thus providing the model with a high-quality, clearly labeled sample foundation. Based on this, multi-level code decomposition of code submission samples at the line, block, file, and project levels enables the model to comprehensively capture detailed features of code changes at different granularities. Furthermore, code embedding processing transforms abstract code elements into numerical embedding vectors, providing a semantically rich representation foundation for subsequent feature extraction. Multi-level feature vectors at the line, block, file, and project levels are then extracted from these embedding vectors, enabling the model to simultaneously learn local code logic and global project context information. Subsequently, these heterogeneous multi-level feature vectors are fused, effectively integrating feature information from different dimensions and enhancing the model's comprehensive representation ability of complex vulnerability repair patterns. Finally, the fused feature vectors are used to train the model, enabling it to more accurately learn the inherent patterns of vulnerability repair code. In conclusion, through multi-level feature extraction and fusion, the code recognition accuracy and efficiency of the vulnerability repair code identification model are significantly improved.

[0150] Figure 2 This invention illustrates a code recognition method based on a vulnerability patching code recognition model, according to an embodiment of this application. Figure 2 As shown, the method includes:

[0151] Step S201: Input the code to be detected into the vulnerability patching code identification model; obtain the raw probability output by the vulnerability patching code identification model;

[0152] The original probability represents the probability that the code to be detected is code used for vulnerability patching;

[0153] Step S202: Obtain the line number of the code to be detected;

[0154] Step S203: Based on the number of lines of code, determine the final score according to the preset perception adjustment mechanism and the original probability;

[0155] Step S204: Determine whether the code to be detected is code used for vulnerability repair based on the final score.

[0156] It should be noted that the core of the code recognition method based on the vulnerability repair code recognition model described in the embodiments of this application lies in using the vulnerability repair code recognition model trained in the above embodiments to make actual predictions, and introducing a post-processing mechanism to optimize the reliability of the prediction results.

[0157] The method begins by inputting the code to be analyzed into a pre-trained vulnerability patching code identification model. This model calculates based on complex patterns learned internally and outputs a raw probability value, which directly represents the initial likelihood that the model considers the code to be used for vulnerability patching. Next, an objective metric for the code to be analyzed—the number of lines of code in the submission—is obtained in parallel. Then, based on the obtained number of lines of code, a comprehensive calculation is performed using a pre-defined perceptual adjustment mechanism and the raw probability output by the model to determine a more accurate and robust final score than the raw probability.

[0158] Therefore, the prior knowledge that "vulnerability fix code submissions typically involve a small number of lines of code" is incorporated into the judgment logic through a mathematical adjustment mechanism, aiming to correct misjudgments that the model might make by ignoring the scale of modifications. Finally, a decision is made based on the calculated final score: when the final score reaches or exceeds a certain preset threshold, the code to be tested is determined to be a modification made to fix a vulnerability; otherwise, it is determined to be a normal code submission that is not for vulnerability fix.

[0159] Overall, this approach not only enhances the credibility of identification results by adding a line-of-code rationality check on top of the model's intelligent judgment, but also significantly reduces the probability of misreporting large-scale ordinary code submissions as vulnerability fixes by introducing a perceptual adjustment mechanism as a post-processing strategy. Thus, it achieves high-precision and high-efficiency vulnerability fix code identification as a whole.

[0160] In one possible implementation, determining the final score based on the number of lines of code, according to a preset perception adjustment mechanism and the original probability, includes: obtaining all code submission samples used for vulnerability repair from the historical training database of the vulnerability repair code identification model, and determining the maximum number of lines of code for all code submission samples used for vulnerability repair; determining an adjustment value based on the maximum number of lines of code and the number of lines of code; and determining the final score based on the adjustment value and the original probability; wherein, when the calculated result of the final score is less than zero, the final score is set to zero.

[0161] It should be noted that, in one specific implementation described in this application, the specific process for determining the final score based on the number of lines of code, a preset perception adjustment mechanism, and the original probability is as follows: The mechanism first retrieves all code submission samples marked as used for vulnerability remediation during the training phase from the historical training database upon which the vulnerability remediation code identification model relies. Then, it statistically analyzes a key statistic of these positive samples—the maximum number of lines of code contained in all code submission samples used for vulnerability remediation—and determines this as the "maximum number of lines of code." This maximum number of lines of code serves as a threshold benchmark learned from historical experience, representing the maximum scale of code changes that a typical vulnerability remediation submission may involve within the scope of the training data.

[0162] Subsequently, the perception adjustment mechanism calculates an adjustment value based on the maximum number of lines of code obtained from historical statistics and the actual number of lines of code in the current code to be detected, using a specific mathematical relationship (e.g., reflecting the degree to which the number of lines of code to be detected exceeds historical experience values). This adjustment value is then combined with the original probability directly output by the vulnerability patch code identification model (e.g., the original probability minus the adjustment value) to determine a final score adjusted based on prior knowledge of historical scale. It should be noted that this mechanism also includes a boundary handling rule: when the result of the above combination operation is less than zero, the final score is forcibly set to zero. This setting ensures that the final score will not result in a meaningless negative score, and also clearly identifies submissions with code lines far exceeding the scale of common historical vulnerability patches, whose original probabilities drop sharply after adjustment, as highly unlikely to be vulnerability patches.

[0163] Overall, this perception adjustment mechanism, by introducing the scale characteristics (maximum number of lines of code) of historical vulnerability repairs as an objective calibration basis, rationally corrects the original probability output of the model, effectively reducing the possibility of misjudging submissions with excessively large code changes that do not meet the typical vulnerability repair characteristics as vulnerability repairs, thereby significantly improving the accuracy and robustness of the final judgment results.

[0164] In one possible implementation, determining whether the code to be tested is code used for vulnerability remediation based on the final score includes: when the final score is greater than or equal to a preset threshold, determining that the code to be tested is code used for vulnerability remediation; when the final score is less than the preset threshold, determining that the code to be tested is not code used for vulnerability remediation. Furthermore, after determining that the code to be tested is code used for vulnerability remediation when the final score is greater than or equal to the preset threshold, the method further includes: matching the code to be tested with known vulnerabilities in a publicly available vulnerability database; when no known vulnerability corresponding to the code to be tested is found in the publicly available vulnerability database, marking the code to be tested as code used to remediate a potential undisclosed vulnerability.

[0165] It should be noted that in the implementation described in this application, a binary judgment is first made on the final score based on a preset threshold: when the calculated final score is greater than or equal to the preset threshold, it is determined that the code to be detected is a code submission made to fix a vulnerability; conversely, when the final score is less than the preset threshold, it is determined that the code to be detected does not belong to the code used for vulnerability repair. Based on this, the method also includes a further in-depth analysis step: for code that has been determined to be used for vulnerability repair (i.e., the final score is greater than or equal to the preset threshold), it is matched and verified against known vulnerability information in a publicly available vulnerability database (such as a database containing CVE numbers); if no known vulnerability record corresponding to the current code to be detected is found in the publicly available vulnerability database, this result suggests that the current repair may target a security issue that is not yet widely known through public channels. In this case, the method will identify the code to be detected as code used to fix a potential undisclosed vulnerability.

[0166] Overall, this judgment and subsequent processing procedure not only achieves efficient and automated identification of vulnerability patching code through preset thresholds, but also expands the method's insight capabilities by introducing a matching and verification step with a public vulnerability database. This enables it not only to identify patches for known vulnerabilities, but also to effectively filter out code modifications that may indicate potential, undisclosed security threats, thereby greatly enhancing the ability to perceive and warn of unknown security risks.

[0167] In summary, the method described in this application, by constructing a historical vulnerability and code feature association data engine, ensures that the training dataset originates from real vulnerability repair scenarios, thus providing the model with a high-quality, clearly labeled sample foundation. Based on this, multi-level code decomposition of code submission samples at the line, block, file, and project levels enables the model to comprehensively capture detailed features of code changes at different granularities. Furthermore, code embedding processing transforms abstract code elements into numerical embedding vectors, providing a semantically rich representation foundation for subsequent feature extraction. Multi-level feature vectors at the line, block, file, and project levels are then extracted from these embedding vectors, enabling the model to simultaneously learn local code logic and global project context information. Subsequently, these heterogeneous multi-level feature vectors are fused, effectively integrating feature information from different dimensions and enhancing the model's comprehensive representation ability of complex vulnerability repair patterns. Finally, the fused feature vectors are used to train the model, enabling it to more accurately learn the inherent patterns of vulnerability repair code. In conclusion, through multi-level feature extraction and fusion, the code recognition accuracy and efficiency of the vulnerability repair code identification model are significantly improved.

[0168] This paper introduces the vulnerability remediation code identification method shown in the embodiments of this application from the perspective of specific application scenarios. This method can comprehensively and in real-time detect and predict whether code vulnerability change submissions are used for vulnerability remediation. Specifically, by constructing a vulnerability and code rule data engine, integrating multi-level polymorphism for code decomposition, code embedding, feature extraction, different levels of neural network algorithm fusion models, and an effort perception mechanism, it better addresses the noise and highly imbalanced characteristics of vulnerability remediation submission data. Furthermore, the method shown in the embodiments of this application constructs a highly flexible and complex intelligent identification system, ensuring that it can predict with excellent accuracy and robustness when facing complex and ever-changing code vulnerability remediation submissions, and can identify potential risks similar to 0-day vulnerabilities. 0-day vulnerabilities, also known as zero-day vulnerabilities or zero-time-difference vulnerabilities, refer to vulnerabilities that are known or publicly disclosed before the system developer releases a patch. These vulnerabilities are usually discovered by personnel not directly involved in the project, and therefore no patch is available. The specific process of the method shown in the embodiments of this application (refer to...) Figure 3 )as follows:

[0169] Step 1: Automated construction of a historical vulnerability and code feature association data engine (e.g., Figure 4 (As shown)

[0170] First, the engine automatically crawls code change records, commit logs, corresponding versions, code change descriptions, and code comments from code hosting platforms such as GitHub and GitLib. Second, it uses keyword search to match all historical vulnerabilities (including but not limited to CVE, CWE, NVD, CNNVD, etc.) of the correct project from official vulnerability platforms (including but not limited to CVE, CWE, NVD, CNNVD, etc.). After collecting the information, the engine will associate and identify it, process and analyze it according to the following logic, and output code snippets (lines, blocks, files, projects) that address CVE vulnerabilities. The output will also summarize sensitive function calls, error handling logic, input validation, permissions and access control, code injection, encryption and decryption, etc.

[0171] Based on this processing logic, two types of data are output: one type is a dataset strongly related to vulnerability remediation, where the dataset is refined and categorized according to OWASP10 classifications (e.g., SQL injection: [prepareStatement | Hibernate (Java) | mysqli_real_escape_string | ... ], XSS: [htmlspecialchars | escape_html | Encoders.htmlEncode | ...]); the other type is a dataset related to non-remediation vulnerabilities, categorized according to common types, including log printing, error and exception handling, and functional logic adjustments. These two types of data together constitute a vulnerability and code feature association data engine. This engine automatically updates the data mart through periodic monitoring, updating, and learning, as follows:

[0172] To automate the updating of data mart feature data and achieve an efficient discovery mechanism, especially for vulnerability information in open-source software / components, this application proposes an automatic update method based on semantic recognition. This method involves monitoring public opinion on the internet (various vulnerability platforms), analyzing multiple keyword databases, segmenting the search results into sentences to obtain multiple sentences or words, and then generating simplified vulnerability descriptions through natural language processing. For example, for the latest vulnerability in WebLogic, after natural language processing, the simplified statement is: "WebLogic CVE-2023-212308 is an SQL injection vulnerability." This method helps to automatically update the software behavior vulnerability database.

[0173] Next, feature vector extraction and analysis of the text content transforms text processing into vector operations in a vector space to represent semantic similarity. Cosine distance is used as a similarity metric, which assesses document similarity by calculating the cosine of the angle between the vectors. Feature terms and their weights are used to represent target information and evaluate the relevance between unknown text and target samples. This method transforms the text similarity problem into a vector similarity problem, thereby acquiring new valuable vulnerability data and updating the vulnerability dataset.

[0174] Through the above steps, text similarity is transformed into a similarity problem between two vectors, thereby obtaining valuable vulnerability information. Simultaneously, it automatically retrieves code change information for the corresponding project. Using this method, it is possible to quickly retrieve vulnerability information, rapidly identify the corresponding project, capture code information, and then proceed to keyword matching or machine learning to efficiently update the overall feature engine data mart.

[0175] Step Two: Multi-level Polymorphic Code Decomposition (e.g.) Figure 5 (As shown)

[0176] In principle, each block of code changes within a set of files represents the differences in that specific file, using a sequence of lines of code. This stage extracts information from multiple levels of morphological hierarchy, specifically four levels: line, block, file, and commit. For example, at the line code level, code changes are broken down into single lines, and each input commit is treated as a sequence of lines of code (LOCs). Through this process, the following four levels of input commit representations are ultimately obtained: line code, block code, file code, and project code (see reference). Figure 6 )

[0177] Figure 6 This shows the structure of the code changes. Commit 1 involves changes to two files: File 1 and File 2. File 1 modifies blocks 1 and 2, and File 2 modifies blocks 3 and 4. Each block contains two lines of modified code, from line 1 to line 8. Different types of snippets are shown below:

[0178] Submission code: {submission 1,...}

[0179] File code: {file1, file2,...}

[0180] Block code: {block1, block2, block3, block4,...}

[0181] Lines of code: {line 1, line 2, line 3, line 4, line 5, line 6, line 7, line 8...}

[0182] Decomposing code commits treats the entire project commit as a whole, ignoring the internal file or code block structure; decomposing file code, on the other hand, treats each file change in a commit as an independent unit, making it easier to identify change patterns for specific files. If a commit involves multiple files, then changes to each file are considered separately, such as... Figure 7 As shown. The breakdown of code blocks further subdivides file changes into blocks, each block typically containing a set of related line changes, such as... Figure 8 As shown. Line-by-line code decomposition breaks each block down into individual lines, enabling the model to capture the finest morphological changes, such as... Figure 9 As shown.

[0183] A multi-level, polymorphic code decomposition strategy provides different levels of code change information for subsequent feature extraction, which is then used to train and predict models to identify vulnerability fix submissions. This approach allows for analysis of code changes from multiple perspectives, improving the accuracy of vulnerability fix submission identification.

[0184] Step 3: Code embedding (e.g.) Figure 10 (As shown)

[0185] In step three, the method shown in this embodiment automatically converts the code snippet into a high-dimensional vector representation using CodeBERT. The specific operation is as follows:

[0186] 1. Prepare the input format: According to CodeBERT requirements, the input needs to include some special markers, such as '[CLS]' (start), '[SEP]' (separator) and '[EOS]' (end).

[0187] 2. Context Dependency Representation: Added and deleted code are treated as a whole, taking into account their contextual dependencies. The input format is as follows:

[0188]

[0189] This representation is passed to the CodeBERT model, and the output of the [CLS] tag is taken as the initial embedding vector for the code snippet.

[0190] 3. Context-free representation: The addition and deletion codes are treated as two unimodal data points and processed separately, without considering the relationship between them. The input format is as follows:

[0191]

[0192]

[0193] These two representations yield the initial embedding vectors for the newly added and deleted code, respectively.

[0194] 4. Merge Embedded Vectors: Integrate the embedded vectors of different code snippets into a unified representation for use by subsequent models.

[0195] Since CodeBERT is pre-trained for both bimodal and unimodal data, code changes, especially additions and deletions, can be viewed differently when processing code submissions. Based on the existence of source code context, these representations are divided into context-dependent and context-independent representations. Combining four levels and two different forms of code snippet modalities, we obtain... Figure 11 The seven submission embedding settings are shown. Figure 7 The document outlines how different morphological levels handle code variations in commits using different representations and feature extractors. For example, fully connected networks (FCNs) are used at the commit and file levels, while convolutional neural networks (CNNs) are used at the block level. At the line level, bidirectional LSTMs are used to handle context-independent representations.

[0196] It's important to note that code embedding is a crucial step in the entire system, responsible for transforming raw code data into a numerical representation that machine learning models can process. This allows the use of machine deep learning to identify bug fix submissions. To ensure the model's adaptability, a model adaptive selector is included, which performs compression, filtering, pruning, and merging operations based on different code changes. This mechanism improves the efficiency and accuracy of the analysis because it allows the system to preprocess and optimize data before passing it to a specific model.

[0197] The basic workflow for compression, filtering, trimming, and merging operations is as follows:

[0198] Compression filtration (e.g.) Figure 12 and 13 As shown): Filtering out code changes that are unlikely to contain useful information, such as automatically generated code, changes to comments, or known non-security-related changes, can quickly filter code change information, perform compression calculations, and improve work efficiency.

[0199] Pruning: For code changes that contain a lot of irrelevant information, pruning can help narrow down the scope of the analysis and focus on the parts that are most likely to contain key information.

[0200] Merging: Combine multiple small code changes into a larger context to better understand the overall impact of the changes, especially when dealing with changes involving multiple files or multiple commits.

[0201] In this way, the model selector acts as a preliminary data processing step, dynamically adjusting the input data to meet the needs of the subsequent model. This approach helps improve the flexibility of data processing and the responsiveness of the model, especially when dealing with complex, constantly changing code data.

[0202] Step 4: Feature extraction and fusion (e.g.) Figure 14 (As shown)

[0203] Since the features at the four different morphological levels are distinct, corresponding models need to be designed for each level to effectively extract features. Overall, feature extraction for each morphology follows a general structure, including a feature extractor and a feature fusion layer. Each base model is equipped with a customized feature extractor and a shared feature fusion layer. The feature extractor is optimized for different morphological levels, while the feature fusion layer is applicable to all morphological levels. The following is a detailed explanation of each step:

[0204] Feature Extractor: Four deep learning models are used as feature extractors to extract features at different morphological levels. For each submission, the feature extractor takes as input an embedding vector corresponding to a specific morphological level and outputs a feature vector. Specifically:

[0205] Line-level feature extraction: Line-level changes in code occur sequentially. Recurrent Neural Networks (RNNs) are used to extract line-level features, as they excel at handling sequential data, especially since each line of code change can be considered a sequence. A bidirectional BiLSTM model is employed, capable of both forward (from the first to the last line of code) and backward (from the last to the first line of code) reading of submitted code changes. The final output of the LSTM is used as the submitted features. The formula is expressed as:

[0206]

[0207] Block-level feature extraction: While there may be no explicit sequential relationship between code blocks (hunks), adjacent blocks may have dependencies, such as shared variables, constants, or function calls. Therefore, a convolutional neural network (CNN) is used. Given a set of block-level embedding vectors decomposed from a submission... First, information from adjacent code blocks is aggregated using convolutional layers, and then the most important features are extracted using max pooling layers. The formula is expressed as:

[0208]

[0209] File-level feature extraction: At the file level, it is necessary to capture the relationships between all files in the submission. Therefore, a fully connected neural network (FCN) is used to capture the relationships between all files. Given the embedding vector set of a file-level code snippet... By concatenating the feature vectors of all files together, a dimension of ... The vector is then used to extract features through a fully connected layer. The formula is expressed as:

[0210]

[0211] Here, ⊕ represents a splicing operation.

[0212] Engineering-level feature extraction: Similar to document-level feature extraction, engineering-level feature extraction also employs fully connected layers. Given an engineering-level embedding vector generated by CodeBERT... The output features are obtained through a fully connected layer. The formula is expressed as:

[0213]

[0214] These feature extractors at different levels can effectively capture features at various levels in the submission, providing data information for subsequent analysis.

[0215] Feature fusion: After extracting feature vectors through the above steps, a set of fully connected layers is constructed for feature fusion. Two different feature fusion methods are used depending on the code embedding method, corresponding to two representations (context-dependent and context-independent), as detailed below:

[0216] Bimodal fusion involves two different types of data. In code vulnerability remediation scenarios, it's necessary to combine the multi-level polymorphic characteristics of the code (such as code complexity, dependencies, etc.) and dynamic analysis characteristics (such as runtime errors, performance metrics, etc.), such as... Figure 15 As shown. For the context-dependent approach, only one feature vector can be obtained, so it is directly input into the linear layer for feature fusion.

[0217] Single-modal fusion: Feature fusion across data of the same type. For example, in code vulnerability fixing scenarios, only changes to the code itself are considered, such as the number of lines of code added or deleted, the complexity of the changes, etc. Figure 16 As shown. For the context-independent approach, two feature vectors are obtained: one for the added code and one for the deleted code. These two vectors are concatenated into a single vector, which is then input into a linear layer for feature fusion. Through these two methods, effective feature fusion is performed based on different code representations, extracting useful information.

[0218] Step 5: Neural Network Classifier and Perceptual Adjustment

[0219] Neural Network Classifier: For the submission features extracted from the extractor, a neural network classifier is used to predict whether the submission is used to fix a vulnerability. To achieve this, the submission features, which are extracted at multiple morphological levels, are first concatenated and then fed into two fully connected layers, outputting the probability that a given submission is used to fix a vulnerability.

[0220] Perception Adjustment: Considering the length and workload of code submissions, a perception adjustment mechanism is proposed to improve the efficiency of vulnerability detection under limited review resources. The mechanism aims to adjust the output of the vulnerability remediation classifier based on the submission length, thereby prioritizing shorter vulnerability remediation submissions. The perception adjustment function is defined as follows:

[0221]

[0222] in, It is an adjustment value for the neural classifier's predicted probability for the number of lines of code submitted, c. The value is directly proportional to the number of lines of C code; the more lines of code, the larger the adjustment value. Defined as:

[0223]

[0224] 'a' represents the maximum number of lines of code submitted for vulnerability fixes in the training dataset. Greater than or equal to 1 and less than a, therefore, for any submission in the training dataset, The value is limited to between 0 and 1.

[0225] Therefore, the perception adjustment function can be modified as follows:

[0226]

[0227] The output probability of the neural classifier is adjusted through a perceptual adjustment mechanism to obtain the final score for each submission, as shown below:

[0228]

[0229] c is the number of lines of code committed. It is the output probability of the neural classifier. This refers to the perceptual adjustment value calculated for c. In practice, there might be vulnerability fix submissions with a length greater than c, leading to... Negative values ​​are typically only checked. Negative value exceptions are ignored, meaning only shorter commits are checked. The limit is 0.

[0230] therefore, Change to:

[0231] In summary, the perceptual adjustment mechanism modifies the predicted probabilities of all submitted data in the test dataset and affects probability-based evaluation metrics, including AUC, Cost Effort@L, and @L.

[0232] Step Six: Training and Optimization

[0233] Training: Using the historical vulnerability and code feature association data engine from Step 1 as the training dataset, multiple feature extractors are trained for different commit embedding settings. Each base model consists of CodeBERT and a feature extractor, used to classify commits. Training of the base model is completed in one fold. Using CodeBERT requires significant resources, and this training method is only suitable for base models with fewer code snippets in commits, such as project-level and file-level models. For other base models (such as line-level and block-level), the training process can be divided into two steps: First, fine-tune CodeBERT to determine whether a code snippet is used to fix a vulnerability. Since the dataset only contains ground truth labels for the entire commit, it is assumed that if a code snippet comes from a commit that fixes a vulnerability, it is related to the vulnerability. Second, after fine-tuning, all parameters of CodeBERT are fixed, and the extracted embeddings are used to train the corresponding feature extractor.

[0234] During the ensemble training phase, no modifications are made to the previously trained base models. Instead, the parameters of these models are fixed, and only the neural classifier is trained. This ensures that the knowledge of these base models remains unchanged. The neural classifier then combines the outputs of each base model to make the final classification prediction. This approach allows for more efficient use of existing base models, improving the overall model performance.

[0235] Optimization: As a model submitted for vulnerability detection and remediation, the goal is to reduce the probability of incorrect predictions across the entire training dataset, achieved by minimizing cross-entropy loss. The Adam algorithm is used to adjust the weights in the neural network, helping the model learn faster. During this process, the learning rate is set to 0.00001 to help the model improve steadily during training. In the initial training phase, each base model is fine-tuned once using CodeBERT, a pre-trained model that helps the model better understand the code. Then, the base models are further trained on the training data. To prevent overfitting, if the model's performance on the validation data does not improve within five consecutive epochs (i.e., the cross-entropy loss does not decrease), the current training process automatically stops. Each base model is trained for a maximum of 60 epochs.

[0236] During the ensemble training phase, the neural classifier is trained at a learning rate of 0.00001 for 20 epochs. The goal is to combine the predictions from multiple base models to improve overall detection performance.

[0237] Step Seven: Assessment

[0238] To facilitate cross-sectional comparisons, conventional evaluation metrics are used: AUC (Area Under the ROC Curve) and two perceptual metrics. AUC accurately represents the probability of submitting a vulnerability fix submission (positive example) before submitting a non-vulnerability fix submission (negative example).

[0239] "Probability" refers to the likelihood that a randomly selected negative example will be incorrectly ranked ahead of a randomly selected positive example in the model's predicted ranking. If the model performs poorly, it may incorrectly identify non-vulnerability-fixing submissions (negative examples) as vulnerability-fixing submissions (positive examples), thus causing negative examples to rank ahead of positive examples. The lower the predicted probability value, the more accurately most genuine vulnerability-fixing submissions are ranked first, while non-vulnerability-fixing submissions are ranked last.

[0240] The AUC formula is as follows:

[0241]

[0242] in, It is the number of positive examples in the ranking. This represents the number of positive examples, indicating the submission of vulnerability fixes. The number of negative examples represents the number of non-vulnerability fix submissions. ,in, It is the ranking of the i-th vulnerability fix submission in the descending sequence list of the outputs generated by each model.

[0243] CostEffort@L: Represents the number of vulnerability fix submissions detected when checking L% of lines of code (LOC). The higher the value, the better the model's effectiveness. Popt@L: Represents the performance related to the awareness adjustment mechanism at different L% of lines of code (5%, 10%, 15%, 20%).

[0244] It should also be noted that in the experiment, the calculation of four consecutive L values... The performance of @L, where L is 5, 10, 15 and 20 respectively.

[0245] and Figure 17 The performance of the model in Java and Python as the form increases. Figure 18 The performance of the model in Java and Python is evaluated by whether it has an imperceptible tuning mechanism.

[0246] Step 8: Make predictions using a trained multi-level, multi-attitude machine learning model.

[0247] Deploy this model into CI (Continuous Integration) / CD (Continuous Deployment) or SDL (Security Development Lifecycle) processes to predict and rank submitted code vulnerability fixes in real time. By inputting real-time code vulnerability fix submission data from the actual development environment into the model for prediction, the model can identify truly important vulnerability fix submissions based on its previous training experience, thereby improving software security and work efficiency.

[0248] In addition, the model possesses the ability to identify potential vulnerabilities and automatically and elastically expand its prediction capabilities: Code changes are often complex and contain noise, which may interfere with the vulnerability remediation analysis process and results. It is currently difficult to identify potentially hidden, undisclosed vulnerability information, which could be maliciously exploited to exploit vulnerabilities in older software versions, attack them, or even steal critical system data. In the method shown in the embodiments of this application, the model can automatically correlate and analyze code change records, change history, and vulnerability data to discover vulnerability information or security-related information that has not been officially disclosed but has actually been patched. Automatic expansion analysis and prediction: Through compression, trimming, and merging, efficient and rapid automatic expansion testing can be performed based on the data mart, allowing for the discovery of potential security risks by drawing inferences from specific cases.

[0249] In summary, this application proposes a multi-level, multi-morphic machine learning framework for accurately identifying vulnerability fixes in code. It integrates multiple neural network models for different levels and forms of code changes (including line, block, file, and project), deeply capturing the semantic and structural features of code at different levels. By employing an ensemble learning strategy, it combines the predictions of various basic models to generate more accurate vulnerability fix predictions. This design not only optimizes robustness to noise but also effectively addresses the imbalance of vulnerability fix data, thereby improving the accuracy and efficiency of identifying vulnerability fix submissions.

[0250] Furthermore, compared with the prior art, the method shown in the embodiments of this application also has the following advantages:

[0251] Improve vulnerability remediation identification rate and support the identification of potentially overlooked vulnerabilities: The above model can predict whether security vulnerability remediation actions or related security information will occur during the code submission process, which can improve the vulnerability remediation identification rate to a certain extent. At the same time, it can predict the vulnerability type of the remediation point, such as SQL (Structured Query Language Injection), XSS (Cross-Site Scripting), command execution, etc. It also adds the ability to automatically extend and predict the identification of vulnerabilities, which can achieve the effect of learning by analogy.

[0252] Identifying the potential risks of zero-day vulnerabilities: Many open-source software programs undergo frequent version updates or upgrades, and vulnerability patching is often intertwined with daily development. Therefore, code changes are often complex and noisy, which can interfere with the vulnerability patching analysis process and results. Through intelligent learning and identification of code changes, hidden, undisclosed vulnerability information can be identified. This information could be maliciously exploited to launch attacks on older software versions or even steal critical system data.

[0253] Saving significant labor costs and increasing efficiency: The method shown in the embodiments of this application can automatically build a data engine, automatically analyze and identify, and automatically extend the analysis of vulnerabilities, which can significantly reduce the amount of manual work, while greatly improving the effectiveness of vulnerability discovery or vulnerability remediation. This can save significant labor costs and achieve cost reduction and efficiency improvement.

[0254] Figure 19 This invention illustrates a training apparatus 190 for a vulnerability remediation code identification model according to an embodiment of the present application. The apparatus 190 includes:

[0255] Module 1901 is used to build and run a historical vulnerability and code feature association data engine, and obtain a training dataset from the data engine. The training dataset includes multiple labeled code submission samples, and the labels are used to identify whether the code submission samples are used for vulnerability remediation.

[0256] The first execution module 1902 is used to perform code decomposition at different levels on the code submission sample to obtain code decomposition results, which include: line code, block code, file code, and project code;

[0257] The code decomposition results are processed by code embedding to obtain an embedding vector;

[0258] Feature extraction is performed on the embedded vectors to obtain feature vectors, which include: row-level feature vectors, block-level feature vectors, file-level feature vectors, and project-level feature vectors.

[0259] The feature vectors are subjected to feature fusion processing to obtain fused feature vectors;

[0260] The vulnerability patching code identification model is trained based on the fused feature vectors.

[0261] Figure 20 This application illustrates a code recognition device 200 based on a vulnerability patching code recognition model, according to an embodiment of the present application. The device 200 includes:

[0262] The input module 2001 is used to input the code to be detected into the vulnerability repair code recognition model; and to obtain the raw probability output by the vulnerability repair code recognition model; wherein, the vulnerability repair code recognition model is trained using the method described in the above embodiments; the raw probability is used to represent the probability that the code to be detected is code used for vulnerability repair;

[0263] The second execution module 2002 is used to obtain the line number of the code to be detected;

[0264] The final score is determined based on the number of lines of code, according to the preset perception adjustment mechanism and the original probability.

[0265] The final score determines whether the code to be tested is used for vulnerability patching.

[0266] In summary, the method described in this application, by constructing a historical vulnerability and code feature association data engine, ensures that the training dataset originates from real vulnerability repair scenarios, thus providing the model with a high-quality, clearly labeled sample foundation. Based on this, multi-level code decomposition of code submission samples at the line, block, file, and project levels enables the model to comprehensively capture detailed features of code changes at different granularities. Furthermore, code embedding processing transforms abstract code elements into numerical embedding vectors, providing a semantically rich representation foundation for subsequent feature extraction. Multi-level feature vectors at the line, block, file, and project levels are then extracted from these embedding vectors, enabling the model to simultaneously learn local code logic and global project context information. Subsequently, these heterogeneous multi-level feature vectors are fused, effectively integrating feature information from different dimensions and enhancing the model's comprehensive representation ability of complex vulnerability repair patterns. Finally, the fused feature vectors are used to train the model, enabling it to more accurately learn the inherent patterns of vulnerability repair code. In conclusion, through multi-level feature extraction and fusion, the code recognition accuracy and efficiency of the vulnerability repair code identification model are significantly improved.

[0267] This application provides a network device, such as... Figure 21As shown, the network device 210 includes: a processor 2101, a memory 2102, and a program stored on the memory 2102 and executable on the processor 2101. When the program is executed by the processor 2101, it implements the steps of a training method for a vulnerability patching code identification model as shown in the above embodiment, or the steps of a code identification method based on a vulnerability patching code identification model.

[0268] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of a training method for a vulnerability patching code identification model as shown in the above embodiments, or the steps of a code identification method based on the vulnerability patching code identification model, achieving the same technical effect. To avoid repetition, these steps will not be repeated here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0269] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the steps of a training method for a vulnerability patching code identification model as shown in the above embodiments, or the steps of a code identification method based on a vulnerability patching code identification model, and can achieve the same technical effect. To avoid repetition, these steps will not be repeated here.

[0270] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0271] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0272] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A training method for a vulnerability patching code identification model, characterized in that, include: A historical vulnerability and code feature association data engine is built and run, and a training dataset is obtained from the data engine; wherein, the training dataset includes multiple labeled code submission samples, and the labels are used to identify whether the code submission samples are used for vulnerability remediation; The code submission sample is decomposed at different levels to obtain code decomposition results, which include: line code, block code, file code, and project code; The code decomposition results are subjected to code embedding processing to obtain an embedding vector; Feature extraction is performed on the embedded vector to obtain feature vectors, which include: row-level feature vectors, block-level feature vectors, file-level feature vectors, and project-level feature vectors. The feature vectors are subjected to feature fusion processing to obtain fused feature vectors; The vulnerability patching code identification model is trained based on the fused feature vectors to obtain the vulnerability patching code identification model.

2. The method according to claim 1, characterized in that, Build and run a historical vulnerability and code feature association data engine, and obtain a training dataset from the data engine, including: The code feature information is crawled from the code hosting platform, wherein the code feature information includes at least one of the following: change records, commit logs, version information, and code change descriptions; Historical vulnerability information is crawled from official vulnerability platforms, including at least one of the following: general vulnerability disclosure CVE number, vulnerability description, affected versions, impact level, and remediation plan; The code feature information and the historical vulnerability information are associated, and the data engine is constructed based on the associated code feature information and the historical vulnerability information. The data engine is then run to identify code submission samples used to fix vulnerabilities and other code submission samples from the data engine. Based on the code submission samples used to fix the vulnerabilities, code security features are determined, wherein the code security features include at least one of the following: sensitive function calls, error handling logic, input validation, permissions and access control, code injection and encryption / decryption; Based on the code submission samples used to fix vulnerabilities and the code security features, a positive sample dataset strongly correlated with the vulnerabilities is determined, and based on the remaining code submissions, a negative sample dataset not correlated with the vulnerabilities is determined. The training dataset is composed of the positive sample dataset and the negative sample dataset.

3. The method according to claim 1, characterized in that, The code submission samples were decomposed at different levels, and the code decomposition results included: The code submission sample is broken down into lines of code, resulting in a sequence of code lines composed of all modified lines of code arranged in order. The code submission sample is decomposed into code blocks, resulting in code modification blocks consisting of consecutively modified lines of code. The code submission sample is decomposed into file code to obtain the independent modification content of the file corresponding to the code submission sample; The code submission sample is decomposed into project code to obtain all the modifications to the project corresponding to the code submission sample.

4. The method according to claim 1, characterized in that, The code decomposition results are subjected to code embedding processing to obtain embedding vectors, including: The CodeBERT model uses a bidirectional code encoder to represent the code decomposition results, which are then transformed into high-dimensional vector representations. The high-dimensional vector representation is processed using either context-dependent or context-independent representation to obtain the embedded vector; Specifically, for the first type of code, the context-dependent representation is used, and the modifications in the first type of code are input into the CodeBERT model to obtain the corresponding fused embedding vector; wherein, the first type of code includes the file code and the project code; For the second type of code, the context-free representation is used. The modifications in the second type of code are input into the CodeBERT model to obtain new code vectors and deleted code vectors. The new code vectors and deleted code vectors are then concatenated into a concatenated embedding vector. The second type of code includes line code, block code, and file code. The modifications include new content and deleted content. The new content corresponds to the new code vector, and the deleted content corresponds to the deleted code vector. The embedding vector includes the fused embedding vector and the concatenated embedding vector.

5. The method according to claim 4, characterized in that, Before converting the code decomposition results into a high-dimensional vector representation using the CodeBERT model, the method further includes: The code decomposition results are preprocessed using a preset model adaptive selector to obtain preprocessed code decomposition results. The preprocessing includes compression filtering, trimming, and merging.

6. The method according to claim 4, characterized in that, Feature extraction is performed on the embedded vector to obtain a feature vector, including: Using a Bidirectional Long Short-Term Memory (BiLSTM) network model, sequence feature extraction is performed on the row-level concatenated embedding vector obtained by the context-free representation, and the row-level feature vector is output. Using a convolutional neural network (CNN) model, local pattern features are extracted from the block-level concatenated embedding vector obtained by the context-free representation, and the block-level feature vector is output. Using the Fully Connected Network (FCN) model, global correlation feature extraction is performed on the file-level fused embedding vector obtained by the context-dependent representation and the file-level concatenated embedding vector obtained by the context-independent representation, and the file-level feature vector is output. Using the fully connected network (FCN) model, global correlation feature extraction is performed on the fused embedding vector at the engineering level obtained by the context dependency representation, and the engineering-level feature vector is output.

7. The method according to any one of claims 1-6, characterized in that, The feature vector is subjected to feature fusion processing to obtain a fused feature vector, which includes: Construct a feature fusion layer, which includes a fully connected layer; A dual-modal fusion path is adopted, and the file-level feature vector and the project-level feature vector are input into the fully connected layer in the feature fusion layer for processing to obtain the first fused feature vector; Using a single-modal fusion path, the row-level feature vector, the block-level feature vector, and the file-level feature vector are first concatenated, and then the concatenated feature vector is input into the fully connected layer in the feature fusion layer for processing to obtain the second fused feature vector; The first fusion feature vector and the second fusion feature vector are jointly determined as the fusion feature vector.

8. A code recognition method based on a vulnerability patching code recognition model, characterized in that, The method includes: The code to be detected is input into the vulnerability repair code recognition model; the raw probability output by the vulnerability repair code recognition model is obtained; wherein, the vulnerability repair code recognition model is trained using the method described in any one of claims 1-7; the raw probability is used to represent the probability that the code to be detected is code used for vulnerability repair; Obtain the line number of the code to be detected; Based on the number of lines of code, the final score is determined according to the preset perception adjustment mechanism and the original probability; The final score is used to determine whether the code to be detected is code used for vulnerability patching.

9. The method according to claim 8, characterized in that, Based on the number of lines of code, and according to the preset perception adjustment mechanism and the original probability, the final score is determined as follows: From the historical training database of the vulnerability repair code identification model, obtain all code submission samples used for vulnerability repair, and determine the maximum number of lines of code in all code submission samples used for vulnerability repair. The adjustment value is determined based on the maximum number of lines of code and the number of lines of code; The final score is determined based on the adjusted value and the original probability; wherein, when the calculated result of the final score is less than zero, the final score is set to zero.

10. The method according to claim 8, characterized in that, Determining whether the code to be detected is code used for vulnerability remediation based on the final score includes: When the final score is greater than or equal to a preset threshold, the code to be detected is determined to be code used for vulnerability repair. When the final score is less than the preset threshold, it is determined that the code to be detected is not code used for vulnerability repair.

11. The method according to claim 10, characterized in that, After determining that the code to be detected is code used for vulnerability remediation when the final score is greater than or equal to a preset threshold, the method further includes: The code to be detected is matched with known vulnerabilities in a publicly available vulnerability database; If no known vulnerability corresponding to the code under test is found in the publicly available vulnerability database, the code under test is identified as code used to fix potential undisclosed vulnerabilities.

12. A training device for a vulnerability patching code recognition model, characterized in that, The device includes: A building module is used to build and run a historical vulnerability and code feature association data engine, and obtain a training dataset from the data engine; wherein, the training dataset includes multiple labeled code submission samples, and the labels are used to identify whether the code submission samples are used for vulnerability remediation; The first execution module is used to perform code decomposition at different levels on the code submission sample to obtain code decomposition results, which include: line code, block code, file code, and project code; The code decomposition results are subjected to code embedding processing to obtain an embedding vector; Feature extraction is performed on the embedded vector to obtain feature vectors, which include: row-level feature vectors, block-level feature vectors, file-level feature vectors, and project-level feature vectors. The feature vectors are subjected to feature fusion processing to obtain fused feature vectors; The vulnerability patching code identification model is trained based on the fused feature vectors to obtain the vulnerability patching code identification model.

13. A code recognition device based on a vulnerability repair code recognition model, characterized in that, The device includes: An input module is used to input the code to be detected into a vulnerability repair code recognition model; to obtain the raw probability output by the vulnerability repair code recognition model; wherein, the vulnerability repair code recognition model is trained using the method described in any one of claims 1-7; the raw probability is used to represent the probability that the code to be detected is code used for vulnerability repair; The second execution module is used to obtain the line number of the code to be detected; Based on the number of lines of code, the final score is determined according to the preset perception adjustment mechanism and the original probability; The final score is used to determine whether the code to be detected is code used for vulnerability patching.

14. A network device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of a training method for a vulnerability patching code identification model as described in any one of claims 1 to 7, or, when the program is executed by the processor, it implements the steps of a code identification method based on a vulnerability patching code identification model as described in any one of claims 8 to 11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of a training method for a vulnerability patching code identification model as described in any one of claims 1 to 7, or, when executed by the processor, implements the steps of a code identification method based on a vulnerability patching code identification model as described in any one of claims 8 to 11.

16. A computer program product, characterized in that, The method includes computer instructions that, when executed by a processor, implement the steps of a training method for a vulnerability patching code identification model as described in any one of claims 1 to 7, or, when executed by the processor, implement the steps of a code identification method based on a vulnerability patching code identification model as described in any one of claims 8 to 11.

Images