A third-party library function abstract construction method for static vulnerability detection

Abstract

The application provides a third-party library function abstract construction method for static vulnerability detection, comprising: establishing a program P abstract as a two-layer abstract (G, S) and a vulnerability specification (delta src , delta sink ), wherein G is a program dependence graph PDG of the program P, S is a vulnerability-specific abstract of the program P, and delta src and delta sink represent attributes that should be met by source nodes and sink nodes; a two-layer abstract design is provided: one layer uses a linear-size program intermediate representation called a program dependence graph to compactly encode path conditions, and the other layer encodes vulnerability-specific attributes of reachability, the abstract construction method provided by the application can greatly reduce the time of abstract generation and the space of abstract storage, and the third-party library function abstract construction method provided by the application can greatly improve the detection speed and save the detection memory when detecting.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of third-party library security, and particularly to a third-party library function summary construction method for static vulnerability detection. BACKGROUND

[0002] Third-party libraries enable developers to integrate pre-tested and reusable software components developed by other software vendors, thus saving development costs. Despite such benefits, the use of third-party libraries also causes people's concerns about software quality and has become one of the most serious security threats. Misuse of third-party library APIs can also cause quality and even security problems. It is not easy to detect vulnerabilities caused by misuse of third-party library APIs using traditional static analysis. First, if full-program analysis is applied to the code of an application program and a dependent library, it is easy to cause scalability problems due to code bloating. On the other hand, if aggressive or conservative assumptions are made for third-party library APIs, it is inevitable to fill the detection results with false positives or false negatives. A better solution is to generate and persist offline function summaries of third-party library APIs in an automated manner, and then reuse these summaries in online combined static analysis. However, when dealing with millions of lines of code of third-party libraries, the function summaries designed by existing researches have an unsolved paradox - high-precision summary forms lead to unbearable space and time overhead, and imprecise summaries greatly weaken their precision or recall rate. SUMMARY

[0003] The main purpose of the present application is to overcome the above-mentioned defects in the prior art, and to provide a third-party library function summary construction method for static vulnerability detection. A two-layer summary design is proposed: one layer uses a linear-size program intermediate representation called program dependence graph to compactly encode path conditions, and the other layer encodes the reachability of vulnerability-specific properties. The summary construction method provided by the present application can greatly reduce the time of summary generation and the space of summary storage. Using the third-party library function summary construction method proposed by the present application, the detection speed can be greatly improved and the detection memory can be saved.

[0004] The present application adopts the following technical solutions:

[0005] A third-party library function summary construction method for static vulnerability detection comprises:

[0006] A program P summary is established as a two-layer summary (G, S) and a vulnerability specification (δ src , δ sink ), wherein G is a program dependence graph PDG of the program P, S is a vulnerability-specific summary of the program P, δ src and δ sinkrepresents properties satisfied by the source and sink nodes.

[0007] In particular, the program dependence graph, in particular:

[0008] The program dependence graph of a program P is denoted as G = (V, E d , E c , l d , l c );

[0009] where: V contains the vertices of the graph, representing a statement in the program, or equivalently, the value defined by the statement;

[0010] is a data dependence edge, representing that statement v2 uses the value defined by statement v1;

[0011] is a control dependence edge, representing that v2 is an if statement, and v1 is reachable when v2's if condition is satisfied; l d is a function that maps each data dependence edge to a pair of parentheses; l d the value of (v1→v2) represents a function call and return at different call sites, described by the left and right parentheses, respectively; for other edges, l d (v1→v2) = ε; l c is a function that maps each control dependence edge to true or false, representing the true or false branch, respectively.

[0012] In particular, the program dependence graph, further comprises:

[0013] The program dependence graph of a program P G = (V, E d , E c , l d , l c ) is feasible if and only if a dataflow path p: u1→u2→...→u k is feasible if and only if the dataflow path p satisfies: the path condition C(p) is satisfied; where the path condition C(p) is a constraint on the program values;

[0014] The label string of p belongs to the language Dyck-CFL set.

[0015] In particular, the vulnerability-specific summary, in particular:

[0016] The vulnerability-specific summary S maps a pair of vertices (u1, u2) in a single function to a set of dataflow paths, where where, and contains the source and sink nodes of the function f, and and respectively contain the input and output of the argument, return and call statement in function f of function f.

[0017] Specifically, in the vulnerability-specific summary,

