Ranking-based c / c++ vulnerability and its patch interlinkage recovery system and method

Abstract

The application discloses a kind of C / C++ vulnerability and its patch interlink recovery system and method based on sequencing, comprising: vulnerability data acquisition;Generate vulnerability related features, including based on Bert+BiLSTM+CRF named entity recognition, vulnerability automatic detection based on deep learning and text similarity calculation based on TF-IDF+cosine similarity;Based on the correlation between patch and vulnerability is sorted to related features by sequencing model RankNet, supplemented with manual verification, realize the link recovery between vulnerability and its patch.The application can better utilize the semantic information in vulnerability description and the type information of patch code, fully exploit the correlation between vulnerability and patch, better balance the relationship between the coverage of vulnerability patch and manual workload, compared with the popular defect link recovery method, the method focuses on the link recovery of vulnerability, and compared with the existing vulnerability patch positioning work, can expand the coverage area of patch.

Description

Technical Field

[0001] This invention belongs to the field of software security, specifically relating to a sorting-based C / C++ vulnerability and its patch link recovery system and method. Background Technology

[0002] Software vulnerabilities can weaken the security of computer software, leading to problems such as data loss and tampering, and privacy breaches. More than half of these vulnerabilities are related to C / C++ projects. To support the detection, analysis, and diagnosis of C / C++ project-related vulnerabilities, it is necessary to collect descriptions of open-source software vulnerabilities and their corresponding patch code. However, since most open-source software vulnerability fixes are silently committed, existing vulnerability repositories such as NVD and X-Force often lack links to patch code, making it difficult to collect vulnerability patch code. Therefore, it is necessary to restore the links for C / C++ vulnerabilities and their patches. Previous link restoration efforts have mostly focused on defects and patches, with few efforts focused on vulnerabilities and their patches. Furthermore, these efforts often use matching-based methods; if a commit's information does not completely match the defect information, it is discarded. This results in a large number of patches with incomplete matching information being discarded, reducing the coverage of defect-patch link restoration. Many recent works have explored the construction of vulnerability datasets, but these works often fail to fully utilize vulnerability information, using only a portion of the information directly provided in vulnerability repositories and software repositories, without considering the deep correlation between vulnerabilities and patches, resulting in less than ideal link recovery results.

[0003] Some existing works have used ranking-based methods to construct vulnerability datasets. For example, the paper "Xin Tan, Yuan Zhang, Chenyuan Mi, et al. Locating the Security Patches for Disclosed OSS Vulnerabilities with Vulnerability-Commit Correlation Ranking[C]. Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021:3282-3299." extracts vulnerability IDs, vulnerability locations, vulnerability type correlations, and vulnerability text statistical features to rank submissions. However, this method does not fully utilize code change information when extracting vulnerability type correlations, and its use of vulnerability descriptions and submission information is based solely on statistical indicators without considering textual similarity. Furthermore, it does not perform negative example reduction before ranking, resulting in patches ranking low in submissions, requiring significant manual verification, and having low patch coverage. Summary of the Invention

[0004] Purpose of the invention: In view of the problems of the prior art, the purpose of this invention is to provide a sorting-based C / C++ vulnerability and patch link recovery system and method that can recover vulnerabilities and their patch links, and assist downstream vulnerability detection, analysis, diagnosis and remediation tasks.

[0005] Technical solution: To achieve the above-mentioned objectives, the present invention specifically adopts the following technical solution:

[0006] This invention provides a sorting-based C / C++ vulnerability and patch linking recovery system, comprising: a vulnerability data acquisition module, used to extract basic data of vulnerabilities related to open-source C / C++ projects from the vulnerability database NVD and the vulnerability database X-Force, and to extract basic data of relevant commits from the software repository of the project corresponding to the vulnerability, and to establish vulnerability-commit pairs using the basic data of the vulnerability and the basic data of the relevant commits; a vulnerability-related feature generation module, used to generate vulnerability-related features for each vulnerability-commit pair using the basic data of the vulnerability and the basic data of the relevant commits; and a sorting module, used to train a neural network-based sorting model RankNet using the vulnerability-related features to obtain the trained sorting model Ran. kNet takes a vulnerability-submit pair associated with an unknown patch and feeds it into a trained ranking model, RankNet. RankNet calculates a score for each such pair and sorts them by score. A manual inspection module checks the sorted pairs to determine if each submission is a patch submission. If it is, the vulnerability has been patched, and the vulnerability and its corresponding patch submission have been restored. If not, the vulnerability has not been patched, and the vulnerability and its corresponding patch submission have not been restored.

[0007] Furthermore, in the vulnerability data acquisition module,

[0008] For the NVD vulnerability database, vulnerabilities in C / C++ projects are filtered based on whether the vulnerability description contains .c / .cpp files. The vulnerability ID, disclosure date, vulnerability description for each ID, reference links, affected software version configuration, and vulnerability type are obtained for each vulnerability entry. For the X-Force vulnerability database, descriptions of relevant vulnerabilities are obtained. For the software repository of the project corresponding to the vulnerability, submissions are filtered based on whether .c / .cpp files were modified in the submission and whether the submission was released after the affected version. Code changes, submission date, submission title, and submission information for submissions meeting the filtering criteria are obtained, and the submission title and submission information are concatenated into a submission text. For a specific vulnerability entry, data extracted from the NVD and X-Force vulnerability databases are used as vulnerability data. Data extracted from n eligible submissions in the software repository of the project corresponding to the vulnerability are used as submission data. The vulnerability data of this vulnerability is then merged with the submission data of each of these n submissions, ultimately obtaining n vulnerability-submission pairs containing vulnerability information and submission information.

[0009] Furthermore, in the vulnerability-related feature generation module,

[0010] Generate vulnerability identifier features: For each vulnerability-submission pair, based on the reference links extracted from the vulnerability database NVD, use regular expressions ".*jira.* / (.*)", ".*bugzilla.*\?id=(.*)", ".*mantisbt.org.*\?id=(.*)", and ".*bugs.eclipse.*\?id=(.*)" to extract existing vulnerability IDs. Combine this with the corresponding vulnerability ID to determine whether the submitted text contains the relevant vulnerability ID and vulnerability ID. If it does, generate vulnerability identifier features, which include both vulnerability ID and vulnerability ID features; otherwise, the vulnerability does not have vulnerability identifier features.

[0011] Generate vulnerability location features: For each vulnerability-submission pair, based on the vulnerability description extracted from the vulnerability database NVD, the file location where the vulnerability occurs is extracted using regular expressions "(.*?.c)" and "(.*?.cpp)". Then, named entity recognition is performed on the vulnerability description to extract the function location where the vulnerability occurs. The extraction process for this function location is as follows: the vulnerability description is converted into an input sequence for a BERT pre-trained model, and this input sequence is fed into the BERT pre-trained model for calculation to obtain a representation vector. The representation vector is then fed into the Bi-LSTM layer of the named entity recognition model for calculation to obtain text features. The text features are then used as input to the CRF layer of the named entity recognition model, and text tagging is performed to obtain the function location entity where the vulnerability occurs. This function location entity is then used as the function location of the vulnerability.

[0012] The file locations and function locations extracted from the vulnerability description are compared with those directly extracted from the submitted code changes to determine whether the submission has changed the file locations and function locations extracted from the vulnerability description. If they have been changed, a vulnerability location feature is generated, which includes file location features and function location features; if they have not been changed, then the vulnerability does not have a vulnerability location feature.

[0013] Generate vulnerability type characteristics: For each vulnerability-commit pair, based on the submitted code changes, for the .c (C project) / .cpp (C++ project) files in the modified code files, obtain the original and modified code of the functions in those files. Perform function-level vulnerability detection based on a pre-trained graph convolutional neural network on both the original and modified code. If a vulnerability of a certain type is detected in the original code but not in the modified code, it is determined that the vulnerability has been fixed in this code change, and the corresponding vulnerability type is obtained. The specific process is as follows:

[0014] For affected files in .c (C project) / .cpp (C++ project) files, the original code of the file is first divided into n functions. For each function, its Abstract Syntax Tree (AST), Control Flow Graph (CFG), and Data Flow Graph (DFG) are extracted to represent the function's syntax and semantic information. Then, the source code of the function is encoded into a vector, and this vector is input into a pre-trained graph convolutional neural network model for vulnerability detection. If the model outputs that the function has a vulnerability, the vulnerability type is extracted; if the model outputs that the function does not have a vulnerability, the next function is detected. After all functions in the file have been detected, a vulnerability dictionary consisting of the function names and vulnerability types of the file is obtained.

[0015] Then, the modified code of the file is split into n functions, and the above operation process is performed in the same way to obtain a vulnerability dictionary composed of the function names and vulnerability types of the file;

