A method and device for third-party library combination call-oriented graph reachability analysis

Abstract

The application relates to a kind of third-party library combination calling oriented graph reachability analysis method and device, method includes: through internal calling graph abstract generation step, the calling edge of software project and TPL is extracted, internal calling edge and external calling edge are distinguished, reachability abstract is generated by eliminating unreachable method in TPL using refining strategy through matrix operation;Through internal calling graph abstract retrieval step, the TPL position of to-be-retrieved is received, the dependent path thereof is determined by reverse search, and the dependent node link from software project to the TPL queried is constituted;In reachability analysis step, the calling graph abstract retrieved by dependent path is combined with the source method set to be judged, and the reachability path set from source method to target method is constructed.The application optimizes the generation and retrieval process of calling graph abstract, is suitable for processing complex software project containing a large number of TPL, and effectively improves the efficiency of third-party library combination calling oriented graph reachability analysis.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software engineering, and particularly relates to a graph reachability analysis method for third-party library combination calling. BACKGROUND

[0002] Call graph reachability analysis aims to determine whether a particular method can directly or indirectly call a target method. This is a fundamental program analysis problem, and the practicality of its solution can make it efficiently applied in diversified 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 vulnerability methods in third-party libraries. The path reachability analysis from the application code to the third-party library methods with security risks in the call graph reveals the 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 reduction, also rely to a large extent on call graph reachability analysis as an important cornerstone to support specific applications.

[0003] Although the research on call graph reachability analysis has been for decades, the research on implementing this analysis in integrated development environments is significantly scarce. Precise and efficient call graph reachability analysis during the development phase enables developers to proactively identify potential problems related to software security and quality, and thus take preventive measures at an early stage of the project. However, it is quite challenging to achieve this goal, especially the strict time limit in integrated development environments that usually requires the analysis task to be completed within milliseconds or seconds. Existing technologies usually first construct a call graph, and then traverse the graph using a depth-first search (DFS) or breath-first search (BFS) algorithm. However, when dealing with large call graphs, such analysis inevitably accompanies significant time costs. In a preliminary study of 15 Java open source projects, the DFS or BFS-based method takes an average of 327.93 seconds to process reachability queries in a real call graph containing 198,082 call edges and 24,618 methods. Therefore, accelerating the process of call graph reachability analysis is likely to bring substantial benefits and efficiency improvements to various program analysis functions in integrated development environments.

[0004] According to published research literature, using index mechanisms of 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 depends on the stability assumption of the graph structure, while in the development process, the graph structure in the integrated development environment is often unstable. Specifically, adding, deleting and replacing third-party libraries in the integrated development environment is a common operation, 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. In order to solve this problem, an intuitive idea is to construct an index for each third-party library (TPL) through offline analysis, and then combine these indexes online as needed to perform call graph reachability analysis. However, simply combining the call graph index of the third-party library with the project internal index is not enough to build a comprehensive index system that covers the project and TPL methods comprehensively, which significantly hinders the ability and flexibility of accelerating call graph reachability analysis in environments involving third-party libraries. SUMMARY

[0005] In order to solve the above problems, the present application provides a method and device for analyzing the graph reachability of third-party library combined 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 scheme is as follows:

[0007] On the one hand, a method for analyzing the graph reachability of third-party library combined calls, comprising:

[0008] An internal call graph abstract generation step analyzes a software project and its used third-party libraries TPL; for each TPL, all call edge information is collected, and an internal call graph abstract is generated based on the call edge information through a transitive closure calculation;

[0009] An internal call graph abstract retrieval step determines a dependency path according to the position of the queried TPL, and retrieves the internal call graph abstract on demand based on the dependency path;

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

[0011] Preferably, the internal call graph abstract generation step specifically comprises:

[0012] Extracting internal call edges and external call edges from the internal call graph, and using the internal call edges to build a calculation matrix When the result matrix is equal to When the calculation ends, the elimination is removed The reachability of all the accessible methods in the TPL to the other TPL external methods is obtained in correspondence with the methods in the TPL that are not reachable.

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

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

