Graph reachability analysis method and device oriented to third-party library combination calling

Abstract

The invention relates to a graph reachability analysis method and device oriented to third-party library combined calling. The method comprises the steps that through an internal calling graph abstract generation step, calling edges of a software project and a TPL are extracted, an internal calling edge and an external calling edge are distinguished, and a refining strategy is adopted to eliminate inaccessibility in the TPL through matrix operation to generate a reachability abstract; the method comprises the following steps: receiving a to-be-retrieved TPL position through an internal calling graph abstract retrieval step, reversely searching to determine a dependency path of the to-be-retrieved TPL position, and forming a dependency node link from a software project to a queried TPL; in the reachability analysis step, a reachability path set from a source method to a target method is constructed in combination with a call graph abstract retrieved by a dependency path and a to-be-judged source method set. According to the method, the generation and retrieval process of the abstract of the calling graph is optimized, the method is suitable for processing a complex software project containing a large number of TPLs, and the efficiency of reachability analysis of the graph for third-party library combined calling is effectively improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software engineering, and in particular to a graph reachability analysis method for third-party library combination calls. Background Art

[0002] Call graph reachability analysis aims to determine whether a specific method can call a target method directly or indirectly. This is a fundamental program analysis problem, and the practicality of its solution allows it to be efficiently applied in a variety of downstream scenarios. For example, in the field of software composition analysis, developers often need to determine which methods in their application code may be affected by vulnerable methods in third-party libraries. Path reachability analysis from application code to third-party library methods with security risks in the call graph reveals potential threats caused by security vulnerabilities within the software supply chain. In addition, other application scenarios of program analysis, such as dependency conflict detection, TPL compatibility analysis, and software streamlining, also rely heavily on call graph reachability analysis as an important cornerstone to support specific applications.

[0003] Although call graph reachability analysis has been studied for decades, research on implementing such analysis in integrated development environments is remarkably scarce. Accurate and efficient call graph reachability analysis during the development phase allows developers to proactively identify potential issues related to software security and quality, thereby taking preventive measures at an early stage of the project. However, achieving this goal is quite challenging, especially given the strict time constraints in integrated development environments that often require analysis tasks to be completed in milliseconds or seconds. Existing techniques usually construct a call graph first and then traverse the graph using a depth-first search (DFS) or breadth-first search (BFS) algorithm. However, such analysis inevitably comes with a significant time cost when dealing with large call graphs. In a preliminary study of 15 Java open source projects, DFS- or BFS-based methods take an average of 327.93 seconds to process a reachability query in a real call graph containing 198,082 call edges and 24,618 methods. Therefore, accelerating the reachability analysis process of the call graph is very likely to bring substantial benefits and efficiency improvements to various program analysis function providers in the integrated development environment.

[0004] According to the published research literature, using the index mechanism of the graph structure to improve the efficiency of graph reachability analysis is a promising solution. However, the performance of these techniques in answering call graph reachability queries in scenarios may not be satisfactory. This is because the effectiveness of these methods usually relies on the assumption of stability of the graph structure, while the graph structure in the integrated development environment is often unstable during the development process. Specifically, adding, deleting, and replacing third-party libraries in an integrated development environment are common operations, which may cause significant changes in the call graph structure. In this case, existing methods need to rebuild the graph index from scratch, resulting in a large amount of computational cost. To solve this problem, an intuitive idea is to build an index for each third-party library (TPL) through offline analysis, and then combine these indexes online as needed for call graph reachability analysis. However, simply combining the call graph index of the third-party library with the internal index of the project is not enough to build a comprehensive index system that comprehensively covers the project and TPL methods. This limitation significantly hinders the ability and flexibility to accelerate call graph reachability analysis in environments involving third-party libraries. Summary of the invention

[0005] In order to solve the above problems, the present invention proposes a graph reachability analysis method and device for third-party library combination calls, which can improve the efficiency of analysis when querying the reachability of method pairs in the presence of third-party libraries.

