Vulnerability influence software library version detection method based on weighting inter-method program dependency graph

Abstract

The invention belongs to the technical field of computer software security, and particularly relates to a vulnerability influence software library version detection method based on a weighting inter-method program dependency graph. The vulnerability influence software library version detection method comprises the following steps: generating a vulnerability signature and a patch signature for each vulnerability, and representing the vulnerability signature and the patch signature as weighted IPDG; potential vulnerability signatures and potential patch signatures of the candidate software library versions are generated, similarity comparison is carried out on the potential vulnerability signatures and the potential patch signatures and the original signatures, and which software library versions are affected by vulnerabilities are detected. The modified code line in the patch is utilized to generate the vulnerability signature and the patch signature, so that the limitation that the vulnerability signature cannot be generated under the condition that the code line is not deleted in the prior art is overcome. In addition, a key method is selected through an HITS algorithm, key variables and the dependency relationship thereof are identified through taint analysis to determine key statements, and therefore the detection accuracy is further improved. According to the method, the accuracy and efficiency of vulnerability detection in the open source software supply chain can be effectively improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer software security, and in particular relates to a method for detecting a version of a software library affected by a vulnerability. Background Art

[0002] The rapid development of open source software has made the widespread use of third-party software libraries a norm in modern software development. Over time, these software libraries and their different versions may contain a large number of known vulnerabilities, posing security risks to the system. Therefore, timely identifying which package versions are affected by specific vulnerabilities has become an important task in maintaining the security of the open source software supply chain.

[0003] Named entity recognition technology is used to extract affected software library versions from vulnerability reports and descriptions. Dong et al. [1] proposed using named entity recognition technology to extract affected software library version information from vulnerability descriptions. Although this method can automatically process vulnerability descriptions, its effectiveness depends on the quality and detail of the vulnerability description. If the vulnerability description is incomplete or vague, this method cannot accurately identify the affected version. In recent years, researchers have gradually shifted their focus to identifying affected library versions by static analysis of source code. Patch-based methods [2] [3] [4] [5] identify vulnerable versions by tracking changes in code version history. This type of method determines which versions of the code contain the same vulnerability by comparing the new and deleted code lines in the patch. However, this method depends on whether the patch contains deleted code lines and cannot handle patches without deleted lines, thus missing some affected versions. In addition, these methods usually only focus on the code changes in the patch and ignore the contextual information around the vulnerability, which may lead to false positives. Clone detection-based methods [6] [7] [8] [9]

[10] identify affected library versions by generating code clone fingerprints of the repair method. These methods introduce contextual information of the vulnerability through program slicing technology to try to improve the accuracy of detection. However, they assign the same importance to all fixes and fail to distinguish the different roles of certain fixes or statements in vulnerability repair. This unweighted importance division may lead to incorrect matching results, especially when the contributions of different fixes to vulnerability repair vary significantly in large code bases.

[0004] Therefore, the present invention proposes a more effective vulnerability-affected version detection method, which can more accurately identify the software library version affected by the vulnerability based on the analysis of code changes before and after repair and combined with the weighted inter-method dependency graph (IPDG) technology. Summary of the invention

[0005] The purpose of the present invention is to propose a vulnerability-affected software library version detection method based on a program dependency graph between weighted methods with high detection accuracy and efficiency.

[0006] The vulnerability-affected software library version detection method proposed in the present invention generates a weighted inter-method dependency graph (IPDG) to perform in-depth analysis of code changes and identify software library versions affected by the vulnerability. The present invention significantly improves detection accuracy and efficiency by accurately selecting key methods and key statements and their dependencies between methods. The specific steps are as follows:

[0007] (I) Vulnerability and patch signature generation

[0008] The generation of vulnerability and patch signatures is the core of this technology. By analyzing the code changes before and after the vulnerability is fixed, a method dependency graph with semantic weights is generated. In the process of vulnerability repair, the changes in the code are mainly reflected in the modification or addition of certain key methods; the generation of vulnerability and patch signatures first extracts (selects) key methods from the code before and after the repair. The selection of key methods depends not only on the method call relationship in the code, but also on the contextual information in the vulnerability description to ensure that the selected method is directly related to the vulnerability. The specific process is as follows:

[0009] (1) Generation of method reference graph: A method reference graph (MRG) is generated by analyzing the code before and after the vulnerability is fixed. MRG is used to represent the calling relationship between methods. Tools such as Joern

[11] are used in the generation process to automatically parse the code and generate a graph structure. MRG provides structured context information for inter-method analysis, which facilitates the subsequent selection of key methods.

