Method and system for detecting third-party library in application program based on class dependency graph
Through the detection method based on class dependency graph, node feature and semantic matching technology are used to solve the problems of insufficient detection accuracy and insufficient confusion and robustness of existing tools at the version level, and efficient and accurate third-party library detection is achieved, reducing false positive rates and analysis costs.
Patent Information
- Application Number
- CN202510358476.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-25
- Publication Date
- 2025-08-12
AI Technical Summary
Existing third-party library detection tools have insufficient detection accuracy at the version level and are susceptible to obfuscation technologies, resulting in high false positive rates, increased costs and increased difficulty in analytical automation.
The detection method based on the class dependency graph is adopted to construct the class dependency graph, and node features are generated using neighbor node feature aggregation to perform fine-grained semantic matching and structural similarity judgment. Combining the field operation summary and constant feature intersection of the call sequence, third-party libraries and their versions are identified.
It improves the accuracy and robustness of third-party library detection, reduces the false alarm rate, improves the detection speed and anti-confusion ability, and reduces the time overhead of manual review.
Smart Images
Figure CN120470565A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of software engineering and software security, and relates to a method and system for detecting third-party libraries in an application based on a class dependency graph. Background Art
[0002] In Android application development, third-party libraries (3PLs) provide a rich variety of pre-implemented, reusable common functionality, enabling developers to avoid reinventing the wheel. This significantly simplifies the Android app development process and shortens software development and delivery cycles. However, recent security research indicates that 3PLs have become the largest attack surface in applications, and their widespread use raises numerous security and compliance issues. When 3PLs containing vulnerabilities, malicious code, or license conflicts with other 3PLs are integrated into applications, they can harm developers and threaten user privacy and security. Consequently, numerous studies have been proposed to assess and mitigate these threats. For example, the risks of excessive privileges can be mitigated by downgrading 3PL permissions or implementing process isolation for 3PLs. Furthermore, some researchers have utilized function summaries to detect errors in 3PLs, while others have focused on extracting 3PLs to identify and analyze malicious behavior within them and analyzing fraudulent activity in advertising libraries.
[0003] The prerequisite for the above research is to accurately detect third-party libraries in applications. Third-party library detection supports reliable and efficient downstream security and compliance analysis by quickly identifying the third-party libraries and their versions used in applications. Third-party library detection has become a core technology in many commercial software component analysis products. However, existing third-party library detection tools (such as LibScan, LIBLOOM, LibPecker, LibHunter, etc.) still have certain shortcomings, mainly reflected in the following two aspects:
[0004] (1) The accuracy of version-level third-party library detection is insufficient. Current third-party library detection tools usually process each third-party library independently and fail to capture the differences between different versions of the same third-party library. This results in the third-party library detection tool reporting the presence of multiple candidate versions of the third-party library in the application when the differences between different versions are small, resulting in a large number of false positives. These false positives require further manual review, increasing the time and cost of security practitioners and hindering analysis automation. Although existing research has evaluated the version-level detection performance of tools and demonstrated excellent performance, the evaluation metrics used by existing methods are too loose and fail to effectively reflect the true level of version-level detection performance.
[0005] (2) Third-party library detection tools are susceptible to obfuscation. Tools such as LibD and LibID use isomorphic graphs and package structures to decouple modules. These features that rely on package structures are easily affected by obfuscation techniques such as package flattening and repackaging, and the detection performance is significantly reduced. ATVHunter uses a more robust class dependency graph for module decoupling and further uses method-level control flow graphs for fine-grained matching. However, common control flow obfuscation techniques may interfere with the fine-grained detection process. The two most advanced tools, LibScan and LibHunter, use fine-grained instruction opcodes and operands for detection and are extremely vulnerable to obfuscation such as control flow obfuscation and dead code removal.
[0006] Given the importance of third-party library detection technology in the field of software security, there is an urgent need for a third-party library detection tool that can resist most obfuscation techniques and has high version-level accuracy. Summary of the Invention
[0007] In response to the problems of insufficient version-level detection performance of current third-party library detection tools and non-robustness of usage features to obfuscation, the present invention proposes a method and system for detecting third-party libraries within applications based on class dependency graphs, aiming to provide developers, security practitioners and researchers with third-party library detection technology with higher accuracy, fewer false positives and higher robustness to obfuscation technology. The method implements third-party library detection by utilizing rich code structure features and code semantics. On the one hand, the present invention addresses the problem of insufficient version-level detection performance of existing methods, and captures subtle differences between different versions of the same third-party library through carefully designed strategies and auxiliary resource information, gradually filters versions, and finally obtains accurate version information. On the other hand, in response to the problem of insufficient robustness of existing methods to obfuscation, the present method utilizes the robust structural features of the class dependency graph to screen candidate third-party library classes for each application, and achieves class-level precise matching through class state descriptions that are not affected by fine-grained code obfuscation (such as control flow flattening).
[0008] In order to achieve the above-mentioned object of the invention, the present invention adopts the following technical solutions:
[0009] A method for detecting third-party libraries in an application based on a class dependency graph, the steps comprising:
[0010] 1) Analyze the application and third-party libraries to be tested, extract the classes and inter-class dependencies, and build a class dependency graph.
[0011] 2) Using the neighbor node feature aggregation operation, node features are iteratively generated for each node in the class dependency graph;
[0012] 3) Node matching is performed based on the class dependency graph of the application and third-party libraries. For each third-party library node, all application nodes are traversed and the correspondence between classes is established based on the similarity of features between the two nodes.
[0013] 4) Select a class from the class dependency graph of the third-party library for matching, traverse all application classes corresponding to the node, and perform a fine-grained semantic matching process;
[0014] 5) Update the class dependency graph of the third-party library and application based on the matching results (i.e., mark the node in the class dependency graph as successfully matched based on the matching results). Based on the outward diffusion of the currently matched node, select the next node to match, and repeat steps 3) and 4) until all nodes are processed.
[0015] 6) The final detection result is determined based on the structural similarity of the subgraph formed by successfully matching nodes in the class dependency graph of the third-party library and the application; if the similarity is above a threshold, it is determined that the application has integrated the third-party library; otherwise, the application has not integrated the third-party library.
[0016] like Figure 1 As shown in Figure 1, the class dependency graph-based in-application third-party library detection system consists of three modules: the preprocessing module, the class matching module, and the third-party library detection module. The specific functions of each module are as follows:
[0017] 1. Preprocessing module: This module parses the input application and third-party libraries, extracts necessary features, and constructs a class dependency graph (CDG). It then constructs a preliminary correspondence between classes based on the CDG. The specific steps are as follows:
[0018] Step (1.1): Parse the bytecode of the application app and the third-party library lib, extract the class name, modifiers, and the dependencies between classes (including inheritance and implementation relationships) to construct the class dependency graph CDG app (N app ,E app ) and CDG lib (N lib ,E lib Nodes in a class dependency graph represent classes or interfaces, and edges represent class dependencies. Nodes are characterized by class modifiers, and edges are characterized by dependency types.
[0019] Step (1.2): Calculate the depth of the class dependency graph of the third-party library (CDG lib ) as the number of iterations, the features of each node in the class dependency graph of the application and third-party libraries are iteratively calculated by aggregating the features of neighboring nodes and edges.
[0020] Step (1.3): Calculate the application class dependency graph CDG app Node c a and third-party library class dependency graph CDG lib Node c l The feature similarity between them is higher than the threshold T, and a corresponding relationship is established between the nodes <c a ,c l >.
[0021] The depth of the class dependency graph of the third-party library (CDG lib ) reflects the number of iterations required to propagate features between the two farthest nodes in the graph, which is a trade-off between time cost and performance. More iterations may lead to CDG app and CDG lib More similar nodes appear between them, increasing false positives. Fewer iterations lead to insufficient node propagation in the class dependency graph, only utilizing the structural information of the layout, and the reliability of the correspondence is insufficient.
[0022] 2. Class Matching Module: This module performs a fine-grained check on the class correspondence established by the pre-processing module, constructs class matching relationships, eliminates false positives in the correspondence, and provides a foundation for the third-party library detection module. The specific steps are as follows:
[0023] Step (2.1): For unprocessed correspondence <c a ,c l >, based on the instruction opcode set calculation method, the maximum matching strategy is used when the coincidence rate is higher than the threshold T mtd Application class c a Methods and third-party library classes c l Construct a one-to-one mapping M between the methods mtd (c a ,c l ). Extract the access operations of the fields between the methods where mapping exists, and establish a one-to-one mapping relationship between the fields according to the access type (i.e. read or write) and the number of times. fld (c a ,c l ).
[0024] Step (2.2): Randomly sample and construct K method call sequences from the list of third-party library methods with one-to-one mapping And based on the method mapping, generate the corresponding K application class method call sequences
[0025] Step (2.3): Traverse the call sequences of the application class and the third-party library class respectively, identify the operations involved in the field, including initialization, assignment, call and other operations, and extract the parameters, fields, and literals that the field operations depend on to construct the field operation summary of the third-party library and a summary of the field operations for the application Then calculate the similarity Sim(Sum i (c l ),Sum i (c a )), the summary similarity is higher than the threshold T c The sequence is considered a match, and if all K call sequences are successfully matched, it is considered to be an application class c a and third-party library class c l Matches, otherwise does not match.
[0026] Step (2.4): Repeat steps (2.1) to (2.3) until all correspondences are processed.
[0027] 3. Third-party library detection module: This module performs library-level and version-level detection of third-party libraries based on class matching results and class dependency graph structures. Since directly calculating the structural similarity between a small graph (third-party library) and a large graph (application) is an NP-hard problem, this module uses a loose and fast algorithm to indirectly verify the structural similarity of the complete functional module formed by the paths by checking whether the same paths exist in the two graphs. The specific steps are as follows:
[0028] Step (3.1): Extract the third-party library class dependency graph CDG based on the class matching results lib The set of nodes that successfully matched examine Is it possible to form at least one complete path P to a leaf node in the third-party library class dependency graph? lib If P lib If the library does not exist, the third-party library detection process ends. The third-party library lib is not used by the application.
[0029] Step (3.2): If P lib Existence, extract the component path P according to the class matching result lib The application nodes corresponding to the third-party library nodes constitute the application node set In the application class dependency graph CDG app Identify node set Whether it is possible to form at least one complete path P to the leaf node app If P app If the library does not exist, the third-party library detection process ends. The third-party library lib is not used by the application.
[0030] Step (3.3): If P app Exists, calculates the number of method opcodes of all successfully matched third-party library class nodes Accounting for third-party library class dependency graph CDG lib The number of method opcodes for all nodes N in The ratio of , as the confidence of the third-party library recognition, is higher than T G The third-party library lib is recognized as integrated in the application app, otherwise it is not integrated.
[0031] Step (3.4): If there are multiple third-party library versions with a confidence level higher than T G , take the one with the highest confidence as the final version. If there are multiple third-party library versions with the same confidence, extract all successfully matched third-party library classes c l and application class c a The initial values of the fields in the method and the literals used in the method construct the constant feature set I app and I lib , calculate the intersection of the feature sets, and take the version with the largest intersection as the final version of the third-party library.
[0032] Compared with the prior art, the present invention has the following advantages:
[0033] (a) This invention uses a class dependency graph to capture structural information between classes to establish class correspondences. This allows for rapid filtering of structurally dissimilar node pairs, reducing the overhead of fine-grained matching and improving the speed of third-party library detection. Furthermore, the class dependency graph is robust against common obfuscations, effectively preventing potential class correspondences from being missed.
[0034] (b) The present invention uses the field operation summary of the call sequence to represent the semantic information of the class, which is robust to instruction-level obfuscation, can effectively solve the problem of missed reports in class matching, and improve the recall rate of third-party library detection.
[0035] (c) This method uses the intersection size of the constant feature sets of third-party libraries and applications to capture fine-grained differences between third-party library versions, identify the most similar third-party library versions, and effectively reduce version-level false positives. Because this method only differs between different versions of third-party libraries, it is not affected by application obfuscation and has high anti-obfuscation capabilities. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] Figure 1 It is an in-application third-party library detection system based on class dependency graph.
[0037] Figure 2 It is the flowchart of the preprocessing module.
[0038] Figure 3 It is the flow chart of the class matching module.
[0039] Figure 4 This is the flowchart of the third-party library detection module. DETAILED DESCRIPTION
[0040] The present invention will be described in further detail below with reference to the accompanying drawings. The examples given are only used to explain the present invention and are not used to limit the scope of the present invention.
[0041] like Figure 1 As shown in the figure, a third-party library detection system within an application based on a class dependency graph specifically includes three modules: data preprocessing, class matching, and third-party library detection.
[0042] The core of the preprocessing module is to parse the bytecode of the application and third-party libraries and extract the necessary features to build a class dependency graph, and then build a preliminary class correspondence based on the node features calculated on the class dependency graph, such as Figure 2 As shown, the specific steps are as follows:
[0043] 1) Extract the bytecode of the application app and third-party library lib, parse it and build the class dependency graph CDG app (N app ,E app ) and CDG lib (N lib ,E lib ), where nodes represent classes and edges represent dependencies between classes. We extract class modifiers from the bytecode as features of the class nodes. To improve resilience to obfuscation, we only record four types of modifiers that are not affected by obfuscation, as shown in Table 1. We also extract class dependencies as features of the edges.
[0044] 2) Use the depth-first search algorithm to calculate the class dependency graph CDG of the third-party library lib Depth depth (CDG lib ).
[0045] 3) Class dependency graphs (CDGs) for applications and third-party libraries app and CDG lib Calculate node features. For each node c in the graph, perform depth(CDG lib ) iterations to generate node features Γ c :
[0046] a) Aggregate the features of neighbor nodes and embed the edge features in the neighbor node features.
[0047] b) Sort the aggregated features, add the node’s own features at the end, and calculate the fuzzy hash as the node’s new features.
[0048] 4) Get the Cartesian product N of the application node and the third-party library node app ×N lib ={ <c a ,c l >|c a ∈N app ,c l ∈N lib}, for each pair of nodes <c a ,c l >Calculate the similarity of features When the similarity is higher than the threshold T, class c is established. a and c l The correspondence between them.
[0049] The core of the class matching module is to match each pair of nodes with a corresponding relationship. <c a ,c l >Perform fine-grained matching to eliminate false positives in the class correspondences constructed by the data preprocessing module, such as Figure 3 As shown. The successfully matched nodes are updated on the class dependency graph, which is used to ultimately determine the existence of the third-party library based on the overall matching degree of the graph. The specific steps are as follows:
[0050] 1) Given an application class c a and third-party library class c l , extract the opcodes of the methods in the class respectively and where |c a | and |c l | respectively represent application class c a and third-party library class c l The number of methods in . For each c l Methods in Calculate the opcode overlap rate with each application method. Extract all opcodes with an overlap rate higher than the threshold T. mtd The method of Calculate c l 、c a The maximum number of matches between the two sets (i.e., the maximum number of elements between the two sets that establish a one-to-one relationship, which is used to provide a basis for the subsequent generation of call sequences, i.e., through the generated call sequence of the third-party library class, the call sequence of the application class is generated according to the method matching results), and a one-to-one method mapping M is obtained. mtd (c a ,c l ).
[0051] 2) Based on method mapping Mmtd (c a ,c l ) Count the field access operation types and times involved in the method operation code, and establish a one-to-one mapping of the fields in the class M fld (c a ,c l ).
[0052] 3) Randomly sample third-party library class c l The method constructs K method call sequences Mapping M according to the method mtd (c a ,c l )Generate application class c a The calling sequence
[0053] 4) Traverse the call sequence to calculate the field operation hash. When all call sequences are successfully matched, the application class c a and third-party library class c l Match, otherwise not match. Successfully matched application classes and third-party library classes are marked as matched in their respective class dependency graphs. Given a call sequence Seq i (c l ) and Seq i (c a ), the matching steps are as follows:
[0054] a) Traverse the methods in the call sequence of the application and third-party library classes respectively, identify the three types of operations: field initialization, assignment, and call based on the method instructions, extract the parameters, fields, and literals involved in the operation, and generate the operation summary Sum of the call sequence through hashing i (c l ) and Sum i (c a ).
[0055] b) Calculate the similarity of the operation summary of the call sequence If similarity Above the threshold T c , c a and c l Matches, otherwise does not match.
[0056] The core of the third-party library detection module is to perform library-level detection based on the structural similarity of successfully matched application classes and third-party library classes in the class dependency graph and to perform version-level detection by distinguishing the fine-grained feature differences between versions, e.g. Figure 4 The specific steps are as follows:
[0057] 1) Extract the set of successfully matched third-party library class nodes In CDG lib Identification by A path P to a leaf node lib If P lib If it does not exist, the third-party library detection ends.
[0058] 2) If P lib If exists, extract P lib Corresponding application node collection In CDG app Identification by A path P to a leaf node app If P app If it does not exist, the third-party library detection ends.
[0059] 3) If P app If it exists, the third-party library class node that is successfully matched is calculated. The number of opcodes for all methods in And all third-party library class nodes N lib Number of method opcodes in Compute confidence score for opcode match When the confidence score is higher than the threshold T G When the third-party library lib is integrated into the application app, otherwise it is not integrated.
[0060] 4) If there are multiple versions of the third-party library lib {lib 1 ,…,lib v}, select the version with the highest confidence score as the version-level detection result; if the version with the highest confidence score is not unique, for each version of the third-party library, the steps to capture fine-grained differences are as follows:
[0061] a) Extract the node collection of the third-party library The initial value of the field of the class and the literal constant feature set used in the method I lib , extract the application node collection The initial value of the field of the class and the literal constant feature set used in the method I app .
[0062] b) Calculate the intersection size of the application constant features and the third-party library constant features |I lib ∩I app |.
[0063] 5) Select the third-party library version that has the largest intersection with the application's constant features as the final version.
[0064] Table 1. Feature list of nodes and edges in the control class dependency graph
[0065]
[0066] While specific embodiments of the present invention have been disclosed for illustrative purposes, intended to facilitate understanding and implementation of the present invention, those skilled in the art will appreciate that various substitutions, variations, and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the disclosure of the preferred embodiments, and the scope of protection claimed in the present invention shall be determined by the scope of the claims.
Claims
1. A method for detecting third-party libraries in an application based on a class dependency graph, the steps comprising: 1) For the application and third-party library to be tested, extract the classes and inter-class dependencies in the application and build the class dependency graph of the application; Extract the classes and inter-class dependencies in the third-party library and build a class dependency graph for the third-party library; 2) generating corresponding node features for each node in the class dependency graph based on neighbor node features of each node in the class dependency graph; 3) For each node c in the class dependency graph of the third-party library l , computing node c l Each node c in the class dependency graph of the application a The node feature similarity of two nodes c l 、c a The node feature similarity between them establishes the corresponding relationship between the corresponding classes; 4) For each node c in the class dependency graph of the third-party library l , computing node c l With the node c l Establishing semantic matching results for each application class in the corresponding relationship; updating the class dependency graph of the third-party library and the class dependency graph of the application based on the semantic matching results; 5) Verify the structural similarity between the subgraph formed by the successfully matched nodes in the class dependency graph of the third-party library and the subgraph formed by the successfully matched nodes in the class dependency graph of the application. If the structural similarity is greater than the set threshold, it is determined that the application has integrated the third-party library; otherwise, the application has not integrated the third-party library.
2. The method according to claim 1, characterized in that The bytecode of the application is parsed to extract class names, modifiers, and dependencies between classes, and a class dependency graph of the application is constructed. The bytecode of the third-party library is parsed to extract class names, modifiers, and dependencies between classes, and a class dependency graph of the third-party library is constructed. The nodes in the class dependency graph represent classes or interfaces, and the edges in the class dependency graph represent dependencies between classes.
3. The method according to claim 2, characterized in that The node feature is a class modifier, and the edge feature is a dependency type.
4. The method according to claim 3, characterized in that By calculating the depth of the class dependency graph of the third-party library as the number of iterations, the node features of each node in the class dependency graph of the application are iteratively calculated by aggregating the neighbor node features and edge features of each node in the class dependency graph of the application, and the node features of each node in the class dependency graph of the third-party library are iteratively calculated by aggregating the neighbor node features and edge features of each node in the class dependency graph of the third-party library.
5. The method according to claim 1, wherein The method for calculating the semantic matching result is: 41) For two nodes c with corresponding relationship l 、c a , extract c l The opcode of the method Extract c a The opcode of the method Among them, |c a | and |c l | respectively represent c a 、c l The number of methods in c l Each method in Calculate its value with c a The opcode overlap rate of each method in the algorithm; extract all the opcodes whose overlap rate is higher than the threshold T mtd The method of And calculate c l 、c a The maximum number of method pairs matched between them, to obtain a one-to-one method mapping M mtd (c a ,c l ); 42) Based on method mapping M mtd (c a ,c l ) Count the field access operation types and times involved in the method operation code, and establish a one-to-one mapping of the fields in the class M fld (c a ,c l ); 43) Randomly sample K c from the third-party library method list l The method call sequence Mapping M according to the method mtd (c a ,c l ) Generate c a The calling sequence Seq i (c l ) is Article 1c l Method call sequence, Seq i (c a ) is Article 1c a The method call sequence of 44) Traverse the call sequence to calculate the field operation hash, and determine c when all call sequences are successfully matched a and c l Match, otherwise not match; among them, for the method call sequence Seq i (c l ) and Seq i (c a ), the matching steps are as follows: a) traverse the methods in the call sequence of the application and third-party library classes respectively, identify the three types of operations: field initialization, assignment, and call according to the method instructions, extract the parameters, fields, and literals involved in the operation, and generate the method call sequence Seq through hashing i (c l ) and Seq i (c a ) operation summary Sum i (c l ), Sum i (c a ); b) Calculate method call sequence Seq i (c l ) and Seq i (c a )’s operational summary similarity If similarity Above the threshold T c , then c a and c l Matches, otherwise does not match.
6. The method according to claim 1, characterized in that The method for verifying the structural similarity is: 51) Extract the class dependency graph CDG of the third-party library based on the class matching results lib The set of nodes that successfully matched Checking the node collection Class dependency graph CDG in third-party libraries lib Can at least one complete path P to a leaf node be formed? lib ; If P lib If it does not exist, the third-party library detection process ends and it is determined that the third-party library is not used by the application; 52) If P lib If it exists, the component path P is extracted according to the class matching result lib The application nodes corresponding to the third-party library nodes constitute the application node set In the application's class dependency graph CDG app Identify the application node collection in Whether it is possible to form at least one complete path P to the leaf node app ; If P app does not exist, The third-party library detection process ends and it is determined that the third-party library is not used by the application; 53) If P app If it exists, the number of method opcodes of all successfully matched third-party library class nodes is calculated. Accounting for the class dependency graph CDG of third-party libraries lib The number of method opcodes for all nodes N in The ratio is used as the confidence level of the third-party library recognition. If the confidence level is higher than the set threshold T G , It is determined that the third-party library is integrated into the application, otherwise it is not integrated.
7. The method according to claim 6, characterized in that If there are multiple versions of third-party libraries, the confidence level is higher than the set threshold T G , then the third-party library with the highest confidence is taken as the final version; if there are multiple versions of third-party libraries with the same confidence, the initial values of the fields in all successfully matched third-party library classes and the literals used in the methods are extracted to construct the constant feature set I app , extract the initial values of the fields in all successfully matched application classes and the literals used in the methods, and construct the constant feature set I lib ; Then calculate the constant feature set I app and I lib The version with the largest intersection is taken as the final version of the third-party library.
8. A third-party library detection system within an application based on a class dependency graph, characterized in that: Including preprocessing module, class matching module and third-party library detection module; The preprocessing module is used to extract the classes and inter-class dependencies in the application to be detected and the third-party library integrated therein, and construct a class dependency graph of the application; extract the classes and inter-class dependencies in the third-party library and construct a class dependency graph of the third-party library; and then generate corresponding node features for each node in the class dependency graph based on the neighbor node features of each node in the class dependency graph; Then for each node c in the class dependency graph of the third-party library l , computing node c l Each node c in the class dependency graph of the application a The node feature similarity of two nodes c l 、c a The node feature similarity between them establishes the corresponding relationship between the corresponding classes; The class matching module is used to match each node c in the class dependency graph of the third-party library. l , computing node c l With the node c l Establishing semantic matching results for each application class in the corresponding relationship; updating the class dependency graph of the third-party library and the class dependency graph of the application based on the semantic matching results; The third-party library detection module is used to verify the structural similarity between the subgraph formed by the successfully matched nodes in the class dependency graph of the third-party library and the subgraph formed by the successfully matched nodes in the class dependency graph of the application. If the structural similarity is greater than a set threshold, it is determined that the third-party library matches the application, otherwise it does not match.
9. A server, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, the computer program is configured to be executed by the processor, and the computer program comprises instructions for executing the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.