[0006] The specific plan is as follows:

[0007] On the one hand, a graph reachability analysis method for third-party library combination calls includes:

[0008] Internal call graph summary generation step: Analyze the software project and the third-party library TPL it uses; for each TPL, collect all call edge information, and generate an internal call graph summary based on the call edge information through transitive closure calculation;

[0009] The internal call graph summary retrieval step determines a dependency path based on the queried TPL location and retrieves the internal call graph summary on demand based on this dependency path;

[0010] The reachability analysis step determines the reachable paths from the source method set to the target method set based on the internal call graph summary retrieved by the dependency path.

[0011] Preferably, the internal call graph summary generation step specifically includes:

[0012] Extract internal call edges and external call edges from the internal call graph and use the internal call edges to build a calculation matrix When the result matrix equal When the calculation is finished, eliminate Corresponding to the unreachable methods in TPL, get the reachability of all accessible methods in TPL to other TPL external methods.

[0013] Preferably, the internal call edge represents a call relationship formed between a caller and a callee, wherein both the caller and the callee are internally defined methods of a software project or a TPL used by the software project;

[0014] The external call edge represents a call relationship formed between a caller and a callee, wherein the caller is a software project or an internally defined method of TPL used by the software project, and the callee is a software project or an externally defined method of TPL used by the software project.

[0015] Preferably, the internal call graph summary includes an internal summary and an external summary; the internal summary represents each accessible method m s Can directly or indirectly call another internal method m t ; The external summary represents each accessible method m s Can directly or indirectly call other TPL defined methods m t .

[0016] Preferably, the internal call graph summary retrieval step specifically includes:

[0017] Build a dependency tree containing the software project and its sub-dependencies, find the dependency path on the dependency tree based on the location of the query target collection, and retrieve the internal call graph summary based on the location of the TPL node on the dependency path.

[0018] Preferably, the search dependency path specifically includes:

[0019] A reverse search is initiated from the location of the queried TPL until all upper-level nodes are traversed and finally the software project is reached. All dependent nodes traversed during the search process together constitute a dependency path, in which the software project is the starting node, the queried TPL is the ending node, and other traversed TPLs are transition nodes.

[0020] Preferably, the reachability analysis step specifically includes:

[0021] Receive the queried source method set, target method set, dependency path and the internal call graph summary retrieved on demand based on the dependency path, load the external summary for the transition node in the dependency path, and merge the loaded external summary with the source method set to obtain the iteratively expanded reachable method set, obtain all the end points that can be reached from the source method set until the termination node is reached, then load the internal summary, merge the iteratively expanded reachable method set with the internal summary, and determine the complete set of all reachable target method sets.

[0022] On the other hand, a graph reachability analysis device for third-party library combination calls includes:

[0023] Internal call graph summary generation module, used to analyze software projects and the third-party libraries TPL they use; for each TPL, all call edge information is collected, and an internal call graph summary is generated based on the call edge information through transitive closure calculation;

[0024] An internal call graph summary retrieval module is used to determine a dependency path based on the queried TPL location and retrieve the internal call graph summary on demand based on the dependency path;

[0025] The reachability analysis module is used to determine the reachable path from the source method set to the target method set based on the internal call graph summary retrieved by the dependency path.

[0026] The present invention adopts the above technical solution and has the following beneficial effects:

[0027] (1) The present invention is used to process the reachability of query method pairs in the presence of third-party libraries; specifically, the reachability relationship summary of each third-party library is generated through offline transitive closure calculation, and then the summary is combined with the application code as needed, thereby avoiding redundant analysis of the third-party library to accelerate the analysis;

[0028] (2) The present invention introduces a matrix representation of the call graph and uses a fast matrix multiplication algorithm in the transitive closure calculation process. This approach simplifies the data structure and further improves the efficiency of the analysis process. At the same time, it can more quickly and accurately determine the reachability of complex call relationships, thereby enhancing its usability and response speed in the actual development environment.