[0018] as the reuse vulnerability-specific summary.

[0019] Specifically, the vulnerability specification comprises:

[0020] Null dereference: delta src is true if and only if v is a = NULL or a = malloc(), where a is an arbitrary pointer expression; delta sink (v) is true; detecting null dereference, only need to detect whether there is a data flow path from v1 to v2, and satisfy delta src (v1) = true and delta sink (v2) = true.

[0021] Specifically, the vulnerability specification further comprises:

[0022] Memory leak: delta src (v) is true if and only if v is a = malloc(), where a is an arbitrary pointer expression; delta sink (v) is true if and only if v is free(a); if there is a data flow path from v1 to v2, and satisfy delta src (v1) = true and delta sink (v2) = false, a memory leak will occur.

[0023] Specifically, further comprising a persistence summary, specifically:

[0024] Generating the PDG of a given program P based on a program dependence analysis method, and further storing the PDG to a disk for saving;

[0025] Another aspect of the embodiment of the present application provides a vulnerability detection method constructed based on a third-party library function summary, comprising:

[0026] According to the dependency relationship, each third-party library is processed from top to bottom, and a vulnerability is detected by detecting a data flow path in each function; specifically, a first case: checking whether a source node exists in the function, and then querying a sink node downward along the source node, including but not limited to: flowing to the sink node in the library function, passing through third-party library function calls, and flowing to the sink node in the program; a second case: checking whether a calling function c exists in the detected function, wherein the return value of the function c produces a source node in the third-party library, and the return value of the function c flows to the sink node in the detected function or the call.

[0027] From the above description of the present application, compared with the prior art, the present application has the following beneficial effects:

[0028] (1) The present application proposes a third-party library function abstract construction method for static vulnerability detection, including: establishing a program P abstract as a two-layer abstract (G, S) and a vulnerability specification (delta src , delta sink ), wherein G is a program dependency graph PDG of the program P, S is a vulnerability-specific abstract of the program P, and delta src and delta sink represent attributes that should be met by the source node and the sink node; a two-layer abstract design is proposed: one layer uses a linear-size program intermediate representation called a program dependency graph to compactly encode path conditions, and the other layer encodes the reachability of vulnerability-specific attributes, the abstract construction method provided by the present application can greatly reduce the time of abstract generation and the space of abstract storage, and the third-party library function abstract construction method proposed by the present application can greatly improve the detection speed and save the detection memory during detection.

[0029] (2) The detector formed according to the method of the present application can complete the detection of more than 10 million lines of code in 9 hours, and detect 55 real vulnerabilities with a high accuracy of 90.16%. Compared with full-program analysis and traditional path-sensitive precise abstract design, the detector formed by the method of the present application realizes speed improvement of 82.3 times and 2.27 times, respectively, and saves memory usage of 93.52% and 72.67%, respectively. BRIEF DESCRIPTION OF DRAWINGS

[0030] Figure 1is an example of null dereference caused by misuse of third-party library API provided by the embodiment of the application, wherein figure (a) is the code in the application project libopusfile-0.9, figure (b) is the simplified version code in the third-party library glibc-2.31, figure (c) is the safe version code of the function memcpy, and figure (d) is the simplified version code in the third-party library libogg-1.3.4;

[0031] Figure 2 is a program dependence graph of the functions ogg_sync_buffer and alloc provided by the embodiment of the application;

[0032] Figure 3 is an example of vulnerability-specific summary of the third-party library libogg-1.3.4 provided by the embodiment of the application; DETAILED DESCRIPTION

[0033] In order to make the purpose, technical scheme and advantages of the embodiments of the application clearer, the technical scheme in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application.

[0034] In actual programs, when performing path-sensitive analysis, the explosive size of path conditions occupies a huge consumption of memory usage. If a heavy path condition form, i.e., SMT constraint, is used, it means high space overhead of persistence, not to mention high time overhead of persistence. Therefore, in the embodiments of the application, a two-layer summary design is proposed to reduce the high time and space cost while preserving high accuracy.

[0035] In the first layer, a program dependence graph (PDG) is used as a summary, which is a linear-size program intermediate representation and essentially encodes the same program information as the path conditions. The first-layer summary design can guarantee low-cost persistence and the ability to restore path conditions losslessly.

