Multi-function homologous vulnerability detection method based on function selection and semantic equivalence matching

Abstract

The invention belongs to the technical field of software engineering, and particularly relates to a multi-function homologous vulnerability detection method based on function selection and semantic equivalence matching. The method comprises a signature generation stage and a vulnerability detection stage. The signature generation stage comprises the following steps: inputting a vulnerability repair patch, and extracting a modification method and a key repair method therein; after semantic equivalence replacement is carried out on the extracted key repair method, signatures are generated for functions before and after semantic equivalence replacement; the vulnerability detection stage comprises the following steps: inputting target detection software, and preprocessing by using clone detection software to reduce a search space; according to the method, functions in target detection software are extracted, semantic equivalence replacement is carried out on the functions, signatures are generated for the functions before and after semantic equivalence, two-stage signature matching is carried out, and finally whether suspicious multi-method homologous vulnerabilities exist in a target project or not is output. According to the method, the multi-method homologous vulnerabilities in the open source software can be identified, the harm caused by the homologous vulnerabilities is reduced, and the safety of the open source software is improved.

Description

Technical Field

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

[0002] In recent years, the open source software (OSS) ecosystem has developed rapidly[1-2], and developers generally adopt third-party open source software components to accelerate the development process 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 terms of supply chain attacks[4]. Attackers can exploit these vulnerabilities to threaten not only the open source software itself, but also 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 the downstream software is customized, the code originally sourced from the upstream will deviate on both ends, increasing the difficulty of fixing homologous vulnerabilities[6]. Especially in languages ​​that lack a unified package manager (such as C / C++), simply replacing and updating open source components to fix homologous 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 homologous vulnerability problem is far from being effectively solved.

[0004] In order to detect homologous vulnerabilities, existing studies usually adopt cloning-based methods [8-11]. Such methods achieve the purpose of homologous vulnerability detection by extracting vulnerability features from the method level and matching them with the target project. Other studies use deep learning technology [12-16] to transform functions into vectors in an abstract space and then classify their vulnerabilities. However, these methods all assume that all repair functions in the same vulnerability are of equal importance, ignoring that for repair patches involving multiple functions, the semantic importance of different repair functions in resolving vulnerabilities may vary significantly. This simplification of assumptions may lead to over-representation of vulnerability features and increase the risk of false positives. On the other hand, although software component analysis (SCA) technology [17-20] can detect homologous vulnerabilities involving multiple methods, they are mainly used to identify reused open source software components and may ignore specific vulnerabilities or repair features, which may also lead to false positives. Summary of the invention

[0005] The purpose of the present invention is to provide an accurate detection method for 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; wherein:

[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 using the clone detection software to reduce the search space; extracting the functions in the target detection software and performing semantic equivalent replacement on them, generating signatures for the functions before and after semantic equivalence, and performing two-stage signature matching to finally determine whether there are suspicious multi-method homologous vulnerabilities in the target project.

[0009] The specific steps are as follows:

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

[0011] (I) 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 repair source codes, and selecting key methods therein. The specific process is as follows:

[0012] (1) Extract the modification method in the CVE corresponding fix patch, parse the difference report (diffs) in the fix submission, and determine which functions have been modified. The modification here includes the addition, deletion, or modification of code lines;

[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 function and its 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] (ii) performing semantic equivalent replacement of the extracted key repair methods, specifically performing semantic equivalent replacement of the key vulnerability repair methods according to the C11 standard

[22] , including:

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

[0017] (2) Indirect expression: An indirect expression is an expression that indirectly accesses the target data through pointers, references, etc., so that the program parses and operates the actual expression through an intermediary object. Therefore, the indirect access to the indirect expression is equivalent to itself, so it can be rewritten. For example, *&a and &*a can be rewritten as a.

[0018] (3) Logical negation expression: Logical negation expression 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 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] (III) generating signatures for the functions before and after the semantic equivalent replacement, respectively, including extracting vulnerability features and patch features from key methods before and after the semantic equivalent replacement to form vulnerability signatures and patch signatures; specifically including the following process:

[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 to 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, STRING, 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 sentence in the grammatical information, traverse its semantic relationship, and if the sentence appears in the dependency relationship, add the sentence and its related context information to the semantic enhanced signature information (See).

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

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

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

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

[0030] (VI) 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 the similarity of syntax and semantics. The specific similarity is defined as follows:

[0031] Syntactic similarity: used to measure the grammatical similarity between the target function and the vulnerability function. The main calculation method is to calculate the ratio of the number of statements in the target function that are contextually equivalent to the vulnerability syntax signature (Syn) to the number of vulnerability syntax signature sets. The calculation method for contextual equivalence is to calculate the ratio of the intersection of the semantic enhancement signature information (See) sets corresponding to the relevant statements to the number of semantic enhancement signature information (See) sets of the vulnerability statements.

[0032] Semantic similarity: The calculation of semantic similarity is mainly to evaluate the similarity between the target function and the vulnerable function by comparing the semantic dependencies between them. These dependencies include data dependencies and control dependencies, which are represented by the semantic signature Sem. Semantic similarity not only focuses on the surface code structure, but also deeply analyzes the logic and dependencies within the function to ensure that even if the syntax is different, as long as the logic is similar, the vulnerability clone can be detected.

[0033] 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.

[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 line in the vulnerability repair patch, then report that the target function has no vulnerability. Otherwise, proceed to phase 1, that is, match the target function before semantic equivalence 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 report that the target function has 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 report 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 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;

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

[0040] The basic process schematic 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, semantic equivalent statement matching, program slicing, syntax and semantic signature generation and other technologies. It can handle code cloning problems under different coding styles, reduce missed reports 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 The present invention is a flowchart of a multi-function homologous vulnerability detection method based on function selection and semantic equivalence matching.

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

[0043] The following describes a 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 in the figure, 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] (I) For this case, the modified methods in the patch are Media_GetESD, mp4s_box_new, encs_box_new, and gf_isom_sample_entry_init. The local call graph is constructed based on these four methods, the importance scores of the four methods are calculated, and the key function is Media_GetESD according to the threshold.

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

[0046] (III) For the functions before and after semantic equivalent replacement, the present invention first generates PDG for Media_GetESD using Joern, and then performs forward and backward slicing on the modification statements in the method. Specifically, forward slicing is used to find subsequent statements that depend on these modification statements, and backward slicing is used to find previous statements that affect these modification statements. Finally, the obtained 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] (V) Similar to the steps of generating vulnerability signatures and patch signatures, first perform semantic equivalent replacement on each function in the candidate function set to obtain the semantically enhanced function to be detected, then use Joern to generate PDG for each function in the candidate function set, then use each line of code in the method as a benchmark for forward and backward slicing, and abstract and normalize the sliced ​​code to finally obtain the function signatures before and after semantic equivalent replacement.