[0016] Compare the differences between the vulnerability dictionary before and after the file change. If there is no difference between the vulnerability dictionary before and after the file change, it is determined that the code change did not fix the vulnerability. If a function and vulnerability in the vulnerability dictionary before the change disappears in the vulnerability dictionary after the change, it is determined that the vulnerability was fixed in the code change, and the vulnerability type of the fixed vulnerability is obtained. The vulnerability type is compared with the vulnerability type extracted from the vulnerability database NVD, and vulnerability type features are generated.

[0017] Generate vulnerability text similarity features: For each vulnerability-submission pair, based on the vulnerability description extracted from the vulnerability database NVD, delete the text corresponding to the function location entity extracted using named entity recognition when generating vulnerability location features, perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence to obtain the text sequence N_Sequence;

[0018] Based on the vulnerability descriptions and submission texts extracted from the X-Force vulnerability database, the following operations are performed:

[0019] Perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence;

[0020] Finally, text sequences X_Sequence and C_Sequence are obtained respectively;

[0021] The importance of each word in the text sequence N_Text is calculated using the TF-IDF algorithm, and the importance of these words is vectorized to generate the corresponding vector N_Vector for the text sequence N_Text. The calculation process is as follows:

[0022] Calculate the term frequency (TF) of word w in text sequence t:

[0023]

[0024] Where w_num is the number of times word w appears in the text sequence, and t_num is the total number of words in the text sequence t;

[0025] Calculate the inverse document frequency (IDF) of word w in the text sequence set d:

[0026]

[0027] Where |d| represents the total number of text sequences in the text sequence set d, and |{t∈d:w∈t}| represents the number of text sequences containing the word w;

[0028] Calculate the term frequency-inverse document frequency (TF-IDF) of word w: TF-IDF = TF * IDF;

[0029] The text sequence N_Text is vectorized into a vector N_Vector based on the term frequency-inverse document frequency of each word;

[0030] The above method is used to obtain the vector X_Vector of the text sequence X_Text and the vector C_Vector of the text sequence C_Text;

[0031] Finally, cosine similarity is used to calculate the text similarity between text sequence N_Text and text sequence C_Text respectively:

[0032]

[0033] The text similarity X_Similarity between text sequence X_Text and text sequence C_Text is calculated using the above formula. Based on the values ​​of N_Similarity and X_Similarity, vulnerability text similarity features are generated. These vulnerability text similarity features include: similarity features between vulnerability descriptions and submitted texts in the NVD vulnerability database and similarity features between vulnerability descriptions and submitted texts in the X-Force vulnerability database.

[0034] Generate vulnerability remediation potential features: For each vulnerability-submission pair, based on the submitted code changes and the vulnerability detection results when generating vulnerability type features, determine whether the code change has fixed the vulnerability. If the code change has fixed the vulnerability, generate vulnerability remediation potential features; otherwise, the vulnerability-submission pair does not have vulnerability remediation potential features.

[0035] Generate Date Difference Feature: For each vulnerability-commit pair, calculate the difference between the vulnerability disclosure time and the submission time, extracted from the vulnerability database NVD.

[0036] Date_Diff = N_Date - C_Date

[0037] Where Date_Diff represents the difference between the two, N_Date represents the vulnerability disclosure time, and C_Date represents the submission time.

[0038] Based on the survey results, determine the interval in which the difference lies, and generate date difference features based on the proportion of the number of vulnerability-patch pairs in that interval to the total number of survey objects; where a vulnerability-patch pair is a vulnerability and the patch corresponding to that vulnerability, and the survey object is a vulnerability-patch pair.

[0039] Furthermore, in the sorting module,

[0040] For a vulnerability known from a patch, extract any two related vulnerability-submission pairs.<i,j> Calculate the true probability that vulnerability-submission pair i is ranked before vulnerability-submission pair j.

[0041] in

[0042] Then, based on the vulnerability-related characteristics, the two pairs of vulnerability-submission pairs were...<i,j> Represented as a feature vector, and input into the scoring function S:

[0043]

[0044] Where k is the total number of features; F n For the nth feature score of the vulnerability submission pair; W n The score coefficient for the nth feature of the vulnerability-submission pair is generated by the ranking model RankNe;

[0045] Two vulnerability-submission pairs are generated by the scoring function S.<i,j> fractions i ,S j > and use the sigmoid function to calculate the predicted probability P that vulnerability-submission pair i ranks before vulnerability-submission pair j. ij :

[0046]

[0047] Use cross-entropy C as the loss function for the model:

[0048]

[0049] ​Then train the model to minimize the loss function;

[0050] The trained ranking model RankNet is obtained through the above steps.

[0051] A vulnerability-submission pair associated with an unknown patch is input into a trained ranking model RankNet. The model calculates a score for each vulnerability-submission pair associated with an unknown patch and sorts the vulnerability-submission pairs in order of their scores to obtain the sorted vulnerability-submission pairs.

[0052] This invention provides a sorting-based method for recovering C / C++ vulnerabilities and their patch links, comprising: Step 1, extracting basic data of vulnerabilities related to open-source C / C++ projects from the vulnerability database NVD and the vulnerability database X-Force, and extracting basic data of relevant commits from the software repository of the project corresponding to the vulnerability, and establishing vulnerability-commit pairs using the basic data of the vulnerability and the basic data of the relevant commits; Step 2, for each vulnerability-commit pair, generating vulnerability-related features using the basic data of the vulnerability and the basic data of the relevant commits; Step 3, training a neural network-based sorting model RankNet using the vulnerability-related features, obtaining the trained sorting model RankNet, and then... Each vulnerability-submission pair related to an unknown patch vulnerability is input into a trained ranking model RankNet. RankNet calculates a score for each pair and sorts them according to their scores. Step 4 involves manually checking the sorted vulnerability-submission pairs based on the ranking order and determining whether each submission is a patch submission. If it is, the vulnerability has been patched, and the vulnerability and its corresponding patch submission have been restored. If it is not, the vulnerability has not been patched, and the vulnerability and its corresponding patch submission have not been restored.

[0053] Furthermore, in step 1,

[0054] For the NVD vulnerability database, vulnerabilities in C / C++ projects are filtered based on whether the vulnerability description contains .c / .cpp files. The vulnerability ID, disclosure date, vulnerability description for each ID, reference links, affected software version configuration, and vulnerability type are obtained for each vulnerability entry. For the X-Force vulnerability database, descriptions of relevant vulnerabilities are obtained. For the software repository of the project corresponding to the vulnerability, submissions are filtered based on whether .c / .cpp files were modified in the submission and whether the submission was released after the affected version. Code changes, submission date, submission title, and submission information for submissions meeting the filtering criteria are obtained, and the submission title and submission information are concatenated into a submission text. For a specific vulnerability entry, data extracted from the NVD and X-Force vulnerability databases are used as vulnerability data. Data extracted from n eligible submissions in the software repository of the project corresponding to the vulnerability are used as submission data. The vulnerability data of this vulnerability is then merged with the submission data of each of these n submissions, ultimately obtaining n vulnerability-submission pairs containing vulnerability information and submission information.

[0055] Furthermore, in step 2,

[0056] Generate vulnerability identifier features: For each vulnerability-submission pair, based on the reference links extracted from the vulnerability database NVD, use regular expressions ".*jira.* / (.*)", ".*bugzilla.*\?id=(.*)", ".*mantisbt.org.*\?id=(.*)", and ".*bugs.eclipse.*\?id=(.*)" to extract existing vulnerability IDs. Combine this with the corresponding vulnerability ID to determine whether the submitted text contains the relevant vulnerability ID and vulnerability ID. If it does, generate vulnerability identifier features, which include both vulnerability ID and vulnerability ID features; otherwise, the vulnerability does not have vulnerability identifier features.

[0057] Generate vulnerability location features: For each vulnerability-submission pair, based on the vulnerability description extracted from the vulnerability database NVD, the file location where the vulnerability occurs is extracted using regular expressions "(.*?.c)" and "(.*?.cpp)". Then, named entity recognition is performed on the vulnerability description to extract the function location where the vulnerability occurs. The extraction process for this function location is as follows: the vulnerability description is converted into an input sequence for a BERT pre-trained model, and this input sequence is fed into the BERT pre-trained model for calculation to obtain a representation vector. The representation vector is then fed into the Bi-LSTM layer of the named entity recognition model for calculation to obtain text features. The text features are then used as input to the CRF layer of the named entity recognition model, and text tagging is performed to obtain the function location entity where the vulnerability occurs. This function location entity is then used as the function location of the vulnerability.