[0029] (3) The present invention generates call graph summaries for each third-party library (TPL) in advance and retrieves these summaries on demand according to the query target, which greatly reduces the amount of calculation and time overhead for each query. Experimental results show that compared with existing graph indexing technologies and online traversal algorithms, the average speedup of the present invention is as high as hundreds to thousands of times, which not only greatly improves the speed when processing call graph reachability queries in large software projects, but also effectively copes with complex project structures and large-scale data sets. This significant improvement in efficiency is of great significance for promoting rapid feedback and problem location in the software development process.

[0030] (4) The present invention can efficiently solve call graph reachability queries, accelerate the operation of various downstream application scenarios, and further promote various analysis tasks in the integrated development environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 Schematic diagrams of two types of call graphs for the heuristic code examples of the present invention;

[0032] Figure 2 A schematic diagram of the syntax of a software project of an example of the present invention;

[0033] Figure 3 The following is an instructive code example diagram of an example of the present invention;

[0034] Figure 4 It is a flow chart of a graph reachability analysis method for third-party library combination call according to an example of the present invention;

[0035] Figure 5 A method framework diagram of an example of the present invention;

[0036] Figure 6 A schematic diagram of an algorithm for obtaining an internal call graph summary according to an example of the present invention;

[0037] Figure 7 A matrix of inspiring code examples for examples of the present invention;

[0038] Figure 8 This is a simplified effect diagram of the call edge of an example of the present invention;

[0039] Fig. 9 A schematic diagram of an algorithm for on-demand summary retrieval according to an embodiment of the present invention;

[0040] Fig.10 A schematic diagram of total storage usage when analyzing a software project according to an example of the present invention;

[0041] Fig.11 A schematic diagram of a reachability analysis algorithm of an example of the present invention;

[0042] Fig.12Schematic diagram of execution time of the method according to the embodiment of the present invention;

[0043] Fig.13 A schematic diagram of the speed improvement ratio of the method according to the embodiment of the present invention compared with other algorithms;

[0044] Fig.14 This is a structural block diagram of a graph reachability analysis device for third-party library combination calls according to an embodiment of the present invention. DETAILED DESCRIPTION

[0045] The present invention is further described in detail below in conjunction with embodiments and drawings, but the embodiments of the present invention are not limited thereto.

[0046] In order to significantly reduce the time required for graph reachability analysis, the present invention provides a graph reachability analysis method for combined calls of third-party libraries, which covers two stages: offline and online analysis. In the offline analysis stage, call graph analysis is performed for each TPL, aiming to collect all call edge information and generate summary data for disk storage. Entering the online analysis stage, when faced with a call graph reachability query, an on-demand retrieval strategy is adopted to efficiently retrieve summary information of related TPLs from the disk. This strategy significantly reduces the computational burden and improves overall analysis efficiency.

[0047] In the offline analysis phase, we propose to use Transitive Closure (TC), the core of which is to encode the reachability information between all nodes into summary data. Unlike the current graph indexing technology, TC can directly answer the question of which nodes can be reached from a specified node in the call graph, thus helping to build connections between different third-party libraries. For example, in Figure 1 In the call graph of the sample code shown, for the third-party library A, the initial input contains all the edge information in the library, including edges ③ to ⑦. After TC calculation, it is determined that foo_a can reach baz_a and foo_c, which correspond to edges ⑩ and Edge① 1 It is identified as the connecting edge between the third-party libraries A and C. Through the identification of these edges, connections can be established between the libraries, thereby forming a network relationship with other libraries.

[0048] For reachability queries involving third-party libraries within the scope of the project, the summary information of the relevant TPL is dynamically retrieved according to the needs, so as to accurately determine the reachability relationship. The present invention does not load all TPLs indiscriminately, but identifies the TPLs closely related to the reachability query based on the dependency relationship between TPLs, and selectively loads the summary information of the TPLs on the dependency path for combined analysis. This design strategy significantly reduces time overhead. Figure 1For example, to determine whether the host project can reach the risk method in TPL C, only the summary information of third-party libraries A and C that are directly involved in the reachable path from the host to the bar_c method is loaded in a targeted manner, thereby achieving efficient analysis.