[0036] In the second layer, in order to avoid repeatedly verifying bug-specific properties in the third-party library API that have been analyzed, a dataflow path on the PDG is used as a vulnerability-specific summary, and an efficient algorithm is designed to directly restore the path conditions. It should be noted that in order to alleviate the high cost of persistence of the explosive size of candidate paths in the third-party library API, four kinds of dataflow paths are designed for the vulnerability detection that can be modeled as detecting source-sink properties. These persistent paths basically capture the reachability relationship between the parameter and return vertices of a function and the vulnerability-specific source and sink vertices at the intra-procedural level. Then, a method is proposed to restore the inter-procedural path conditions by splicing these intra-procedural dataflow paths on demand. The design of the second-layer summary makes efficient path condition restoration possible without causing great space overhead.

[0037] This invention proposes a method for constructing third-party library function summaries for static vulnerability detection:

[0038] The digest of program P is established as a two-level digest (G,S), and a vulnerability specification (δ). src ,δ sink ), where G is the program dependency graph PDG of program P, serving as a general digest, S is the vulnerability-specific digest of program P, and δ src and δ sink This indicates the properties that the source and sink nodes should satisfy.

[0039] The program dependency graph is as follows:

[0040] The program dependency graph of program P is represented as G = (V, E) d E c ,l d ,l c );

[0041] Where: V contains the vertices of the graph, representing a statement in the program, or equivalently, the value defined by that statement;

[0042] It is a data dependency edge, indicating that statement v2 uses the value defined by statement v1;

[0043] It is a control dependency edge, indicating that v2 is an if statement, and v1 is reachable when the if condition of v2 is met; d It is a function that maps each data dependency edge to parentheses; d The value of (v1→v2) represents the function call and return at different calling locations, described by the left and right parentheses respectively; for other edges, l d (v1→v2)=ε;l c It is a function that maps each control dependency edge to true or false, representing true or false branches respectively;

[0044] Among them, the program dependency graph, as a classic intermediate representation of a program, meets all the above requirements. Therefore, it can be used as a highly compressed data structure for summarizing third-party library functions. Figure 2 Showing Figure 1 (d) is the PDG of the third-party library code. In the diagram, v is used... i This represents the value of the variable or constant v in the i-th row. As shown in the diagram, a program dependency graph essentially consists of data dependency edges and control dependency edges. Each node in the graph is either a statement in the code or represents multiple values ​​merging different branches. Node. For each A node is defined such that if one of its operands has a control dependency edge to a condition, the other operand has a control dependency edge to the negation of that condition. The latter is omitted to maintain clarity in the diagram.

[0045] As an intermediate representation, PDG is linearly large relative to the program, thus satisfying the first requirement. Secondly, given any data flow path, its path conditions can be easily recovered through simple graph traversal. For example, for the first data flow path in Table 1, the data flow path 1→7→10→15 is first found, where each number is labeled... Figure 2 A rectangular node in the PDG. Then, the conditions of the data flow path are collected from two aspects. For the data flow conditions, since the values ​​along the data flow path are the same, the conditions 0 = cRet9 = cRet can be obtained. 14 =cRet 23 Along with the control dependency edge, the condition can be obtained. Recursively, there is another data flow condition sz 11 =sz8. There are no additional data flow conditions for cRet14 because its data flow conditions have already been collected. For the third requirement, the specific information about the vulnerability can be easily recorded as the data flow path in the diagram. For example, for the null pointer dereference detection described earlier, the data flow path 1→7→10→15 can be recorded, meaning that a third-party library API might return a null pointer. Note that the data flow path here is much more compact than a traditional program path. This is mainly because the data flow path can skip unnecessary control flow in the code through data dependencies.

[0046] Table 1 Data Flow Paths and Path Conditions

[0047]

[0048] Figure 2 Showing Figure 1 (d) shows the PDG of the program. For example, there is a data dependency edge from 17 to 19, indicating that the value of ret defined in line 26 is used as a possible return value of the function alloc. Additionally, a control dependency edge connects 8 and 12, indicating that the value of cRet in line 20 is affected by whether cRet→buf in line 12 is empty. For the two calls to alloc, there are two pairs of data dependency edges, with different indices indicated in parentheses. Finally, two control dependency edges are shown.

[0049] It is worth mentioning that PDG has resolved indirect data dependencies caused by pointers, which means that several basic analyses, such as pointer analysis, are necessary for constructing a PDG for a given program.