[0058] The file locations and function locations extracted from the vulnerability description are compared with those directly extracted from the submitted code changes to determine whether the submission has changed the file locations and function locations extracted from the vulnerability description. If they have been changed, a vulnerability location feature is generated, which includes file location features and function location features; if they have not been changed, then the vulnerability does not have a vulnerability location feature.

[0059] Generate vulnerability type characteristics: For each vulnerability-commit pair, based on the submitted code changes, for the .c (C project) / .cpp (C++ project) files in the modified code files, obtain the original and modified code of the functions in those files. Perform function-level vulnerability detection based on a pre-trained graph convolutional neural network on both the original and modified code. If a vulnerability of a certain type is detected in the original code but not in the modified code, it is determined that the vulnerability has been fixed in this code change, and the corresponding vulnerability type is obtained. The specific process is as follows:

[0060] For affected files in .c (C project) / .cpp (C++ project) files, the original code of the file is first divided into n functions. For each function, its Abstract Syntax Tree (AST), Control Flow Graph (CFG), and Data Flow Graph (DFG) are extracted to represent the function's syntax and semantic information. Then, the source code of the function is encoded into a vector, and this vector is input into a pre-trained graph convolutional neural network model for vulnerability detection. If the model outputs that the function has a vulnerability, the vulnerability type is extracted; if the model outputs that the function does not have a vulnerability, the next function is detected. After all functions in the file have been detected, a vulnerability dictionary consisting of the function names and vulnerability types of the file is obtained.

[0061] Then, the modified code of the file is split into n functions, and the above operation process is performed in the same way to obtain a vulnerability dictionary consisting of the function names and vulnerability types of the file;

[0062] Compare the differences between the vulnerability dictionary before and after the file change. If there is no difference between the vulnerability dictionary before and after the file change, it is determined that the code change did not fix the vulnerability. If a function and vulnerability in the vulnerability dictionary before the change disappears in the vulnerability dictionary after the change, it is determined that the vulnerability was fixed in the code change, and the vulnerability type of the fixed vulnerability is obtained. The vulnerability type is compared with the vulnerability type extracted from the vulnerability database NVD, and vulnerability type features are generated.

[0063] Generate vulnerability text similarity features: For each vulnerability-submission pair, based on the vulnerability description extracted from the vulnerability database NVD, delete the text corresponding to the function location entity extracted using named entity recognition when generating vulnerability location features, perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence to obtain the text sequence N_Sequence;

[0064] Based on the vulnerability descriptions and submission texts extracted from the X-Force vulnerability database, the following operations are performed:

[0065] Perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence;

[0066] Finally, text sequences X_Sequence and C_Sequence are obtained respectively;

[0067] The importance of each word in the text sequence N_Text is calculated using the TF-IDF algorithm, and the importance of these words is vectorized to generate the corresponding vector N_Vector for the text sequence N_Text. The calculation process is as follows:

[0068] Calculate the term frequency (TF) of word w in text sequence t:

[0069]

[0070] Where w_num is the number of times word w appears in the text sequence, and t_num is the total number of words in the text sequence t;

[0071] Calculate the inverse document frequency (IDF) of word w in the text sequence set d:

[0072]

[0073] Where |d| represents the total number of text sequences in the text sequence set d, and |{t∈d:w∈t}| represents the number of text sequences containing the word w;

[0074] Calculate the term frequency-inverse document frequency (TF-IDF) of word w: TF-IDF = TF * IDF;

[0075] The text sequence N_Text is vectorized into a vector N_Vector based on the term frequency-inverse document frequency of each word;

[0076] The above method is used to obtain the vector X_Vector of the text sequence X_Text and the vector C_Vector of the text sequence C_Text;

[0077] Finally, cosine similarity is used to calculate the text similarity between text sequence N_Text and text sequence C_Text respectively:

[0078]

[0079] The text similarity X_Similarity between text sequence X_Text and text sequence C_Text is calculated using the above formula. Based on the values ​​of N_Similarity and X_Similarity, vulnerability text similarity features are generated. These vulnerability text similarity features include: similarity features between vulnerability descriptions and submitted texts in the NVD vulnerability database and similarity features between vulnerability descriptions and submitted texts in the X-Force vulnerability database.

[0080] Generate vulnerability remediation potential features: For each vulnerability-submission pair, based on the submitted code changes and the vulnerability detection results when generating vulnerability type features, determine whether the code change has fixed the vulnerability. If the code change has fixed the vulnerability, generate vulnerability remediation potential features; otherwise, the vulnerability-submission pair does not have vulnerability remediation potential features.

[0081] Generate Date Difference Feature: For each vulnerability-commit pair, calculate the difference between the vulnerability disclosure time and the submission time, extracted from the vulnerability database NVD.

[0082] Date_Diff = N_Date - C_Date

[0083] Where Date_Diff represents the difference between the two, N_Date represents the vulnerability disclosure time, and C_Date represents the submission time.

[0084] Based on the survey results, determine the interval in which the difference lies, and generate date difference features based on the proportion of the number of vulnerability-patch pairs in that interval to the total number of survey objects; where a vulnerability-patch pair is a vulnerability and the patch corresponding to that vulnerability, and the survey object is a vulnerability-patch pair.

[0085] Furthermore, in step 3,

[0086] For a vulnerability known from a patch, extract any two related vulnerability-submission pairs.<i,j> Calculate the true probability that vulnerability-submission pair i is ranked before vulnerability-submission pair j.

[0087] in

[0088] Then, based on the vulnerability-related characteristics, the two pairs of vulnerability-submission pairs were...<i,j> Represented as a feature vector, and input into the scoring function S:

[0089]

[0090] Where k is the total number of features; F n For the nth feature score of the vulnerability submission pair; W n The score coefficient for the nth feature of the vulnerability-submission pair is generated by the ranking model RankNe;

[0091] Two vulnerability-submission pairs are generated by the scoring function S.<i,j> fractions i ,S j > and use the sigmoid function to calculate the predicted probability P that vulnerability-submission pair i ranks before vulnerability-submission pair j. ij :

[0092]

[0093] Use cross-entropy C as the loss function for the model:

[0094]

[0095] Then train the model to minimize the loss function;

[0096] The trained ranking model RankNet is obtained through the above steps.

[0097] A vulnerability-submission pair associated with an unknown patch is input into a trained ranking model RankNet. The model calculates a score for each vulnerability-submission pair associated with an unknown patch and sorts the vulnerability-submission pairs in order of their scores to obtain the sorted vulnerability-submission pairs.

[0098] The present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the steps of the above-described sorting-based C / C++ vulnerability and its patch linking recovery method.

[0099] ​The present invention provides a computer-readable storage medium having a computer program stored thereon, characterized in that, when the computer program is executed by a processor, it implements the steps of the above-described sorting-based C / C++ vulnerability and its patch linking recovery method.

[0100] Beneficial effects:

[0101] 1. It uses targeted features to better reflect the implicit relationship between vulnerability-commit pairs;

[0102] 2. Two vulnerability data sources were used, and different weights were given to different vulnerability characteristics during the sorting stage, which can better deal with the situation where some information is missing in a vulnerability-submission pair;

[0103] 3. Counterexample reduction was performed before sorting vulnerability-submission pairs, which can greatly reduce the amount of manual inspection required at the end without reducing the recall rate. Attached Figure Description

[0104] Figure 1 This is a flowchart of the sorting-based C / C++ vulnerability and its patch linking recovery method according to the present invention.

[0105] Figure 2 This is a vulnerability in the present invention - submitting a preliminary survey diagram of date difference.

[0106] Figure 3 This is a vulnerability in the present invention - a flowchart of the submission feature generation process.

[0107] Figure 4 This is a vulnerability in the present invention - a flowchart of the submission pair sorting process. Detailed Implementation

[0108] The specific embodiments of the present invention will be described below with reference to the accompanying drawings.

[0109] Example 1

[0110] like Figure 1As shown, this embodiment discloses a sorting-based C / C++ vulnerability and patch linking recovery system, including: a vulnerability data acquisition module, used to extract basic data of vulnerabilities related to open-source C / C++ projects from the vulnerability database NVD and the vulnerability database X-Force, and extract basic data of relevant commits from the software repository of the project corresponding to the vulnerability, and establish vulnerability-commit pairs using the basic data of the vulnerability and the basic data of the relevant commits; a vulnerability-related feature generation module, used to generate vulnerability-related features for each vulnerability-commit pair using the basic data of the vulnerability and the basic data of the relevant commits; and a sorting module, used to train a neural network-based sorting model RankNet using the vulnerability-related features to obtain a trained sorting model R. AnkNet takes a vulnerability-submit pair associated with an unknown patch and feeds it into a trained ranking model, RankNet. RankNet calculates a score for each such pair and sorts them by score. A manual inspection module checks the sorted vulnerability-submit pairs based on the ranking order, determining if each submission is a patch submission. If it is, the vulnerability has been patched, and the vulnerability and its corresponding patch submission have been restored. If not, the vulnerability has not been patched, and the vulnerability and its corresponding patch submission have not been restored.

