A method for constructing a large-scale semantically equivalent secure patch dataset

Abstract

The application provides a large-scale semantic equivalent security patch data set construction method, different real security patch sets are collected through cross OSS project and branch; based on the equivalent patch generation technology of natural evolution, the context change of the transplanted security patch in the real development environment is covered, the number of equivalent patches is exponentially increased to form an evolution patch set; based on the semantic equivalent patch generation technology of compilation-decompilation, the real security patch set and the evolution patch set are processed, the syntax and control flow change of the security patch across projects and branches is covered, and the comprehensiveness of the security patch is increased; based on the equivalent patch generation technology of AST control flow change, the real security patch set and the evolution patch set are processed, the typical modification characteristics of the security patch are covered, the repair characteristics of the security patch are enhanced, stronger model generalization can be provided, and finally all the sets are fused to form a large-scale semantic equivalent security patch data set.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a method for constructing a large-scale semantically equivalent security patch dataset. Background Technology

[0002] The increasing prevalence of open-source software (OSS) allows enterprise developers to reuse streamlined functionalities from reliable OSS projects for agile development. However, the propagation of vulnerabilities resulting from reusing third-party OSS can threaten the security of the entire system. In principle, keeping the reused OSS code up-to-date can prevent the impact of vulnerabilities. Vulnerabilities often have a lifespan of up to two years, and OSS project developers typically prefer to silently patch vulnerabilities, meaning they don't disclose which vulnerabilities a patch fixes in patch commit messages. Therefore, software developers reusing the project are unaware of the relevant vulnerability fixes. Software developers need to use the disclosed vulnerability information to detect undiscovered vulnerabilities in their software source code; furthermore, to patch vulnerabilities as early as possible, they must quickly obtain critical security patches from upstream suppliers. Therefore, how to accurately detect vulnerabilities and quickly and accurately identify relevant security patches has received considerable attention from researchers.

[0003] However, security patch identification methods based on machine learning or rules require a large, accurate, and comprehensive dataset of security patches. Existing public datasets, however, cannot collect enough patches and are often limited to specific patches from a single or a few specific open-source repositories. Furthermore, they fail to cover the feature changes brought about by patch modifications across projects. Currently, existing datasets are not conducive to the generalization of solutions, and their tendency to overfit has significantly limited the progress of related research. Therefore, a method is needed to automatically collect security patches with the same CVE ID across different branches of different projects. This method must also satisfy the characteristic that security patches adapt to contextual modifications by developers in real-world development environments, ultimately forming a large-scale, semantically equivalent security patch dataset.

[0004] The 2021 OSSRA report shows that 98% of codebases currently contain open-source components; of these, 84% contain at least one publicly disclosed CVE vulnerability, and nearly 60% contain high-risk vulnerabilities. Typically, a vulnerability's lifespan lasts about two years. This means that within two years of a vulnerability being unpatched, attackers can exploit N-Day vulnerabilities disclosed in vulnerability databases to attack unpatched software systems. For example, the remote command execution vulnerability (CVE-2021-22205) was initially released in April 2021; however, seven months later, over 30,000 unpatched GitLab servers were compromised and abused to launch DDoS attacks.

[0005] To prevent unpatched vulnerabilities from being exploited by hackers, downstream software vendors need to promptly patch vulnerabilities. Software patches are a set of changes between two source code versions used to improve security, resolve functional issues, and add new features. Security patches, in particular, can address specific security vulnerabilities and enhance software security. Because OSS software often has multiple versions or branches coexisting, and enterprises frequently reuse different versions of OSS software components, versions can be categorized as upstream and downstream. The upstream version is the latest iteration of the OSS project, and all other versions can be categorized as downstream versions based on their update time. Upstream software developers often silently commit vulnerability patches, while downstream vendors often customize reused code. Therefore, downstream vendors cannot confirm whether the upstream version has patched the vulnerability, nor can they confirm whether their customized code still contains the vulnerabilities disclosed by NVD.

[0006] First, based on the characteristics of porting to a real environment, security patches can be categorized into the following four types: 1) Patch location adjustment: When porting a patch to a given branch, the vulnerable code may be located in different files, functions, or lines of code. Therefore, developers need to adjust the position of the patch statements to apply the patch; 2) Adapting to code context: When the context of the vulnerable code on a branch differs from the context of the patch development branch, directly applying the original patch may lead to semantic or syntax errors. Developers do not need to adjust the vulnerability fix logic; they only need to modify the patch to adapt to the new code context, such as using a new namespace; 3) Changing the fix logic: Code differences between the ported branch and the original patch development branch require adjustments to the vulnerability fix logic; 4) Irrelevant changes: Vulnerability fixes may involve some unrelated changes, such as modifying comments and indentation. These changes are not necessary during patch porting.

[0007] Because security patches aggregate both vulnerable code and corresponding modifications, many vulnerability detection studies begin with security patches. Jin et al. obtained security patches from eight well-known Git repositories to detect vulnerable code clones; Li et al. built a Vulnerability Patch Database (VPD) consisting of 19 products. However, these datasets are insufficient in size to perform machine learning-based research and may introduce bias into the analysis results. Although SARD provides some samples of mitigating vulnerabilities, it primarily focuses on vulnerable code, and most samples are manually generated. By querying thousands of CVE records from the NVD open-source project, F. Li et al. built a large-scale security patch database, and they were the first to conduct a large-scale empirical study on security patches and non-security bug fixes, discussing the metadata characteristics and lifecycle of security patches. Furthermore, considering silent security patches, Xiao et al. enriched their dataset with submissions obtained from their industry partners, but this dataset is not publicly available.

[0008] However, most existing security patch datasets have the following limitations:

[0009] 1) The publicly available security patch dataset is insufficient. Insufficient data indicates that the dataset is not comprehensive, and the missing security patches are often not due to random bias, but rather systematic bias. These biases will greatly affect the accuracy of related applications.

[0010] 2) Publicly available security patch datasets are collected from only one or a few specific software repositories. The security patches collected in a specific OSS project cover a very small number of patch modification types and vulnerabilities. Vulnerability detection or security patch identification methods designed based on this dataset will only support the detection of specific software and vulnerabilities and cannot be migrated to the detection of other software.

[0011] 3) Publicly available security patch datasets often focus only on specific types of security patches. These datasets tend to focus only on specific types of vulnerabilities such as buffer overflows and null pointer exceptions, while collecting fewer other types of security patches, which limits the generalization ability of related applications;

[0012] 4) Publicly available security patch datasets lack security patch feature enhancements. Patching the same vulnerability in different projects will generate many security patches with the same semantics but different syntaxes. However, existing security patch datasets often only collect a single patch for each vulnerability, lacking the richness of patches for real vulnerabilities, which will lead to overfitting problems in related applications. Summary of the Invention

[0013] To address the aforementioned problems in existing technologies, this invention provides a method for constructing large-scale semantically equivalent security patch datasets.

[0014] The present invention provides a method for constructing a large-scale semantically equivalent security patch dataset, comprising:

[0015] Step 1: Obtain vulnerability disclosure entries (CVE) from a general database, recursively access potentially related hyperlinks based on the CVE information to obtain the original security patch, locate potential patches across all branches based on the original security patch, perform equivalent and valid judgment on the potential patches, and thus form a real security patch set.

[0016] Step 2: Extract the patch content of each patch in the real security patch set, analyze the historical modification evolution timeline of the patch based on the patch content, and perform patch oversampling along the historical modification evolution timeline to obtain the evolved patch set;

[0017] Step 3: For each patch in the real security patch set and the evolved patch set, compile and decompile the patch to generate equivalent security patches with different syntax but equivalent semantics, and eliminate invalid differences introduced by the compiler in the equivalent security patches, to obtain the first equivalent security patch set corresponding to the real security patch set and the second equivalent security patch set corresponding to the evolved patch set.

[0018] Step 4: For each patch in the real security patch set and the evolved patch set, generate control flow equivalent and semantically equivalent security patches by building an abstract syntax tree, changing the equivalent control flow nodes of the abstract syntax tree, and mapping them to the source code of the patch; and form a third equivalent security patch set by combining the security patches corresponding to the real security patch set, and form a fourth equivalent security patch set by combining the security patches corresponding to the evolved patch set.

[0019] Step 5: Merge the real security patch set, the evolution patch set, the first equivalent security patch set, the second equivalent security patch set, the third equivalent security patch set, and the fourth equivalent security patch set to obtain a large-scale semantically equivalent security patch dataset.

[0020] This invention has at least the following beneficial effects:

[0021] (1) This invention provides a method for constructing a large-scale semantically equivalent security patch dataset. Through three different patch generation techniques, the semantic equivalence characteristics of security patches in the natural evolution process are satisfied. Based on this method, a large-scale semantically equivalent security patch dataset can be formed.

[0022] (2) When constructing the security patch dataset, this invention proposes an equivalent natural evolution security patch generation technique that meets the security patch porting habits in real-world environments. Compared with existing security patch dataset generation methods, this technique can generate context-modified, semantically equivalent security patch natural evolution versions based on historical modification timelines through oversampling across all branches of the OSS project affected by real vulnerabilities. The natural evolution security patches generated by this method have the advantages of wide software version coverage, semantic diversity equivalence, and large-scale batch operation.

[0023] (3) When constructing the security patch dataset, this invention proposes a security patch generation technology based on compilation-decompilation syntax changes and semantic equivalence. This technology transforms the target code from source code to binary and then decompiles it back to source code form. This transformation introduces a certain degree of reconstruction of the syntax structure, thereby obtaining security patches with different syntax and control flow but still semantically equivalent.

[0024] (4) When constructing the security patch dataset, this invention proposes a security patching technique based on AST-modified control flow and semantic equivalence of control flow. This technique enriches the equivalent expression of security patches by introducing control flow complexity into the security patches, which can effectively reduce the overfitting of the learning model and improve the performance of automatic patch analysis tasks.

[0025] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the prior art solution that is closest to the present invention;

[0027] Figure 2 This invention provides a flowchart of a method for constructing a large-scale semantically equivalent security patch dataset;

[0028] Figure 3 This is a flowchart of the method for collecting security patches from real projects according to the present invention;

[0029] Figure 4 This is a flowchart of the method for generating equivalent security patches through natural evolution;

[0030] Figure 5 This is a schematic diagram illustrating the search for evolutionary patches based on a historical modification timeline.

[0031] Figure 6 This is a flowchart of the method for generating equivalent security patches based on decompilation;

[0032] Figure 7 This is the process for generating AST equivalent control flow security patches;

[0033] Figure 8 It is an example diagram of an equivalent control flow change for the negation of the AST conditional logic. Detailed implementation manners

[0034] The following further describes the present invention in detail with reference to specific embodiments, but the implementation manners of the present invention are not limited thereto.

[0035] Before introducing the present invention, the closest prior art and technical concept of the present invention will be introduced first.

[0036] Reference Figure 1 , Figure 1 is the technical solution closest to the present invention, Figure 1 The technical solution in []] is mainly divided into three stages:

[0037] (1) Generate an Abstract Syntax Tree (AST) from the patch file:

[0038] For each patch, this solution retrieves the relevant source code before and after applying the target patch file so that these corresponding source code files can be parsed; thereafter, the corresponding repository is rolled back to the versions before and after merging the target patch. In addition, this solution analyzes each security patch to find the source code files related to the patch listed in the lines starting with diff-git in the patch. Finally, this solution uses LLVM to generate the AST of these source code files.