[0050] Given a program's PDG (Programming Distribution Graph), we can infer how the data stream of interest propagates by detecting a special class of paths, namely feasible data stream paths. Before providing their formal definitions, we first introduce the concept of path conditions as follows.

[0051] Path conditions: Consider a program P whose PDGG = (V, E) d E c ,l d ,l c A data flow path p: u1→u2→...→u k , where u i →u i+1 ∈Ed, 1≤i≤(k-1). The path condition C(p) is a constraint on the program value, which holds if and only if there exists a specific execution path of P such that the data flow along p occurs.

[0052] The program dependency graph (PDG) encodes both data dependencies and control dependencies. Based on the PDG, the data flow of interest can be traced along data dependency edges, and the path conditions of the data flow based on both types of dependencies can be recovered. Furthermore, the concept of a data flow path can be defined as follows.

[0053] Data flow path: Given a PDGG = (V, e d E c ,l d ,l c A data flow path p: u1→u2→...→u k It is feasible if and only if p satisfies:

[0054] (1) The path condition C(p) is satisfyable;

[0055] (2) The tag string of p belongs to the extended Dyck-CEL

[54] .

[0056] Consider the data flow path 1→7→10→15 in Table 1. During the PDG traversal, the following data flow facts can be obtained: 0 = cRet, 9 = cRet. 14 =cRet 23 At the same time, control dependency induces conditionalization. Additionally, sz 11 Having sz8 as its data dependency induces additional conditions: sz 11 =sz8. By establishing a conjunction of the three parts, the conditions for the data flow path can be obtained. Clearly, the path conditions are unsatisfactory, therefore a data flow path cannot be formed.

[0057] Static vulnerability detection essentially explores feasible paths from a particular form of source node and sink node. In the presence of third-party libraries, only certain types of dataflow paths in their PDGs can be stitched with those of the application code to induce feasible dataflow paths across the application and the library. Based on this intuition, a vulnerability-specific summary is formally defined as follows.

[0058] Vulnerability-specific summary: a pair of predicates (δ src ,δ sink ) as a vulnerability specification and a PDG G of a given program. A vulnerability-specific summary S maps a pair of vertices (u1, u2) in a single function to a set of dataflow paths, where Here, and contain the source and sink nodes of function f, while and contain the inputs and outputs of the arguments, return, and call statements in function f, respectively.

[0059] Intuitively, a vulnerability-specific summary abstracts the semantics of a library function relevant to a vulnerability specification. Although there can be a large number of nodes and paths in the PDG of a third-party library, only a few key dataflow paths are really important when detecting a particular vulnerability type. From a high-level perspective, a vulnerability-specific summary provides a compact semantic signature of a library that guides the static vulnerability detection of applications that use the library.

[0060] For NPD detection, a vulnerability-specific summary from output node 6 to return node 15 can be obtained. The dataflow paths connecting them involve the propagation of null values, which leads to an NPD vulnerability in the program shown in Figure 1 , where (a) is the code in the application project libopusfile-0.9, (b) is the simplified version of the code in the third-party library glibc-2.31, (c) is the secure version of the function memcpy, and (d) is the simplified version of the code in the third-party library libogg-1.3.4.

[0061] It is also worth mentioning that several summaries of vulnerability-specific summaries can also be reused when detecting other types of bugs. Specifically, if it can be safely reused because the dataflow paths connecting the specific types of nodes do not change. In specific embodiments, these four vulnerability-specific summaries are reused, avoiding the generation and storage of duplicate summaries for different vulnerability types.

[0062] Vulnerability specification τ is a pair of predicates on PDG nodes, denoted as (δ src ,δsink ) represents. Specifically, δ src and δ sink represent properties that should be satisfied by the source and sink nodes.

[0063] Null dereference: δ src is defined to determine whether v is a = NULL or a = malloc(), where a is an arbitrary pointer expression. δ sink (v) is true if and only if v is a statement that accesses the memory object pointed to by the pointer expression. To detect null dereferences, it is only necessary to detect whether there is a feasible dataflow path from vi to v2, and δ src (v1) = true and δ sink (v2) = true.

[0064] Memory leak: δ src (v) is true if and only if v is a = malloc(), where a is an arbitrary pointer expression. δ sink (v) is true if and only if v is free(a). A potential memory leak can occur if there is a feasible dataflow path from vi to v2, and δ src (v1) = true and δ sink (v2) = false.

[0065] To generate and save a two-level summary for a given third-party library, one first constructs the PDG of the third-party library, and then collects the vulnerability-specific summaries. Note that a third-party library can also depend on other third-party libraries, i.e., its functions can call functions of other third-party libraries. After generating the function summaries in a many static analyses, one processes each third-party library in a bottom-up manner using the dependencies among TPLs. The two-level summary of a third-party library is generated after all the third-party dependent libraries are processed.

[0066] The technical details of the embodiment for persisting the two-level summaries of a list of third-party libraries, which are the third-party libraries that an application program code depends on. Initially, the embodiment takes as input a list of third-party libraries and a vulnerability specification; the list of third-party libraries is sorted according to their dependencies, and the functions of each third-party library are sorted according to the caller relationships. Technically, one first generates a PDG of a given program P following existing program dependence analysis techniques, and further stores the PDG on disk for persistence.

[0067] Then, each third-party library is processed according to the order and vulnerability-specific summaries are identified by detecting dataflow paths in each function, specifically, for a dataflow path p ending at an input node, check the connected parameter nodes, which are in the PDG of the third-party library on which Lib depends. If a parameter node is the start of a summary path, persist the path p because p can be concatenated with the summary path to form an inter-procedural dataflow path; handle the case of ui∈V out in a similar way. Each third-party library is processed top-down according to the dependency relationship and vulnerability-specific summaries are identified by detecting dataflow paths in each function.

[0068] In another aspect, the embodiments of the present application provide a vulnerability detection method based on third-party library function summaries, comprising:

[0069] Each third-party library is processed top-down according to the dependency relationship and vulnerabilities are detected by detecting dataflow paths in each function; specifically, a first case: check whether there is a source node in the function, and then query a sink node downward along the source node, including but not limited to: in the library function, flow to the sink node, pass through third-party library function calls, and in the program, flow to the sink node; a second case: check whether there is a calling function c in the detected function, wherein the return value of the function c produces a source node in the third-party library, and the flow is transferred to the return value of the function c, and along the return value of the function c, flow to the sink node in the detected function or in the call.

[0070] For the third-party library libogg-1.3.4 in (d), the PDG in Figure 1 can be obtained as its general summary. For NPD detection, vulnerability-specific summaries shown in Figure 2 can be further constructed and saved. Based on the PDG, the path condition of each dataflow path can be easily recovered, for example, the discussed path corresponds to the dataflow path 1→7→10→15 in Figure 3 . Figure 3

[0071] Based on the efficient path condition recovery, the persisted third-party library summaries can finally be utilized in static vulnerability detection. The key idea is to scan the program paths from source to sink and load the previously computed persistent vulnerability-specific summaries as needed. Benefiting from the summary design and path condition recovery, vulnerability detection can achieve full sensitivity at a lower time and memory cost.

[0072] ​To clearly demonstrate, consider the vulnerability caused by the existence of a feasible source-sink path as an example, such as a null pointer dereference vulnerability; embodiments give details of detecting vulnerabilities with persistent summaries, which first prepare summaries for all third-party libraries and build the PDG of the application P. After determining the source and sink nodes according to the vulnerability specification, it starts traversing from the source node and tries to find a path ending at the required sink node. During the path search process, if the path encounters a call or return statement that requires a third-party library summary to connect the data flow path, it will load the persistent summary in this statement to continue searching. When the path finally reaches a sink node, it verifies whether the label string of the path belongs to the extended Dyck-CFL. If so, it loads the persistent PDG, then restores the path condition, and uses the solver to determine the satisfiability of the path condition. For the detection of null pointer dereference, a feasible vulnerability causes the algorithm to report a potential null pointer dereference vulnerability as a result.

[0073] The detector LIBCACHE based on the method of the application is implemented on the basis of the most advanced sparse value flow analysis framework to detect four security vulnerabilities with source-sink attributes, including null pointer dereference (NPD), use after free (UAF), memory leak (ML) and use of uninitialized variable. Evaluation shows that LIBCACHE is very effective in detecting security vulnerabilities caused by abuse of third-party library APIs. It can complete detection of more than 10 million lines of code in 10 hours and find a total of 55 real vulnerabilities in 15 popular open source projects, with an accuracy of 90.16%. Due to the severity of the detected vulnerabilities, three of them even have CVE identifiers assigned. Compared with whole program analysis using application and library code, LIBCACHE can achieve a speed of 82.3 times, saving an average of 93.52% of memory usage. In addition, compared with traditional path-sensitive precise summary design, LIBCACHE achieves a space reduction of 94.30% and a time reduction of 97.60% in the summary persistence process; in the summary reuse process, LIBCACHE achieves a speedup of 2.27 times, saving an average of 72.67% of memory usage.

[0074] The above is only a specific embodiment of the application, but the design concept of the application is not limited thereto, and any non-essential modification of the application using this concept shall be deemed to infringe the protection scope of the application.

Claims

1. A method for constructing third-party library function summaries for static vulnerability detection, characterized in that, include: The digest of program P is established as a two-level digest (G,S), and a vulnerability specification (δ). src ,δ sink ), where G is the program dependency graph PDG of program P, serving as a general digest, S is the vulnerability-specific digest of program P, and δ src and δ sink This indicates the properties that the source node and sink node satisfy; The vulnerability-specific digest is as follows: The vulnerability-specific digest S maps a pair of vertices (u1, u2) in a single function to a set of data flow paths, where in, and It contains the source node and sink node of function f, while and These include the parameters, return value, and input and output of the calling statements within function f; In the vulnerability-specific summary As a reuse vulnerability-specific summary.

