Sorting-based open source software security vulnerability patch location method

Abstract

The present invention provides a method for locating open source software security vulnerability patches based on sorting, specifically comprising: collecting vulnerability and code submission data from a website; extracting vulnerability and code submission similarity features in four dimensions, namely, code line, vulnerability identity, vulnerability repair location, and bag-of-words, using data mining and statistical analysis methods; training a vulnerability domain text semantic encoding module based on a Bert model, and using the semantic encoding module to extract vulnerability semantic features and code submission semantic features; concatenating the vulnerability semantic features and code submission semantic features to form a complete feature set of the vulnerability and code submission; model training; and model fusion using the concept of majority voting. The present invention can extract features from vulnerabilities and code submissions, establish a vulnerability patch submission sorting model, sort code submissions in an open source software repository according to their matching degree with the vulnerability, and effectively reduce the number of code submissions that patch annotators need to review.

Description

Technical Field

[0001] The patent of this invention relates to the field of computer security technology, and specifically to a sorting-based open source software security vulnerability patch location method. Background Art

[0002] Both the XGBoost model and the LightGBM model are gradient boosting trees that can extract the connection between independent variables and dependent variables from multiple features. The principle is to achieve the effect of a strong classifier by fusing multiple weak classifiers. Each time, the residual between the true value and the current predicted value is used as the training target for the next weak classifier, and continuous iteration is carried out to make the final model fit the data. The difference is that the tree structure in the XGBoost model adopts layer-by-layer growth, while the tree structure in the LightGBM model adopts leaf-by-leaf growth, and each time the leaf with the largest splitting benefit is found.

[0003] A convolutional neural network (CNN) model is a neural network model that uses convolutional computation. Due to the nonlinearity of the activation function and the depth of the network layers, CNN models can detect deeper relationships between training data and prediction data. CNN models generate prediction data through forward propagation, obtain model error through a loss function, and then update the network's internal parameters through backpropagation. After multiple iterations, the CNN model can better fit the data.

[0004] The BERT (Bidirectional Encoder Representation from Transformers) model is an emerging natural language processing model. It maps text into vectors for training and employs an attention mechanism to closely contextualize sentences, thereby obtaining more realistic text semantics and outputting them in the form of vectors. The BERT model has been widely used in text processing.

[0005] Currently, open source software is used by numerous programs in the software industry. However, security vulnerabilities in open source software can cause significant damage to these programs, such as data leaks and software crashes. Furthermore, with the increasing use of open source software, the number of security vulnerabilities is also increasing. To effectively manage vulnerability data, public vulnerability databases such as CVE, NVD, and Snyk have emerged. These databases contain vulnerability descriptions, related links, and other information, allowing developers to understand and identify vulnerabilities. To fix vulnerabilities, open source software developers typically publish patches as code commits to websites such as GitHub and GitLab. Vulnerability patches play a crucial role in vulnerability management for open source software. First, developers can directly apply patches to address the corresponding vulnerabilities. Second, patches can be used to assess vulnerability severity, helping software companies optimize the timing of remediation. Furthermore, developers can analyze vulnerability characteristics based on patches and learn how to remedy or prevent similar issues. Furthermore, a rich collection of vulnerability patches can facilitate other areas of vulnerability research, such as vulnerability prediction, vulnerability code clone detection, and vulnerability testing.

[0006] Currently, vulnerability patches are primarily located by manually examining code submissions one by one, a difficult and time-consuming process. A technique currently exists for locating vulnerability patches using feature engineering. However, this approach only extracts the connection between vulnerabilities and code submissions through statistical analysis, ignoring the semantic content of vulnerability descriptions and code submissions. Furthermore, it uses only a single model for training and prediction, resulting in poor model performance. Summary of the Invention