[0111] Furthermore, in the vulnerability data acquisition module,

[0112] For the NVD vulnerability database, vulnerabilities in C / C++ projects are filtered based on whether the vulnerability description contains .c / .cpp files. The vulnerability ID (CVE-ID), disclosure date (N_Date), vulnerability description (N_Description) for each ID, reference link (Reference), affected software version configuration (N_Version), and vulnerability type (CWE) are then obtained. For the X-Force vulnerability database, the description of the relevant vulnerability (X_Description) is obtained. For the software repository of the project corresponding to the vulnerability, the vulnerability is assessed based on whether the commits modified .c files. The commits are filtered based on whether the .cpp file was released after the affected version. The code changes (CodeDiff), commit date (C_Date), commit title (C_Title), and commit message (C_Message) of commits meeting the filter criteria are obtained, and the commit title and message are concatenated into a commit text (C_Text). For a specific vulnerability entry, data extracted from the NVD and X-Force vulnerability databases is used as vulnerability data (V_Data), and data extracted from n eligible commits in the software repository of the vulnerability-related project is used as commit data (C_Data). i (i∈[1,n])), and then merge the vulnerability data of the vulnerability with the submission data of each of the n submissions, and finally obtain n sets of vulnerability-submission pairs containing vulnerability information and submission information.

[0113] Furthermore, such as Figure 3 As shown, in the vulnerability-related feature generation module,

[0114] Generate vulnerability identifier features: For each vulnerability-submission pair, based on the reference links extracted from the vulnerability database NVD, use regular expressions ".*jira.* / (.*)", ".*bugzilla.*\?id=(.*)", ".*mantisbt.org.*\?id=(.*)", and ".*bugs.eclipse.*\?id=(.*)" to extract existing vulnerability IDs. Combine this with the corresponding vulnerability ID to determine whether the submitted text contains relevant vulnerability IDs and vulnerability IDs. If they are contained, a vulnerability identifier feature is generated, which includes a vulnerability ID feature (Bug_ID feature) and a vulnerability ID feature (CVE_ID feature). If they are not contained, the vulnerability does not have a vulnerability identifier feature.

[0115] Generate vulnerability location features: For each vulnerability-submission pair, based on the vulnerability description (N_Description) extracted from the vulnerability database NVD, the file location (File_Location) where the vulnerability occurs is extracted using regular expressions "(.*?.c)" and "(.*?.cpp)". Then, Named Entity Recognition (NER) is performed on the vulnerability description (N_Description) to extract the function location (Func_Location) where the vulnerability occurs. The extraction process for the function location is as follows: The vulnerability description (N_Description) is converted into an input sequence for a BERT pre-trained model and fed into the BERT pre-trained model for computation to obtain a representation vector (Desc_Vector). The representation vector is then fed into the Bi-LSTM layer of the Named Entity Recognition model for computation to obtain a text feature (Desc_Feature). The text feature is then used as the input to the CRF layer of the Named Entity Recognition model, and text tagging is performed to obtain the function location entity where the vulnerability occurs. This function location entity is then used as the function location of the vulnerability.

[0116] The file locations and function locations extracted from the vulnerability description are compared with those directly extracted from the submitted code changes to determine whether the submission has changed the file locations and function locations extracted from the vulnerability description. If they have been changed, a vulnerability location feature is generated, which includes a file location feature (File_Location feature) and a function location feature (Func_Location feature). If they have not been changed, then the vulnerability does not have a vulnerability location feature.

[0117] Generate vulnerability type characteristics: For each vulnerability-commit pair, based on the submitted code changes (CodeDiff), for the .c (C project) / .cpp (C++ project) files in the modified files, obtain the original and modified code of the functions in those files. Perform function-level vulnerability detection based on a pre-trained graph convolutional neural network on both the original and modified code. If a vulnerability of a certain type is detected in the original code but not in the modified code, it is determined that the vulnerability has been fixed in this code change, and the corresponding vulnerability type is obtained. The specific process is as follows:

[0118] For affected files in .c (C project) / .cpp (C++ project) files, the original code of the file is first divided into n functions. For each function, its Abstract Syntax Tree (AST), Control Flow Graph (CFG), and Data Flow Graph (DFG) are extracted to represent the function's syntax and semantic information. The source code of the function is then encoded into a vector, and this vector is input into a pre-trained graph convolutional neural network model for vulnerability detection. If the model outputs that the function has a vulnerability, the vulnerability type (C_TypeBefore_n) is extracted; if the model outputs that the function does not have a vulnerability, the next function is detected. After all functions in the file have been detected, a vulnerability dictionary (C_TypeBefore_Dict) consisting of the function names and vulnerability types in the file is obtained.

[0119] Then, the modified code of the file is split into n functions, and the above operation process is performed in the same way to obtain a vulnerability dictionary (C_TypeAfter_Dict) composed of the function names and vulnerability types of the file;

[0120] Compare the vulnerability dictionary before and after the file change. If there is no difference in the vulnerability dictionary before and after the file change, it is determined that the code change did not fix the vulnerability. If a function and vulnerability in the vulnerability dictionary before the change disappears in the vulnerability dictionary after the change, it is determined that the vulnerability was fixed in the code change, and the vulnerability type (C_Type) of the fixed vulnerability is obtained. The vulnerability type (C_Type) is compared with the vulnerability type (CWE) extracted from the vulnerability database NVD, and a vulnerability type feature (Vul_Type feature) is generated.

[0121] Generate vulnerability text similarity features: For each vulnerability-submission pair, based on the vulnerability description extracted from the vulnerability database NVD, delete the text corresponding to the function location entity extracted using named entity recognition when generating vulnerability location features, perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence to obtain the text sequence N_Sequence;

[0122] Based on the vulnerability descriptions and submission texts extracted from the X-Force vulnerability database, the following operations are performed:

[0123] Perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence;

[0124] Finally, text sequences X_Sequence and C_Sequence are obtained respectively;

[0125] The importance of each word in the text sequence N_Text is calculated using the TF-IDF algorithm, and the importance of these words is vectorized to generate the corresponding vector N_Vector for the text sequence N_Text. The calculation process is as follows:

[0126] Calculate the term frequency (TF) of word w in text sequence t:

[0127]

[0128] Where w_num is the number of times word w appears in the text sequence, and t_num is the total number of words in the text sequence t;

[0129] Calculate the inverse document frequency (IDF) of word w in the text sequence set d:

[0130]

[0131] Where |d| represents the total number of text sequences in the text sequence set d, and |{t∈d:w∈t}| represents the number of text sequences containing the word w;

[0132] Calculate the term frequency-inverse document frequency (TF-IDF) of word w: TF-IDF = TF * IDF;

[0133] The text sequence N_Text is vectorized into a vector N_Vector based on the term frequency-inverse document frequency of each word;

[0134] The above method is used to obtain the vector X_Vector of the text sequence X_Text and the vector C_Vector of the text sequence C_Text;

[0135] Finally, cosine similarity is used to calculate the text similarity between text sequence N_Text and text sequence C_Text respectively:

[0136]

[0137] The text similarity X_Similarity between text sequence X_Text and text sequence C_Text is calculated using the above formula. Based on the values ​​of N_Similarity and X_Similarity, vulnerability text similarity features are generated. These vulnerability text similarity features include: similarity features between vulnerability descriptions and submitted texts in the NVD vulnerability database (N_Similarity feature) and similarity features between vulnerability descriptions and submitted texts in the X-Force vulnerability database (X_Similarity feature).

[0138] Generate vulnerability fix potential feature: For each vulnerability-commit pair, based on the submitted code changes and the vulnerability detection results when generating vulnerability type features, determine whether the code change fixes the vulnerability. If the code change fixes the vulnerability, generate vulnerability fix potential feature (Vul_Fix feature). If the code change does not fix the vulnerability, then the vulnerability-commit pair does not have vulnerability fix potential feature.

[0139] Generate Date Difference Feature (Date_Diff Feature): For each vulnerability-commit pair, calculate the difference between the vulnerability disclosure time and the submission time, extracted from the vulnerability database NVD.

[0140] Date_Diff = N_Date - C_Date

[0141] Where Date_Diff represents the difference between the two, N_Date represents the vulnerability disclosure time, and C_Date represents the submission time.