[0015] Preferably, the internal calling graph abstract includes an internal abstract and an external abstract; the internal abstract represents each accessible method m s may directly or indirectly call another internal method m t ; the external abstract represents each accessible method m s may directly or indirectly call another TPL defined method m t .

[0016] Preferably, the internal calling graph abstract retrieving step specifically includes:

[0017] A dependency tree containing the software project and its sub-dependencies is constructed, a dependency path is found on the dependency tree according to the position of the query target set, and the internal calling graph abstract is retrieved based on the position of the TPL node on the dependency path.

[0018] Preferably, the dependency path finding step specifically includes:

[0019] A reverse search is initiated from the position of the queried TPL, and the search is performed until all the upper nodes are traversed and finally the software project is reached, wherein all the dependency nodes traversed in the search process collectively constitute the dependency path, the software project is the starting node, the queried TPL is the terminal node, and the other traversed TPLs are the transition nodes.

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

[0021] receive the queried source method set, target method set, dependency path and internal call graph summary retrieved on demand based on the dependency path, load external summary for the transition node in the dependency path, and combine the loaded external summary with the source method set to obtain iteratively expanded reachable method set, obtain all endpoints reachable from the source method set until a termination node is reached, load internal summary again, combine the iteratively expanded reachable method set with the internal summary, and determine the complete set of all reachable target method sets.

[0022] In another aspect, a graph reachability analysis device for third-party library combination calling comprises:

[0023] An internal call graph summary generation module is configured to analyze a software project and third-party libraries (TPLs) used by the software project, collect all call edge information for each TPL, and generate an internal call graph summary based on the call edge information through transitive closure calculation.

[0024] An internal call graph summary retrieval module is configured to determine a dependency path according to a queried TPL position, and retrieve an internal call graph summary based on the dependency path.

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

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

[0027] (1) The present application is used to process the reachability of queried 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 these summaries are combined with application code on demand, thereby avoiding redundant analysis of third-party libraries to accelerate the analysis.

[0028] (2) The present application introduces the 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, further improves the efficiency of the analysis process, and enables more rapid and accurate reachability determination for complex call relationships, thereby enhancing its usability and response speed in actual development environments.

[0029] (3) The application greatly reduces the calculation amount and time cost of each query by pre-generating call graph abstracts for each third-party library (TPL) and retrieving these abstracts on demand according to the query target; experimental results show that, compared with existing graph indexing technologies and online traversal algorithms, the average speedup ratio of the application is as high as hundreds to thousands of times, which not only greatly improves the speed in processing call graph reachability queries in large software projects, but also effectively deals with complex project structures and large-scale data sets; the significant improvement in efficiency is of great significance for promoting rapid feedback and problem positioning in the software development process;

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

[0031] Figure 1 Two call graph type schematic diagrams for the heuristic code example of the application;

[0032] Figure 2 A software project syntax schematic diagram for the example of the application;

[0033] Figure 3 A heuristic code example diagram for the example of the application;

[0034] Figure 4 A graph reachability analysis method flowchart for the third-party library combination call of the example of the application;

[0035] Figure 5 A method framework diagram for the example of the application;

[0036] Figure 6 An algorithm schematic diagram for obtaining internal call graph abstracts for the example of the application;

[0037] Figure 7 A matrix for the heuristic code example of the example of the application;

[0038] Figure 8 An effect diagram of call edge reduction for the example of the application;

[0039] Figure 9 An algorithm schematic diagram for on-demand retrieval of abstracts for the embodiment of the application;

[0040] Figure 10 A total storage usage schematic diagram when analyzing a software project for the example of the application;

[0041] Figure 11 A reachability analysis algorithm schematic diagram for the example of the application;

[0042] Figure 12Time diagram for the execution of the method of the embodiment of the present application;

[0043] Figure 13 Speed improvement ratio diagram of the method of the embodiment of the present application compared with other algorithms;

[0044] Figure 14 Structural block diagram of a graph reachability analysis device for third-party library combination calling of the embodiment of the present application. DETAILED DESCRIPTION

[0045] The present application will be further described in conjunction with the embodiments and the accompanying drawings, but the embodiments of the present application are not limited thereto.

