Method for detecting multiple function homologous vulnerabilities based on function selection and semantic equivalent matching

Abstract

The present application belongs to the technical field of software engineering, and specifically relates to a multi-function homologous vulnerability detection method based on function selection and semantic equivalent matching. The method comprises two stages of signature generation and vulnerability detection. The signature generation stage comprises: inputting a vulnerability repair patch, extracting a modification method and a key repair method therein; performing semantic equivalent replacement on the extracted key repair method, and generating signatures for the functions before and after the semantic equivalent replacement respectively; the vulnerability detection stage comprises: inputting a target detection software, pre-processing by using a clone detection software to reduce the search space; extracting functions in the target detection software and performing semantic equivalent replacement thereon, generating signatures for the functions before and after the semantic equivalent replacement respectively, and performing two-stage signature matching, and finally outputting whether there is a suspicious multi-method homologous vulnerability in the target project. The method can help identify multi-method homologous vulnerabilities in open source software, reduce the harm caused by homologous vulnerabilities, and improve the security of open source software.

Description

Technical Field

[0001] The present invention belongs to the technical field of software engineering, and in particular relates to a method for detecting complex homologous vulnerabilities in multiple functions. Background Art

[0002] In recent years, the open source software (OSS) ecosystem has grown rapidly[1-2], with developers generally adopting third-party open source software components to accelerate development and reduce costs[3]. As the scope of vulnerabilities expands from traditional proprietary software to open source software, the increasing number of vulnerabilities in open source software has attracted widespread attention, especially in the context of supply chain attacks[4]. Attackers exploiting these vulnerabilities not only threaten the open source software itself, but also potentially affect its downstream users, greatly increasing the potential harm of the vulnerabilities[5].

[0003] It is worth noting that downstream software often shares or reuses the logic of upstream open source software components. As these components evolve and downstream software is customized, the code originally sourced from upstream will deviate on both ends, increasing the difficulty of fixing common vulnerabilities[6]. Especially in languages ​​that lack a unified package manager (such as C / C++), simply replacing and updating open source components to fix common vulnerabilities becomes infeasible or too cumbersome when faced with incompatible changes or customized components. In this case, developers usually need to manually find and backport security patches to downstream software, a process that is not only time-consuming but also resource-intensive. It is worth mentioning that 80% of attacks exploit vulnerabilities that were reported three years ago[7], which shows that the problem of common vulnerabilities is far from being effectively solved.

[0004] To detect common vulnerabilities, existing research typically employs cloning-based methods [8-11]. These methods extract vulnerability features at the method level and match them with target projects to achieve the same-source vulnerability detection goal. Other studies utilize deep learning techniques [12-16] to transform functions into vectors in an abstract space and then classify their vulnerability. However, these methods assume that all repair functions for the same vulnerability are equally important, ignoring the fact that for patches involving multiple functions, the semantic importance of different repair functions in resolving the vulnerability may vary significantly. This simplistic assumption can lead to over-representation of vulnerability features, increasing the risk of false positives. On the other hand, while software composition analysis (SCA) techniques [17-20] can detect common vulnerabilities involving multiple methods, they are primarily designed to identify reused open source software components and may overlook specific vulnerability or repair features, potentially leading to false positives. Summary of the Invention

[0005] The purpose of the present invention is to provide an accurate method for detecting complex multi-function homologous vulnerabilities, thereby effectively detecting homologous vulnerabilities and reducing the harm caused by homologous vulnerabilities.

[0006] The multi-function homology vulnerability detection method provided by the present invention is based on function selection and semantic equivalence matching technology, and includes two stages: signature generation and vulnerability detection.

[0007] The signature generation phase includes: extracting the modification methods in the vulnerability repair patch and selecting the key repair methods; performing semantic equivalent replacement on the extracted key repair methods, and then generating signatures for the functions before and after the semantic equivalent replacement;

[0008] The vulnerability detection phase includes: inputting the target detection software and preprocessing it with clone detection software to reduce the search space; extracting functions in the target detection software and performing semantic equivalent replacements on them, generating signatures for the functions before and after semantic equivalence, and performing two-stage signature matching to ultimately determine whether there are suspicious multi-method homologous vulnerabilities in the target project.

