Security patch variant positioning method based on two-dimensional feature design

Abstract

The invention belongs to the technical field of open source software supply chain security, and particularly relates to a security patch variant positioning method based on two-dimensional feature design. By designing the two-dimensional features and applying the rule model, comprehensive, accurate and automatic positioning of the security patch variants in the specified open source software code warehouse is realized. The method comprises the following specific steps: data preprocessing: extracting basic information in a submission record and carrying out normalization processing; feature generation: designing and calculating similar features and characterization features of submission record pairs; and variant prediction: predicting the extracted features by applying a random forest model, and judging whether the submitted record is the security patch variant according to a prediction score. According to the method, by widely mining similar features and characterization features between patch variants and combining with a rule-based model, the comprehensiveness, accuracy and automation degree of patch variant positioning are improved, and an effective patch variant positioning tool is provided for software security analysts.

Description

Technical Field

[0001] The present invention belongs to the technical field of open-source software supply chain security, and specifically relates to a method for locating security patch variants designed based on two-dimensional features. Background Art

[0002] With the widespread application of open-source software in various fields, open-source software developers generally adopt the strategy of maintaining multiple code branches or versions to meet diverse requirements. This strategy not only helps maintain the stability of the project, but also supports user conservatism and provides compatibility for downstream software. However, it also brings new challenges: when a vulnerability is discovered in open-source software, the vulnerability will affect multiple code branches or versions. To fix the vulnerability, developers usually develop a security patch on a certain branch and then transplant the patch to all affected branches, including both upstream and downstream. Since each branch has a specific code context, the transplantation of the patch often involves different degrees of code modification to the original patch, ranging from adjusting the patch position to changing the patch logic. Therefore, there are multiple variants of the patch for the same vulnerability.

[0003] To better manage open-source software vulnerabilities and their patches, it is very necessary to locate patch variants of security patches in different software versions or code branches. A high-precision method for locating security patch variants can detect the existence of patches at the source code level, quickly confirm which branches affected by security vulnerabilities have been repaired and which branches have not. In addition, locating patch variants can provide a reference for fixing the same vulnerability, improve the efficiency of vulnerability repair, and provide multiple patch versions for fixing the same vulnerability. The dataset composed of these versions has a wide range of applications, such as training an automatic repair model for vulnerabilities in different software versions.

[0004] Although locating security patch variants is very useful, few patch location works consider this problem. The existing works mainly study how to locate one or more patches for a vulnerability and cannot locate all patch variants. For example, the idea of security patch location is to identify security patches from the open-source software code repository by learning the patterns of security patches, including the syntax of code differences and the semantics of commit messages. However, due to problems such as the difficulty of learning the syntax pattern of code differences and the widespread lack of semantics of commit messages for vulnerabilities, the methods adopting this idea have a low recall rate and cannot locate all patch variants of the vulnerability. In addition, the publicly available security patch location methods usually locate security patches by using the correlation between security patches and publicly available vulnerability information. However, due to problems such as the high missing rate of information in the publicly available vulnerability database and the non-standard writing of security patch commit messages, the works adopting this idea also have a low recall rate and cannot effectively locate all security patch variants.

[0005] Due to the diversity and complexity of the variants of security patches in different software versions or code branches, traditional patch localization methods are difficult to comprehensively and accurately identify all variants.

[0006] Therefore, a new patch localization idea is needed to solve the problem of achieving high-precision and all-round security patch variant localization by referring to a known patch.

[0007] Based on fully exploring the challenges existing in the problem of locating all variants according to a reference security patch, this invention describes the relevance between the security reference patch and other security patch variants from two dimensions, and proposes a security patch variant localization method based on two-dimensional feature design. Summary of the Invention

[0008] The purpose of this invention is to provide an accurate, comprehensive and automatic security patch variant localization method, which provides an effective patch variant localization tool for software security analysts.