[0049] Further, as follows, we first explain the program syntax, then build a call graph model suitable for applications using third-party libraries, and finally clearly define the call graph reachability problem.

[0050] (1) Program syntax

[0051] like Figure 2 As shown in Figure 1, the project syntax is formally defined. A project P includes a set of source code files F and a collection of other projects that are dependent on software development.

[0052] In each source code file F, at least one method M is defined; the method M consists of a modifier, a fully qualified name, and a series of statements, where the modifier indicates the accessibility of the method, that is, whether the method is public, protected, or private.

[0053] (2) Calling graph model

[0054] In order to accurately describe the call graph reachability problem, two key call graph models are defined below, aiming to formally describe the different forms of caller-callee relationships in projects that use third-party libraries.

[0055] Definition 1. (Internal Call Graph) For a given software project P, its internal call graph G is defined as a tuple (M, E) consisting of a method set and a call edge set, where M represents the set of all methods and E represents the set of call edges. Specifically, method m can be a method defined in project P, m∈M i , or a method m∈M provided by the TPL used by project P o .

[0056] The call edge c∈E includes the following two types:

[0057] Internal call edge If and only if m s and m t All of them are methods defined in software project P, that is, m s ∈M i , m t ∈M i .

[0058] External call edge If and only if m s Method m defined in project P s ∈Mi , and m t The method m is provided by a third-party library t ∈M o .

[0059] like Figure 1 As shown, Figure 1 The two call graph types for inspiring code examples are Figure 3 The call graph of the third-party library A in the inspirational code example. The third-party library A has five call edges: ③ to ⑦, among which edges ③, ④ and ⑤ are internal call edges, and edges ⑥ and ⑦ are external call edges.

[0060] The internal call graph follows the standard definition of caller-callee relationship. In library-aware program analysis, it is also necessary to analyze the program constructs in TPL. Therefore, a second call graph model is introduced to provide a global perspective for analyzing the reachability issues of the call graph on projects using TPL.

[0061] Definition 2. (Global Call Graph) Consider a system that uses a series of third-party libraries (where n≥1) software project P. Assume that the software project P is associated with each third-party library L i The internal call graphs are G P =(M P ,E P )and Then the global call graph of software project P is defined as in:

[0062]

[0063] Essentially, the global call graph is a concatenation of the internal call graphs of the project and the TPLs it uses. In particular, the external call edges in each internal call graph depict the caller-callee relationship between the software project and the TPL. Notably, all methods derived from function calls in the software project and the TPL, as well as the corresponding caller-callee pairs, are fully encoded in the global call graph. Therefore, with library awareness, the global call graph can serve as a fundamental building block for checking call graph reachability.

[0064] like Figure 1 As shown, Figure 1 Four internal call graphs of the main project and its three TPLs are shown, each within a rectangular area. There are four external call edges, including ①, ②, ⑥, and ⑦. Finally, all methods, internal call edges, and external call edges together constitute the global call graph of the project using the three TPLs.

[0065] (3) Clearly define the call graph reachability problem

[0066] As explained in Definitions 1 and 2, the call graph model is an important intermediate representation of projects using TPL. By performing specific downstream client analysis on the call graph model, we can understand how a method in the current project calls a method in TPL, which has a significant impact on improving software security and quality. For example, if there is a path from a method in the current project to a risky method in TPL, the vulnerability that may arise from the use of unsafe TPL can be detected through call graph analysis. Therefore, it is a fundamental problem to determine whether a method can call another method directly or indirectly. This problem is expressed as the call graph reachability problem, as follows.

[0067] Definition 3. (Call graph reachability problem) For a series of third-party libraries (where n≥1) software project P, and source method m in software project P s and target method m t , the global call graph needs to be calculated And determine in Is there a s To m t The path p.