[0009] The specific steps are as follows:

[0010] 1. Signature generation phase, the specific steps are:

[0011] (1) Extracting modification methods from vulnerability repair patches and selecting key repair methods therein specifically includes collecting Common Vulnerabilities & Exposures (CVE) and corresponding repair patches, extracting repair functions from the repair source code, and selecting key methods therein. The specific process is as follows:

[0012] (1) Extract the modification methods in the CVE-related patch, parse the diff reports in the patch submission, and determine which functions have been modified. Modifications here include newly added, deleted, or modified lines of code;

[0013] (2) Based on the identified modification method, the static analysis tool Doxygen

[25] is used to construct a local call graph that is strongly related to the vulnerability. The call graph only includes the affected functions and their direct and indirect callers and callees within 3 hops.

[0014] (3) Based on the generated local call graph, the PageRank algorithm

[21] is used to calculate the importance score of each function and the threshold th is designed. pr , if the importance score of a function exceeds the threshold, the function is considered to be a key function;

[0015] (2) The extracted key repair methods are semantically replaced, specifically according to the C11 standard

[22] , and the key vulnerability repair methods are semantically replaced, including:

[0016] (1) Macro: A macro is a technique used to simplify and automate code by replacing it during compilation or preprocessing. Its semantics are equivalent to manually written code, so it can be rewritten. For example, a statement containing the macro MUL(a,b) can be rewritten as a*b;

[0017] (2) Indirect Expressions: Indirect expressions are expressions that indirectly access target data through pointers, references, etc., allowing the program to parse and operate on the actual expression through an intermediary object. Therefore, indirect access to an indirect expression is equivalent to the indirect expression itself and can be rewritten. For example, *&a and &*a can be rewritten as a.

[0018] (3) Logical negation: Logical negation uses the logical operator ! to negate a Boolean value. Since the Boolean values ​​false and 0 are equivalent, true and 1 are equivalent, and double negation and affirmation are equivalent, they can be rewritten. For example, !E can be rewritten as 0=E, and ! !E can be rewritten as E.

[0019] (4) Comparison expression: A comparison expression is an operation used to compare two values ​​or expressions and returns a Boolean value. The arithmetic operators and logical operators (AND or NOT) used in the expression can be integrated to perform a variety of equivalent operations. For example, a>=b can be rewritten as a>b||a==b;

[0020] (3) Generating signatures for the functions before and after semantic equivalence replacement, respectively, includes extracting vulnerability features and patch features from key methods before and after semantic equivalence to form vulnerability signatures and patch signatures; specifically, the following process is included:

[0021] (1) Generate a program dependency graph (PDG) based on the static analysis tool Joern

[23] . Use the deleted code lines and the newly added code lines as the starting point of program slicing, and extract the statement set that has data dependency and control dependency with the statement set;

[0022] (2) Code may differ in different projects due to variable renaming, parameter changes, or differences in code style. To reduce the impact of these differences, the static analysis tool Joern abstracts the code, abstracting function parameters, type declarations, local variables, function calls, and string literals into FPARAM, DTYPE, LVAR, FUNCCALL, and STRING, respectively, and removes non-code elements such as spaces, brackets, and comments in the code;

[0023] (3) Semantic Enhanced Signature Generation: The generated vulnerability signature and patch signature are both represented by (Syn, Sem, See) triples, and the contents of each component are as follows:

[0024] (I) Syn (vulnerability signature grammatical information), which is the set of statements obtained after slicing in process (1). The grammatical information of the patch signature is the newly added lines in the patch;

[0025] (II) Sem (semantic information in vulnerability signatures and patch signatures), both contain the semantic relationship between each statement in the grammatical signature statement set;

[0026] (III) See (Semantic Enhanced Signature Information), for each statement in the grammatical information, traverse its semantic relations, and if a statement appears in a dependency relationship, add the statement and its related context information to the semantic enhanced signature information (See).

[0027] 2. Vulnerability detection phase, the specific steps are:

[0028] (4) Input the project software to be tested, and perform clone detection based on code fragments using the high-recall clone detection tool SAGA