[0009] Based on fully exploring the challenges existing in the problem of locating all variants according to a reference security patch, this invention describes the relevance between the security reference patch and other security patch variants from two dimensions, and proposes a security patch variant localization method based on two-dimensional feature design. This invention realizes the comprehensive, accurate and automatic localization of security patch variants in the specified open-source software code repository by designing two-dimensional features and applying a rule model. Specifically, this invention first extracts similar features from two dimensions of commit messages and code changes to capture the similarity between patch variants; then, it measures the representativeness of these similar features through characterization features to reduce false positives; finally, it uses a rule-based model (such as a random forest) to integrate these features to achieve the comprehensive and accurate identification of patch variants.

[0010] The following introduces the related definitions of patch variants, similar features and characterization features:

[0011] Patch variants refer to different versions of patches used to fix the same vulnerability in different code branches or versions. These variants may have differences in commit messages, code changes, etc.

[0012] Similar features refer to the features of the similarity between patch variants, including identifiers, commit message similarity, code change similarity, etc.

[0013] Characterization features refer to the features used to measure the representativeness of similar features, including title generality, number of title words, body length, minimum number of code change lines, and coincidence rate of modified files, etc.

[0014] The security patch variant localization method based on two-dimensional feature design provided by this invention is specifically as follows:

[0015] (1) Data preprocessing: Extract basic information from each submitted record, including identifier, title string, body string, changed file path, and changed code, and normalize this information.

[0016] (2) Feature generation: Pair the reference submission with each submission in the code repository, and generate similarity features and characterization features for the submission pairs based on the extracted basic information.

[0017] (3) Variant prediction: Apply a rule-based model (random forest model) to predict the extracted similarity features and characterization features, and output the prediction score; by comparing the score with a predefined threshold, determine whether the submission is a variant.

[0018] The following is a further description of each step:

[0019] 1. Data preprocessing

[0020] Data preprocessing is mainly used to extract basic information from the submission records and normalize it. The specific steps are as follows:

[0021] (1) Extract basic information

[0022] Through the API provided by the GitPython package, five types of information are extracted from each submission record: identifier, title string, body string, changed file path, and changed code. Among them, the identifier is extracted through a matching pattern, such as the matching pattern for vulnerability identifiers (CVE ID) is CVE-20[0-9]2-[0-9]+; the remaining four types of information are obtained through the API provided by the GitPython package.

[0023] (2) Normalization processing

[0024] The extracted information is further processed, including removing document files and corresponding changes through keywords (such as VERSION, NEWS, README), and deleting all spaces and blank lines in the code changes, deleting commas, parentheses, underscores, etc. at the beginning or end of each modified line. In addition, the submission title is tokenized and lemmatized to avoid affecting the detection effect due to different word forms with the same meaning during subsequent detection feature extraction and similarity calculation.

[0025] 2. Feature generation

[0026] Feature generation designs and calculates the similarity features and characterization features of the submission record pairs, including four similarity features and five characterization features. The specific steps are as follows:

[0027] (1) Similarity feature design

[0028] The present invention explores the similarities between patch variants from three aspects: shared content, derivative relationship, and inclusion relationship. Using one patch to locate other patch variants is essentially a search problem. To narrow down the search scope and ensure the accuracy of patch location, the key lies in making full use of the relevance between patches. Figure 2 Figure 2 shows the patches used to fix vulnerability CVE-2018-11236 in two branches (the main branch and the release / 2.26 / master branch) of glibc respectively, which well reflect these relevances. First, both patches mention the same issue identifier, namely BZ 22786. Second, the two patches have similar commit messages. The patch on the release / 2.26 / master branch is slightly modified based on the security patch of the main branch, including rewriting the message title and adding a cherry-pick mark. These modifications are marked with green underlines in Figure 2 (b). Finally, the code differences of the two patches are exactly the same. Based on this, the present invention proposes a total of four similarity features:

[0029] Identifier, used to determine whether two commits commit the same vulnerability identifier or one commit mentions the hash value of another commit. By checking whether two commits contain the same vulnerability identifier (such as CVE-ID) or whether the hash value of another commit (such as CommitID) is mentioned in the message body of one commit, to determine whether they originate from the same vulnerability or have a derivative relationship.