[0007] In view of this, the present invention proposes a novel open source software security vulnerability patch location method VCMatch (Vulnerability-Commit Match) based on sorting. The method uses data mining and statistical analysis techniques to collect the connection between vulnerabilities and code patches from a broader dimension. The present invention also creates a vulnerability-related text semantic encoding module to extract vulnerability semantic features and code submission semantic features, thereby more comprehensively characterizing vulnerabilities and code submissions. Since the current task is a task with an imbalance of positive and negative samples, the present invention proposes a method of using multi-model training and then fusion to ensure the excellence of vulnerability patch location. The present invention uses three models, XGBoost, LightGBM and CNN, for training and prediction, and proposes a novel model fusion method based on voting ideas for the current sorting-based location problem. Experimental verification shows that for the same data set, the vulnerability patch method VCMatch proposed in the present invention is superior to the existing methods.

[0008] The present invention comprises the steps of:

[0009] Step 1: Data collection.

[0010] Step 2: Data preprocessing.

[0011] Step 3: Extract similarity features between vulnerabilities and code submissions.

[0012] Step 4: Extract vulnerability semantic features and code submission semantic features.

[0013] Step 5: Feature concatenation: All features obtained in steps 3 and 4 are concatenated to form the complete features of the vulnerability and code submission.

[0014] Step 6: Model training.

[0015] Step 7: Use the idea of ​​majority voting to perform model fusion.

[0016] The method of the present invention collects vulnerability and code submission data from CVE, NVD, Snyk, GitHub and GitLab websites; uses data mining and statistical analysis methods to extract vulnerability and code submission similarity features in four dimensions, namely code lines, vulnerability identities, vulnerability repair locations, and word bags; trains a vulnerability domain text semantic encoding module based on a BERT model, and uses the semantic encoding module to extract vulnerability semantic features and code submission semantic features; splices the above-mentioned collected features in a total of six dimensions, and trains them using an XGBoost model, a LightGBM model, and a CNN model, and sorts all code submissions according to the vulnerability and code submission matching probabilities predicted by the models and obtains their corresponding rankings; uses a model fusion method based on voting ideas to fuse the ranking values ​​of the three models to obtain a final ranking value of the code submission.

[0017] Among them, the data collection described in step 1 specifically refers to: collecting the matching relationship between vulnerabilities and code submissions from the Snyk website, generating corresponding negative samples based on the vulnerabilities and the repositories where they appear, collecting vulnerability-related data from the CVE and NVD websites, and collecting code submission data from websites such as GitHub and GitLab.

[0018] Step 1 specifically includes the following steps:

[0019] Step 1.1: Collect vulnerability and code submission matching relationships. Traverse all data pages in the Snyk vulnerability database to obtain vulnerability numbers and related links. Based on whether the link contains the "commit" keyword and the software repository name keyword, obtain the corresponding open source software vulnerability patch submission link. Finally, use regular expressions to extract patch submissions.

[0020] Step 1.2: Generate negative samples of the dataset. For each vulnerability, randomly select 5,000 code submissions from the repository where the vulnerability is located as negative samples.

[0021] Step 1.3: Collect vulnerability-related data. Based on the vulnerability number obtained in step 1.1, traverse the CVE website to obtain the vulnerability description and the date the vulnerability number was assigned. Traverse the NVD website to obtain the vulnerability type name of the corresponding vulnerability.

[0022] Step 1.4: Collect commit data. Clone the code repository contents of the open source software in GitHub and GitLab. Based on all the code commits obtained in Steps 1.1 and 1.2, obtain the commit information, commit time, and modified code content corresponding to each code commit from the code repository.

[0023] Furthermore, the data preprocessing described in step 2 specifically refers to: using the word segmentation method in Cubert to segment the text content in the vulnerability and code submission, removing stop words after the segmentation, and retaining the segmentations that exist in both the vulnerability word bag and the code submission word bag.

[0024] Step 2 specifically includes the following steps:

[0025] Step 2.1: Use the word segmentation method in Cubert to perform word segmentation. Segment the vulnerability description and vulnerability type name to obtain the vulnerability word bag. Segment the submission information and modified code content to obtain the code submission word bag.