[0068] Based on the above analysis, if Figure 4 and Figure 5 As shown, the present invention provides a graph reachability analysis method for third-party library combination calls, including:

[0069] S401, internal call graph summary generation step, analyzes the software project and the third-party library TPL used by it; for each TPL, collects all call edge information, and generates an internal call graph summary based on the call edge information through transitive closure calculation.

[0070] Existing graph indexing algorithms are difficult to adapt to call graph changes caused by dependency tree changes during software development. In order to reduce the overhead of analyzing TPL, we use an observation that any change in the dependency tree will not change the call graph reachability of a specific TPL. It can be seen that as long as the reachability relationships of TPL methods are summarized, these relationships can be further reused when analyzing projects that use the TPL, and the reachability between any two methods between the project and the TPL can be efficiently evaluated. For this reason, the concept of "internal call graph summary" is formally introduced to summarize the reachability on the internal call graph of a project or TPL.

[0071] Definition 4. (Internal Call Graph Summary) Assume that the internal call graph of a software project or TPL is G = (M i ∪M o ,E), where M i and M oThe definition of is as described in Definition 1. Its internal call graph summary S is a two-tuple (S i ,S o ),in:

[0072] is a set of internal summaries. (m s ,m t )∈S i Represents each accessible method m s Can directly or indirectly call another internal method m t .

[0073] is a set of external summaries. (m s ,m t )∈S o Represents each accessible method m s Can directly or indirectly call other TPL defined methods m t .

[0074] like Figure 1 As shown in the figure, method foo_a contains two direct call edges (③ and ⑤), and the indirect call edge ⑩ can be calculated transitively through ③ and ④. Similarly, two indirect call edges ⑨ and These reachable methods are recorded in foo_a to create a call graph summary. Through this summary, we can quickly determine which methods foo_a can reach. Among them, ③, ⑤, and ⑩ belong to S i , while ⑨ and Belongs to S o .

[0075] Figure 6 The presented Algorithm 2 describes the computation process of the internal call graph summary. First, the internal call edges E are extracted from the input internal call graph. i and external call edge E o Then, the refinement strategy is performed on the call edge, that is, the internal call edge E i Constructing the calculation matrix Executing a refinement strategy on call edges significantly reduces the computational overhead during transitive closure (TC) calculations and saves processing time. equal The calculation ends when The rows in S that correspond to unreachable methods in TPL reduce storage requirements. i With E o Combined, we get the reachability of all accessible methods in TPL to other external methods of TPL, denoted as S o .

[0076] by Figure 1Take the third-party library A shown in as an example to calculate its call graph summary. First, a matrix is ​​constructed from all internal call edges in the third-party library A, specifically, the call relationship from method foo_a to qux_a (4×4 matrix), as shown in Figure 7 Then, the matrix multiplication operation is used to obtain the final result matrix. In order to save computational space, since the path from bar_a to qux_a does not exist, only the (1×4) submatrix in matrix 2 is retained, which is marked as S in matrix 2. i Next, by connecting the external call edges, i.e., the edges numbered 6 and 7, to S i Combined, the (1×2) submatrix in matrix 2 is calculated, which contains the call relationship from foo_a to bar_b and foo_c. This submatrix is ​​marked as S o .

[0077] like Figure 8 As shown in the figure, the refinement strategy for call edges significantly improves the computational efficiency. After implementing call edge refinement, the average execution time of the TC algorithm on the GPU is significantly reduced by 79.07%. This significant reduction highlights the effectiveness of the strategy in optimizing performance and resource utilization.

[0078] S402, an internal call graph summary retrieval step, determines a dependency path according to the queried TPL location, and retrieves the internal call graph summary on demand based on the dependency path.

[0079] Specifically, the dependent path of obtaining the TPL position to be retrieved specifically includes:

[0080] A reverse search is initiated from the location of the queried TPL, traversing all upper-level call nodes, and finally reaching the software project. The dependency path is composed of all dependent nodes in the traversal process, where the software project is the starting node, the queried TPL is the ending node, and the remaining TPLs in the traversal process are transition nodes.

[0081] Specifically, in S401, the call graph summary of the TPL used by the software project P is obtained. However, for a reachability query, loading the call graph summaries of all TPLs at once may generate significant overhead. Therefore, it is necessary to determine a dependency path based on the location of the queried TPL, and then retrieve the call graph summary on demand based on this path.

[0082] like Figure 1 As shown, assuming that M t is a risky method bar_c in the third-party library C, then all TPLs from software project P to C constitute this dependency path D p , where A represents the transition node and C is the terminal node.

[0083] Furthermore, Fig. 9 Algorithm 3 presented here illustrates the process of retrieving summaries on demand by calling Figure 6 The procedure presented in Algorithm 2 generates a call graph summary for each TPL in advance and then generates a call graph summary for each TPL that the software project P depends on and a specific query target set M. T (i.e., risk method set) retrieves the call graph summary. First, a dependency tree containing software project P and its sub-dependencies is constructed. Then, according to M T , find the dependency path D on the dependency tree p Finally, different types of call graph summaries are retrieved based on the location of the TPL node on the dependency path. For transition nodes, only S o ; For the terminal node, only S i According to D p node properties to get different call graph summaries.

[0084] for Figure 1 For the query pair (foo, bar_c) in , the dependency path points from A to C. A is the transition node, and C is identified as the terminal node because C contains the target risk method bar_c. For node A, we only need to pay attention to its S o part, so that we can understand the methods from other TPL that foo_a can reach, which is consistent with side ⑨ and As for the other edges of A, they are irrelevant to the current query. As for node C, its S i Information is used to determine all internal methods that foo_c can reach, especially edge⑧. By locking these specific summary information, not only can the query be executed efficiently, but the consumption of storage resources can also be effectively controlled.

[0085] In this step, the optimization strategy adopted is to first build a dependency path and accurately retrieve the call graph summary based on the position of the TPL node on this path. The advantage of this approach is that it can focus on the necessary summaries required for the query method and its transition path in the project structure, thereby reducing storage requirements and computing costs.

[0086] On-demand retrieval of summaries optimizes query efficiency by streamlining the data retrieval process of TPL nodes. By limiting the detailed internal call graph requirements to endpoint nodes and using an external graph structure to represent transition nodes, the complexity of data management is reduced, which significantly speeds up the execution of reachability queries.

[0087] like Fig.10 As shown, using on-demand summary retrieval, the total storage requirement is significantly reduced by 55.82%.

[0088] S403, a reachability analysis step, determines a reachable path from the source method set to the target method set based on the internal call graph summary retrieved by the dependency path.

[0089] The constructing of a reachable path from the source method to the target method specifically includes:

[0090] A source method set and a target method set for determining whether a path exists are received, a call graph summary retrieved from a dependent path is merged with the source method set, and a set of all paths from the source method to the target method is obtained.

[0091] In step S402, according to the query target method set M T The TPL where the call graph summary S is retrieved on the dependency path i and S o On this basis, if Fig.11 Algorithm 4 is presented to describe the reachability analysis process. It is worth noting that if there are multiple paths, a p Run Algorithm 4 once. Initially, the input includes the source method set M S and the target method set M T , dependency path D p , and the internal call graph summary S retrieved on demand in S402 i and S o Next, for D p The transition node in S o , and S o With M S Collection merge to obtain S This process will be repeated until the end node is reached, at which time S i Then, the iteratively expanded reachable method set M S With S i Merge to finally determine the complete set R of all reachable method paths.