[0030] Title similarity, calculated as the ratio of the length of the longest common subsequence of the titles of two commit messages to the length of the longer title. First, extract the title part from the commit message, then use the dynamic programming algorithm to calculate the length of the longest common subsequence (LCS) of the two titles, and finally divide the LCS length by the length of the longer title to obtain the title similarity. The calculation method of the title similarity of the commit record is shown in formula (1):

[0031]

[0032] where P r e f is the upstream reference security patch in the current commit record pair, C c a n d is the downstream software candidate commit record,

[0033] T r e f and T c a nd They are the title of the submission records of the two respectively. The LCS calculates the longest common substring of two strings:

[0034] The occurrence of the title in the text, to determine whether the title of one submission is mentioned in the text of the message of another submission. Extract the text part from the submission message, and then check whether the text of one submission contains the title of another submission. If it contains, it is considered that there is shared content between these two submissions.

[0035] The inclusion of code changes, to measure the inclusion relationship between the code changes of two submissions. Extract the code change part from the submission. By comparing the code changes of two submissions, determine whether the code change of one submission is completely included in the code change of another submission. If it is included, it is considered that there is an inclusion relationship between these two submissions. The code change similarity and the change path similarity are calculated as shown in formula (2):

[0036]

[0037] Among them, ChangedLines(C) calculates the number of modified lines for the given submission record C, and P ref ∩C cand represents the common code changes in the two submission records:

[0038] (2) Characterization feature design

[0039] The present invention summarizes three typical situations that may cause similar features to be difficult to distinguish variants from other submissions, namely general title submissions, short submissions, and submissions with the same code changes as patches for fixing other vulnerabilities. To solve these situations, the present invention proposes a total of five characterization features:

[0040] Title generality, calculate the TF-IDF value of each word in the title, and use the average TF-IDF value of each word as the generality of the title. First, tokenize the text in the title, then calculate the TF-IDF value of each word, and finally average the TF-IDF values of all words to obtain the generality of the title. TF is the term frequency, and IDF is the inverse document frequency. When calculating TF-IDF, for the given word w, the submission title m, and the corpus M composed of all the collected reference security patch description information, the TF-IDF is calculated as follows, where n w represents the number of times w appears in m:

[0041]

[0042] TF-IDF(w,m,M) = TF(w,m) * IDF(w,M) #(5)

[0043] Title Word Count: Calculate the average number of words in the titles of two commit messages. Tokenize the text in the titles, count the number of words in each title, and then calculate the average of the word counts of the two titles to obtain the title word count.

[0044] Body Length: Calculate the average length of the bodies of two commit messages. Extract the body part from the commit messages, count the number of characters in each body, and then calculate the average of the lengths of the two bodies to obtain the body length.

[0045] Minimum Number of Code Change Lines: Calculate the smaller value of the number of code change lines in two commits. Extract the code change part from the commits, count the number of lines in each code change, and then take the minimum value of the number of code change lines in the two commits to obtain the minimum number of code change lines.

[0046] Overlap Rate of Modified Files: Calculate the ratio of twice the number of common modified files in two code changes to the total number of modified files in the two commits. Extract the list of modified files from the commits, count the number of common modified files in the two commits, and then divide twice the number of common modified files by the total number of modified files in the two commits to obtain the overlap rate of modified files.

[0047] 3. Variant Prediction

[0048] After calculating the similarity features and representative features, the present invention uses a random forest model to predict the extracted features and determines whether the commit record is a security patch variant based on the prediction score. The specific steps are as follows:

[0049] (1) Random Forest Model Training

[0050] The present invention adopts a random forest ensemble algorithm to generate multiple decision trees with certain differences using randomly selected training data and randomly screened commit features, and makes a final prediction by combining the results of each decision tree. The random forest model contains 100 decision trees, and each decision tree randomly selects 75% of the training data for training and randomly selects by CVE. Specifically:

[0051] Data Grouping: Divide all patch commits in the training set into several groups by CVE to ensure that multiple commits of the same CVE are in the same group;