[0026] Step 2.2: Remove stop words. Use the stop word library in NLTK to remove stop words from the vulnerability word bag and code submission word bag.

[0027] Step 2.3: Count the words that appear only in one of the word bags and remove them from the corresponding word bag.

[0028] Furthermore, the similarity feature extraction described in step 3 specifically refers to extracting similarity features between vulnerabilities and code submissions in four major directions: code lines, vulnerability identity, vulnerability location, and word bag.

[0029] Step 3 specifically includes the following steps:

[0030] Step 3.1: Generate similarity features from the perspective of code lines. Count the number of code lines added, deleted, and modified in the code submission.

[0031] Step 3.2: Generate similarity features from the perspective of vulnerability identity. Count the number of vulnerability numbers, defect numbers, question numbers, and web page links in the submission information, and count whether the vulnerability numbers in the submission information match the corresponding vulnerabilities.

[0032] Step 3.3: Generate similarity features based on vulnerability location. Calculate the number of days between the time the vulnerability was assigned a vulnerability number and the time the code was submitted. Count the number of file paths / file names / function names that appear in the vulnerability description and are also modified. Count the ratio of these file paths / file names / function names to the number of file paths / file names / function names modified in the code submission. Count the number of file paths / file names / function names that only appear in the modified code submission.

[0033] Step 3.4: Generate similarity features from the bag-of-words perspective. Count the number of identical words between the submission information and the vulnerability type name, and the proportion of these identical words to the total number of words in the vulnerability type name. Calculate the cosine similarity between the vulnerability TFIDF vector and the code submission TFIDF vector. Count the number of identical words between the submission information and the vulnerability description, and the proportion of these identical words to the total number of words in the vulnerability description. Count the maximum, average, and total frequency of these identical words. Count the number of identical words between the modified code content and the vulnerability description, and the proportion of these identical words to the total number of words in the vulnerability description. Count the maximum, average, and total frequency of these identical words.

[0034] Furthermore, the semantic feature extraction described in step 4 specifically refers to: constructing a Bert semantic encoding module, and generating a training framework to train the encoding module, and then using the vectorization method provided by the Bert model to convert the vulnerability description and submission information into vector form, and then passing them through the semantic encoding module respectively to obtain the vulnerability semantic features and code submission semantic features.

[0035] Step 4 specifically includes the following steps:

[0036] Step 4.1: Build the Bert semantic encoding module. The Bert semantic encoding module consists of two layers: the Bert layer and the fully connected layer.

[0037] Step 4.2: Build the BERT semantic encoding module training framework and train it. The semantic encoding module training framework is as follows Figure 3 As shown in Figure 2, the vulnerability description vector and submission information vector obtained in step 4.1 are passed through the Bert semantic encoding module respectively to obtain two vectors. The two vectors are concatenated and then passed through the fully connected layer. The output of the fully connected layer is the probability of matching the vulnerability with the corresponding submission.

[0038] Step 4.3: Use the vectorization method provided by the BERT model to vectorize the vulnerability description and submission information.

[0039] Step 4.4: Use the trained semantic encoding module to generate vulnerability semantic features and code submission semantic features. Use the semantic encoding module to process the vulnerability description to obtain vulnerability semantic features, and use the semantic encoding module to process the submission information to obtain code submission semantic features.

[0040] Furthermore, the model training described in step 6 specifically refers to: using the three models of XGBoost, LightGBM, and CNN to train on the features spliced ​​in step 5 and obtain the ranking results of each model submitted on each model.

[0041] Step 6 specifically includes the following steps:

[0042] Step 6.1: Train an XGBoost model for code submission ranking. Use the concatenated features from Step 5 as input to the XGBoost model. Use the matching label for the vulnerability and patch submission as the model training result. Train the XGBoost model using a logarithmic loss function. After model training, the model predicts the matching probability for each pair of vulnerability and patch submission features. Then, sort all code submissions in descending order based on the matching probability.