[0046] In order to significantly reduce the time required for graph reachability analysis, the present application provides a graph reachability analysis method for third-party library combination calling, which covers two stages of offline and online analysis. In the offline analysis stage, calling graph analysis is performed for each TPL, aiming to collect all calling edge information and generate summary data for disk storage. In the online analysis stage, when facing a calling graph reachability query, the on-demand retrieval strategy is adopted to efficiently retrieve the summary information of the relevant TPL from the disk, which significantly reduces the computational burden and improves the overall analysis efficiency.

[0047] In the offline analysis stage, the transitive closure (TC) is proposed, which encodes the reachability information between all nodes as summary data. Unlike existing graph indexing techniques, TC can directly answer the question of which nodes can be reached from a specified node in the calling graph, thereby helping to build the association between different third-party libraries. For example, in the calling graph of the example code shown in Figure 1 In the calling graph of the example code shown in FIG. 1, for the third-party library A, the initial input contains all edge information within the library, including edges ③-⑦. After TC calculation, it is determined that foo_a can reach baz_a and foo_c, which correspond to edges ⑩ and Edge ①1 is identified as the connection edge between the third-party libraries A and C. Through the identification of these edges, the connection between the libraries is established, and further network relationships with other libraries are formed.

[0048] For reachability queries involving third-party libraries within a project, the summary information of the relevant TPL is dynamically retrieved according to the requirements, thereby accurately determining the reachability relationship. Instead of indiscriminately loading all TPLs, the present application discriminates 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 combination analysis. This design strategy significantly reduces the time overhead. Taking Figure 1For example, to determine whether a host project can reach the risk method in TPL C, only the abstract information of the third-party libraries A and C directly involved in the path from the host to the bar_c method is loaded, thereby achieving efficient analysis.

[0049] Further, the program syntax is first described, then the call graph model applicable to the application program using the third-party library is constructed, and finally the call graph reachability problem is defined.

[0050] (1) Program syntax

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

[0052] In each source code file F, at least one method M is defined; the method M is composed of a modifier, a fully qualified name, and a series of statement representations, wherein the modifier indicates the accessibility of the method, i.e., whether the method is public, protected, or private.

[0053] (2) Call graph model

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

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

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

[0057] Internal call edge iff m s and m t are both methods defined in the software project P, i.e., m s ∈ M i , m t ∈ M i .

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

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

[0060] The internal call graph follows the standard definition of the caller-callee relationship. In the library-aware program analysis, the program constructs in the TPL also need to be analyzed. Therefore, a second call graph model is introduced to provide a global perspective for analyzing the reachability problem of the inter-project call graph using TPL.

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

[0062]

[0063] In essence, the global call graph is spliced from the internal call graphs of the project and its used TPLs. In particular, the external call edges in each internal call graph depict the caller-callee relationship between the software project and the TPL. It is worth noting that all methods derived from function calls in the software project and the TPL, as well as the corresponding caller-callee pairs, are completely encoded in the global call graph. Therefore, in the case of library awareness, the global call graph can serve as a basic component for checking the reachability of the call graph.

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

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

[0066] As described in Definitions 1 and 2, the call graph model is an important intermediate representation of projects using the TPL. By performing specific downstream client analysis on the call graph model, it is possible to understand how a method in the current project calls a method in the 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 the TPL, vulnerabilities that may arise from the use of an insecure TPL can be detected through call graph analysis. Therefore, determining whether one method can directly or indirectly call another method is a fundamental problem. This problem can be formulated as the call graph reachability problem, as follows.

[0067] Definition 3. (Call Graph Reachability Problem) For a series of third-party libraries... A software project P (where n≥1) and source methods m in software project P. s and target method m t The global call graph needs to be calculated. And determined in Does there exist from m? s to m t The path p.

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

[0069] S401, Internal Call Graph Summary Generation Steps: Analyze the software project and its third-party libraries (TPLs); 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.