[0052] Sample Sampling: For the i-th decision tree, randomly select 75% of the CVE groups from all CVE groups as the training sample group of this tree, and include all commit instances within these groups in the training;

[0053] Decision Tree Construction:

[0054] For each sample set, use the DecisionTreeClassifier module in sklearn (https: / / scikit-learn.org / stable / modules / generated / sklearn.tree.DecisionTreeClassifi er.html )Construct a decision tree, with default parameters or determine the optimal tree depth and feature partitioning strategy according to the results of cross-validation;

[0055] Heterogeneous enhancement: Since different CVE groups are sampled for each tree, the difference between decision trees can be increased. In the present invention, 100 such decision trees are trained in total to form a random forest.

[0056] (2) Patch variant prediction

[0057] During prediction, the random forest model will output the prediction results of each decision tree. The average value of the number of decision trees that classify the specified submission as "yes variant" is used as the variant prediction score of the random forest for the specified submission. Then, this score is compared with a predefined threshold to finally determine whether the submission is a variant.

[0058] Voting of a single tree: For the submission S to be tested, it is sequentially sent into 100 decision trees in the random forest, and each decision tree outputs a binary classification result, denoted as:

[0059]

[0060] Calculation of variant prediction score: Define the variant prediction score

[0061]

[0062] represents the proportion of votes for "yes variant" among all decision trees in the random forest;

[0063] Threshold determination rule: On the independent validation set, determine the threshold θ by drawing an ROC curve and taking the maximum F1 value as the criterion. In the present invention, the default value of θ is 0.50;

[0064] Final classification: Compare V(S) with θ. If V(S) ≥ θ, then determine that S is a variant; otherwise, determine it as a non-variant;

[0065] Example illustration: Assume that the test submission is determined to be "yes variant" by 48 decision trees, then V(S) = 0.48; since 0.48 < 0.50, the submission is finally determined to be a non-variant.

[0066] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0067] The security patch variant localization technology provided by the present invention can automatically locate all variants of security patches in a specified open-source software code repository, including multi-commit patches and multi-fix patches; by designing two-dimensional features and applying a rule model, the present invention achieves high-precision localization of patch variants without introducing excessive false positives; the method of the present invention can give a finite set of security patch variants without additional manual participation, improving the automation degree of patch variant localization. Brief Description of the Drawings

[0068] Figure 1 It is a flowchart of a security patch variant localization method designed based on two-dimensional features.

[0069] Figure 2 They are two patch variants for fixing vulnerability CVE-2018-11236 (glibc). Detailed Embodiment

[0070] The present invention will be further introduced below through embodiments in combination with the drawings.

[0071] The present invention mainly aims at the problem of security patch variant localization in open-source software. The goal is to achieve comprehensive, accurate and automatic localization of security patch variants in a specified open-source software code repository by designing two-dimensional features and applying a rule model. In this embodiment, a security patch variant localization system is designed, and its overall framework is as Figure 1 shown, including a data preprocessing module, a feature generation module and a variant prediction module. The execution process of the present invention is as follows:

[0072] (1) The data preprocessing module extracts the basic information in the commit records and performs normalization processing;

[0073] (2) The feature generation module designs and calculates the similarity features and characterization features of commit record pairs;

[0074] (3) The variant prediction module applies a random forest model to predict the extracted features and determines whether the commit record is a security patch variant according to the prediction score.

[0075] The code of the two-dimensional feature stealth patch variant recognition algorithm can be found in the appendix. The system first extracts the basic information in the commit records through the data preprocessing module and performs normalization processing, then designs and calculates the similarity features and characterization features of commit record pairs by using the feature generation module, and finally applies a random forest model to predict the extracted features through the variant prediction module and determines whether the commit record is a security patch variant according to the prediction score.

[0076] (1) Data Preprocessing Module

[0077] This module is mainly used to determine the basic information in the commit record and perform normalization processing. Taking the commit record as input, it finally generates the normalized commit record information.

[0078] 1. Extraction of commit records