[24] to extract the target function that may contain the vulnerable code clone;

[0029] (5) After performing semantic equivalence on the candidate detection function set using the semantic equivalence method described in step (2), generating the target function signatures before and after semantic equivalence according to step (3);

[0030] (6) According to the matching rules, the function signature and vulnerability signature are matched with the patch signature to obtain the multi-method homologous vulnerability detection results. This process is divided into two stages, each of which matches the original signature of the target function and the semantically equivalent signature. The matching in each stage is based on syntactic and semantic similarity. The specific similarity is defined as follows:

[0031] Syntactic similarity: This measures the syntactic similarity between the target function and the vulnerable function. It is calculated by taking the ratio of the number of contextually equivalent statements in the target function to the vulnerability's grammatical signature (Syn) to the number of grammatical signatures in the vulnerability's set. Contextual equivalence is calculated by taking the ratio of the intersection of the semantically enhanced signature information (See) sets corresponding to the relevant statements to the number of semantically enhanced signature information (See) sets for the vulnerable statements.

[0032] Semantic Similarity: Semantic similarity is calculated by comparing the semantic dependencies between the target function and the vulnerable function to assess their similarity. These dependencies include data and control dependencies, represented by the semantic signature Sem. Semantic similarity not only focuses on the surface code structure but also deeply analyzes the internal logic and dependencies of the function, ensuring that even if the syntax is different, as long as the logic is similar, vulnerability clones can be detected.

[0033] To accurately evaluate the semantic similarity between the target function and the vulnerability function, we first need to determine which parts of the target function are most semantically similar to the vulnerability function. This is achieved by selecting sentence pairs with the greatest semantic similarity, ensuring that each sentence is matched to the most appropriate semantic dependency.

[0034] According to the above similarity calculation method, the matching rules of the present invention are as follows:

[0035] (1) If the target function does not contain the deleted lines in the vulnerability repair patch, then the target function is reported to have no vulnerability. Otherwise, the first stage is carried out, that is, the target function before semantic equivalence is matched with the vulnerability function before semantic equivalence.

[0036] (2) If the target function before semantic equivalence is syntactically and semantically similar to the vulnerability function before semantic equivalence, and is not similar to the patch function before semantic equivalence, then the target function is reported to have a vulnerability;

[0037] (3) If the target function before semantic equivalence is similar to the vulnerability function and patch function before semantic equivalence in both syntax and semantics, then it is reported that there is no vulnerability in the target function;

[0038] (4) If the objective function before semantic equivalence is not similar to the vulnerability function and patch function before semantic equivalence in both syntax and semantics, then proceed to stage 2 to compare the objective function after semantic equivalence with the vulnerability function and patch function;

[0039] (5) If the semantically equivalent target function is syntactically and semantically similar to the semantically equivalent vulnerability function and is not similar to the semantically equivalent patch function, then the target function is reported to have a vulnerability; otherwise, the target function is reported to have no vulnerability.

[0040] The basic process diagram of the present invention is as follows Figure 1 As shown. The method of the present invention significantly improves the accuracy and coverage of vulnerability detection through its unique key function selection, semantically equivalent statement matching, program slicing, grammatical and semantic signature generation and other technologies. It can handle code cloning problems under different coding styles, reduce missed and false positives, and has cross-project and cross-version detection capabilities. The method of the present invention can help identify multi-method homologous vulnerabilities in open source software, reduce the harm caused by homologous vulnerabilities, and improve the security of open source software. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a flowchart of the multi-function homology vulnerability detection method based on function selection and semantic equivalence matching of the present invention.

[0042] Figure 2 This is a schematic diagram of the CVE-2021-32134 case. DETAILED DESCRIPTION

[0043] The following describes the specific implementation of the present invention for multi-method homology vulnerability identification. The present invention uses the patch for CVE-2021-32134 in gpac as an example. Figure 2 As shown. The modified method is split and the relevant modified lines are underlined. From the figure, it can be seen that the key method is modified to Media_GetESD. Although there are statements deleted in mp4s_box_new and encs_box_new (such as Figure 2 (a)), but these deleted statements do not change the overall semantics, because these deleted statements are reintroduced into the gf_isom_sample_entry_init function (as shown in Figure 2 (b)). The main process of the present invention is:

[0044] (1) For this case, the modified methods in the patch are Media_GetESD, mp4s_box_new, encs_box_new, and gf_isom_sample_entry_init. A local call graph is constructed based on these four methods, and the importance scores of the four methods are calculated. According to the threshold, the key function is Media_GetESD.

[0045] (2) For the extracted key functions, semantic equivalent replacement is performed according to the C11 standard to obtain the semantically enhanced key functions.

[0046] (3) For functions before and after semantic equivalent replacement, the present invention first uses Joern to generate a PDG for Media_GetESD. Next, forward and backward slicing is performed on the modified statements in this method. Specifically, forward slicing is used to find subsequent statements that depend on these modified statements, while backward slicing is used to find previous statements that affect these modified statements. Finally, the resulting statement set is abstracted and normalized to generate vulnerability signatures and patch signatures before and after semantic equivalent replacement.

[0047] (IV) For the input target project, the present invention uses SAGA to perform fragment-level clone detection, and finally obtains a set of candidate functions that may have potential homology vulnerabilities.

[0048] (5) Similar to the steps of generating vulnerability signatures and patch signatures, each function in the candidate function set is first replaced with semantic equivalents to obtain the semantically enhanced function to be detected. Then, Joern is used to generate PDG for each function in the candidate function set. Then, each line of code in the method is used as a benchmark for forward and backward slicing, and the sliced ​​code is abstracted and normalized to finally obtain the function signatures before and after semantic equivalent replacement.

[0049] (6) Perform two-stage matching on the target function signature before and after semantic equivalence replacement with the vulnerability signature and patch signature before and after semantic equivalence replacement, and finally obtain the corresponding detection results to determine whether the CVE-2021-32134 vulnerability exists in the input target software project.

[0050] Method instance testing

[0051] We selected the top 1,000 most popular projects from GitHub, sorted by the number of stars, and used existing static analysis-based homology vulnerability detection tools for detection. The union of the detection results of each tool was used as our experimental dataset, which included 329 positive samples and 318 negative samples. The experiment used precision, recall, and F1 value as evaluation indicators, and specifically compared four existing static analysis-based homology vulnerability detection tools: Vuddy, MVP, Movery, and V1scan. The final effectiveness experimental results showed that the present invention improved the F1 value of Movery, the most advanced homology vulnerability detection tool, by 30.30%. In addition, after manually checking the recognition results of the present invention, relevant reports were written and submitted to the developers. A total of 54 reports were submitted, of which 28 reports were confirmed and fixed by the developers, 14 reports were confirmed by the developers and are waiting for repair, and 5 reports have applied for relevant CVE numbers and CNNVD numbers.

[0052] References

[0053] [1].Checkmarx.2023.9th Annual State of Software the Supply Chain..

[0054] [2].GitHub.2023.The 2023State of the OCTOVERSE.Retrieved April 20,2024from https: / / octoverse.github.com / .

[0055] [3].Rainer Koschke and Saman Bazrafshan.2016.Software-clone rates inopensour ce programs written in C or C++.In 2016IEEE 23rd InternationalConference o n Software Analysis,Evolution,and Reengineering(SANER),Vol.3.1–7.

[0056] [4].crowdstrike.2024.Supply Chain Attacks.Retrieved April 20,2024fromhttp s: / / www.crowdstrike.com / cybersecurity-101 / cyberattacks / supply-chain-attacks / .[5].arcticwolf.2024.Beyond Sisense Navigating Rising Tide of SupplyChain Att acks.Retrieved April 20,2024from https: / / arcticwolf.com / resources / blog / bey ondsisense-navigating-rising-tide-of-supply-chain-attacks / .

[0057] [6].Nam H Pham,Tung Thanh Nguyen,Hoan Anh Nguyen,and Tien NNguyen.2010.De tection of recurring software vulnerabilities.In Proceedingsof the 25th IEE E / ACM International Conference on Automated SoftwareEngineering.447–456.