[0142] like Figure 2 As shown, the interval of the difference is determined based on the survey results, and the date difference feature is generated based on the proportion of the number of vulnerability-patch pairs in that interval to the total number of survey objects; where a vulnerability-patch pair is a vulnerability and the patch corresponding to that vulnerability, and the survey object is a vulnerability-patch pair.

[0143] To date, a total of 6 types of features (9 vulnerability features in total) of vulnerability-commit pairs have been generated, namely:

[0144] (1) Vulnerability identifier characteristics: Bug_ID characteristics, CVE_ID characteristics;

[0145] (2) Vulnerability location characteristics: File_Location characteristics, Func_Location characteristics;

[0146] (3) Vulnerability type characteristics: Vul_Type characteristic;

[0147] (4) Text similarity features: N_Similarity feature, X_Similarity feature;

[0148] (5) Repair probability characteristics: Vul_Fix feature;

[0149] (6) Date difference feature: Date_Diff feature.

[0150] Furthermore, such as Figure 4 As shown, in the sorting module,

[0151] For a vulnerability known from a patch, extract any two related vulnerability-submission pairs.<i,j> Calculate the true probability that vulnerability-submission pair i is ranked before vulnerability-submission pair j.

[0152] in

[0153] Then, based on the vulnerability-related characteristics, the two pairs of vulnerability-submission pairs were...<i,j> Represented as a feature vector, and input into the scoring function S:

[0154]

[0155] Where k is the total number of features, here k = 9; F n For the nth feature score of the vulnerability submission pair; W n The score coefficient for the nth feature of the vulnerability-submission pair is generated by the ranking model RankNe;

[0156] Two vulnerability-submission pairs are generated by the scoring function S.<i,j> fractions i ,S j > and use the sigmoid function to calculate the predicted probability P that vulnerability-submission pair i ranks before vulnerability-submission pair j. ij :

[0157]

[0158] Use cross-entropy C as the loss function for the model:

[0159]

[0160] Then train the model to minimize the loss function;

[0161] The trained ranking model RankNet is obtained through the above steps.

[0162] A vulnerability-submit pair associated with an unknown patch is input into a trained ranking model RankNet. The model calculates a score for each vulnerability-submit pair associated with an unknown patch and sorts the vulnerability-submit pairs associated with unknown patches according to the score order, resulting in the top 1, top 5, and top 30 vulnerability-submit pairs.

[0163] Furthermore, in the manual inspection module,

[0164] ​Manually inspect the vulnerability-submit pairs obtained, sorted by Top 1, Top 5, and Top 30, and determine whether the submission in the vulnerability-submit pair is a patch submission. If it is, it means that the vulnerability has been fixed and the vulnerability and its corresponding patch submission have been restored. If it is not, it means that the vulnerability has not been fixed and the vulnerability and its corresponding patch submission have not been restored.

[0165] Example 2

[0166] like Figure 1 As shown, this embodiment provides a sorting-based method for recovering C / C++ vulnerabilities and their patch links, including: Step 1, extracting basic data of vulnerabilities related to open-source C / C++ projects from the vulnerability database NVD and the vulnerability database X-Force, and extracting basic data of relevant commits from the software repository of the project corresponding to the vulnerability, and establishing vulnerability-commit pairs using the basic data of the vulnerability and the basic data of the relevant commits; Step 2, for each vulnerability-commit pair, generating vulnerability-related features using the basic data of the vulnerability and the basic data of the relevant commits; Step 3, training a neural network-based sorting model RankNet using the vulnerability-related features to obtain the trained sorting model RankNet. A vulnerability-submit pair related to a vulnerability with an unknown patch is input into a trained ranking model RankNet. RankNet calculates the score for each such pair and sorts them according to their scores. Step 4 involves manually checking the sorted vulnerability-submit pairs based on the ranking order and determining whether each submission is a patch submission. If it is, the vulnerability has been patched, and the vulnerability and its corresponding patch submission have been restored. If it is not, the vulnerability has not been patched, and the vulnerability and its corresponding patch submission have not been restored.

[0167] Furthermore, in step 1,

[0168] For the NVD vulnerability database, vulnerabilities in C / C++ projects are filtered based on whether the vulnerability description contains .c / .cpp files. The vulnerability ID (CVE-ID), disclosure date (N_Date), vulnerability description (N_Description) for each ID, reference link (Reference), affected software version configuration (N_Version), and vulnerability type (CWE) are then obtained. For the X-Force vulnerability database, the description of the relevant vulnerability (X_Description) is obtained. For the software repository of the project corresponding to the vulnerability, the vulnerability is assessed based on whether the commits modified .c files. The commits are filtered based on whether the .cpp file was released after the affected version. The code changes (CodeDiff), commit date (C_Date), commit title (C_Title), and commit message (C_Message) of commits meeting the filter criteria are obtained, and the commit title and message are concatenated into a commit text (C_Text). For a specific vulnerability entry, data extracted from the NVD and X-Force vulnerability databases is used as vulnerability data (V_Data), and data extracted from n eligible commits in the software repository of the vulnerability-related project is used as commit data (C_Data). i (i∈[1,n])), and then merge the vulnerability data of the vulnerability with the submission data of each of the n submissions, and finally obtain n sets of vulnerability-submission pairs containing vulnerability information and submission information.

[0169] Furthermore, such as Figure 3 As shown, in step 2,

[0170] Generate vulnerability identifier features: For each vulnerability-submission pair, based on the reference links extracted from the vulnerability database NVD, use regular expressions ".*jira.* / (.*)", ".*bugzilla.*\?id=(.*)", ".*mantisbt.org.*\?id=(.*)", and ".*bugs.eclipse.*\?id=(.*)" to extract existing vulnerability IDs. Combine this with the corresponding vulnerability ID to determine whether the submitted text contains relevant vulnerability IDs and vulnerability IDs. If they are contained, a vulnerability identifier feature is generated, which includes a vulnerability ID feature (Bug_ID feature) and a vulnerability ID feature (CVE_ID feature). If they are not contained, the vulnerability does not have a vulnerability identifier feature.

[0171] Generate vulnerability location features: For each vulnerability-submission pair, based on the vulnerability description (N_Description) extracted from the vulnerability database NVD, the file location (File_Location) where the vulnerability occurs is extracted using regular expressions "(.*?.c)" and "(.*?.cpp)". Then, Named Entity Recognition (NER) is performed on the vulnerability description (N_Description) to extract the function location (Func_Location) where the vulnerability occurs. The extraction process for the function location is as follows: The vulnerability description (N_Description) is converted into an input sequence for a BERT pre-trained model and fed into the BERT pre-trained model for computation to obtain a representation vector (Desc_Vector). The representation vector is then fed into the Bi-LSTM layer of the Named Entity Recognition model for computation to obtain a text feature (Desc_Feature). The text feature is then used as the input to the CRF layer of the Named Entity Recognition model, and text tagging is performed to obtain the function location entity where the vulnerability occurs. This function location entity is then used as the function location of the vulnerability.

[0172] The file locations and function locations extracted from the vulnerability description are compared with those directly extracted from the submitted code changes to determine whether the submission has changed the file locations and function locations extracted from the vulnerability description. If they have been changed, a vulnerability location feature is generated, which includes a file location feature (File_Location feature) and a function location feature (Func_Location feature). If they have not been changed, then the vulnerability does not have a vulnerability location feature.

[0173] Generate vulnerability type characteristics: For each vulnerability-commit pair, based on the submitted code changes (CodeDiff), for the .c (C project) / .cpp (C++ project) files in the modified files, obtain the original and modified code of the functions in those files. Perform function-level vulnerability detection based on a pre-trained graph convolutional neural network on both the original and modified code. If a vulnerability of a certain type is detected in the original code but not in the modified code, it is determined that the vulnerability has been fixed in this code change, and the corresponding vulnerability type is obtained. The specific process is as follows:

[0174] For affected files in .c (C project) / .cpp (C++ project) files, the original code of the file is first divided into n functions. For each function, its Abstract Syntax Tree (AST), Control Flow Graph (CFG), and Data Flow Graph (DFG) are extracted to represent the function's syntax and semantic information. The source code of the function is then encoded into a vector, and this vector is input into a pre-trained graph convolutional neural network model for vulnerability detection. If the model outputs that the function has a vulnerability, the vulnerability type (C_TypeBefore_n) is extracted; if the model outputs that the function does not have a vulnerability, the next function is detected. After all functions in the file have been detected, a vulnerability dictionary (C_TypeBefore_Dict) consisting of the function names and vulnerability types in the file is obtained.

[0175] Then, the modified code of the file is split into n functions, and the above operation process is performed in the same way to obtain a vulnerability dictionary (C_TypeAfter_Dict) composed of the function names and vulnerability types of the file;