[0043] Step 6.2: Train a LightGBM model for ranking vulnerability patch submissions. Use the concatenated features from Step 5 as input to the LightGBM model. Use the matching label for the vulnerability and patch submission as the training result label. Train the LightGBM model using a logarithmic loss function. After model training, the model predicts the matching probability for each pair of vulnerability and patch submission features. Then, sort all submissions in descending order based on the matching probability.

[0044] Step 6.3: Train a CNN model to sort vulnerability patch submissions. Use the concatenated features from Step 5 as input to the CNN model. Use the matching label for the vulnerability and patch submission as the model training result. Train the CNN model using the Focalloss loss function. After model training, the features generated by each pair of vulnerability and patch submission are used to predict the matching probability between the two. All code submissions are then sorted in descending order based on the matching probability.

[0045] Furthermore, the idea of ​​majority voting described in step 7 is used to perform model fusion, specifically: for each code submission and the ranking value given by the three models in step 6, the average of the two closest rankings is obtained; all code submissions are sorted in ascending order according to the average; if the averages are the same, they are sorted in ascending order according to the unused rankings to obtain the final ranking of each code submission.

[0046] Compared with the prior art, the present invention has the following advantages:

[0047] (1) This paper proposes a semantic encoding model based on BERT: Vulnerability descriptions and submission information contain rich textual semantic information, but current methods based on word frequency cannot effectively extract this deep semantic information. Therefore, we construct a semantic encoding module to extract this deep semantic information. Compared with the word frequency features obtained by statistical analysis methods, this method can better represent the true meaning of the text, making the model more effective.

[0048] (2) The present invention selects features from more dimensions: The present invention extracts dozens of connections between vulnerabilities and code submissions from six dimensions, covering a wide range and with more complete feature selection. It truly captures the effective connection between vulnerabilities and code submissions, which is conducive to matching vulnerabilities with patch code submissions.

[0049] (3) Select more excellent models and propose a fusion method that is beneficial to the positioning effect: The present invention adopts three models, XGBoost, LightGBM, and CNN, as basic models. These models can still maintain excellent results in tasks with unbalanced data. At the same time, in response to the current sorting-based positioning problem, the present invention proposes a model fusion method based on voting sorting that is beneficial to improving the positioning effect. The results of the three basic models are fused to make the final model more effective and better able to locate vulnerability patches.

[0050] (4) Rich and effective data sets: The collected data sets cover 10 open source projects and 3 programming languages, with a wide coverage. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 is a flow chart of the method proposed by the present invention;

[0052] Figure 2 This is a schematic diagram of the matching relationship between collected vulnerabilities and code submissions in the present invention;

[0053] Figure 3 It is a data preprocessing flow chart of the present invention;

[0054] Figure 4 It is the semantic encoding module proposed by the present invention;

[0055] Figure 5 This is a training framework diagram of the semantic coding module of the present invention;

[0056] Figure 6 It is a schematic diagram of the training and prediction of three models of the present invention;

[0057] Figure 7 It is a schematic diagram of the fusion of the model of the present invention;

[0058] Figure 8It is a model framework diagram of the present invention. DETAILED DESCRIPTION

[0059] To facilitate those skilled in the art to understand and implement the present invention, the present invention is further described in detail below with reference to the accompanying drawings and implementation examples. It should be understood that the implementation examples are only used to illustrate and explain the present invention and should not limit the scope of the present invention.

[0060] like Figure 1 As shown, a method for locating open source software security vulnerability patches based on sorting includes the following steps:

[0061] Step 1: Data collection. Its specific implementation includes the following sub-steps:

[0062] Step 1.1: Collect the matching relationship between vulnerabilities and code submissions, such as Figure 2 As shown in the figure, we use Python crawler technology to traverse all data pages in the Snyk vulnerability database and obtain the vulnerability numbers and corresponding related links in the data pages.

[0063] After obtaining the vulnerability-related link, the real vulnerability patch link is obtained by judging whether the link contains the "commit" keyword.