[0092] exist Figure 1 In the example, consider bar_c as the query target method set M T Risk methods within. Query source method set M S It consists of two methods in the project. Dependency path D p It extends from TPL A to TPL C. The first node in the path is TPLA, which is a transition node. Figure 7 S of matrix 2 o Based on the analysis of the project, method foo can reach foo_a in TPL A, but bar does not call any method in A.S With S o Combined, we get the updated M S , which contains methods bar_b and foo_c that can be propagated to the next node. The next node in the path, TPL C, is a terminal node, so the search Figure 7 S of matrix 2 i part. The updated M S With S i After combining, it is finally confirmed that risk method bar_c can be reached. Therefore, it is concluded that risk method bar_c is reachable from the perspective of the project.

[0093] In summary, reachability analysis makes full use of pre-computed call graph summaries to accelerate the determination of node reachability. The method of the present invention significantly reduces computational overhead and improves query efficiency by utilizing summary information on dependency paths, and can perform complex reachability checks faster, thereby optimizing the entire analysis process.

[0094] The evaluation will be carried out through specific experiments as follows.

[0095] The experimental dataset is 147 active Maven projects collected from GitHub. Each project has been forked and starred more than 20 times and has been updated in the past year. For each Maven project, four dependency paths are randomly selected. On each path, 2,500 APIs are randomly selected as source methods. s , and select another 2,500 APIs as target methods M t This selection yielded a total of 4 × 2500 per project. 2 And this dataset is named ReachBench.

[0096] Fig.12The execution time of the method ReachCheck of the present invention for querying API reachability in 147 Maven projects is demonstrated. Specifically, the average query time of ReachCheck per project is 138.60 milliseconds, which is consistent with previous studies, indicating that the detection time of the IDE plug-in should be in the range of seconds or even milliseconds. After randomly updating the TPL version in ReachBench, ReachCheck was used again for reachability analysis. The results show that the average query time of ReachCheck dropped to 106.85 milliseconds, an increase of about 23%. The reason is that after the TPL version was randomly modified, ReachCheck had already obtained the corresponding graph data of the unchanged TPL during the initial reachability analysis. When performing the reachability analysis again, there is no need to reload the existing information, only the graph data of the changed TPL needs to be loaded. After completing all queries, it can be found that the method of the present invention only increases the storage overhead by 1.81% compared with the corresponding TPL package size.

[0097] like Fig.13 As shown, the graph reachability analysis method (ReachCheck) for combined calls of third-party libraries of the present invention is demonstrated in the ReachBench dataset relative to the query time of FERRARI, BL, BFL (FERRARI, BL, BFL are three cutting-edge graph indexing technologies) and online traversal algorithms. Specifically, the average speedup ratios of ReachCheck relative to FERRARI, BL, BFL and online traversal algorithms are 78.67 times, 5264.54 times, 74.66 times and 187.56 times, respectively. The main reason for this significant improvement is that ReachCheck utilizes a pre-built transitive closure (TC) index based on project dependencies, which enables the indexes of each TPL to be efficiently combined, thereby supporting fast reachability queries. In contrast, existing graph indexing algorithms often take a lot of time to build a complete call graph, a process that involves merging the call edges of all TPLs.

[0098] Furthermore, even if the time overhead of merging call edges is eliminated, ReachCheck still shows a significant acceleration effect in comparison with other algorithms, achieving a speedup ratio of 8.23 ​​times, 5194.10 times, 4.22 times, and 187.56 times respectively. These empirical results strongly support the significant advantages of ReachCheck.

[0099] like Fig.14 As shown, this embodiment also discloses a graph reachability analysis device for third-party library combination calls, including:

[0100] The internal call graph summary generation module 1401 is used to obtain the software project and the TPL used by the software project, obtain the call edges from the internal call graph of the TPL used by the software project, and perform a refinement strategy on the call edges to obtain a reachability summary;

[0101] The internal call graph summary retrieval module 1402 is used to receive the TPL position to be retrieved, obtain the dependency path of the TPL position to be retrieved, and retrieve the internal call graph summary based on the dependency path;

[0102] The reachability analysis module 1403 is used to construct a reachable path from the source method to the target method based on the internal call graph summary retrieved by the dependency path.