2. The method for constructing third-party library function digests for static vulnerability detection according to claim 1, characterized in that, The program dependency graph is specifically as follows: The program dependency graph of program P is represented as G = (V, E) d E c ,l d ,l c ); Where: V contains the vertices of the graph, representing a statement in the program, or equivalently, the value defined by that statement; It is a data dependency edge, indicating that statement v2 uses the value defined by statement v1; It is a control dependency edge, indicating that v2 is an if statement, and v1 is reachable when the if condition of v2 is met; d It is a function that maps each data dependency edge to parentheses; d The value of (v1→v2) represents the function call and return at different calling locations, described by the left and right parentheses respectively; for other edges, l d (v1→v2)=ε;l c It is a function that maps each control dependency edge to true or false, representing true or false branches respectively.

3. The method for constructing third-party library function digests for static vulnerability detection according to claim 2, characterized in that, The program dependency graph also includes: The program dependency graph G = (V, E) of program P d E c ,l d ,l c The data flow path is p: u1→u2→...→u k It is feasible if and only if the data flow path p satisfies: the path condition C(p) is satisfied, where C(p) is a constraint on the program values ​​involved in the path p; and the label string of p belongs to the language Dyck-CFL set.

4. The method for constructing third-party library function digests for static vulnerability detection according to claim 1, characterized in that, The vulnerability specification includes: Null pointer dereferencing: Define δ src Determine whether v is a = NULL or a = malloc(), where a is an arbitrary pointer expression; v is a statement that accesses the memory object pointed to by the pointer expression if and only if v is a statement that accesses the memory object pointed to by the pointer expression. sink (v) is true; to detect null pointer dereferencing, it is only necessary to check whether there is a data flow path from v1 to v2 that satisfies δ. src (v1) = true and δ sink (v2) = true.

5. The method for constructing third-party library function digests for static vulnerability detection according to claim 1, characterized in that, The vulnerability specification also includes: Memory leak: δ src (v) is true if and only if v is a = malloc(), where a is an arbitrary pointer expression; δ sink (v) is true if and only if v is free(a); if there exists a data flow path from v1 to v2, and δ src (v1) = true and δ sink If (v2) = false, a memory leak will occur.

6. The method for constructing third-party library function digests for static vulnerability detection according to claim 1, characterized in that, It also includes persistent digests, specifically: The PDG of a given program P is generated based on the program dependency analysis method, and then the PDG is stored on the disk for preservation.

7. The method for constructing third-party library function digests for static vulnerability detection according to any one of claims 1-6, characterized in that, include: Each third-party library is processed from top to bottom according to the dependency relationship, and vulnerabilities are detected by detecting the data flow path in each function; specifically, in the first case: check whether there is a source node in the function, and then query the sink node down along the source node, including: flow to the sink node in the library function, through the call of the third-party library function, and flow to the sink node in the program; Second scenario: Check if there is a call to function c in the function being checked, where the return value of function c is generated in the source node of the third-party library, flows to the return value of function c through the stream, and flows to the sink node along the return value of function c in the function being checked or in the call.

Images