[0010] (2) Vulnerability description analysis: The present invention extracts class names and method names related to the vulnerability from CVE descriptions and GitHub submission information. These descriptions are usually written by security experts and contain detailed analysis of the root causes of the vulnerability, thus providing valuable semantic information. This information is integrated into the method reference graph to enhance the understanding of the semantic relationship of the method. Here, CVE (Common Vulnerabilities and Exposures) is an internationally used vulnerability identification system that provides detailed descriptions of security vulnerabilities. CVE descriptions usually include the scope of the vulnerability, the cause of the problem, and an outline of the solution. These descriptions can provide clues to help locate class names and method names in the code where vulnerabilities may exist. In GitHub, submission information is a short description that developers attach when submitting changes to the code library. These submission messages usually explain which vulnerability-related modules are specifically modified.

[0011] (3) Selection of key methods: The Hyperlink Induced Topic Search (HITS)

[12] algorithm is used to determine key methods by calculating the authority value and hub value between methods. The input of the HITS algorithm is the MRG graph, and the algorithm outputs the authority value (representing the importance of the method) and hub value (representing the possibility of the method as an entry point) of each method. Based on the authority value and hub value, the key parties related to the vulnerability and the key methods related to the patch are selected. In particular, methods with high authority values ​​are usually key methods that will be triggered by attackers, while methods with high hub values ​​are entry points that may trigger attacks.

[0012] (4) Identification of key statements: After the key methods are selected, the next step is to perform statement-level analysis to identify key statements that are directly related to the vulnerability fix. To achieve this, first generate a program dependency graph (PDG) for each key method, and then perform forward and backward slicing to identify statements and variables related to the vulnerability. The details are as follows:

[0013] (4.1) Generate a Program Dependency Graph (PDG): PDG represents the control flow and data flow dependencies between statements in a program. The present invention generates PDG using the Joern tool, which can parse the source code into a graph structure to facilitate the analysis of program dependencies.

[0014] (4.2) Forward and backward program slicing: Forward and backward slicing is performed on the modification statements in each key method to identify other statements that have dependencies on these modification statements. 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.

[0015] (4.3) Taint analysis: Use forward taint analysis and backward taint analysis to identify the statements that affect key variables by tracing the control flow and data flow starting from these variables. In this way, the key statements most relevant to vulnerability repair can be identified.

[0016] (5) Generate vulnerability and patch signatures: Based on key methods and key statements, construct a weighted inter-method dependency graph (IPDG); IPDG comprehensively represents the calling relationships between methods and the dependencies between statements, thereby generating vulnerability signatures and patch signatures; specifically, the method reference graph (MRG) and program dependency graph (PDG) are combined to generate an inter-method dependency graph. Specifically, first, for each method call point in the call graph, the call relationship is connected to the nodes in the dependency graph to form a control flow and data flow representation between methods; secondly, different weights are assigned to each key method, key statement and its dependency relationship; by default, the initial weight of all nodes and edges is 1, while the weights of key methods and key statements are assigned higher values ​​to reflect their importance in vulnerability detection; in this way, vulnerability signatures and patch signatures are generated, which are used to identify vulnerabilities and patch features, respectively.

[0017] (II) Signature generation of potentially affected versions

[0018] After identifying the signatures of the vulnerability and patch, the next step is to generate the signatures of the potentially affected versions. By reverse analyzing the code of the candidate software library version, the key methods and key statements related to the vulnerability fix are identified, and the corresponding weighted inter-method dependency graph is generated. Since the code of the candidate software library version is usually reconstructed or modified many times, there may be implementations that are different from the original vulnerability fix code. Therefore, the present invention uses a code clone detection tool (such as NiCad) to identify the methods in the candidate version and compare them with the original vulnerability fix method. Specifically:

[0019] First, the present invention reverse compiles the candidate software library version and extracts its source code representation. Using tools such as JavaDecompiler

[13] , the bytecode of the candidate library is converted into source code to facilitate subsequent analysis.

[0020] Next, the present invention uses code clone detection tools such as NiCad

[14] to analyze whether the methods in the candidate version are similar to the key methods before and after the vulnerability is fixed. In this way, the candidate methods that are potentially affected by the vulnerability can be identified. Since the methods in the candidate version may have certain grammatical differences from the original vulnerability repair code, it is necessary to identify related statements through statement similarity calculation. Specifically, the Levenshtein distance