[0049] (VI) Perform two-stage matching on the target function signature before and after semantic equivalent replacement with the vulnerability signature and patch signature before and after semantic equivalent 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 1000 most popular projects in GitHub sorted by the number of stars, and used the existing homologous vulnerability detection tools based on static analysis for detection. The union of the detection results of each tool was used as our experimental data set, 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 homologous vulnerability detection tools based on static analysis, namely Vuddy, MVP, Movery and V1scan. The final effectiveness experimental result was that the F1 value of the present invention was 30.30% higher than that of the most advanced homologous vulnerability detection tool Movery. 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 waiting for repair, and 5 reports had 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.6

[0064] 541–6556.

[0065]

[12] .Kenneth Ward Church.2017.Word2Vec.Natural Language Engineering23,1(2

[0066] 017),155–162.

[0067]

[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.

[0068]

[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.

[0069] IEEE,757–762.

[0070]

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

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

[0072]

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

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

[0074]

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

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

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

[0077]

[18] .Can Yang,Zhengzi Xu,Hongxu Chen,Yang Liu,Xiaorui Gong,and BaoxuLiu.2022.ModX:binary level partially imported third-party library detectionvia program modularization and semantic matching.In Proceedings of the 44thInt ernational Conference on Software Engineering.1393–1405.

[0078]

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

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

[0080]

[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

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

[0082]

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

[0083]

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

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

[0085]

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

[0086]

[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

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

[0088]

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

[0089] nl / 。

Claims

1. A multi-function homology vulnerability detection method based on function selection and semantic equivalence matching, characterized in that: 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 using clone detection software to reduce the search space; extracting the functions in the target detection software and performing semantic equivalent replacement on them, generating signatures for the functions before and after semantic equivalence, and performing two-stage signature matching to finally 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: (I) Extract the modification methods in the vulnerability repair patch and select the key repair methods therein, which specifically includes collecting CVE and the corresponding repair patch, extracting the repair function in the repair source code, and selecting the key methods therein. The specific process is as follows: (1) Extract the modification method 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 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 jumps. (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; (II) 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 code at the compilation or preprocessing stage. Their semantics are equivalent to manually written code and can be rewritten. (2) Indirect expressions are expressions that indirectly access target data through pointers and 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, through the logical operator !, the Boolean value is inverted, and the Boolean value false is equivalent to 0, true is equivalent to 1, and double negation is equivalent to affirmation, so it is rewritten; (4) 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, and NOT used in this expression can be integrated to perform a variety of equivalent operations; (III) Generate signatures for the functions before and after semantic equivalent 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, and extract the statement set that has data dependency and control dependency on the statement set; (2) Codes 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 (Syn, Sem, See) triples, and 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: (iv) Input the project software to be tested, perform clone detection based on code snippets using the high-recall clone detection tool SAGA, and extract the target function that may contain the clone of the vulnerability code; (5) performing semantic equivalence on the candidate detection function set using the semantic equivalence method described in step (2), and then generating the target function signatures before and after semantic equivalence according to step (3); (VI) According to the matching rules, the function signature and the vulnerability signature are matched with the patch signature to obtain the multi-method homologous vulnerability detection results; the process is divided into two stages, each stage matches the original signature of the target function and the semantically equivalent signature respectively; specifically, the matching in each stage is based on the similarity of syntax and semantics; The specific matching rules are as follows: (1) If the target function does not contain the deleted line in the vulnerability repair patch, then report that the target function has no vulnerability. Otherwise, proceed to phase 1, that is, match the target function before semantic equivalence 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 report that the target function has 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 report 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 target function after semantic equivalence is syntactically and semantically similar to the vulnerability function after semantic equivalence, and is not similar to the patch function after semantic equivalence, 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 the syntactic and semantic similarities are as follows: Syntactic equivalence: It is used to measure the grammatical 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 syntax signature (Syn) to the number of vulnerability syntax signature sets. Among them, contextual equivalence is calculated by calculating the ratio of the intersection of the semantic enhancement signature information (See) sets corresponding to the relevant statements to the number of semantic enhancement signature information (See) sets of the vulnerability statements. Semantic similarity: It evaluates the similarity between the target function and the vulnerability function by comparing the semantic dependencies between them. These dependencies include data dependency and control dependency, which are represented by the semantic signature Sem. 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 sentence pairs with the greatest semantic similarity, ensuring that each sentence is matched to the most appropriate semantic dependency.

Images