[0079] In order to map the commit record to the binary executable file, the present invention first parses the commit record to extract the commit-related function information and the line number information where the commit is located. To obtain the commit record, the present invention directly obtains the commit record through the API provided by the GitPython package. Each commit record contains a commit header, indicating the function name where this commit is located and the position of the code lines affected by the commit. In addition, considering that the commit-related function names given in the commit record may be overwritten by macros (such as SYSCALL_DEFINE(func)), the present invention chooses to determine the commit-related functions by parsing the source code.

[0080] 2. Normalization processing

[0081] To complete the normalization processing, the debugging information in the commit record is directly used for processing. The processing process is as follows:

[0082] (1) First, the title string and the body string in the commit record are tokenized and lemmatized to avoid affecting the detection effect due to different forms of synonymous words during subsequent detection feature extraction and similarity calculation.

[0083] (2) Then, the changed code in the commit record is processed, including deleting all spaces and blank lines in the code change, and deleting commas, parentheses, underscores, etc. at the beginning or end of each modified line.

[0084] (3) Finally, the document files and the corresponding changes are removed through keywords (such as VERSION, NEWS, README).

[0085] (II) Feature generation module

[0086] This module is mainly used to design and calculate the similarity features and characterization features of commit record pairs. This module takes the normalized commit record as input and finally generates the similarity features and characterization features of commit record pairs; see Table 1 below:

[0087] Table 1, Two-dimensional code commit features

[0088]

[0089] 1. Design of similarity features

[0090] To design similar features, the present invention explores the similarities between patch variants from three aspects: shared content, derivative relationship, and inclusion relationship. Based on this, the present invention proposes a total of four similar features:

[0091] ① An identifier, used to determine whether two submissions submit the same vulnerability identifier or one submission mentions the hash value of another submission;

[0092] ② Title similarity, calculating the ratio of the length of the longest common subsequence of the two submission message titles to the length of the longer title;

[0093] ③ Appearance of the title in the text, determining whether the title of another submission is mentioned in the text of one submission's message;

[0094] ④ Code change inclusion, measuring the inclusion relationship between the code changes of two submissions.

[0095] 2. Design of characterization features

[0096] To design characterization features, the present invention summarizes three typical situations that may make it difficult to distinguish variants from other submissions with similar features, namely general title submissions, short submissions, and submissions with the same code changes as patches for fixing other vulnerabilities. To address these situations, the present invention proposes a total of five characterization features:

[0097] ① Title generality, calculating the TF-IDF value of each word in the title and taking the average TF-IDF value of each word as the generality of the title;

[0098] ② Number of title words, calculating the average number of words in the titles of two submission messages;

[0099] ③ Text length, calculating the average length of the texts of two submission messages;

[0100] ④ Minimum number of code change lines, calculating the smaller value of the number of code change lines of two code changes;

[0101] ⑤ Coincidence rate of modified files, calculating the ratio of twice the number of common modified files of two code changes to the total number of modified files of the two submissions.

[0102] (3) Variant prediction module

[0103] This module is mainly used to apply the random forest model to predict the extracted features and determine whether the submission record is a security patch variant based on the prediction score. This module takes the similar features and characterization features of the submission record pair as input and finally generates the prediction result of whether the submission record is a security patch variant.

[0104] (1) Random forest model training

[0105] To train the random forest model, the present invention adopts the random forest ensemble algorithm, generates multiple decision trees with certain differences using randomly selected training data and randomly screened submitted features, and makes a final prediction by combining the results of each decision tree. Specifically, the random forest model contains 100 decision trees, each tree randomly selects 75% of the training data for training, and makes random selections in units of CVE.

[0106] (2) Patch variant prediction

[0107] During prediction, the random forest will output the prediction results of each decision tree, and take the average value of the number of decision trees that classify the specified submission as "yes variant" as the variant prediction score of the random forest for the specified submission. Then, this score is compared with a predefined threshold to finally determine whether the submission is a variant.

[0108] Effectiveness evaluation