[15] is used to calculate the similarity of the statements. If the similarity exceeds the set threshold, the two statements are considered to be a matching pair. At this time, the system marks these statement pairs as potential key statements and performs program slicing. On the one hand, in order to handle the grammatical differences between code versions, the present invention normalizes the statements, including reordering operators, standardizing different conditional expressions, etc. On the other hand, for the mapped key statements, the present invention uses the same slicing technology as mentioned above to generate the program dependency graph (PDG) in the candidate version.

[0021] Then, through forward and backward slicing, the dependencies of these statements in the candidate version are analyzed to further generate signatures of potential vulnerabilities and patches.

[0022] (III) Detection of affected software library versions

[0023] Through the generated signature, the system can identify which software library versions are affected by the vulnerability. The specific steps are as follows:

[0024] (1) Signature similarity calculation: The present invention uses the UniXcoder model

[16] to convert program statements and dependencies into embedding vectors, and calculates the similarity between the original vulnerability signature and the candidate version signature through cosine similarity. The similarity calculation includes the comparison of node (statement) similarity and edge (dependency) similarity.

[0025] (2) Bipartite graph matching and distance minimization: In order to find the best statement mapping pair, the present invention converts the similarity problem of statements and dependencies into a bipartite graph matching problem. By solving this problem, the minimum distance between the vulnerability signature and the candidate version signature is calculated, and the candidate version is judged whether it is affected by the vulnerability based on the result.

[0026] (3) Affected version determination: Ultimately, the candidate version will be determined as "affected" or "not affected" based on the similarity with the vulnerability signature. If the candidate version is more similar to the vulnerability signature than the patch signature, then the version is considered to be affected by the vulnerability.

[0027] The technical features of the present invention are mainly as follows:

[0028] (1) Vulnerability and patch signature generation based on the weighted inter-method dependency graph (IPDG) can accurately capture the dependency relationships between key methods and statements in the vulnerability repair process. The hyperlink-induced topic search (HITS) algorithm is used to weight the repair methods and statements to ensure more accurate detection results.

[0029] (2) Compared with the existing patch and clone detection methods, the present invention can effectively solve the problem of patches without deleted lines. Even if the patch only contains newly added code lines, it can still generate vulnerability signatures, thereby improving the comprehensiveness of detection;

[0030] (3) By combining semantic analysis and program slicing technology, the present invention not only analyzes code versions from code library hosting platforms (such as GitHub), but also extends to software package registries (such as Maven), realizing vulnerability detection for multi-version and multi-platform libraries, thereby improving the efficiency and coverage of vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is a flowchart of the vulnerability impact software library version detection method of the present invention.

[0032] Figure 2 This is the patch icon corresponding to CVE-2022-22976. DETAILED DESCRIPTION