[0058] [7].businessinsights.2024.10Stats on the State of Vulnerabilities andExploi ts.Retrieved April 20,2024from https: / / www.bitdefender.com / blog / businessin sights / 10-stats-on-the-state-of-vulnerabilities-and-exploits / .

[0059] [8].Seulbae Kim,Seunghoon Woo,Heejo Lee,and Hakjoo Oh.2017.Vuddy:Ascalab le approach for vulnerable code clone discovery.In 2017IEEE Symposiumon Se curity and Privacy.595–614.

[0060] [9].Yang Xiao,Bihuan Chen,Chendong Yu,Zhengzi Xu,Zimu Yuan,Feng Li,Bingho ng Liu,Yang Liu,Wei Huo,Wei Zou,et al.2020.{MVP}:Detecting Vulnerabilities using{Patch-Enhanced}Vulnerability Signatures.In 29th USENIX SecuritySymposium.1165–1182.

[0061]

[10] .Seunghoon Woo,Hyunji Hong,Eunjin Choi,and Heejo Lee.2022.{MOVERY}:A Precise Approach for Modified Vulnerable Code Clone Discovery fromModified

[0062] {Open-Source}Software Components.In 31st USENIX SecuritySymposium.3037–3053.

[0063]

[11] .Seunghoon Woo,Eunjin Choi,Heejo Lee,and Hakjoo Oh.2023.{V1SCAN}:Disc overing 1-day Vulnerabilities in Reused{C / C++}Open-source SoftwareComponen ts Using Code Classification Techniques.In 32nd USENIX SecuritySymposium.6541–6556.

[0064]

[12] .Kenneth Ward Church.2017.Word2Vec.Natural Language Engineering23,1(2017),155–162.

[0065]

[13] .Lei Cui,Zhiyu Hao,Yang Jiao,Haiqiang Fei,and XiaochunYun.2020.Vulde tector:Detecting vulnerabilities using weighted feature graphcomparison.IE EE Transactions on Information Forensics and Security 16(2020),2004–2017.

[0066]

[14] .Rebecca Russell,Louis Kim,Lei Hamilton,Tomo Lazovich,JacobHarer,Onur Ozdemir,Paul Ellingwood,and Marc McConley.2018.Automatedvulnerability d etection in source code using deep representation learning.InProceedings of the 17th IEEE international conference on machine learning andapplications.

[0067] IEEE,757–762.

[0068]

[15] .Shu Wang,Xinda Wang,Kun Sun,Sushil Jajodia,Haining Wang,and QiLi.20

[0069] 23.GraphSPD:Graph-based security patch detection with enriched codesemanti cs.In 2023 IEEE Symposium on Security and Privacy.2409–2426.

[0070]

[16] .Yaqin Zhou,Shangqing Liu,Jingkai Siow,Xiaoning Du,and YangLiu.2019.

[0071] Devign:Effective vulnerability identification by learningcomprehensive prog ram semantics via graph neural networks.Advances in neuralinformation proce ssing systems 32(2019).

[0072]

[17] .Ling Jiang,Hengchen Yuan,Qiyi Tang,Sen Nie,Shi Wu,and YuqunZhang.20

[0073] 23.Third-Party Library Dependency for Large-Scale SCA in the C / C++Ecosystem:

[0074] How Far Are We?.In Proceedings of the 32nd ACM SIGSOFT InternationalSympos ium on Software Testing and Analysis.1383–1395.

[0075]

[18] .Can Yang,Zhengzi Xu,Hongxu Chen,Yang Liu,Xiaorui Gong,and BaoxuLiu.

[0076] 2022.ModX:binary level partially imported third-party librarydetection via program modularization and semantic matching.In Proceedings ofthe 44th Int ernational Conference on Software Engineering.1393–1405.

[0077]

[19] .Seunghoon Woo,Sunghan Park,Seulbae Kim,Heejo Lee,and HakjooOh.2021.

[0078] CENTRIS:A precise and scalable approach for identifying modifiedopen-source software reuse.In 2021 IEEE / ACM 43rd International Conference onSoftware E ngineering.860–872.

[0079]

[20] .Jiahui Wu,Zhengzi Xu,Wei Tang,Lyuye Zhang,Yueming Wu,ChengyueLiu,Ka iran Sun,Lida Zhao,and Yang Liu.2023.Ossfp:Precise and scalable c / c++th ird-party library detection using fingerprinting functions.In 2023 IEEE / ACM