[0109] To evaluate the effectiveness of the present invention, the algorithm is as shown in the attachment. Each reference patch in the effectiveness evaluation dataset is paired with all its known variant submissions to form positive samples, and at the same time, it is paired with other submissions in the same code repository to form negative samples; since the number of negative samples far exceeds that of positive samples, the present invention proposes three screening rules: one is that the two submissions mention the same vulnerability identifier or mutually reference hash values; the second is that the longest common subsequence ratio of the titles is greater than 0.5; the third is that the code change inclusion ratio exceeds 50%. Only the negative samples that meet any one of the rules are retained, so as to construct a balanced labeled submission pair dataset of about 3.3K positive samples and 25.7K negative samples.

[0110] Subsequently, the present invention adopts 10-fold cross-validation. In each round, 75% of the vulnerabilities are randomly selected for training and 25% for testing. During testing, the reference patches of the remaining vulnerabilities and all submissions in the repository are input into the model, and the prediction scores are output and compared with the threshold of 0.43 to determine variants.

[0111] The experimental results show that SPV has achieved an accuracy of over 99% and a recall rate of 98% in each round, the F1 score is nearly 99.2%, the AUPRC is about 1.0, and the standard deviation is extremely small, fully verifying the comprehensiveness, accuracy and stability of the method of the present invention in the location of security patch variants.

[0112] The present invention realizes the comprehensive, accurate and automated location of security patch variants in the specified open-source software code repository by designing two-dimensional features and applying a rule model. The method of the present invention not only improves the comprehensiveness and accuracy of patch variant location, but also significantly improves the degree of automation, providing an effective patch variant location tool for software security analysts.

[0113] Attachment, code of the security patch variant location algorithm.

[0114]

Claims

1. A method for locating security patch variants based on two-dimensional feature design, characterized in that The specific steps are as follows: (1) Data preprocessing: Extract basic information from each submitted record, including the identifier, title string, body string, changed file path, and change code, and normalize this information; (2) Feature generation: Pair the reference submission with each submission in the code repository, and generate similarity features and characterization features for the submission pairs based on the extracted basic information; (3) Variant prediction: Apply a rule-based model - the random forest model to predict the extracted similarity features and characterization features, and output the prediction score; By comparing the score with a predefined threshold, determine whether the submission is a variant.

2. The security patch variant localization method according to claim 1, wherein The specific steps of the data preprocessing described in step (1) are as follows: (1) Extract basic information Among the five types of information, the identifier is extracted through a matching pattern, and the other four types of information are obtained through the APIs provided by the GitPython package; (2) Normalization processing Include removing document files and corresponding changes through keywords, deleting all spaces and blank lines in the code changes, deleting commas, parentheses, and underscores at the beginning or end of each modified line; In addition, tokenize the submission title and perform lemmatization.