[0039] (2) Locate conditional statements in the AST:

[0040] The goal of this solution in this step is to locate all IF statements related to the patch, that is, the statements added, deleted or modified. This solution locates the ifstmt<line: if statements in the IFSTMT<line: n:n, line: n:n> field by using the search identifiers built into the AST file.

[0041] (3) Add control flow variants:

[0042] Instead of modifying both the previous version and the subsequent version simultaneously, one of these two versions can be modified and a patch variant can be generated. When modifying the subsequent version source code, it is equivalent to adding some other modifications to the subsequent version code. In this case, when considering the patch variant, it is equivalent to the original change between the original version and the new version. Therefore, only the original patch and other modifications need to be merged. Similarly, when only changing the previous version source code, it is equivalent to adding some other modifications to the original version before the version code. Therefore, the patch variant is equivalent to the merger of the inverse additional modification and the original patch.

[0043] This technology suffers from the shortcomings of most existing security patch datasets. Therefore, this invention proposes a method for constructing a large-scale, realistic, and comprehensive security patch dataset that fully covers the characteristics of security patches. This invention designs a method capable of automatically collecting real security patches with the same CVE number across different projects and branches, and designs three different patch synthesis techniques to satisfy the semantic equivalence characteristic during the natural evolution of security patches. Based on this method, a large-scale semantically equivalent security patch dataset can be formed. This invention mainly includes the following four stages, where the third and fourth stages are of equal relationship and only need to be executed after the second step. The details of the scheme involved in this invention are described below.

[0044] Example 1

[0045] refer to Figure 2 This invention provides a method for constructing a large-scale semantically equivalent security patch dataset, comprising:

[0046] Step 1: Obtain vulnerability disclosure entries (CVE) from a general database, recursively access potentially related hyperlinks based on the CVE information to obtain the original security patch, locate potential patches across all branches based on the original security patch, perform equivalent and valid judgment on the potential patches, and thus form a real security patch set.

[0047] This step enables the collection and resolution of different security patches for the same CVE across OSS projects and branches, enriching the data sources for the security patch dataset.

[0048] Step 2: Extract the patch content of each patch in the real security patch set, analyze the historical modification evolution timeline of the patch based on the patch content, and perform patch oversampling along the historical modification evolution timeline to obtain the evolved patch set;

[0049] This step can cover the contextual changes of porting security patches in a real development environment, enabling an exponential increase in the number of equivalent patches.

[0050] Step 3: For each patch in the real security patch set and the evolved patch set, compile and decompile the patch to generate equivalent security patches with different syntax but equivalent semantics, and eliminate invalid differences introduced by the compiler in the equivalent security patches, to obtain the first equivalent security patch set corresponding to the real security patch set and the second equivalent security patch set corresponding to the evolved patch set.

[0051] This step can cover security patch syntax and control flow changes across projects and branches, increasing the comprehensiveness of security patches.

[0052] Step 4: For each patch in the real security patch set and the evolved patch set, generate control flow equivalent and semantically equivalent security patches by building an abstract syntax tree, changing the equivalent control flow nodes of the abstract syntax tree, and mapping them to the source code of the patch; and form a third equivalent security patch set by combining the security patches corresponding to the real security patch set, and form a fourth equivalent security patch set by combining the security patches corresponding to the evolved patch set.

[0053] This step covers typical modification features of security patches, enhances the repair features of security patches, and provides stronger model generalization.

[0054] Step 5: Merge the real security patch set, the evolution patch set, the first equivalent security patch set, the second equivalent security patch set, the third equivalent security patch set, and the fourth equivalent security patch set to obtain a large-scale semantically equivalent security patch dataset.

[0055] Example 2

[0056] Before enriching the security patch dataset, this invention needs to collect a sufficient number of security patches. Specific steps include... Figure 3 As shown. The real security patch collection method used in this invention is well known to relevant practitioners. This invention only makes adaptive modifications to the selection of relevant auxiliary tools and patch screening methods. Step 1 of this invention is the real security patch collection stage, which specifically includes:

[0057] Step 11: Obtain common vulnerability entries from the general database to disclose CVE information;

[0058] Step 11 is (1) Collecting CVE information: Collecting Common Vulnerability Disclosure (CVE) entries from the National Vulnerability Database (NVD). The vulnerability information in this database is rigorously reviewed by authoritative personnel before being made public, thus possessing high credibility. In this invention, the collection of CVE information is primarily based on the open-source tool cve-search. Publicly available CVEs are imported into a local MongoDB database, and Python scripts are written for faster searching and processing of CVEs. The main purpose of using this open-source tool is to avoid direct and public searches of the public CVE database, which would lead to the NVD website's restriction on IP-sensitive queries.

[0059] Step 12: Obtain the URL field from the CVE information;

[0060] Step 12 is (2) Accessing the CVE source website: In the previous step, the import of CVE-related information has been completed, so CVE vulnerability information within a specific timeframe can be collected, including CPE (potential software version of the vulnerability), CWE (vulnerability category), CVSS (vulnerability severity), and available patch information (commit). Each CVE-related data contains detailed information disclosing the CVE, such as... Figure 3 As shown in ③, this includes a URL field, which details the source project website where the CVE was initially disclosed. To obtain more accurate data, you need to access this URL.

[0061] Step 13: Recursively access the URL of the source project website corresponding to the URL field, and obtain the patch content on Github and the list of affected OSS projects and related content through the hyperlinks that may appear in the URL;