[0033] The following further introduces the specific implementation of the present invention for identifying vulnerable versions of software libraries. The present invention takes a modified method (i.e., crypt_raw) in the CVE-2022-22976 patch in spring-security as an example. Figure 2 As shown in the figure, the modified lines are underlined, the unchanged parts are folded, and the blank lines are removed to improve clarity. The line numbers are consistent with the original code. We analyzed the cause of the vulnerability and the patch repair logic. The main reason is an integer overflow error: in the original method, when log_rounds is set to 31 ( Figure 2 (a) line 10), the integer rounds will overflow. The patch changes rounds from an int to a long ( Figure 2 (b) and adds an if conditional check on rounds and log_rounds ( Figure 2 (b) lines 8-20). The main process of the present invention is:

[0034] (I) Vulnerability and patch signature generation

[0035] The present invention uses Joern to first generate PDG for the patch corresponding to CVE, and then performs forward and backward slicing on the modification statements in each key 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. Using forward taint analysis and backward taint analysis, by tracing the control flow and data flow starting from key variables, the statements that affect these variables are identified. In this way, the key statements most relevant to vulnerability repair can be identified. Figure 2 In the process of changing the statement slice, the present invention extracts Figure 2 The newly added lines in (b): 1-2, 6, 8-21, 29, 34-35 and 40-41. Since there is a control dependency on line 8, the present invention includes lines 9-20 in the forward slice; since there is a data dependency on line 8, the present invention includes line 2 in the backward slice. After the slicing is completed, all statements that have no control or data dependencies on the changed lines are pruned. The partial program dependency graph (PDG) includes lines 1-2, 6, 8, 9, 11, 12, 14, 16, 17-19, 29-31, 34-36, 40-45 and their dependencies. Figure 2 The first row in (a) and Figure 2 Lines 1-2 in (b) represent a modified change block. Figure 2 The for_check parameter in line 1 of (b) is identified as a critical statement because it contains a newly added variable in the modified change block. Next, the present invention uses taint analysis to track the variable and identifies lines 8 and 9 as critical statements. Line 8 becomes a critical statement due to its data dependency on for_check, while line 9 becomes a critical statement due to its control dependency on line 8. Figure 2 Lines 28-29 in (a) and Figure 2 Lines 40-41 in (b) are also modified change blocks. However, since there are no new or deleted variables in these lines, they do not contain key statements.

[0036] (II) Signature generation of potentially affected versions

[0037] Next, Java Decompiler is used to convert the Maven bytecode of the candidate library into source code for subsequent analysis, and the NiCad

[14] code clone detection tool is used to analyze whether the methods in the candidate version are similar to the key methods before and after the vulnerability is fixed. In this way, we identify the key method crypy_raw in the target version. Then, since the methods in the candidate version may have certain grammatical differences from the original vulnerability fix code, it is necessary to identify related statements through statement similarity calculation. The Levenshtein distance is used to calculate the similarity of the statements. If the similarity exceeds the set threshold, the two statements are considered to be a matching pair. At this point, the system marks these statement pairs as potential key statements and performs program slicing. The present invention uses the same slicing technology as mentioned above to generate a program dependency graph (PDG) in the candidate version. Then, through forward and backward slicing, the dependencies of these statements in the candidate version are analyzed, and signatures of potential vulnerabilities and patches are further generated.

[0038] (III) Detection of affected software library versions

[0039] Finally, the UniXcoder model is used to convert program statements and dependencies into embedding vectors, and the similarity between the original vulnerability signature and the candidate version signature is calculated by cosine similarity. Finally, the candidate version is judged as "affected" or "not affected" based on the similarity with the vulnerability signature. If the candidate version has a higher similarity with the vulnerability signature than the patch signature, it is considered to be affected by the vulnerability.

[0040] Comparative testing of methods

[0041] The present invention was compared with five vulnerability databases: NVD, Veracode, GitHub, GitLab, and Snyk. Unknown CVEs and library versions that were not in our benchmark data were excluded. The results of the effectiveness evaluation of the present invention are: precision and recall are improved in all five databases. The largest improvement in precision is 0.22 in GitHub and GitLab, and the largest improvement in recall is 0.14 in NVD. In addition, it helps to identify more fully identified vulnerabilities, at least 19 in Snyk and up to 27 in NVD. In addition, we selected inaccurate vulnerabilities identified by the present invention from the benchmark data and the datasets of V-SZZ and VerJava. We reported 52, 31, and 46 incorrectly labeled vulnerabilities to NVD, Veracode, and Snyk, respectively, by email, and reported 39 and 42 incorrectly labeled vulnerabilities to GitHub and GitLab, respectively, by creating issue reports. At present, GitHub and GitLab have corrected all incorrectly labeled affected library versions. NVD corrected the incorrectly affected versions in 8 vulnerabilities, and the rest are under review. Notably, GitLab has expressed interest in the present invention for use in identifying affected library versions.

[0042] References

[0043] [1]. Dong, Y., Guo, W., Chen, Y., Xing, X., Zhang, Y., & Wang, G. (2019).

[0044] Towards the detection of inconsistencies in public securityvulnerabilityreports.In 28th USENIX security symposium(USENIX Security 19)(pp.869-885).

[0045] [2].Nguyen,VH,Dashevskyi,S.,&Massacci,F.(2016).An automatic method for assessing the versions affected by a vulnerability.EmpiricalSoftwareEngineering,21,2268-2297.

[0046] [3].Bao,L.,Xia,X.,Hassan,A.E.,&Yang,X.(2022,May).V-SZZ:automaticidentification of version ranges affected by CVE vulnerabilities.

[0047] In Proceedings of the 44th International Conference onSoftwareEngineering(pp.2352-2364).

[0048] [4].Sun,Q.,Xu,L.,Xiao,Y.,Li,F.,Su,H.,Liu,Y.,...&Huo,W.(2022,October).VERJava:Vulnerable Version Identification for Java OSS with aTwo-StageAnalysis.In 2022IEEE International Conference on SoftwareMaintenance andEvolution(ICSME)(pp.329-339).IEEE.

[0049] [5].He,Y.,Wang,Y.,Zhu,S.,Wang,W.,Zhang,Y.,Li,Q.,&Yu,A.(2023).

[0050] Automatically identifying cve affected versions with patches anddeveloperlogs.IEEE Transactions on Dependable and Secure Computing,21(2),905-919.[6].Woo,S.,Choi,E.,Lee,H.,&Oh,H.(2023).{V1SCAN}:Discovering 1-dayVulnerabilities in Reused{C / C++}Open-source Software Components UsingCodeClassification Techniques.In 32nd USENIX Security Symposium(USENIXSecurity 23)(pp.6541-6556).

[0051] [7].Woo,S.,Hong,H.,Choi,E.,&Lee,H.(2022).{MOVERY}:A PreciseApproachfor Modified Vulnerable Code Clone Discovery from Modified{Open-Source}Software Components.In 31st USENIX Security Symposium(USENIXSecurity 22)(pp.3037-3053).

[0052] [8].Woo,S.,Lee,D.,Park,S.,Lee,H.,&Dietrich,S.(2021).{V0Finder}:

[0053] Discovering the Correct Origin of Publicly Reported SoftwareVulnerabilities.

[0054] In 30th USENIX Security Symposium(USENIX Security 21)(pp.3041-3058).

[0055] [9].Xiao,Y.,Chen,B.,Yu,C.,Xu,Z.,Yuan,Z.,Li,F.,...&Shi,W.

[0056] (2020).{MVP}:Detecting vulnerabilities using{Patch-Enhanced}

[0057] vulnerability signatures.In 29th USENIX Security Symposium(USENIXSecurity 20)(pp.1165-1182).

[0058]

[10] .Kim,S.,Woo,S.,Lee,H.,&Oh,H.(2017,May).Vuddy:A scalableapproachfor vulnerable code clone discovery.In 2017 IEEE symposium onsecurity andprivacy(SP)(pp.595-614).IEEE.

[0059]

[11] .ShiftLeftSecurity(2024).Joern.https: / / github.com / ShiftLeftSecurity / joern

[0060]

[12] .Wikepedia(2024).HITS algorithm.https: / / en.wikipedia.org / wiki / HITS_algorithm

[0061]

[13] .java-decompiler(2024).jd-gui.https: / / github.com / java-decompiler / jd-gui

[14] .NiCad(2024).NiCad.https: / / github.com / bumper-app / nicad

[0062]

[15] .wiki(2024).Levenshtein Distance.https: / / en.wikipedia.org / wiki / Levenshtein_distance.

[0063]

[16] .Guo,D.,Lu,S.,Duan,N.,Wang,Y.,Zhou,M.,&Yin,J.(2022).Unixcoder:Unified cross-modal pre-training for code representation.arXiv preprintarXiv:2203.03850。

Claims

1. A method for detecting vulnerability-affected software library versions based on a weighted program dependency graph between methods, characterized in that: By generating a weighted inter-method dependency graph (IPDG), we can deeply analyze the code changes and identify the software library versions affected by the vulnerability. The specific steps are as follows: (I) Vulnerability and patch signature generation By analyzing the code changes before and after the vulnerability is fixed, a method dependency graph with semantic weights is generated. Since the code changes in the vulnerability repair process are mainly reflected in the modification or addition of some key methods, the first step in generating vulnerability and patch signatures is to select key methods from the code before and after the repair. The selection of key methods depends not only on the method call relationship in the code, but also on the context information in the vulnerability description to ensure that the selected method is directly related to the vulnerability. The specific process is as follows: (1) Generation of method reference graph: Generate a method reference graph (MRG) by analyzing the code before and after the vulnerability is fixed. MRG is used to represent the calling relationship between various methods. The tool Joern is used during the generation process to automatically parse the code and generate a graph structure; MRG provides structured context information for inter-method analysis, facilitating subsequent key method selection; (2) Vulnerability description analysis: Extract the class names and method names related to the vulnerability from the CVE description and GitHub submission information; these descriptions are written by security experts and contain detailed analysis of the root causes of the vulnerability, thereby providing semantic information; this information is integrated into the method reference graph to enhance the understanding of the semantic relationship of the method; (3) Selection of key methods: The hyperlink-induced topic search (HITS) algorithm is used to calculate the authority value and hub value between methods to determine the key methods; The input of the HITS algorithm is the MRG graph, which outputs the authority value of the importance of each method and the hub value of the possibility of the method as an entry point. Based on the authority value and hub value, the key methods related to the vulnerability and the key methods related to the patch are selected. Here, the methods with high authority values ​​are usually the key methods that will be triggered by attackers, while the methods with high hub values ​​are the entry points that may trigger attacks. (4) Identification of key sentences; After the key method selection, statement-level analysis is performed to identify key statements directly related to vulnerability fixes; first, the program dependency graph (PDG) of each key method is generated, and then forward and backward slicing is performed to identify key statements related to the vulnerability; (5) Generate vulnerability and patch signatures: Construct a weighted inter-method dependency graph (IPDG) based on key methods and key statements; IPDG comprehensively represents the calling relationships between methods and the dependencies between statements, thereby generating vulnerability signatures and patch signatures. Specifically, it combines the method reference graph (MRG) and the program dependency graph (PDG) to generate a method dependency graph. Specifically, first, for each method call point in the call graph, the calling relationship is connected with the nodes in the dependency graph to form a control flow and data flow representation between methods. Secondly, different weights are assigned to each key method, key statement and its dependency relationship. By default, the initial weight of all nodes and edges is 1, while the weights of key methods and key statements are assigned higher values ​​to reflect their importance in vulnerability detection. In this way, vulnerability signatures and patch signatures are generated to identify vulnerabilities and patch features, respectively. (II) Signature generation of potentially affected versions By reverse-analyzing the code of the candidate software library version, we identify the key methods and key statements related to the vulnerability fix, and generate a corresponding weighted method dependency graph. Since the code of the candidate software library version is usually refactored or modified many times, there may be implementations that are different from the original vulnerability fix code. We use code clone detection tools to identify the methods in the candidate version and compare them with the original vulnerability fix methods. (III) Detection of affected software library versions The generated signature can be used to identify which software library versions are affected by the vulnerability. The specific process is as follows: (1) Signature similarity calculation: Using the UniXcoder model, program statements and dependencies are converted into embedding vectors, and the similarity between the original vulnerability signature and the candidate version signature is calculated using cosine similarity. The similarity calculation includes the comparison of node (i.e., statement similarity) and edge (i.e., dependency similarity). (2) Bipartite graph matching and distance minimization: In order to find the best statement mapping pair, the similarity problem of statements and dependencies is converted into a bipartite graph matching problem. By solving this problem, the minimum distance between the vulnerability signature and the candidate version signature is calculated, and the result is used to determine whether the candidate version is affected by the vulnerability. (3) Determination of affected versions: Ultimately, the candidate version is determined to be "affected" or "unaffected" based on its similarity to the vulnerability signature; if the candidate version's similarity to the vulnerability signature is higher than that to the patch signature, then the version is considered to be affected by the vulnerability.

2. The vulnerability-affected software library version detection method according to claim 1, characterized in that: The specific process of identifying the key sentences in step (1) is as follows: (4.1) Generate a program dependency graph (PDG): PDG represents the control flow and data flow dependencies between statements in a program. Specifically, the Joern tool is used to generate PDG. This tool can parse the source code into a graph structure to facilitate the analysis of program dependencies. (4.2) Forward and backward program slicing: Perform forward and backward slicing on the modification statements in each key method to identify other statements that have dependencies on these modification statements; 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; (4.3) Taint analysis: Use forward taint analysis and backward taint analysis to track the control flow and data flow starting from key variables, identify the statements that affect these variables, and thus identify the key statements most relevant to vulnerability repair.

3. The vulnerability-affected software library version detection method according to claim 2, characterized in that: Step (ii) generates the signature of the potentially affected version, specifically: First, the candidate software library version is reverse compiled to extract its source code representation; the Java Decompiler tool is used to convert the candidate library's bytecode into source code for subsequent analysis; Next, the NiCad code clone detection tool is used to analyze whether the methods in the candidate version are similar to the key methods before and after the vulnerability is fixed, thereby identifying the candidate methods potentially affected by the vulnerability; since the methods in the candidate version may have certain differences in syntax from the original vulnerability fix code, it is necessary to identify related statements through statement similarity calculation; specifically, the Levenshtein distance is used to calculate the similarity of the statements, and if the similarity exceeds the set threshold, the two statements are considered to be a matching pair; these statement pairs are marked as potential key statements and program slicing is performed; on the one hand, in order to deal with the grammatical differences between code versions, the statements are normalized, including reordering operators and standardizing different conditional expressions; on the other hand, for the mapped key statements, the same slicing technology as mentioned above is used to generate the program dependency graph (PDG) in the candidate version; Then, through forward and backward slicing, the dependencies of these statements in the candidate version are analyzed to further generate signatures of potential vulnerabilities and patches.

Images