[0064] Furthermore, we screened out links containing the keywords “FFmpeg”, “ImageMagick”, “Jenkins”, “OpenSSL”, “QEMU”, “Wireshark”, “Linux”, “Moodle”, “PHP-src” or “phpMyAdmin” to obtain vulnerability patch data corresponding to 10 open source software as positive samples of the dataset.

[0065] Afterwards, a regular expression is applied to extract the vulnerability patch submission number from the vulnerability-related links, thereby obtaining the correspondence between the vulnerability number and the vulnerability patch submission, that is, the patch submission ID corresponding to the CVE ID.

[0066] Step 1.2: Generate negative samples of the dataset. For each vulnerability, use the GitPython library to randomly select 5,000 code commits from all code commits in the corresponding repository as negative samples of vulnerability patches.

[0067] Step 1.3: Collect vulnerability-related data. Based on the vulnerability numbers collected in Step 1.1, traverse the corresponding vulnerability page on the CVE website to obtain the vulnerability description and the date the vulnerability was assigned the CVE number. Traverse the corresponding vulnerability page on the NVD website to obtain the corresponding vulnerability type (CWE) name.

[0068] Step 1.4: Collect commit data. Clone the open source software repository in GitHub and GitLab. Based on all the code commits obtained in Steps 1.1 and 1.2, use the GitPython library to obtain the commit information, commit time, and modified code content for each commit.

[0069] Step 2: Data preprocessing, such as Figure 3 Its specific implementation includes the following sub-steps:

[0070] Step 2.1: Use the word segmentation method in Cubert to perform word segmentation. Segment the vulnerability description and vulnerability type name to obtain the vulnerability word bag. Segment the submission information and modified code content to obtain the code submission word bag.

[0071] Step 2.2: Remove stop words. Use the stop word library in NLTK to remove stop words from the vulnerability word bag and code submission word bag.

[0072] Step 2.3: Count the words that appear only in one of the word bags and remove them from the corresponding word bag.

[0073] Step 3: Extract similarity features between vulnerabilities and code submissions. The specific implementation includes the following sub-steps:

[0074] Step 3.1: Generate similarity features from the perspective of code lines. Count the number of code lines added, deleted, and modified in the code submission.

[0075] Step 3.2: Generate similarity features from the perspective of vulnerability identity. Count the number of vulnerability numbers, defect numbers, question numbers, and web page links in the submission information, and count whether the vulnerability numbers in the submission information match the corresponding vulnerabilities.

[0076] Step 3.3: Generate similarity features based on vulnerability location. Calculate the number of days between the time the vulnerability was assigned a vulnerability number and the time the code was submitted. Count the number of file paths / file names / function names that appear in the vulnerability description and are also modified. Count the ratio of these file paths / file names / function names to the number of file paths / file names / function names modified in the code submission. Count the number of file paths / file names / function names that only appear in the modified code submission.

[0077] Step 3.4: Generate similarity features from the bag-of-words perspective. Count the number of identical words between the submission information and the vulnerability type name, and the proportion of these identical words to the total number of words in the vulnerability type name. Calculate the cosine similarity between the vulnerability TFIDF vector and the code submission TFIDF vector. Count the number of identical words between the submission information and the vulnerability description, and the proportion of these identical words to the total number of words in the vulnerability description. Count the maximum, average, and total frequency of these identical words. Count the number of identical words between the modified code content and the vulnerability description, and the proportion of these identical words to the total number of words in the vulnerability description. Count the maximum, average, and total frequency of these identical words.

[0078] Step 4: Extract vulnerability semantic features and code submission semantic features. The specific steps are as follows:

[0079] Step 4.1: Construct the Bert semantic encoding module. The Bert semantic encoding module is as follows Figure 4 As shown in the figure, it consists of two layers: a Bert layer and a fully connected layer. The fully connected layer has a 768-dimensional input and a 36-dimensional output. Since the Bert model is rich enough, only one fully connected layer is added to convert the output dimension.