[0062] Step 13 is (3) recursively accessing potentially related hyperlinks: The URLs accessed in the previous step usually provide hyperlinks where the CVE may appear. These hyperlinks often point to different OSS projects where the CVE exists, thus providing potential security patches in other OSS projects, requiring further recursive access. The original website of CVE-2017-11428 provides information on potentially related projects. In this step, there may be nested access situations, so the process terminates when the accessed URL contains .git information.

[0063] Step 14: Search the repository in the OSS project list using the patch content to obtain several original security patches;

[0064] Step 14 is the specific process of (4) accessing the relevant commit hyperlink. This hyperlink points to the specific patch content on GitHub. Access the hyperlink and save the patch content. Use the GitHub REST API to obtain relevant information and clone the OSS software affected by the vulnerability. By collecting real security patches, the relevant content of the OSS software corresponding to each security patch can be obtained based on the GitHub REST API, including OWNER (author) and REPO (OSS repository name). Therefore, the command git clone https: / / github.com / OWNER / REPO can be used to automatically clone the relevant vulnerable software repository and branch to the local machine.

[0065] Step 15: Locate potential patches using the original security patch, and determine the equivalence and validity of the potential patches to obtain potential equivalent patches that are validly equivalent to the original security patch;

[0066] This step (5) is the specific process of expanding potential patches. In a real development environment, developers usually tend to patch vulnerabilities secretly. Therefore, this invention defines a rule for expanding potential equivalent security patches by strictly matching known security patches. This rule will be introduced later.

[0067] Step 16: Combine the potential equivalent patches with the original security patches to form a real security patch set.

[0068] Example 3

[0069] Step 15 involves expanding the potential equivalent security patch rules through strict matching of known security patches. The specific expansion process includes:

[0070] Step 151: Use the subject information of the original security patch to locate potential patches in all branches of the OSS project. If a potential patch is similar to the subject of the original security patch, then the potential patch is identified as a potential equivalent patch to the original security patch.

[0071] Step 152: Compare the potential equivalent patch with each added line, deleted line, and related context information of the original security patch. If the average of the three differences is lower than the preset difference threshold, the potential equivalent patch is confirmed as an equivalent valid patch.

[0072] Step 153: Save the relevant information of the equivalent effective patch.

[0073] It is worth noting that the expansion rules include the following points:

[0074] 1. Use the subject information of known patches to locate potential patches in all branches of the project. If two patches have similar subjects, they can be identified as potentially equivalent security patches.

[0075] 2. Determine the validity of potential equivalent security patches: Compare each added line (+), deleted line (-) and related context information of the two patches. If the average difference is below a certain threshold, the patches are considered equivalent.

[0076] 3. Save the relevant information of the located equivalent patch, including the commit number, software name, and the version information of the software to which the patch is located.

[0077] Example 4

[0078] In real-world development environments, downstream software developers often introduce customized modifications when reusing upstream open-source components. Therefore, security patches for vulnerabilities disclosed upstream need to be adaptively modified before they can be applied downstream. This version difference between upstream and downstream systems resulting from the natural evolution of code has not been considered in existing publicly available datasets. Step 2 is an equivalent security patch generation stage based on natural evolution designed in this invention, referencing... Figure 4 Step 2 specifically includes:

[0079] Step 21: Extract the patch content of each patch in the real security patch set;

[0080] The patch includes modifying the file name (FileName), adding lines, and deleting lines.

[0081] Step 22: Analyze the historical modification evolution timeline of the patch content to obtain the natural evolution timeline of the patch;

[0082] In the natural evolution timeline, the changes corresponding to the original security patch are called the original commits, the previous changes before the original commits are called the past commits, and the changes after the original commits are called the update commits.

[0083] This step is the specific process of (1) extracting relevant content from the real patch. In the real patch collection collected in step 1, relevant information from the original patch can be extracted, including the modified file name FileName (lines starting with diff), the patch function name FuncName (lines starting with @@), added lines (lines starting with +), and deleted lines (lines starting with -).

[0084] As shown in the following patch file code:

[0085]

[0086] The code above represents a simple patch file. A patch is a difference between two versions of a file, not a complete program unit. Each patch corresponds to a unique commit, and patching means the code has been updated to a new version. It typically contains two parts: a patch header and patch blocks. The patch header consists of two lines starting with `---` or `+++` (corresponding to lines 1 and 2 in patch file code 6), indicating the files to be patched. `---` indicates the old file, and `+++` indicates the new file. A patch file may contain multiple sections starting with `---` or `+++`, each section applying one patch. Therefore, a single patch file can contain multiple patches.

[0087] A patch block is the part of the patch to be modified (corresponding to lines 3 to 10 of the patch file code). It typically begins and ends with a set of lines of code that don't need modification; these lines are only used to identify the location to be modified. It usually begins with @@ and ends at the beginning of another block or a new patch header. The number after '-' represents the line number of the block in the old file, indicating the total number of lines in the block before the modification; the number after '+' represents the line number of the block in the new file, indicating the total number of lines in the block after the modification. The block is indented by one column, which indicates whether the line was added or to be deleted.

[0088] The plus sign indicates that the line is a new line and will be added to the source file.

[0089] The minus sign (-) indicates that the line to be deleted will be removed from the source file. The absence of either a plus or minus sign indicates that the line is only being referenced and does not require modification.

[0090] In the equivalent security patch generation stage of the natural evolution of this invention, the historical modification timeline of the patch-modified file-level object can be traced, and the natural evolution version of the patch can be generated sequentially. The patch-modified file can be replaced with the repository-level object (i.e., OSS repository) that the patch affects, and the function-level object (i.e., the function that the patch affects) that the patch affects. The natural evolution version can also be replaced with synonyms.

[0091] Step 23: Generate evolution patches from the differences between each update commit and past commits;