[0080] 45th International Conference on Software Engineering.270–282.

[0081]

[21] .Wikipedia.2024.PageRank.Retrieved April 20,2024 from https: / / en.wikipe dia.org / wiki / PageRank.

[0082]

[22] .Openstd.2024.Open Std.Retrieved April 20,2024 from https: / / www.openstd.

[0083] org / jtc1 / sc22 / wg14 / www / docs / n1548.pdf.

[0084]

[23] .Joern.2019.Joern-The Bug Hunter’s Workbench.Retrieved May 20,2024 fr om https: / / joern.io / .

[0085]

[24] .Guanhua Li,Yijian Wu,Chanchal K Roy,Jun Sun,Xin Peng,NanjieZhan,Bin Hu,and Jingyi Ma.2020.SAGA:efficient and large-scale detection ofnear-m iss clones with GPU acceleration.In 2020 IEEE 27th InternationalConference

[0086] on Software Analysis,Evolution and Reengineering(SANER).272–283.

[0087]

[25] .doxygen.2024.Doxygen.Retrieved April 20,2024 from https: / / www.doxygen.

[0088] nl / 。

Claims

1. A multi-function homology vulnerability detection method based on function selection and semantic equivalence matching, characterized by: It includes two stages: signature generation and vulnerability detection; among them: The signature generation phase includes: extracting the modification methods in the vulnerability repair patch and selecting the key repair methods; performing semantic equivalent replacement on the extracted key repair methods, and then generating signatures for the functions before and after the semantic equivalent replacement; The vulnerability detection phase includes: inputting the target detection software and preprocessing it with clone detection software to reduce the search space; extracting functions in the target detection software and performing semantic equivalent replacements on them, generating signatures for the functions before and after semantic equivalence, and performing two-stage signature matching to ultimately determine whether there are suspicious multi-method homologous vulnerabilities in the target project.

2. The multi-function homology vulnerability detection method according to claim 1 is characterized in that: The specific steps of the signature generation phase are: (1) Extract the modification methods in the vulnerability repair patch and select the key repair methods. Specifically, this includes collecting CVEs and corresponding repair patches, extracting the repair functions in the repair source code, and selecting the key methods. The specific process is as follows: (1) Extract the modification methods in the CVE corresponding fix patch, parse the difference report in the fix submission, and determine which functions have been modified. The modification here includes the addition, deletion, or modification of code lines; (2) Based on the identified modification method, a local call graph that is strongly related to the vulnerability is constructed. The call graph only includes the affected function and its direct and indirect callers and callees within 3 hops. (3) Based on the generated local call graph, the PageRank algorithm is used to calculate the importance score of each function, and a threshold is designed. If the importance score of a function exceeds the threshold, the function is considered to be a key function; (2) Perform semantic equivalent replacement on the extracted key repair methods. Specifically, according to the C11 standard, perform semantic equivalent replacement on the key vulnerability repair methods, including: (1) Macros are a technique for simplifying and automating code by replacing it during compilation or preprocessing. Their semantics are equivalent to manually written code and can be rewritten. (2) Indirect expressions are expressions that indirectly access target data through pointers or references, allowing the program to parse and operate the actual expression through an intermediary object; indirect access to an indirect expression is equivalent to the indirect expression itself and can be rewritten; (3) Logical negation expression, which uses the logical operator ! to negate the Boolean value. Since the Boolean value false is equivalent to 0, true is equivalent to 1, and double negation is equivalent to affirmation, it is rewritten; (4) Comparison expressions are operations used to compare two values ​​or expressions and return a Boolean value. The arithmetic operators and logical operators used in the expression can be integrated with each other to perform a variety of equivalent operations. (3) Generate signatures for the functions before and after semantic equivalence replacement, including extracting vulnerability features and patch features from key methods before and after semantic equivalence to form vulnerability signatures and patch signatures; the specific process is as follows: (1) Generate a program dependency graph (PDG) based on the static analysis tool Joern. Use the deleted code lines and the newly added code lines as the starting point of program slicing to extract the statement set that has data and control dependencies with the statement set. (2) Code may differ in different projects due to variable renaming, parameter changes, or differences in code style. To reduce the impact of these differences, the static analysis tool Joern abstracts the code. Specifically, it abstracts function parameters, type declarations, local variables, function calls, and string literals into FPARAM, DTYPE, LVAR, FUNCCALL, and STRING, respectively, and removes spaces, brackets, and comments in the code. (3) Semantic Enhanced Signature Generation: The generated vulnerability signature and patch signature are both represented by the Syn, Sem, See triples. The contents of each component are as follows: (I) Syn refers to the grammatical information of the vulnerability signature, which is the set of statements obtained after slicing in process (1). The grammatical information of the patch signature is the newly added lines in the patch; (II)Sem refers to the semantic information in vulnerability signatures and patch signatures, both of which contain the semantic relationship between each statement in the grammatical signature statement set; (III) See refers to the semantic enhancement signature information. For each sentence in the grammatical information, its semantic relationship is traversed. If the sentence appears in the dependency relationship, the sentence and its related context information are added to the semantic enhancement signature information See.