3. The method for locating security patch variants according to claim 2, wherein The specific steps of the feature generation described in step (2) are as follows: (1) Similarity feature design Mining the similarity between patch variants from three aspects: shared content, derivative relationship, and inclusion relationship; Therefore, four similarity features are proposed: Identifier similarity, used to determine whether two submissions submit the same vulnerability identifier or one submission mentions the hash value of another submission; By checking whether the two submissions contain the same vulnerability identifier, determine whether they originate from the same vulnerability or have a derivative relationship; Title similarity, calculate the ratio of the length of the longest common subsequence of the two submission message titles to the length of the longer title; First, extract the title part from the submission message, then use the dynamic programming algorithm to calculate the length of the longest common subsequence (LCS) of the two titles, and finally divide the LCS length by the length of the longer title to obtain the title similarity; The calculation method of the submission record title similarity is shown in formula (1): Among them, P ref is the upstream reference security patch in the current commit record pair, C cand is the downstream software candidate commit record, T ref and T cand are the titles of the commit records of the two respectively. The LCS calculates the longest common substring of the two strings: Appearance of the title in the body, determine whether the title of another submission is mentioned in the body of the message of one submission; Extract the body part from the submission message, and then check whether the body of one submission contains the title of another submission. If it contains, it is considered that the two submissions have shared content; Code change inclusion, measure the inclusion relationship between the code changes of two submissions; Extract the code change part from the submission. By comparing the code changes of the two submissions, determine whether the code change of one submission is completely included in the code change of the other submission. If it is included, it is considered that the two submissions have an inclusion relationship; The code change similarity and change path similarity are calculated as shown in formula (2): Among them, ChangedLines(C) calculates the number of modified lines for a given commit record C, and P ref ∩C cand represents the common code changes between the two commit records: (2) Characterization feature design Summarize three typical situations where similarity features are difficult to distinguish variants from other submissions, namely submissions with a general title, short submissions, and submissions with the same code changes as patches for fixing other vulnerabilities. A total of five characterization features are proposed: Title generality: Calculate the TF-IDF value of each word in the title, and use the average TF-IDF value of each word as the generality of the title. First, tokenize the text in the title, then calculate the TF-IDF value of each word, and finally average the TF-IDF values of all words to obtain the generality of the title. TF is the term frequency, and IDF is the inverse document frequency. When calculating TF-IDF, for a given word w, the submitted title m, and the corpus M composed of all collected reference security patch description information, the TF-IDF is calculated as follows: TF-IDF(w,m,M) = TF(w,m) * IDF(w,M) #(5) where n w represents the number of times w appears in m; Number of title words: Calculate the average number of words in two submitted message titles. Tokenize the text in the title, count the number of words in each title, and then average the number of words in the two titles to obtain the number of title words. Body length: Calculate the average length of the bodies of two submitted messages. Extract the body part from the submitted message, count the number of characters in each body, and then average the lengths of the two bodies to obtain the body length. Minimum number of code change lines: Calculate the smaller value of the number of code change lines in two code changes. Extract the code change part from the submission, count the number of lines in each code change, and then take the minimum value of the number of code change lines in the two code changes to obtain the minimum number of code change lines. Overlap rate of modified files: Calculate the ratio of twice the number of common modified files in two code changes to the total number of modified files in the two submissions. Extract the list of modified files from the submission, count the number of common modified files in the two submissions, and then divide twice the number of common modified files by the total number of modified files in the two submissions to obtain the overlap rate of modified files.

4. The method for locating a security patch variant according to claim 3, wherein The specific steps of the variant prediction described in step (3) are as follows: (1) Random forest model training Generate multiple decision trees with certain differences using randomly selected training data and randomly screened submission features, and make a final prediction by combining the results of each decision tree. The random forest model contains 100 decision trees. Each decision tree randomly selects 75% of the training data for training and is randomly selected in units of CVE. Specifically: Data grouping: Divide all patch submissions in the training set into several groups in units of CVE to ensure that multiple submissions of the same CVE remain in the same group. Sample extraction: For the i-th decision tree, randomly extract 75% of the CVE groups from all CVE groups as the training sample group of this tree, and include all submission instances within these groups in the training. Decision tree construction: For each sample set, use the DecisionTreeClassifier module in sklearn to construct a decision tree, with default parameters or determine the optimal tree depth and feature partitioning strategy based on the results of cross-validation. Heterogeneous enhancement: Since the CVE groups sampled by each tree are different, the difference between each decision tree can be increased. A total of 100 such decision trees are trained to form a random forest. (2) Patch variant prediction During prediction, the random forest model outputs the prediction results of each decision tree, and takes the average value of the number of decision trees that classify the specified submission as "variant" as the variant prediction score of the random forest for the specified submission; then, compares this score with a predefined threshold to finally determine whether the submission is a variant; specifically: Voting of a single tree: For the submission S to be tested, it is sequentially sent into 100 decision trees in the random forest, and each decision tree outputs a binary classification result, denoted as: Calculation of variant prediction score: Define the variant prediction score indicating the proportion of those voting "variant" among all decision trees in the random forest; Classification rule: On the independent validation set, determine the threshold θ by plotting the ROC curve and taking the maximum F1 value as the criterion, compare V(S) with θ, if V(S) ≥ θ, then determine S as a variant, otherwise determine it as a non-variant.

Images