[0070] Existing graph indexing algorithms struggle to adapt to changes in the call graph caused by dependency tree variations during software development. To reduce the overhead of analyzing TPLs, we utilize the observation that any change in the dependency tree does not alter the reachability of a specific TPL's call graph. Therefore, by summarizing the reachability relationships of TPL methods, we can further reuse these relationships when analyzing projects using the TPL, enabling efficient evaluation of the reachability between any two methods in a project and a TPL. To this end, 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) Suppose the internal call graph of a software project or TPL is G = (M i ∪M o ,E), where M i and M oThe definition is as described in Definition 1. Its internal call graph summary S is a tuple (S... i ,S o ),in:

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

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

[0074] like Figure 1 As shown, the method foo_a contains two direct call edges (③ and ⑤), and the indirect call edge ⑩ can be computed transitively through ③ and ④. Similarly, two indirect call edges ⑨ and ⑨ can be computed. These reachable methods are recorded in foo_a to create a call graph summary. This summary allows for a quick determination of which methods foo_a can reach. Among these, methods ③, ⑤, and ⑩ belong to S. i And ⑨ and Belongs to S o .

[0075] Figure 6 Algorithm 2 presented describes the computation process of the inner call graph summary. First, the inner call edges E are extracted from the input inner call graph. i and external call edge E o Then, a refinement strategy is applied to the calling edge, that is, using the internal calling edge E. i Constructing computational matrices Applying a refinement strategy to the calling edge significantly reduces the computational overhead during transitive closure (TC) computation and saves processing time. When the result matrix... equal The calculation ends when [the time is reached]. This is achieved by eliminating [the following]. The rows corresponding to unreachable methods within the TPL reduce storage requirements. Finally, S i With E o By combining these, we obtain the reachability of all methods accessible within a TPL to methods outside of other TPLs, denoted as S. o .

[0076] by Figure 1Taking the third-party library A as an example, we calculate its call graph summary. First, a matrix is ​​constructed from all the internal call edges in third-party library A, specifically, the call relationships from method foo_a to qux_a (a 4×4 matrix), as shown below. Figure 7 The matrix is ​​shown in matrix 1. Then, matrix multiplication is used to obtain the final result matrix. 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 labeled as S in matrix 2. i Next, by connecting the external call edges, namely the edges numbered 6 and 7, with S... i By combining these, a 1×2 submatrix in matrix 2 was calculated. This submatrix contains the calling relationships from foo_a to bar_b and foo_c. This submatrix is ​​labeled S. o .

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

[0078] S402, Internal Call Graph Summary Retrieval Step: Determine a dependency path based on the location of the queried TPL, and retrieve the internal call graph summary as needed based on this dependency path.

[0079] Specifically, the dependency path for obtaining the location of the TPL to be retrieved includes:

[0080] Starting from the position of the queried TPL, a reverse search is initiated, traversing all parent call nodes, and finally reaching the software project. The dependency path is composed of all the dependency nodes in the traversal process, where the software project is the starting node, the queried TPL is the ending node, and the other TPLs in the traversal process are transition nodes.

[0081] Specifically, in S401, a call graph summary of the TPLs used by software project P is obtained. However, loading the call graph summaries of all TPLs at once can incur significant overhead for a single reachability query. Therefore, a dependency path needs to be determined based on the location of the queried TPL, and then call graph summaries are retrieved on demand based on this path.

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

[0083] Further, Figure 9 Algorithm 3 presents the procedure of on-demand retrieval of summaries, by invoking Figure 6 Algorithm 2 presents the procedure of pre-generating invocation graph summaries for each TPL, and then retrieving invocation graph summaries for the TPLs depended by the software project P and the specific query target set M T (i.e., the risk method set) is retrieved. First, a dependency tree containing the software project P and its sub-dependencies is constructed. Then, according to the location of M T , the dependency path D p is searched on the dependency tree. Finally, based on the location of the TPL nodes on the dependency path, different types of invocation graph summaries are retrieved. For the transition nodes, only S o is used; while for the terminal nodes, only S i is used. Different invocation graph summaries are obtained according to the node attributes of D p .

[0084] For the query pair (foo, bar_c) in Figure 1 , the dependency path is from A to C. Where A is a transition node, while C is identified as a terminal node because C contains the target risk method bar_c. For node A, only its S o part is concerned, which reveals the methods from other TPLs that foo_a can reach, which is directly related to edges ⑨ and . As for the other edges of A, they are irrelevant to the current query. As for node C, its S i information must be utilized to determine all the internal methods that foo_c can reach, especially edge ⑧. By locking these specific summary information, not only the query can be performed effectively, but also the storage resource consumption can be controlled effectively.