3. The multi-function homology vulnerability detection method according to claim 2 is characterized in that: The specific steps of the vulnerability detection phase are: (4) Input the project software to be tested and perform clone detection based on code snippets using the high-recall clone detection tool SAGA to extract target functions that may contain vulnerable code clones; (5) Perform semantic equivalence on the candidate detection function set using the semantic equivalence method described in step (2), and then generate the target function signatures before and after semantic equivalence according to step (3); (6) According to the matching rules, the function signature and vulnerability signature are matched with the patch signature to obtain the multi-method homologous vulnerability detection results; this process is divided into two stages, each stage matching the original signature of the target function and the semantically equivalent signature; specifically, the matching in each stage is based on syntactic and semantic similarity; The specific matching rules are as follows: (1) If the target function does not contain the deleted lines in the vulnerability repair patch, then the target function is reported to have no vulnerability. Otherwise, the first stage is carried out, that is, the target function before semantic equivalence is matched with the vulnerability function before semantic equivalence. (2) If the target function before semantic equivalence is syntactically and semantically similar to the vulnerability function before semantic equivalence, and is not similar to the patch function before semantic equivalence, then the target function is reported to have a vulnerability; (3) If the target function before semantic equivalence is similar to the vulnerability function and patch function before semantic equivalence in both syntax and semantics, then it is reported that there is no vulnerability in the target function; (4) If the objective function before semantic equivalence is not similar to the vulnerability function and patch function before semantic equivalence in terms of syntax and semantics, then proceed to stage 2 to compare the objective function after semantic equivalence with the vulnerability function and patch function; (5) If the semantically equivalent target function is syntactically and semantically similar to the semantically equivalent vulnerability function and is not similar to the semantically equivalent patch function, then the target function is reported to have a vulnerability. Otherwise, the target function is reported to have no vulnerability.

4. The multi-function homology vulnerability detection method according to claim 3 is characterized in that: The definitions of syntactic and semantic similarity are as follows: Syntactic equivalence: This is used to measure the syntactic similarity between the target function and the vulnerability function. Specifically, it is the ratio of the number of statements in the target function that are contextually equivalent to the vulnerability signature grammatical information Syn to the number of statements in the vulnerability grammatical signature set. Contextual equivalence refers to the ratio of the number of statements in the intersection of the semantically enhanced signature information See set corresponding to the relevant statements and the semantically enhanced signature information See set of the vulnerability statement to the number of statements in the semantically enhanced signature information See set of the vulnerability statement. Semantic similarity: This is done by comparing the semantic dependencies between the target function and the vulnerability function to evaluate their similarity. These dependencies include data dependency and control dependency, which are represented by the semantic information Sem in the vulnerability signature and the patch signature. In order to accurately evaluate the semantic similarity between the target function and the vulnerability function, we first need to determine which parts of the target function are most semantically similar to the vulnerability function; this is achieved by selecting the sentence pairs with the greatest semantic similarity, ensuring that each sentence is matched to the most appropriate semantic dependency.

Images