[0092] This step (2) involves analyzing the specific process of the natural evolution timeline of the patch. Using the git version control system, combined with the OSS repository cloned to the local machine in the first stage, the command `git log --pretty=online FileName` can be used to view the historical modification evolution timeline of the patched file. Each modification will update the object being patched. In the timeline of this invention, as shown... Figure 5 As shown, the changes corresponding to the original security patch are called the original commit, the previous changes before the original commit are called the before commit, and the changes after the original commit are called the after commit.

[0093] Step 24: Oversample the evolution patch using the oversampling rule to obtain the sampled evolution patch set;

[0094] This step is the specific process of patch oversampling in (3) natural evolution. Since each version iterates from the Orig Commit contains the content of the original version, the difference between After Commit and Before Commit will also contain all the differences between Orig Commit and Before Commit. Based on this finding, this invention uses the historical modification evolution timeline obtained in step 3 and the git format-patch command of the git version control tool, such as... Figure 5 As shown, the differences between each After Commit and Before Commit are generated as Evolutionary Patches. In the generated set of Evolutionary Patches, not all modifications are natural evolutions of the original security patch modifications. Therefore, this invention designs a supersampling rule for security patch evolution versions. This invention can utilize this rule for supersampling, which will be described later.

[0095] Step 25: Assemble the sampled evolutionary patches into an evolutionary patch set;

[0096] The sampled evolution patch includes the patch's commit number, the name of the OSS project it belongs to, the version information of the patch, and the source code content corresponding to the patch.

[0097] This step details the process of generating the equivalent security patch dataset for natural evolution (4). Based on the sampling rules, each sampled evolutionary patch is saved, including the commit number, OSS project name, patch version information, and the corresponding source code content. The following original patch code demonstrates the relevant content of the original patch:

[0098]

[0099] The following evolution patch code demonstrates the relevant content of evolution patching:

[0100]

[0101] The code above reveals that only three modifications were made in the original patch, while the evolved patch adapts to the porting habits of software developers. It not only retains the relevant modifications of the original patch but also introduces six additional modifications, demonstrating that the generation method of this invention can effectively expand the patch data volume of the security patch dataset in a context that adapts to real development environments.

[0102] Example 5

[0103] The oversampling rules of this invention mainly include sampling the original security patch and the same function modifications as the evolved patch, sampling related modifications to the evolved patch function, and sampling the maximum modification of the evolved patch. Specifically, step 24 of this invention involves oversampling according to the oversampling rules, including:

[0104] Step 241: Remove other content from the evolution patch that does not involve the original security patch;

[0105] This step involves sampling the original security patch and the same function modifications as the evolution patch. Evolution patches often modify several functions, while the original security patch usually only involves a single function. Therefore, it is necessary to first delete other content in the evolution patch that does not involve the functions of the original security patch.

[0106] Step 242: Compare the code similarity of the added and deleted lines between the evolved patch and the original security patch, and discard the evolved patch whose overall average similarity is lower than the preset code threshold;

[0107] This step involves modifying the sampling evolution patch function. These modifications include adding lines (+), deleting lines (-), and related context information. To adapt to new code semantics, software developers will revise the content modified in the source security patch during its natural evolution. Therefore, a code similarity threshold for adding and deleting lines between two patches must be specified; evolution patches below this threshold must be discarded.

[0108] Step 243: Compare the function modification similarity between the evolved patch and the original security patch, and discard the evolved patch whose overall mean similarity is lower than the preset function threshold;

[0109] This step involves sampling the maximum modification of the evolution patch. Referring to the evolution patch code above, the original version will iterate through more versions over time, and the latest version may have modified the entire file code. In this case, the generated evolution patch and the original patch have deviated from the definition of semantic equivalence. Therefore, it is necessary to specify the threshold for function modifications of the evolution patch and the original security patch. Evolution patches that exceed this threshold must be discarded.

[0110] Step 244: Take all the evolution patches that have gone through steps 241-243 as the sampled evolution patches.

[0111] Based on the sampling rules, each sampled evolved patch is saved, including the commit number, OSS project name, patch version information, and the corresponding source code content. The original patch code shows the relevant content of the original patch, while the evolved patch code shows the relevant content of the evolved patch generated by this invention. This code reveals that only three modifications were made in the original patch, while the evolved patch adapts to the porting patching habits of software developers, not only retaining the relevant modifications of the original patch but also introducing six additional modifications. This demonstrates that this method can effectively expand the patch data volume of the security patch dataset in a real-world development environment.

[0112] Example 6

[0113] In reality, open-source projects rarely maintain multiple branches or fork projects. Although this invention has expanded the relevant dataset through the natural evolution of patches, this method, while ensuring semantic equivalence, only adapts to common modifications in real-world development environments such as format transformation, obfuscation, and context modification. Therefore, the expected performance of the trained model may become limited to recognizing only these format differences, which does not meet the expectation of generating a large-scale, comprehensive, and effective security patch dataset. Therefore, this invention proposes a semantically equivalent security patch generation method based on decompilation, the specific process of which is as follows: Figure 7 As shown, by transforming the target code from source code to binary and then decompiling it back to source code, this transformation introduces a certain degree of syntactic restructuring, resulting in security patches with different syntax but equivalent semantics. Step 3 is the equivalent security patch generation stage of compilation-decompilation, which mainly includes (1) compiling the source code of the two versions before and after the patch, (2) performing decompilation using the IDApro tool, (3) generating security patches with different syntax and equivalent semantics, and (4) eliminating invalid differences in the patch file, specifically including:

[0114] Step 31: For each patch in the real security patch set and the evolution patch set, compile the OSS project containing the commit and the previous version's commit under the same compilation configuration conditions to obtain two versions of binary files;

[0115] Step 31 is the specific process of compiling the source code of the two versions before and after the patch (1). First, for the security patch in step 1 and the evolution patch collected in step 2, clarify the commit corresponding to the patch and the commit of the previous version. For these two code states, under the premise of ensuring the same compilation configuration, compile the source code of these two versions respectively to obtain binary .o files.