[0085] In this step, the optimization strategy is to construct a dependency path first, and then retrieve invocation graph summaries according to the location of TPL nodes on this path. The advantage of this approach is that it can focus on the necessary summaries of the query method and its transition path in the project structure, thereby reducing the storage requirements and computational cost.

[0086] On-demand retrieval of summaries optimizes the query efficiency by simplifying the data retrieval process of TPL nodes. By limiting the detailed internal invocation graph requirements to endpoint nodes and using external graph structures to represent transition nodes, the data management complexity is reduced, thereby significantly accelerating the execution speed of reachability queries.

[0087] As shown in Figure 10 , using on-demand retrieval of summaries, the total storage requirement is greatly reduced by 55.82%.

[0088] S403, reachability analysis step, based on the internal call graph summaries retrieved from the dependency paths, determine the reachable paths from the source method set to the target method set.

[0089] The construction of the reachable paths from the source methods to the target methods specifically includes:

[0090] Receiving the source method set and the target method set to be determined whether there is a path, merging the call graph summaries retrieved from the dependency paths with the source method set to obtain the path set that can reach the target method from the source method.

[0091] In step S402, according to the query target method set M T , the call graph summaries S i and S o are retrieved on the dependency path. On this basis, as Figure 11 The algorithm 4 presented describes the reachability analysis process. It is worth noting that if there are multiple paths, algorithm 4 will be run once for each dependency path D p Initially, the input includes the source method set M S and the target method set M T , the dependency path D p , and the internal call graph summaries S i and S o retrieved as needed in S402. Next, for the transition nodes in D p , load S o , and merge S o with M S set to obtain all endpoints that can be reached from M S . This process will continue until the end node is reached, at which time S i is loaded. Then, the iteratively expanded reachable method set M S is merged with S i to finally determine the complete set R of all reachable method paths.

[0092] In Figure 1 , consider bar_c as a risk method within the query target method set M T . The query source method set M S is composed of two methods in the project. The dependency path D p extends from TPL A to TPL C. The first node in the path is TPL A, which is a transition node. Therefore, the analysis is performed using the S o part of matrix 2 in Figure 7 . Based on the analysis of the project, method foo can reach foo_a in TPL A, while bar does not call any method in A. MS S o , resulting in an updated M S containing the methods bar_b and foo_c that can be propagated to the next node. The next node in the path, TPL C, is a sink node, so the method bar_b is retrieved Figure 7 S i part of matrix 2 in S . After combining the updated M i with S s , it is finally confirmed that the risk method bar_c is reachable. Thus, it is concluded that the risk method bar_c is reachable from the project.

[0093] In summary, the reachability analysis makes full use of the pre-computed call graph summaries to accelerate the determination of node reachability. By utilizing the summary information on the dependency path, the proposed method significantly reduces the computational overhead and improves the query efficiency, enabling faster execution of complex reachability checks and thus optimizing the entire analysis process.

[0094] The following will be evaluated through specific experiments.

[0095] The experimental dataset consists of 147 active Maven projects collected from GitHub, each with more than 20 forks and stars and updated within 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 M s , and another 2,500 APIs are selected as target methods M t . This selection results in a total of 4x2500 2 queries per project. This dataset is named ReachBench.

[0096] Figure 12The execution time of ReachCheck in the present application method is shown in the API reachability query of 147 Maven projects. 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 seconds or even milliseconds. After updating the TPL version in ReachBench at random, the reachability analysis is performed again using ReachCheck. The results show that the average query time of ReachCheck decreases to 106.85 milliseconds, which increases by about 23%. The reason is that after the random modification of the TPL version, ReachCheck has obtained the corresponding graph data of the unchanged TPL in the initial reachability analysis. When performing the reachability analysis again, there is no need to reload these existing information, but only to load the graph data of the changed TPL. After completing all queries, it can be found that the present application method only increases 1.81% of the storage overhead compared with the corresponding TPL package size.