[0176] Compare the vulnerability dictionary before and after the file change. If there is no difference in the vulnerability dictionary before and after the file change, it is determined that the code change did not fix the vulnerability. If a function and vulnerability in the vulnerability dictionary before the change disappears in the vulnerability dictionary after the change, it is determined that the vulnerability was fixed in the code change, and the vulnerability type (C_Type) of the fixed vulnerability is obtained. The vulnerability type (C_Type) is compared with the vulnerability type (CWE) extracted from the vulnerability database NVD, and a vulnerability type feature (Vul_Type feature) is generated.

[0177] Generate vulnerability text similarity features: For each vulnerability-submission pair, based on the vulnerability description extracted from the vulnerability database NVD, delete the text corresponding to the function location entity extracted using named entity recognition when generating vulnerability location features, perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence to obtain the text sequence N_Sequence;

[0178] Based on the vulnerability descriptions and submission texts extracted from the X-Force vulnerability database, the following operations are performed:

[0179] Perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence;

[0180] Finally, text sequences X_Sequence and C_Sequence are obtained respectively;

[0181] The importance of each word in the text sequence N_Text is calculated using the TF-IDF algorithm, and the importance of these words is vectorized to generate the corresponding vector N_Vector for the text sequence N_Text. The calculation process is as follows:

[0182] Calculate the term frequency (TF) of word w in text sequence t:

[0183]

[0184] Where w_num is the number of times word w appears in the text sequence, and t_num is the total number of words in the text sequence t;

[0185] Calculate the inverse document frequency (IDF) of word w in the text sequence set d:

[0186]

[0187] Where |d| represents the total number of text sequences in the text sequence set d, and |{t∈d:w∈t}| represents the number of text sequences containing the word w;

[0188] Calculate the term frequency-inverse document frequency (TF-IDF) of word w: TF-IDF = TF * IDF;

[0189] The text sequence N_Text is vectorized into a vector N_Vector based on the term frequency-inverse document frequency of each word;

[0190] The above method is used to obtain the vector X_Vector of the text sequence X_Text and the vector C_Vector of the text sequence C_Text;

[0191] Finally, cosine similarity is used to calculate the text similarity between text sequence N_Text and text sequence C_Text respectively:

[0192]

[0193] The text similarity X_Similarity between text sequence X_Text and text sequence C_Text is calculated using the above formula. Based on the values ​​of N_Similarity and X_Similarity, vulnerability text similarity features are generated. These vulnerability text similarity features include: similarity features between vulnerability descriptions and submitted texts in the NVD vulnerability database (N_Similarity feature) and similarity features between vulnerability descriptions and submitted texts in the X-Force vulnerability database (X_Similarity feature).

[0194] Generate vulnerability fix potential feature: For each vulnerability-commit pair, based on the submitted code changes and the vulnerability detection results when generating vulnerability type features, determine whether the code change fixes the vulnerability. If the code change fixes the vulnerability, generate vulnerability fix potential feature (Vul_Fix feature). If the code change does not fix the vulnerability, then the vulnerability-commit pair does not have vulnerability fix potential feature.

[0195] Generate Date Difference Feature (Date_Diff Feature): For each vulnerability-commit pair, calculate the difference between the vulnerability disclosure time and the submission time, extracted from the vulnerability database NVD.

[0196] Date_Diff = N_Date - C_Date

[0197] Where Date_Diff represents the difference between the two, N_Date represents the vulnerability disclosure time, and C_Date represents the submission time.

[0198] like Figure 2 As shown, the interval of the difference is determined based on the survey results, and the date difference feature is generated based on the proportion of the number of vulnerability-patch pairs in that interval to the total number of survey objects; where a vulnerability-patch pair is a vulnerability and the patch corresponding to that vulnerability, and the survey object is a vulnerability-patch pair.

[0199] To date, a total of 6 types of features (9 vulnerability features in total) of vulnerability-commit pairs have been generated, namely:

[0200] (1) Vulnerability identifier characteristics: Bug_ID characteristics, CVE_ID characteristics;

[0201] (2) Vulnerability location characteristics: File_Location characteristics, Func_Location characteristics;

[0202] (3) Vulnerability type characteristics: Vul_Type characteristic;

[0203] (4) Text similarity features: N_Similarity feature, X_Similarity feature;

[0204] (5) Repair probability characteristics: Vul_Fix feature;

[0205] (6) Date difference feature: Date_Diff feature.

[0206] Furthermore, such as Figure 4 As shown, in step 3,

[0207] For a vulnerability known from a patch, extract any two related vulnerability-submission pairs.<i,j> Calculate the true probability that vulnerability-submission pair i is ranked before vulnerability-submission pair j.

[0208] in

[0209] Then, based on the vulnerability-related characteristics, the two pairs of vulnerability-submission pairs were...<i,j> Represented as a feature vector, and input into the scoring function S:

[0210]

[0211] Where k is the total number of features, here k = 9; F n For the nth feature score of the vulnerability submission pair; W n The score coefficient for the nth feature of the vulnerability-submission pair is generated by the ranking model RankNe;

[0212] Two vulnerability-submission pairs are generated by the scoring function S.<i,j> fractions i ,S j > and use the sigmoid function to calculate the predicted probability P that vulnerability-submission pair i ranks before vulnerability-submission pair j. ij :

[0213]

[0214] Use cross-entropy C as the loss function for the model:

[0215]

[0216] Then train the model to minimize the loss function;

[0217] The trained ranking model RankNet is obtained through the above steps.

[0218] A vulnerability-submit pair associated with an unknown patch is input into a trained ranking model RankNet. The model calculates a score for each vulnerability-submit pair associated with an unknown patch and sorts the vulnerability-submit pairs associated with unknown patches according to the score order, resulting in the top 1, top 5, and top 30 vulnerability-submit pairs.

[0219] Furthermore, in step 4,

[0220] ​Manually inspect the vulnerability-submit pairs obtained, sorted by Top 1, Top 5, and Top 30, and determine whether the submission in the vulnerability-submit pair is a patch submission. If it is, it means that the vulnerability has been fixed and the vulnerability and its corresponding patch submission have been restored. If it is not, it means that the vulnerability has not been fixed and the vulnerability and its corresponding patch submission have not been restored.

[0221] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The feature is that when the processor executes the computer program, it implements the steps of the above-described sorting-based C / C++ vulnerability and patch linking recovery method.

[0222] This embodiment provides a computer-readable storage medium storing a computer program, characterized in that the computer program, when executed by a processor, implements the steps of the above-described sorting-based C / C++ vulnerability and its patch linking recovery method.

[0223] There are many methods and approaches to implement this technical solution, and the above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention. All components not explicitly stated in this embodiment can be implemented using existing technology.

Claims

1. A sorting-based C / C++ vulnerability and patch linking recovery system, characterized in that, include: The vulnerability data acquisition module is used to extract basic data of vulnerabilities related to open source C / C++ projects from the vulnerability database NVD and the vulnerability database X-Force, and to extract basic data of relevant submissions from the software repository of the project corresponding to the vulnerability. The vulnerability-submission pair is established using the basic data of the vulnerability and the basic data of the relevant submissions. For the vulnerability database NVD, relevant vulnerabilities in C / C++ projects are filtered based on whether the vulnerability description contains .c / .cpp files, and the vulnerability ID, disclosure date, vulnerability description corresponding to each ID, reference link, software version configuration affected by the vulnerability, and vulnerability type are obtained for the relevant vulnerability entries; Obtain descriptions of relevant vulnerabilities from the X-Force vulnerability database; For the software repository of the project corresponding to the vulnerability, the submissions are filtered based on whether the .c / .cpp files were modified in the submission and whether the submission was released after the affected version. The code changes, submission date, submission title and submission information of the submissions that meet the filtering criteria are obtained, and the submission title and submission information are concatenated into the submission text. For a given vulnerability entry, data extracted from the vulnerability databases NVD and X-Force is used as vulnerability data. Data extracted from the software repository of the project corresponding to the vulnerability that meets the conditions is used as submission data. Then, the vulnerability data of the vulnerability is merged with the submission data of each of the n submissions, and finally n sets of vulnerability-submission pairs containing vulnerability information and submission information are obtained. The vulnerability-related feature generation module is used to generate vulnerability-related features for each vulnerability-submission pair using the basic data of the vulnerability and the basic data of the related submission. The sorting module is used to train a neural network-based sorting model RankNet through the vulnerability-related features, obtain the trained sorting model RankNet, input a vulnerability-submission pair related to an unknown patch into the trained sorting model RankNet, calculate the score of each vulnerability-submission pair related to an unknown patch through the sorting model RankNet, and sort the vulnerability-submission pairs related to an unknown patch according to the score order to obtain the sorted vulnerability-submission pairs. For a vulnerability known from a patch, extract any two related vulnerability-submission pairs. Computational vulnerability - Submission Vulnerability - Submission Previous true probability : Then, based on the vulnerability-related characteristics, the two vulnerability-submission pairs were... Represented as a feature vector, and input into the scoring function. : in, The total number of features; For the vulnerability - the first submission Each feature score; For the vulnerability - the first submission The score coefficients for each feature are generated by the ranking model RankNet; By scoring function Calculate and generate two pairs of vulnerabilities - submit pairs fractions And use the sigmoid function to calculate the vulnerability - submit pair Vulnerability - Submission Previous predicted probability : Using cross-entropy As the loss function of the model: Then train the model to minimize the loss function; The trained ranking model RankNet is obtained through the above steps. A vulnerability-submission pair related to a vulnerability with an unknown patch is input into a trained ranking model RankNet. The model calculates the score of each vulnerability-submission pair related to a vulnerability with an unknown patch and sorts the vulnerability-submission pairs related to the unknown patch according to the score order to obtain the sorted vulnerability-submission pairs. The manual inspection module is used to manually inspect the sorted vulnerability-commit pairs according to the sorting order, and determine whether the commit in the vulnerability-commit pair is a patch commit. If it is, it means that the vulnerability has been fixed and the vulnerability and its corresponding patch commit have been restored. If it is not, it means that the vulnerability has not been fixed and the vulnerability and its corresponding patch commit have not been restored.