[0116] Step 32: Decompile the two versions of the binary file to obtain two versions of decompiled files;

[0117] Step 32 is the specific process of performing decompilation using the IDA Pro tool (2). IDA Pro is a well-known disassembler in the relevant research field, which can be used to convert machine code into a human-readable format and generate pseudo-code in .c format. For the two patched versions of the .o files obtained from compilation, IDA Pro can be used to decompile the two patched versions of the .c files. Note that the .c files generated in this step have changed compared to the original .c files before compilation. This invention proposes to perform decompilation based on IDA Pro, where the IDA Pro tool can be replaced by any related decompilation tool / program; and the "compile-decompile" operation can also be replaced by any "convert source code to intermediate representation, and then convert intermediate representation back to source code" operation.

[0118] Step 33: Using the two versions of the decompiled files, generate an equivalent security patch with different syntax and semantic equivalentity from the patch before compilation;

[0119] Step 33 is the specific process of generating security patches with different syntax and equivalent semantics (3). For the two .c files before and after the patch is generated after compilation, the git version control tool is used to generate security patches with different syntax and equivalent semantics using the git format-patch command.

[0120] Step 34: Eliminate invalid differences introduced by the compiler within the equivalent security patch, and obtain the first equivalent security patch set corresponding to the real security patch set and the second equivalent security patch set corresponding to the evolution patch set.

[0121] Step 34 is the specific process for (4) eliminating invalid differences in the patch file. Under the premise of ensuring that the compilation uses exactly the same configuration, the decompiled patch should eliminate as many syntax differences as possible introduced by binary-level structural differences.

[0122] The original patch code is shown below:

[0123]

[0124] The equivalent patch code generated from the decompilation is shown below.

[0125]

[0126] The vast majority of differences between V3 and V4 in the equivalent patch code generated by decompilation are due to unrecognized local variable names randomly named by IDA in the format "vXXX". These are losses from compilation-time optimizations during source code execution, or temporary variables automatically generated at the assembly level to serve machine code translation. These variables often borrow temporary storage from registers. Since the differentiated code inevitably involves the addition or removal of such intermediate variables, it causes name misalignment and introduces a large number of irrelevant differences. Therefore, during the comparison, lines with only these differences should be ignored.

[0127] Other differences are not explicitly shown in the source code but are introduced by macro expansion or automatically generated code. For example, in the example, the `ERR_raise()` function is expanded into three functions: `ERR_new()`, `ERR_Set_BUG`, and `ERR_set_error()`, thus causing discrepancies. These are often specific uniform patterns in particular projects and can be ignored by custom pattern matching.

[0128] Example 7

[0129] For C / C++ projects, the built-in config script is typically executed first to adjust the compilation configuration according to the corresponding parameters and generate a Makefile, which guides the compilation process. To meet the compilation requirements of this invention, two compilation parameters CFLAG are usually added: "-g-O0". The former adds debugging information, and the latter disables all unnecessary compilation optimizations.

[0130] Step 31 of this invention, compiling the two versions of the patch, specifically includes:

[0131] Step 311: For any patch in the real security patch set, under the same compilation configuration conditions, by adding debugging symbols and reducing the compilation optimization level, perform a full compilation of the OSS project containing the patch's commit and the commit of the previous version to obtain the binary file of each patch;

[0132] It's worth noting that incremental compilation is used to reduce the time overhead of the compilation process. The second phase involves collecting evolution patches for the same original patch, which actually originate from different time points within the same OSS project. First, a full compilation is performed based on the previous commit status of the original patch. Then, while preserving the compiled object files, only the evolution patching operation is completed. This involves modifying the relevant files and then recompiling using `make`, thus compiling only the .o object files related to the differing code, achieving speedup.

[0133] Step 312: For each patch in the evolution patch set, under the same compilation configuration conditions, perform a full compilation on the OSS project where the previous version commit of the patch is located by adding debugging symbols and reducing the compilation optimization level, and determine the target file for the patch operation;

[0134] It's worth noting that, while maintaining the same compilation configuration, you need to add debug symbol information and set compilation optimization to the lowest level. Debug symbols ensure that non-exported functions in the binary representation also include function names for location purposes, and ideally, variable names within the functions. Disabling compilation optimization avoids inlining or machine code-level optimizations that could introduce unnecessary structural differences. This generally requires analyzing the specific project to determine how to configure it using parameter passing or through hacking techniques.

[0135] Step 313: Under the same compilation configuration conditions, recompile the target file of the patch operation by adding debugging symbols and reducing the compilation optimization level to obtain the binary file of the evolution patch.

[0136] Example 8

[0137] Related research has found that approximately 70% of security patches involve modifications to conditional statements. Therefore, this invention proposes a security patch generation technique based on AST (Abstract Syntax Tree) equivalent control flow. By introducing control flow complexity into security patches, the synthetic dataset can enrich patch representations, mitigate overfitting of the learning model, and improve the performance of automated patch analysis tasks. (References) Figure 6 Step 4 is the specific process of generating security patches based on AST equivalent control flow, mainly divided into (1) establishing two versions of the abstract syntax tree (AST) before and after the patch, (2) adding or changing the control flow relationship of the AST, (3) mapping the changed AST to the source code, and (4) generating equivalent patches for the control flow changes. Specifically, it includes:

[0138] Step 41: For each patch in the real security patch set and the evolution patch set, build an abstract syntax tree corresponding to the patch;