[0080] Step 4.2: Build the BERT semantic encoding module training framework and train it. The semantic encoding module training framework is as follows Figure 5 As shown in Figure 2, the vulnerability description vector and submission information vector obtained in step 4.1 are passed through the Bert semantic encoding module respectively to obtain two vectors. The two vectors are concatenated and then passed through the fully connected layer. The output of the fully connected layer is the probability of matching the vulnerability with the corresponding submission.

[0081] During training, the vulnerability dataset obtained in step 1 is used for training. Whether the vulnerability matches the patch submission is used as the training result label. The Adam optimization training algorithm is used to train the entire framework.

[0082] Step 4.3: Use the vectorization method provided by the BERT model to vectorize the vulnerability description and submission information.

[0083] Step 4.4: Use the trained semantic encoding module to generate vulnerability semantic features and code submission semantic features. Use the semantic encoding module to process the vulnerability description to obtain vulnerability semantic features, and use the semantic encoding module to process the submission information to obtain code submission semantic features.

[0084] Step 5: Feature concatenation: All features obtained in steps 3 and 4 are concatenated to form the complete features of the vulnerability and code submission.

[0085] Step 6: Model training, such as Figure 6 The specific steps are as follows:

[0086] Step 6.1: Train the XGBoost model for code submission ranking. Use the features concatenated in step 5 as the input of the XGBoost model, use the matching of the vulnerability and the patch submission as the model training result label, and use the logarithmic loss function to train the XGBoost model. After model training, the features generated by each pair of vulnerability and code submission are predicted by the model to obtain the matching probability between the two. All code submissions are sorted in descending order according to the matching probability. xgb To characterize the ranking results of the XGBoost model.

[0087] Step 6.2: Train the LightGBM model for vulnerability patch submission sorting. Use the concatenated features from step 5 as the input to the LightGBM model, use the matching between the vulnerability and the patch submission as the model training result label, and train the LightGBM model using the logarithmic loss function. After model training, the features generated by each pair of vulnerability and code submission are predicted by the model to obtain the matching probability between the two, and all code submissions are sorted in descending order according to the matching probability. lgb To characterize the ranking results of the LightGBM model.

[0088] Step 6.3: Train the CNN model for vulnerability patch submission ranking. Use the features concatenated in step 5 as the input to the CNN model, use the matching between the vulnerability and the patch submission as the model training result label, and use the Focalloss loss function to train the CNN model. The Focalloss loss function is defined as follows:

[0089]

[0090] Where p is the probability that the predicted sample belongs to 1; y is whether the real vulnerability matches the submitted label, and the value of y is {0, 1}; γ is the focusing parameter, which is used to smoothly adjust the rate at which samples that are easy to predict correctly are weighted downward.

[0091] After model training, the features generated by each pair of vulnerability and code submission are predicted by the model to obtain the matching probability between the two, and all code submissions are sorted in descending order according to the matching probability. cnn To characterize the ranking results of the CNN model.

[0092] Step 7: Use the idea of ​​majority voting to perform model fusion, such as Figure 7 As shown. The ranking results obtained by the XGBoost model, LightGBM model, and CNN model are integrated. The specific method is: for each code submission, the three corresponding rankings are obtained according to the three models in step 6. xgb Ranklgb Rank cnn , select the two rankings with the closest values ​​and calculate their average Rank avg According to Rank avg Sort all code submissions in ascending order. If there are two submissions with the same Rank avg If there is no result, the remaining ranking values ​​are sorted in ascending order.

[0093] After sorting in step 7, vulnerability patch annotators can check the code submissions in sequence according to the sorting results given by the model, and can locate the real vulnerability patch submissions more quickly.

Claims