2. The sorting-based C / C++ vulnerability and patch linking recovery system according to claim 1, characterized in that, In the vulnerability-related feature generation module Generate vulnerability identifier features: For each vulnerability-submission pair, based on the reference links extracted from the vulnerability database NVD, use regular expressions ".*jira.* / (.*)", ".*bugzilla.*\?id=(.*)", ".*mantisbt.org.*\?id=(.*)", and ".*bugs.eclipse.*\?id=(.*)" to extract existing vulnerability IDs. Combine this with the corresponding vulnerability ID to determine whether the submitted text contains the relevant vulnerability ID and vulnerability ID. If it does, generate vulnerability identifier features, which include both vulnerability ID and vulnerability ID features; otherwise, the vulnerability does not have vulnerability identifier features. Generate vulnerability location features: For each vulnerability-submission pair, based on the vulnerability description extracted from the vulnerability database NVD, the file location where the vulnerability occurs is extracted using regular expressions "(.*?.c)" and "(.*?.cpp)". Then, named entity recognition is performed on the vulnerability description to extract the function location where the vulnerability occurs. The extraction process for this function location is as follows: The vulnerability description is converted into an input sequence for a BERT pre-trained model, and this input sequence is fed into the BERT pre-trained model for calculation to obtain a representation vector. The representation vector is then fed into the Bi-LSTM layer of the named entity recognition model for calculation to obtain text features. The text features are then used as input to the CRF layer of the named entity recognition model, and text tagging is performed to obtain the function location entity where the vulnerability occurs. This function location entity is then used as the function location of the vulnerability. The file locations and function locations extracted from the vulnerability description are compared with those directly extracted from the submitted code changes to determine whether the submission has changed the file locations and function locations extracted from the vulnerability description. If they have been changed, a vulnerability location feature is generated, which includes file location features and function location features; if they have not been changed, then the vulnerability does not have a vulnerability location feature. Generate vulnerability type characteristics: For each vulnerability-commit pair, based on the submitted code changes, for the .c (C project) / .cpp (C++ project) files in the modified code files, obtain the original and modified code of the functions in those files. Perform function-level vulnerability detection based on a pre-trained graph convolutional neural network on both the original and modified code. If a vulnerability of a certain type is detected in the original code but not in the modified code, it is determined that the vulnerability has been fixed in this code change, and the corresponding vulnerability type is obtained. The specific process is as follows: For affected files in .c (C project) / .cpp (C++ project) files, the original code of the file is first divided into n functions. For each function, its Abstract Syntax Tree (AST), Control Flow Graph (CFG), and Data Flow Graph (DFG) are extracted to represent the function's syntax and semantic information. Then, the source code of the function is encoded into a vector, and this vector is input into a pre-trained graph convolutional neural network model for vulnerability detection. If the model outputs that the function has a vulnerability, the vulnerability type is extracted; if the model outputs that the function does not have a vulnerability, the next function is detected. After all functions in the file have been detected, a vulnerability dictionary consisting of the function names and vulnerability types of the file is obtained. Then, the modified code of the file is split into n functions, and the above operation process is performed in the same way to obtain a vulnerability dictionary composed of the function names and vulnerability types of the file; Compare the differences between the vulnerability dictionary before and after the file change. If there is no difference between the vulnerability dictionary before and after the file change, it is determined that the code change did not fix the vulnerability. If a function and vulnerability in the vulnerability dictionary before the change disappears in the vulnerability dictionary after the change, it is determined that the vulnerability was fixed in the code change, and the vulnerability type of the fixed vulnerability is obtained. The vulnerability type is compared with the vulnerability type extracted from the vulnerability database NVD, and vulnerability type features are generated. Generating vulnerability text similarity features: For each vulnerability-submission pair, based on the vulnerability description extracted from the NVD vulnerability database, the text corresponding to the function location entities extracted using named entity recognition when generating vulnerability location features is deleted, and text tokenization is performed. The tokenized words are then combined into a text sequence, and stop word removal, lemmatization, and synonym replacement are performed on the text sequence to obtain the final text sequence. ; Based on the vulnerability descriptions and submission texts extracted from the X-Force vulnerability database, the following operations are performed: Perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence; Finally, the text sequences were obtained. and text sequence ; Calculate text sequences using the TF-IDF algorithm. The importance of each word is determined and vectorized to generate a text sequence. corresponding vector The calculation process is as follows: Calculate words In text sequence TF in the middle: in Words in a text sequence Number of times it appears It is a text sequence The total number of words in the text; Calculate words In text sequence set Inverse document frequency (IDF) in: in Represents a set of text sequences The total number of text sequences in the text. Indicates words The number of text sequences; Calculate words Term Frequency-Inverse Document Frequency (TF-IDF): - ; The text sequence is analyzed based on the term frequency-inverse document frequency of each word. Vectorization to vector ; The text sequence is obtained using the method described above. vector and text sequence vector ; Finally, cosine similarity was used to calculate the text sequences. With text sequence Text similarity between: The text sequence is calculated using the above formula. With text sequence Text similarity between and according to and Numerical generation of vulnerability text similarity features, which include: similarity features between vulnerability descriptions and submitted texts in the NVD vulnerability database and the X-Force vulnerability descriptions and submitted texts in the vulnerability database; Generate vulnerability remediation potential features: For each vulnerability-submission pair, based on the submitted code changes and the vulnerability detection results when generating vulnerability type features, determine whether the code change has fixed the vulnerability. If the code change has fixed the vulnerability, generate vulnerability remediation potential features; otherwise, the vulnerability-submission pair does not have vulnerability remediation potential features. Generate Date Difference Feature: For each vulnerability-commit pair, calculate the difference between the vulnerability disclosure time and the submission time, extracted from the vulnerability database NVD. in, This represents calculating the difference between the two. Indicates the time when the vulnerability was disclosed. This represents the submission time. Based on the survey results, determine the interval in which the difference lies, and generate date difference features based on the proportion of the number of vulnerability-patch pairs in that interval to the total number of survey objects; where a vulnerability-patch pair is a vulnerability and the patch corresponding to that vulnerability, and the survey object is a vulnerability-patch pair.