[0103] The specific implementation of a graph reachability analysis device for third-party library combination calls is the same as the graph reachability analysis method for third-party library combination calls, and this embodiment will not be repeated.

[0104] Although the present invention has been specifically shown and described in conjunction with the preferred embodiments, it should be understood by those skilled in the art that various changes may be made to the present invention in form and details without departing from the spirit and scope of the present invention as defined by the appended claims, all of which are within the scope of protection of the present invention.

Claims

1. A graph reachability analysis method for third-party library combination calls, characterized in that: include: Internal call graph summary generation step, analyzing the software project and the third-party library TPL it uses; For each TPL, collect all call edge information, and generate an internal call graph summary based on the call edge information through transitive closure calculation; The internal call graph summary retrieval step determines a dependency path based on the queried TPL location and retrieves the internal call graph summary on demand based on this dependency path; The reachability analysis step determines the reachable paths from the source method set to the target method set based on the internal call graph summary retrieved by the dependency path.

2. The graph reachability analysis method for third-party library combination calls according to claim 1 is characterized in that: The internal call graph summary generation step specifically includes: Extract internal call edges and external call edges from the internal call graph and use the internal call edges to build a calculation matrix When the result matrix equal When the calculation is finished, eliminate Corresponding to the unreachable methods in TPL, get the reachability of all accessible methods in TPL to other TPL external methods.

3. The graph reachability analysis method for third-party library combination calls according to claim 2 is characterized in that: The internal call edge represents a call relationship formed between a caller and a callee, wherein both the caller and the callee are internally defined methods of a software project or a TPL used by the software project; The external call edge represents a call relationship formed between a caller and a callee, wherein the caller is a software project or an internally defined method of TPL used by the software project, and the callee is a software project or an externally defined method of TPL used by the software project.

4. The graph reachability analysis method for third-party library combination calls according to claim 1, characterized in that: The internal call graph summary includes an internal summary and an external summary; the internal summary represents each accessible method m s Can directly or indirectly call another internal method m t ; The external summary represents each accessible method m s Can directly or indirectly call other TPL defined methods m t .

5. The graph reachability analysis method for third-party library combination calls according to claim 1, characterized in that: The internal call graph summary retrieval step specifically includes: Build a dependency tree containing the software project and its sub-dependencies, find the dependency path on the dependency tree based on the location of the query target collection, and retrieve the internal call graph summary based on the location of the TPL node on the dependency path.

6. The graph reachability analysis method for third-party library combination calls according to claim 5, characterized in that: The search dependency path specifically includes: A reverse search is initiated from the location of the queried TPL until all upper-level nodes are traversed and finally the software project is reached. All dependent nodes traversed during the search process together constitute a dependency path, in which the software project is the starting node, the queried TPL is the ending node, and other traversed TPLs are transition nodes.

7. The graph reachability analysis method for third-party library combination calls according to claim 1, characterized in that: The reachability analysis step specifically includes: Receive the queried source method set, target method set, dependency path and the internal call graph summary retrieved on demand based on the dependency path, load the external summary for the transition node in the dependency path, and merge the loaded external summary with the source method set to obtain the iteratively expanded reachable method set, obtain all the end points that can be reached from the source method set until the termination node is reached, then load the internal summary, merge the iteratively expanded reachable method set with the internal summary, and determine the complete set of all reachable target method sets.

8. A graph reachability analysis device for third-party library combination calls, characterized in that: include: Internal call graph summary generation module for analyzing software projects and the third-party libraries they use, TPL; For each TPL, collect all call edge information, and generate an internal call graph summary based on the call edge information through transitive closure calculation; An internal call graph summary retrieval module is used to determine a dependency path based on the queried TPL location and retrieve the internal call graph summary on demand based on the dependency path; The reachability analysis module is used to determine the reachable path from the source method set to the target method set based on the internal call graph summary retrieved by the dependency path.

Images