[0097] As shown in Figure 13 , the speedup ratio of the graph reachability analysis method (ReachCheck) of the present application for third-party library combined calls on the ReachBench dataset relative to FERRARI, BL, BFL (FERRARI, BL, BFL are three leading graph indexing technologies) and online traversal algorithm query time is shown. Specifically, the average speedup ratio of ReachCheck relative to FERRARI, BL, BFL and online traversal algorithm is 78.67 times, 5264.54 times, 74.66 times and 187.56 times, respectively. The main reason for this significant improvement is that ReachCheck uses a pre-built transitive closure (TC) index based on project dependencies, which enables efficient combination of indexes of various TPLs, thereby supporting fast reachability queries. In contrast, existing graph indexing algorithms often need to spend a lot of time to build a complete call graph, which involves merging all TPL call edges.

[0098] Further, even if the time overhead required to merge the call edges is excluded, ReachCheck still exhibits significant speedup in comparison with each algorithm, achieving speedup ratios 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] As shown in Figure 14 , the present embodiment also discloses a graph reachability analysis device for third-party library combined calls, comprising:

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

[0101] The internal call graph abstract retrieval module 1402 is configured to receive a TPL position to be retrieved, obtain a dependency path of the TPL position to be retrieved, and retrieve an internal call graph abstract based on the dependency path.

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

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

[0104] Although the present application is specifically shown and introduced in combination with the preferred embodiments, it should be understood by those skilled in the art that various changes can be made in form and details without departing from the spirit and scope of the present application defined in the appended claims, and all such changes are within the protection scope of the present application.

Claims

1. A graph reachability analysis method for third-party library composite calls, characterized in that, include: Internal call graph summary generation steps, 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 by calculating the transitive closure. The internal call graph digest retrieval step involves determining a dependency path based on the location of the queried TPL, and then retrieving the internal call graph digest as needed based on this dependency path. The reachability analysis step determines the reachable path from the source method set to the target method set based on the internal call graph summary retrieved from the dependency path. The reachability analysis steps specifically include: The system receives the source method set, target method set, dependency path, and internal call graph summary retrieved on demand based on the dependency path. For transition nodes in the dependency path, the system loads the external summary and merges the loaded external summary with the source method set to obtain the iteratively expanded reachable method set. It obtains all endpoints that can be reached from the source method set until the terminal node is reached. Then, the system loads the internal summary and merges the iteratively expanded reachable method set with the internal summary to determine the complete set of all reachable target method sets.

2. The graph reachability analysis method for third-party library composite calls according to claim 1, characterized in that, The internal call graph digest generation step specifically includes: Extract internal call edges and external call edges from the internal call graph, and use the internal call edges to construct the computation matrix. When the result matrix equal The calculation ends, then the elimination occurs. The value corresponds to the unreachable method within the TPL, and the reachability of all accessible methods within the TPL to other methods outside the TPL is obtained.

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

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

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

6. The graph reachability analysis method for third-party library composite calls according to claim 5, characterized in that, The search for dependency paths specifically includes: The search proceeds backward from the location of the queried TPL until all parent nodes are reached, eventually arriving at the software project. All dependent nodes traversed during the search process together constitute the dependency path, with the software project as the starting node, the queried TPL as the ending node, and other traversed TPLs as transition nodes.

7. A graph reachability analysis device for third-party library composite calls, characterized in that, include: Internally calls the graph summary generation module to analyze software projects 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 by calculating the transitive closure. The internal call graph digest retrieval module is used to determine a dependency path based on the location of the queried TPL, and retrieve the internal call graph digest on demand based on this 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 from the dependency path; The reachability analysis module is specifically used for: The system receives the source method set, target method set, dependency path, and internal call graph summary retrieved on demand based on the dependency path. For transition nodes in the dependency path, the system loads the external summary and merges the loaded external summary with the source method set to obtain the iteratively expanded reachable method set. It obtains all endpoints that can be reached from the source method set until the terminal node is reached. Then, the system loads the internal summary and merges the iteratively expanded reachable method set with the internal summary to determine the complete set of all reachable target method sets.

Images