3. A sorting-based method for recovering C / C++ vulnerabilities and their inter-patch linking, comprising: Step 1: Extract basic data of vulnerabilities related to open source C / C++ projects from the vulnerability database NVD and the vulnerability database X-Force, and extract basic data of relevant submissions from the software repository of the project corresponding to the vulnerability. Use the basic data of the vulnerability and the basic data of the relevant submissions to establish vulnerability-submission pairs. For the vulnerability database NVD, relevant vulnerabilities in C / C++ projects are filtered based on whether the vulnerability description contains .c / .cpp files, and the vulnerability ID, disclosure date, vulnerability description corresponding to each ID, reference link, software version configuration affected by the vulnerability, and vulnerability type are obtained for the relevant vulnerability entries; Obtain descriptions of relevant vulnerabilities from the X-Force vulnerability database; For the software repository of the project corresponding to the vulnerability, the submissions are filtered based on whether the .c / .cpp files were modified in the submission and whether the submission was released after the affected version. The code changes, submission date, submission title and submission information of the submissions that meet the filtering criteria are obtained, and the submission title and submission information are concatenated into the submission text. For a given vulnerability entry, data extracted from the vulnerability databases NVD and X-Force is used as vulnerability data. Data extracted from the software repository of the project corresponding to the vulnerability that meets the conditions is used as submission data. Then, the vulnerability data of the vulnerability is merged with the submission data of each of the n submissions, and finally n sets of vulnerability-submission pairs containing vulnerability information and submission information are obtained. Step 2: For each vulnerability-submission pair, generate vulnerability-related features using the basic data of the vulnerability and the basic data of the related submission; Step 3: Train a neural network-based ranking model RankNet using the vulnerability-related features to obtain the trained ranking model RankNet. Input a vulnerability-submission pair related to an unknown patch vulnerability into the trained ranking model RankNet, and calculate the score of each vulnerability-submission pair related to an unknown patch vulnerability through the ranking model RankNet. Sort the vulnerability-submission pairs related to an unknown patch vulnerability according to the score order to obtain the sorted vulnerability-submission pairs. For a vulnerability known from a patch, extract any two related vulnerability-submission pairs. Computational vulnerability - Submission Vulnerability - Submission Previous true probability : Then, based on the vulnerability-related characteristics, the two vulnerability-submission pairs were... Represented as a feature vector, and input into the scoring function. : in, The total number of features; For the vulnerability - the first submission Each feature score; For the vulnerability - the first submission The score coefficients for each feature are generated by the ranking model RankNet; By scoring function Calculate and generate two pairs of vulnerabilities - submit pairs fractions And use the sigmoid function to calculate the vulnerability - submit pair Vulnerability - Submission Previous predicted probability : Using cross-entropy As the loss function of the model: Then train the model to minimize the loss function; The trained ranking model RankNet is obtained through the above steps. A vulnerability-submission pair related to a vulnerability with an unknown patch is input into a trained ranking model RankNet. The model calculates the score of each vulnerability-submission pair related to a vulnerability with an unknown patch and sorts the vulnerability-submission pairs related to the unknown patch according to the score order to obtain the sorted vulnerability-submission pairs. Step 4: Manually check the sorted vulnerability-commit pairs according to the sorting order, and determine whether the commit in the vulnerability-commit pair is a patch commit. If it is, it means that the vulnerability has been fixed and the vulnerability and its corresponding patch commit have been restored. If it is not, it means that the vulnerability has not been fixed and the vulnerability and its corresponding patch commit have not been restored.

4. The sorting-based C / C++ vulnerability and its inter-patch linking recovery method according to claim 3, characterized in that, In step 2, Generate vulnerability identifier features: For each vulnerability-submission pair, based on the reference links extracted from the vulnerability database NVD, use regular expressions ".*jira.* / (.*)", ".*bugzilla.*\?id=(.*)", ".*mantisbt.org.*\?id=(.*)", and ".*bugs.eclipse.*\?id=(.*)" to extract existing vulnerability IDs. Combine this with the corresponding vulnerability ID to determine whether the submitted text contains the relevant vulnerability ID and vulnerability ID. If it does, generate vulnerability identifier features, which include both vulnerability ID and vulnerability ID features; otherwise, the vulnerability does not have vulnerability identifier features. Generate vulnerability location features: For each vulnerability-submission pair, based on the vulnerability description extracted from the vulnerability database NVD, the file location where the vulnerability occurs is extracted using regular expressions "(.*?.c)" and "(.*?.cpp)". Then, named entity recognition is performed on the vulnerability description to extract the function location where the vulnerability occurs. The extraction process for this function location is as follows: The vulnerability description is converted into an input sequence for a BERT pre-trained model, and this input sequence is fed into the BERT pre-trained model for calculation to obtain a representation vector. The representation vector is then fed into the Bi-LSTM layer of the named entity recognition model for calculation to obtain text features. The text features are then used as input to the CRF layer of the named entity recognition model, and text tagging is performed to obtain the function location entity where the vulnerability occurs. This function location entity is then used as the function location of the vulnerability. The file locations and function locations extracted from the vulnerability description are compared with those directly extracted from the submitted code changes to determine whether the submission has changed the file locations and function locations extracted from the vulnerability description. If they have been changed, a vulnerability location feature is generated, which includes file location features and function location features; if they have not been changed, then the vulnerability does not have a vulnerability location feature. Generate vulnerability type characteristics: For each vulnerability-commit pair, based on the submitted code changes, for the .c (C project) / .cpp (C++ project) files in the modified code files, obtain the original and modified code of the functions in those files. Perform function-level vulnerability detection based on a pre-trained graph convolutional neural network on both the original and modified code. If a vulnerability of a certain type is detected in the original code but not in the modified code, it is determined that the vulnerability has been fixed in this code change, and the corresponding vulnerability type is obtained. The specific process is as follows: For affected files in .c (C project) / .cpp (C++ project) files, the original code of the file is first divided into n functions. For each function, its Abstract Syntax Tree (AST), Control Flow Graph (CFG), and Data Flow Graph (DFG) are extracted to represent the function's syntax and semantic information. Then, the source code of the function is encoded into a vector, and this vector is input into a pre-trained graph convolutional neural network model for vulnerability detection. If the model outputs that the function has a vulnerability, the vulnerability type is extracted; if the model outputs that the function does not have a vulnerability, the next function is detected. After all functions in the file have been detected, a vulnerability dictionary consisting of the function names and vulnerability types of the file is obtained. Then, the modified code of the file is split into n functions, and the above operation process is performed in the same way to obtain a vulnerability dictionary composed of the function names and vulnerability types of the file; Compare the differences between the vulnerability dictionary before and after the file change. If there is no difference between the vulnerability dictionary before and after the file change, it is determined that the code change did not fix the vulnerability. If a function and vulnerability in the vulnerability dictionary before the change disappears in the vulnerability dictionary after the change, it is determined that the vulnerability was fixed in the code change, and the vulnerability type of the fixed vulnerability is obtained. The vulnerability type is compared with the vulnerability type extracted from the vulnerability database NVD, and vulnerability type features are generated. Generating vulnerability text similarity features: For each vulnerability-submission pair, based on the vulnerability description extracted from the NVD vulnerability database, the text corresponding to the function location entities extracted using named entity recognition when generating vulnerability location features is deleted, and text tokenization is performed. The tokenized words are then combined into a text sequence, and stop word removal, lemmatization, and synonym replacement are performed on the text sequence to obtain the final text sequence. ; Based on the vulnerability descriptions and submission texts extracted from the X-Force vulnerability database, the following operations are performed: Perform text tokenization, combine the tokenized words into a text sequence, and then perform stop word removal, lemmatization, and synonym replacement on the text sequence; Finally, the text sequences were obtained. and text sequence ; Calculate text sequences using the TF-IDF algorithm. The importance of each word is determined and vectorized to generate a text sequence. corresponding vector The calculation process is as follows: Calculate words In text sequence TF in the middle: in Words in a text sequence Number of times it appears It is a text sequence The total number of words in the text; Calculate words In text sequence set Inverse document frequency (IDF) in: in Represents a set of text sequences The total number of text sequences in the text. Indicates words The number of text sequences; Calculate words Term Frequency-Inverse Document Frequency (TF-IDF): - ; The text sequence is analyzed based on the term frequency-inverse document frequency of each word. Vectorization to vector ; The text sequence is obtained using the method described above. vector and text sequence vector ; Finally, cosine similarity was used to calculate the text sequences. With text sequence Text similarity between: The text sequence is calculated using the above formula. With text sequence Text similarity between and according to and Numerical generation of vulnerability text similarity features, which include: similarity features between vulnerability descriptions and submitted texts in the NVD vulnerability database and the X-Force vulnerability descriptions and submitted texts in the vulnerability database; Generate vulnerability remediation potential features: For each vulnerability-submission pair, based on the submitted code changes and the vulnerability detection results when generating vulnerability type features, determine whether the code change has fixed the vulnerability. If the code change has fixed the vulnerability, generate vulnerability remediation potential features; otherwise, the vulnerability-submission pair does not have vulnerability remediation potential features. Generate Date Difference Feature: For each vulnerability-commit pair, calculate the difference between the vulnerability disclosure time and the submission time, extracted from the vulnerability database NVD. in, This represents calculating the difference between the two. Indicates the time when the vulnerability was disclosed. This represents the submission time. Based on the survey results, determine the interval in which the difference lies, and generate date difference features based on the proportion of the number of vulnerability-patch pairs in that interval to the total number of survey objects; where a vulnerability-patch pair is a vulnerability and the patch corresponding to that vulnerability, and the survey object is a vulnerability-patch pair.

5. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 3 to 4.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 3 to 4.

Images