[0139] Step 41 is (1) the process of building the abstract syntax tree (AST) for both versions before and after the patch. The AST is a tree-like representation of the abstract syntax structure of the source code, where each node represents a structure in the source code. Since the patch is a difference between two version files and not a complete program unit, it lacks relevant parts, therefore, the AST cannot be directly generated from the patch. For the security patches collected in the first and second stages, the version corresponding to the patch and the previous version are identified, and the AST is built using the Joern tool only for the version after the patch.

[0140] This invention can generate an Abstract Syntax Tree (AST) based on joern and modify the control flow accordingly. The joern tool can be replaced by any tool that supports parsing an abstract syntax tree, and the AST can be replaced by a code property graph, a program control flow graph, or a program dependency graph.

[0141] Step 42: Add or modify equivalent control flow nodes in the abstract syntax tree that do not affect the original security patch to obtain the modified abstract syntax tree;

[0142] The rules for adding or changing equivalent control flow nodes that affect the original security patch include: adjusting the execution order of conditional statements, directly negating conditions, logically negating conditions, and adding conditions.

[0143] Step 42 involves (2) adding or modifying the control flow relationships in the abstract syntax tree. Based on the IF statements appearing in the added lines (+) in the patch, the control flow nodes related to the patch are retrieved and located in the patch version's AST file. Adding or modifying the equivalent control flow does not affect the original file. The main rules for adding or modifying are as follows:

[0144] 1. Adjust the execution order of conditional statements;

[0145] 2. Directly negating the condition: Generally, you simply add "!" to the conditional control flow;

[0146] 3. Conditional Logic Inversion: Here, the logical comparison symbols in conditional expressions are divided into three categories. Each category contains symbols representing logically relative relationships: "<" and "≥"; "≤" and ">"; "==" and "!=", as shown below. Figure 8 The diagram shown is an example of equivalent control flow modification by negating the condition;

[0147] 4. Adding Conditions: Generally, "&&" or "||" are used to add conditions. For example, "&&" is combined with a condition that must be true, and "||" is combined with a condition that must be false, etc. Such control conditions do not change the control flow of the original IF statement; they merely serve a semantically equivalent function.

[0148] Step 43: Map the modified abstract syntax tree to source code to obtain the later-committed version with the changed control flow; and generate a security patch that is equivalent in both control flow and semantics based on the later-committed version with the changed control flow.

[0149] Step 43 of the present invention includes:

[0150] Step 431: Use automatic traversal transformation technology to convert the modified abstract syntax tree into source code form, obtain the patch, and change the commit version of the control flow;

[0151] Step 432: Generate a control flow equivalent and semantically equivalent security patch based on the pre-patch version and the post-patch commit version that has changed the control flow.

[0152] Step 43 is (3) mapping the modified Abstract Syntax Tree (AST) to the source code. An automatic traversal conversion technique is used to convert the modified AST into source code form, i.e., the source code related to the control flow has been modified after the patch was obtained.

[0153] Step 44: Combine the security patches corresponding to the real security patch set into a third equivalent security patch set, and combine the security patches corresponding to the evolution patch set into a fourth equivalent security patch set.

[0154] Step 44 is the process of generating equivalent patches for control flow changes (4). For the version before the patch and the version after the patch that has changed the control flow, the git version control tool is used to generate control flow equivalent and semantically equivalent security patches using the git format-patch command. Of course, git can be replaced with any version control tool, and the corresponding git format-patch can also be replaced with the command of the corresponding tool.

[0155] This invention proposes a method for constructing a large-scale semantically equivalent security patch dataset. The method utilizes three key techniques: a real-world patch collection technique to collect and resolve different security patches for the same CVE across OSS projects and branches, enriching the data sources for the security patch dataset; a natural evolution-based equivalent patch generation technique to cover contextual changes in ported security patches in real-world development environments, resulting in an exponential increase in the number of equivalent patches; a compilation-decompilation-based semantically equivalent patch generation technique to cover syntax and control flow changes in security patches across projects and branches, increasing the comprehensiveness of security patches; and an AST-based control flow change-based equivalent patch generation technique to cover typical modification features of security patches, enhancing the repair features of security patches and providing stronger model generalization. The patch datasets generated by these three techniques address a series of problems in existing publicly available security patch datasets, such as insufficient data volume, limitations imposed by specific software libraries, limitations imposed by specific patch types, and weakened security features.

[0156] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0157] Although this application has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings, the disclosure, and the appended claims in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality.

[0158] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for constructing a large-scale semantically equivalent security patch dataset, characterized in that, include: Step 1: Obtain vulnerability disclosure entries (CVE) from a general database, recursively access potentially related hyperlinks based on the CVE information to obtain the original security patch, locate potential patches across all branches based on the original security patch, perform equivalent and valid judgment on the potential patches, and thus form a real security patch set. Step 2: Extract the patch content of each patch in the real security patch set, analyze the historical modification evolution timeline of the patch based on the patch content, and perform patch oversampling along the historical modification evolution timeline to obtain the evolved patch set; Step 3: For each patch in the real security patch set and the evolved patch set, compile and decompile the patch to generate equivalent security patches with different syntax but equivalent semantics, and eliminate invalid differences introduced by the compiler in the equivalent security patches, to obtain the first equivalent security patch set corresponding to the real security patch set and the second equivalent security patch set corresponding to the evolved patch set. Step 4: For each patch in the real security patch set and the evolved patch set, generate control flow equivalent and semantically equivalent security patches by building an abstract syntax tree, changing the equivalent control flow nodes of the abstract syntax tree, and mapping them to the source code of the patch; and form a third equivalent security patch set by combining the security patches corresponding to the real security patch set, and form a fourth equivalent security patch set by combining the security patches corresponding to the evolved patch set. Step 5: Merge the real security patch set, the evolution patch set, the first equivalent security patch set, the second equivalent security patch set, the third equivalent security patch set, and the fourth equivalent security patch set to obtain a large-scale semantically equivalent security patch dataset.