1. A method for locating open source software security vulnerability patches based on sorting, characterized by: The following steps are involved: Step 1: Data collection; Step 2: Data preprocessing; Step 3: Extract similarity features between vulnerabilities and code submissions, including: Extract similarity features between vulnerabilities and code submissions in four major areas: code line, vulnerability identity, vulnerability location, and bag-of-words. Generate similarity features from the perspective of code lines, and count the number of code lines added, deleted, and modified in the code submission; Generate similarity features from the perspective of vulnerability identity, count the number of vulnerability numbers, defect numbers, question numbers, and web page links in the submission information, and count whether the vulnerability numbers in the submission information match the corresponding vulnerabilities; Generate similarity features based on vulnerability location. Calculate the number of days between the time the vulnerability is assigned a vulnerability number and the time the code is submitted. Count the number of file paths / file names / function names that appear in the vulnerability description and are also modified. Count the ratio of these file paths / file names / function names to the number of file paths / file names / function names modified in the code submission. Count the number of file paths / file names / function names that only appear in the modified code submission. Generate similarity features from the perspective of word bag, count the number of identical word segments between the submission information and the vulnerability type name, and count the proportion of the number of identical word segments to the total number of vulnerability type name word segments; calculate the cosine similarity between the vulnerability TFIDF vector and the code submission TFIDF vector; count the number of identical word segments between the submission information and the vulnerability description, count the proportion of the number of identical word segments to the total number of vulnerability description word segments, and count the maximum frequency, average frequency, and total frequency of the identical word segments; count the number of identical word segments between the modified code content and the vulnerability description, count the proportion of the number of identical word segments to the total number of vulnerability description word segments, and count the maximum frequency, average frequency, and total frequency of the identical word segments; Step 4: Extract vulnerability semantic features and code submission semantic features, including: Build a BERT semantic encoding module and generate a training framework to train the encoding module. Then, use the BERT model's built-in vectorization method to convert vulnerability descriptions and submission information into vector form. Then, pass them through the semantic encoding module to obtain vulnerability semantic features and code submission semantic features. Step 5: Concatenate all the features obtained in Step 3 and Step 4 to form the complete features of the vulnerability and code submission; Step 6: Model training, including: Use XGBoost, LightGBM, and CNN models to train on the features concatenated in step 5 and obtain the ranking results of each submitted code on each model; Train an XGBoost model for sorting code submissions. Use the concatenated features from step 5 as input to the XGBoost model. Use the matching of the vulnerability and the patch submission as the label for the model training result. Train the XGBoost model using a logarithmic loss function. After model training, the model predicts the matching probability of each pair of vulnerability and code submission features. Sort all code submissions in descending order based on the matching probability. Train the LightGBM model for sorting vulnerability patch submissions. Use the concatenated features from step 5 as the input to the LightGBM model. Use the matching between the vulnerability and the patch submission as the label for the model training result. Use the logarithmic loss function to train the LightGBM model. After model training, the features generated by each pair of vulnerability and code submission are used to predict the matching probability between the two. Then, sort all code submissions in descending order based on the matching probability. Train a CNN model to sort vulnerability patch submissions. Use the concatenated features from step 5 as input to the CNN model. Use the matching between the vulnerability and the patch submission as the model training result label. Use the Focalloss loss function to train the CNN model. After model training, the model predicts the matching probability of each pair of vulnerability and code submission features. Then, sort all code submissions in descending order based on the matching probability. Step 7: Use the idea of ​​majority voting to perform model fusion, including: For each code submission and the ranking values ​​given by the three models in step 6, obtain the mean of the two closest rankings; sort all code submissions in ascending order based on this mean; if the means are the same, sort them in ascending order based on the unused rankings to obtain the final ranking of each code submission.

2. The method for locating open source software security vulnerability patches based on sorting according to claim 1, characterized in that: In step 1, data collection specifically includes: Collect the matching relationship between vulnerabilities and code submissions from the Snyk website, generate corresponding negative samples based on the vulnerabilities and the repositories where they appear, collect vulnerability-related data from the CVE and NVD websites, and collect code submission data from GitHub and GitLab websites.

3. The method for locating open source software security vulnerability patches based on sorting according to claim 1, characterized in that: In step 2, data preprocessing includes: Use the word segmentation method in Cubert to segment the text content in the vulnerability and code submission, remove the stop words after segmentation, and retain the segmentations that exist in both the vulnerability word bag and the code submission word bag.

Images