2. The method for constructing a large-scale semantically equivalent security patch dataset according to claim 1, characterized in that, Step 1 includes: Step 11: Obtain common vulnerability entries from the general database to disclose CVE information; Step 12: Obtain the URL field from the CVE information; Step 13: Recursively access the URL of the source project website corresponding to the URL field, and obtain the patch content on Github and the list of affected OSS projects and related content through the hyperlinks that may appear in the URL; Step 14: Search the repository in the OSS project list using the patch content to obtain several original security patches; Step 15: Locate potential patches using the original security patch, and determine the equivalence and validity of the potential patches to obtain potential equivalent patches that are validly equivalent to the original security patch; Step 16: Combine the potential equivalent patches with the original security patches to form a real security patch set.

3. The method for constructing a large-scale semantically equivalent security patch dataset according to claim 2, characterized in that, Step 15 includes: Step 151: Use the subject information of the original security patch to locate potential patches in all branches of the OSS project. If a potential patch is similar to the subject of the original security patch, then the potential patch is identified as a potential equivalent patch to the original security patch. Step 152: Compare the potential equivalent patch with each added line, deleted line, and related context information of the original security patch. If the average of the three differences is lower than the preset difference threshold, the potential equivalent patch is confirmed as an equivalent valid patch. Step 153: Save the relevant information of the equivalent effective patch.

4. The method for constructing a large-scale semantically equivalent security patch dataset according to claim 1, characterized in that, Step 2 includes: Step 21: Extract the patch content of each patch in the real security patch set; The patch includes modifying the file name (FileName), adding lines, and deleting lines. Step 22: Analyze the historical modification evolution timeline of the patch content to obtain the natural evolution timeline of the patch; In the natural evolution timeline, the changes corresponding to the original security patch are called the original commits, the previous changes before the original commits are called the past commits, and the changes after the original commits are called the update commits. Step 23: Generate evolution patches from the differences between each update commit and past commits; Step 24: Oversample the evolution patch using the oversampling rule to obtain the sampled evolution patch set; Step 25: Assemble the sampled evolutionary patches into an evolutionary patch set; The sampled evolution patch includes the patch's commit number, the name of the OSS project it belongs to, the version information of the patch, and the source code content corresponding to the patch.

5. The method for constructing a large-scale semantically equivalent security patch dataset according to claim 4, characterized in that, Step 24 includes: Step 241: Remove other content from the evolution patch that does not involve the original security patch; Step 242: Compare the code similarity of the added and deleted lines between the evolved patch and the original security patch, and discard the evolved patch whose overall average similarity is lower than the preset code threshold; Step 243: Compare the function modification similarity between the evolved patch and the original security patch, and discard the evolved patch whose overall mean similarity is lower than the preset function threshold; Step 244: Take all the evolution patches that have gone through steps 241-243 as the sampled evolution patches.

6. The method for constructing a large-scale semantically equivalent security patch dataset according to claim 1, characterized in that, Step 3 includes: Step 31: For each patch in the real security patch set and the evolution patch set, compile the OSS project containing the commit and the previous version's commit under the same compilation configuration conditions to obtain two versions of binary files; Step 32: Decompile the two versions of the binary file to obtain two versions of decompiled files; Step 33: Using the two versions of the decompiled files, generate an equivalent security patch with different syntax and semantic equivalentity from the patch before compilation; Step 34: Eliminate invalid differences introduced by the compiler within the equivalent security patch, and obtain the first equivalent security patch set corresponding to the real security patch set and the second equivalent security patch set corresponding to the evolution patch set.

7. The method for constructing a large-scale semantically equivalent security patch dataset according to claim 6, characterized in that, Step 31 includes: Step 311: For any patch in the real security patch set, under the same compilation configuration conditions, by adding debugging symbols and reducing the compilation optimization level, perform a full compilation of the OSS project containing the patch's commit and the commit of the previous version to obtain the binary file of each patch; Step 312: For each patch in the evolution patch set, under the same compilation configuration conditions, perform a full compilation on the OSS project where the previous version commit of the patch is located by adding debugging symbols and reducing the compilation optimization level, and determine the target file for the patch operation; Step 313: Under the same compilation configuration conditions, recompile the target file of the patch operation by adding debugging symbols and reducing the compilation optimization level to obtain the binary file of the evolution patch.

8. The method for constructing a large-scale semantically equivalent security patch dataset according to claim 1, characterized in that, Step 4 includes: Step 41: For each patch in the real security patch set and the evolution patch set, build an abstract syntax tree corresponding to the patch; Step 42: Add or modify equivalent control flow nodes in the abstract syntax tree that do not affect the original security patch to obtain the modified abstract syntax tree; Step 43: Map the modified abstract syntax tree to source code to obtain the later-committed version with the changed control flow; and generate a security patch that is equivalent in both control flow and semantics based on the later-committed version with the changed control flow. Step 44: Combine the security patches corresponding to the real security patch set into a third equivalent security patch set, and combine the security patches corresponding to the evolution patch set into a fourth equivalent security patch set.

9. A method for constructing a large-scale semantically equivalent security patch dataset according to claim 8, characterized in that, The rules for adding or changing equivalent control flow nodes that affect the original security patch in step 42 include: adjusting the execution order of conditional statements, directly negating conditions, logically negating conditions, and adding conditions.

10. A method for constructing a large-scale semantically equivalent security patch dataset according to claim 9, characterized in that, Step 43 includes: Step 431: Use automatic traversal transformation technology to convert the modified abstract syntax tree into source code form, obtain the patch, and change the commit version of the control flow; Step 432: Generate control flow equivalent and semantically equivalent security patches based on the pre-patch version and the post-patch commit version with changes to the control flow.

Images