Vulnerability reachability analysis method and device
By constructing the application's call graph and reverse-engineering the vulnerable call paths, the accuracy and efficiency issues of vulnerability reachability analysis were resolved, achieving efficient and accurate vulnerability identification.
Patent Information
- Application Number
- CN202511312581.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-15
- Publication Date
- 2026-02-03
AI Technical Summary
In existing technologies, the accuracy of vulnerability accessibility analysis for applications is not high, the false positive rate is high, it cannot accurately identify the real vulnerability risks, and the computational load is large and the efficiency is low.
Constructing the application's call graph, starting from the location of the vulnerable code as the sink, and tracing back to the source point that calls the vulnerable code, improves the accuracy of analysis and reduces computational load by constructing the vulnerability call path.
It improves the accuracy of vulnerability reachability analysis, reduces the false positive rate, reduces computational complexity, and improves analysis efficiency.
Smart Images
Figure CN121456875A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software security technology, and in particular to a vulnerability reachability analysis method and apparatus. Background Technology
[0002] With the development of software technology, applications increasingly incorporate third-party code, which in turn introduces numerous vulnerabilities. Traditional automated security testing tools generate a large number of alerts, many of which are false positives. These false positives include instances where a vulnerability exists but the vulnerable component is not loaded, or where the vulnerable component is loaded but the vulnerable code is not executed. Furthermore, vulnerability reachability analysis is inaccurate and fails to accurately identify the true vulnerability risks present in the application. Summary of the Invention
[0003] In view of this, the purpose of this application is to provide a vulnerability reachability analysis method and apparatus.
[0004] To achieve the above objectives, embodiments of this application provide a vulnerability reachability analysis method, including:
[0005] Construct the application's call graph; wherein, the call graph includes the call graphs of each component in the application and the call relationships between the components;
[0006] Using the location of the vulnerable code as the sink, find the source point in the call graph of the component containing the vulnerable code that calls the vulnerable code and is called by the upstream component;
[0007] When the source point is found, it is used as the new sink point. The call graph of the upstream component is searched for a new source point that calls the new sink point and is called by the new upstream component. This process is repeated until the initial source point is found. Based on the initial source point and the location of the vulnerability code, the vulnerability call path is constructed.
[0008] Optionally, the step of locating the source point in the call graph that calls the vulnerable code and is called by an upstream component includes:
[0009] Iterate through the import statements in the call graph of the candidate components to determine whether there is a set of package names of the component containing the vulnerability.
[0010] If present, determine through logical analysis whether the candidate component invokes vulnerable code;
[0011] If so, the candidate component is used as the upstream component of the component that calls the vulnerable code, and the location of the candidate component imported into the vulnerable component is used as the source point.
[0012] Optionally, after locating the source point in the call graph that calls the vulnerable code and is called by an upstream component, the process further includes:
[0013] If the source point is not found, the location of the vulnerable code is unreachable;
[0014] If the source point is found, determine whether there is a valid path between the sink point and the source point. If not, the location of the vulnerable code is unreachable.
[0015] Optionally, after locating the source point, the method further includes:
[0016] Dynamic analysis is used to verify whether the source point will trigger the vulnerable code.
[0017] If so, execute the steps of using the source point as the new sink point, searching in the call graph of the upstream components for the new source point that calls the new sink point and is called by the new upstream component.
[0018] Optionally, the call graph for building the application includes:
[0019] Use a call graph generation tool to generate a call graph for each component in the application;
[0020] Determine the calling relationships between components based on the dependencies between components in the application;
[0021] Generate the application's call graph based on the call relationships between components and the call graph of each component.
[0022] This application also provides a vulnerability reachability analysis device, including:
[0023] The call graph construction module is used to construct the call graph of the application; wherein, the call graph includes the call graphs of each component in the application and the call relationships between the components;
[0024] The search module is used to find the source point that calls the vulnerable code and is called by the upstream component, based on the call graph of the component where the vulnerable code is located, with the location of the vulnerable code as the sink point.
[0025] The path construction module is used to, when the source point is found, use the source point as the new sink point, search for a new source point that calls the new sink point and is called by the new upstream component in the call graph of the upstream component; follow this process until the initial source point is found, and construct the vulnerability call path based on the initial source point and the location of the vulnerability code.
[0026] Optionally, the search module is used to traverse each import statement in the call graph of the candidate component and determine whether there is a set of package names that import the component where the vulnerability is located; if there is, determine whether the candidate component calls the vulnerability code through logical analysis; if so, take the candidate component as the upstream component of the component that calls the vulnerability code, and take the position of the candidate component imported into the component where the vulnerability is located as the source point.
[0027] Optionally, the device further includes:
[0028] The judgment module is used to determine that the location of the vulnerable code is unreachable when the source point is not found; when the source point is found, it determines whether there is a valid path between the sink point and the source point. If there is no valid path, the location of the vulnerable code is unreachable.
[0029] Optionally, the device further includes:
[0030] The analysis module is used to dynamically analyze and verify whether the source point will trigger the vulnerable code; if so, the path construction module is used to find a new source point.
[0031] Optionally, the call graph construction module is used to generate a call graph for each component in the application using a call graph generation tool; determine the call relationships between components based on the dependencies between components in the application; and generate the application's call graph based on the call relationships between components and the call graphs of each component.
[0032] As can be seen from the above description, the vulnerability reachability analysis method and apparatus provided in this application constructs a call graph of the application. Using the location of the vulnerable code as the sink, it searches for the source point in the call graph of the component containing the vulnerable code that calls the vulnerable code and is called by an upstream component. When a source point is found, it is used as the new sink, and the call graph of the upstream component searches for a new source point that calls the new sink and is called by the new upstream component. This process continues until the initial source point is found. Based on the initial source point and the location of the vulnerable code, a vulnerability call path is constructed. This application can improve the accuracy of vulnerability reachability analysis, reduce computational load, lower complexity, and improve analysis efficiency. Attached Figure Description
[0033] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0034] Figure 1 This is a schematic diagram of the method flow of an embodiment of this application;
[0035] Figure 2 This is a schematic diagram illustrating the method principle of an embodiment of this application;
[0036] Figure 3 This is a block diagram of the device structure according to an embodiment of this application;
[0037] Figure 4 This is a block diagram of the electronic device structure according to an embodiment of this application. Detailed Implementation
[0038] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.
[0039] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.
[0040] In related technologies, application vulnerability reachability analysis is used to find vulnerabilities that are actually being exploited in a program. Some methods analyze whether vulnerable code is called by constructing the application's call graph. This involves a full path traversal on the search call paths, which suffers from path combination explosion, resulting in high computational cost and low efficiency.
[0041] In view of this, embodiments of this application provide a vulnerability reachability analysis method that starts from the location of the vulnerability code and reverses the call chain that calls the vulnerability code location, which can improve the accuracy of vulnerability reachability analysis, improve search efficiency, and avoid the path combination explosion problem.
[0042] The technical solution of this application will be further described in detail below through specific embodiments.
[0043] like Figure 1 , 2 As shown in the figure, this application provides a vulnerability reachability analysis method, including:
[0044] S101: Construct the call graph of the application; wherein, the call graph includes the call graph of each component in the application and the call relationships between the components;
[0045] In this embodiment, application components are independent, callable code units within the software, forming the basic modules of the program. In Python, components can be .py files, packages containing multiple modules (e.g., .py files, functions, classes, etc.), classes within packages, functions, and other functional units that can be called externally. Components in Python can be imported and called by other code, serving as fundamental nodes in the call graph.
[0046] In some embodiments, constructing the application's call graph includes:
[0047] Use a call graph generation tool to generate a call graph for each component in the application;
[0048] Determine the calling relationships between components based on the dependencies between components in the application;
[0049] Generate the application's call graph based on the call relationships between components and the call graph of each component.
[0050] In this embodiment, to analyze the call chain of the vulnerability, a preset call graph generation tool is used to generate the call graph (CG) of each component in the application, representing the function call relationship and / or method call relationship within the component. By parsing the application package, components with dependencies are identified, and the dependencies between components are constructed. Then, based on the dependencies between components and the call graphs of each component, a complete call graph of the application is generated. This call graph includes not only the call relationship within the component but also the call relationship between components, providing a basis for subsequent analysis of the reachable path from the source to the sink.
[0051] In some implementations, for the Python language, the dependencies between components in the application are resolved by using a package import statement parsing method based on an index tree and a transitive import parsing method based on import domain mapping, thus solving problems such as path ambiguity and complex transitive imports in package imports.
[0052] The package import statement parsing method based on the index tree employs static analysis to parse package import statements and correctly associate the referenced package files. During parsing, the component's directory structure is first analyzed, and an index tree is constructed based on this structure to assist in resolving the import path. During the parsing process, for relative imports—that is, module imports within a component, especially calls between submodules within the same package—the index tree can be traced back to locate the corresponding package path, ensuring correct matching of the source file. For example, in the file `my_package / module_a.py`, importing a function from a subpackage within the same package using the statement `from.subpackage import func` achieves a relative import. The index tree can be traced starting from the package node containing the current module `module_a.py`, locating the package path as `my_package.subpackage`. That is, starting from the `my_package` node, the index tree is used to search for its subdirectory `subpackage`.
[0053] For absolute imports, the imported project is another package, submodule, or third-party library under the root directory. The matching starts from the root directory, checking if it belongs to a module or submodule within the component. If the corresponding path is not found in the index tree, it is determined as an external dependency and categorized as a third-party library or dependency package of other components, improving the ability to parse complex Python component structures. For example, to import a module from `my_package` starting from the root directory, the `from my_package.module_aimport func` statement is used to implement an absolute import. If the `my_package` package is not found in the index tree, it can be identified as an external dependency.
[0054] The Python transitive import resolution method based on import domain mapping builds upon recursive analysis by extracting all definitions from the package to be imported. It then establishes a mapping between these extracted definitions and the definitions mapped in the import domain, constructing a call edge between each extracted definition and the mapped definition in the import domain. In other words, it establishes a mapping between the definition of the caller in a component and the definition of the callee in the component it calls. For example, a technical manual explains that if function A calls function B in a tool library, it's necessary to search for the actual definition of function B in all possible tool libraries (i.e., import domains) to determine which tool library function B is defined in, establish an import domain mapping between function B and the tool library where its definition is located, and construct a call edge between the definitions of function A and function B. This provides traceable and computable dependencies, supporting precise vulnerability propagation path tracing.
[0055] S102: Using the location of the vulnerable code as the sink, find the source point in the call graph of the component containing the vulnerable code that calls the vulnerable code and is called by the upstream component;
[0056] In this embodiment, after generating the call graph, within the component containing the vulnerable code, using the location of the vulnerable code as the sink, the source point that called the vulnerable code and was called by the upstream component is searched within that component. That is, starting from the location of the vulnerable code, the component that called the vulnerability is searched in reverse.
[0057] like Figure 2 As shown, in traditional forward analysis, the initial source node is used as the starting point to search every possible call path and determine whether there is a vulnerability in the call path. For example, in Python, component n is the initial source node. Component n calls component 2, and component 2 calls component 1. Component 1 has a vulnerability, which is triggered in the call chain of component n-component 2-component 1. Because forward analysis requires traversing all possible call chains from the initial source node to all possible sink nodes and then determining whether a vulnerability is triggered in each call chain, the computational load is large and the search efficiency is low.
[0058] In this embodiment, the initial source of the vulnerability is traced backward from the location of the vulnerable code. In this example, within component 1 where the vulnerable code is located, the sink is the location of the vulnerable code. c1 Find the source point that calls the vulnerable code and is invoked by the upstream component, i.e., component 2. c1 This allowed us to determine the call relationship from the source to the sink in Component 1, thus identifying the component that directly triggered the vulnerability.
[0059] In some embodiments, locating the source point that calls the vulnerable code and is invoked by an upstream component in the call graph of the component containing the vulnerable code includes:
[0060] Iterate through the import statements in the call graph of the candidate components to determine whether there is a set of package names of the component containing the import vulnerability;
[0061] If present, determine through logical analysis whether the candidate component invokes vulnerable code;
[0062] If so, the candidate component is used as the upstream component of the component that calls the vulnerable code, and the location where the candidate component is imported into the vulnerable component is used as the source point.
[0063] In this embodiment, to determine the actual call relationship of the vulnerable code, it is necessary to identify the upstream component of the component that calls the vulnerable code, and to determine that this upstream component not only calls the component containing the vulnerable code, but also calls the vulnerable code itself. To determine the call relationship of the vulnerable code, it is necessary to first determine the package name set of the component containing the vulnerable code and the analysis scope of the actually deployed code package, ensuring that the component containing the vulnerable code is a real, callable API interface. For candidate components that may call the component containing the vulnerable code, each import statement is traversed in its call graph to determine if there is an import statement that imports the package name set of the component containing the vulnerable code. If so, it is further analyzed whether the import statement calls the vulnerable code. If so, it can be determined that the import statement of the candidate component does indeed call the vulnerable code, and the candidate component can be regarded as the upstream component that calls the component containing the vulnerable code. The position in the component containing the vulnerable code that is called by the candidate component is taken as the source point. At least one source point that calls the vulnerable code is determined in this way, and each source point is added to the source point set.
[0064] In some embodiments, after locating the source point that calls the vulnerable code and is invoked by an upstream component in the call graph of the component containing the vulnerable code, the method further includes:
[0065] If the source cannot be found, the location of the vulnerable code is unreachable.
[0066] If the source point is found, determine whether there is a valid path between the sink point and the source point. If not, the location of the vulnerable code is unreachable.
[0067] In this embodiment, if the source point triggering the vulnerability is not found, it can be determined that although the vulnerable code exists, it has not been invoked or executed; therefore, the vulnerability is unreachable. If the source point is found, it is determined whether there is a valid path between the source point and the sink point. If there is no valid path, it can also be determined that the vulnerable code has not been executed.
[0068] In some approaches, after finding at least one source point within a component, all possible paths from the source point to the sink point are calculated in the current component's call graph. For example, a depth-first search (DFS) method can be used to traverse all possible paths between the source and sink points. For each source point, the reachability of the source point to the sink point on the path is checked to determine whether the vulnerability can be triggered within the current component, and all reachable valid paths are stored. The reachability criteria from the source point to the sink point include: the existence of at least one call path that starts from the source point, passes through a series of intermediate nodes, and finally reaches the sink point; the input data received by the source point can be transmitted to the sink point without interruption through all intermediate nodes on the call path; and all conditions on the call path are true under a specific input. If there are no paths between all source points and the sink point, i.e., no valid path to trigger the vulnerability is found, it indicates that the vulnerability is unreachable.
[0069] S103: When a source point is found, use that source point as the new sink point, and search for a new source point that calls the new sink point and is called by the new upstream component in the call graph of the upstream component; follow this process until the initial source point is found, and construct the vulnerability call path based on the initial source point and the location of the vulnerability code.
[0070] In this embodiment, if a source point that directly triggers the vulnerability and is called by an upstream component is found, this source point is used as a new sink point. The call graph of this upstream component is then used to search for a new source point that calls this new sink point and is simultaneously called by the new upstream component. This process continues in reverse, searching for the next source point. Starting from the downstream component where the vulnerability is located, the upstream components with calling relationships are searched step-by-step and in reverse until the initial source point is found. This initial source point does not have any calling relationships with other components. Based on the initial source point and the component where the vulnerable code is located, a complete vulnerability call path is constructed.
[0071] In some implementations, when searching for the next source point, it is necessary to determine the analysis scope of the new sink's package name set and the actual deployed code package to ensure that the component containing the new sink is a real, callable API interface. For candidate components that may call the component containing the new sink, traverse each import statement in its call graph to determine if there is an import statement that imports the package name set of the component containing the new sink. If so, continue to analyze whether the import statement calls the code corresponding to the new sink. If so, it can be determined that the import statement of the candidate component does indeed call the code corresponding to the new sink, and the candidate component can be regarded as the upstream component that calls the component containing the new sink, and the position in the component containing the new sink that is called by the candidate component is taken as the new source point.
[0072] like Figure 2As shown, for example, the vulnerability is in component 1, and the source point is found in component 1. c1 To the sink where the vulnerability is located c1 A valid path between them, and the source point. c1 Called by component 2, the source point is... c1 As the new sink of component 2 c2 (Sink) c2 By calling the source point of component 1 c1 (Triggered), continue searching for the sink in component 2. c2 Source c2 and the source point c2 Called by component n, the source point Source c2 Sink as the new sink of component n cn Continue searching for the sink in component n. cn The source point, if the sink point is found in component n. cn Source cn However, if the source point is not invoked by other components, then the source point will be... cn As the initial source point, reverse construction includes the source point Source. c1 Sink c1 Source c2 Sink c2 Source cn Sink cn The call chain, viewed from the forward direction, is a chain where component n calls component 2, component 2 calls component 1, and triggers the vulnerability in component 1. In other words, it starts from the source point of component n. cn To Sink cn Execution path, Sink cn Calling component 2, from the source of component 2. c2 Sink c2 Execution path, Sink c2 Calling component 1, from the source of component 1. c1 Sink c1 The execution path.
[0073] In some embodiments, if the source point is found, the process further includes, after finding the source point:
[0074] Verify whether the source point will trigger the vulnerable code through dynamic analysis;
[0075] If so, execute the steps of using the source point as the new sink point, searching in the call graph of the upstream components for the new source point that calls the new sink point and is called by the new upstream component.
[0076] In this embodiment, to improve the accuracy of vulnerability reachability analysis, after locating the source point in the component containing the vulnerable code, a dynamic analysis method is used to verify the source point. This involves running the program to determine whether the found source point will trigger the vulnerable code and whether execution from the source point will reach the vulnerable code's location. If so, the found source point is confirmed as correct, and the process continues to use this source point as a new sink to find new source points. Each newly found source point can be verified through dynamic analysis to ensure the correctness of each step in the traced call relationship. When tracing back to the initial source point, the correctness of the complete call chain from the initial source point to the vulnerability can be verified through dynamic analysis. If all source points are verified, a complete and correct call chain is constructed.
[0077] In some methods, multiple vulnerabilities in an application can be identified from a pre-defined vulnerability database. For each vulnerability, the method provided in this application is used to reverse-engineer and construct the call chain that triggers the vulnerability, starting from the location of the vulnerability code. If the call chain is successfully constructed, it indicates that the corresponding vulnerability has indeed been triggered and is reachable. If the call chain is not successfully constructed, it indicates that the corresponding vulnerability has not been triggered and is not reachable. The reachability results of all vulnerabilities are determined by analyzing the above process.
[0078] The vulnerability reachability analysis method provided in this application adopts a reverse analysis approach. Starting from the vulnerable code, it searches for the source point that calls the vulnerability within the component containing the vulnerable code. If the source point is found, it continues to search for a new source point calling the new sink in the upstream component of that component, using the source point as the new sink, until the initial source point is traced back. A path merging strategy is employed to construct a complete call chain based on the call path from the initial source point to the component containing the vulnerability. By using the call source point of the downstream component as the new sink for upstream analysis, the continuity of the vulnerability propagation path is ensured. A dynamic analysis method is used to verify the identified source points, guaranteeing the accuracy and completeness of the call chain. This application eliminates the need for a full path search, reducing computational load, lowering complexity, improving the accuracy of vulnerability reachability analysis, and reducing the false positive rate.
[0079] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.
[0080] It should be noted that the above description describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims may be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0081] like Figure 3 As shown in the figure, this application provides a vulnerability reachability analysis device, including:
[0082] The call graph construction module is used to construct the call graph of the application; wherein, the call graph includes the call graphs of each component in the application and the call relationships between the components;
[0083] The search module is used to find the source point that calls the vulnerable code and is called by the upstream component, based on the call graph of the component where the vulnerable code is located, with the location of the vulnerable code as the sink.
[0084] The path construction module is used to find a new source point that calls the new source point and is called by the new upstream component when a source point is found, using the source point as the new sink point; and to follow this process until the initial source point is found. Based on the initial source point and the location of the vulnerability code, the vulnerability call path is constructed.
[0085] Optionally, a search module is used to traverse each import statement in the call graph of the candidate component and determine whether there is a set of package names that import the component where the vulnerability is located. If there is, it is determined through logical analysis whether the candidate component calls the vulnerability code. If so, the candidate component is taken as the upstream component of the component that calls the vulnerability code, and the position of the candidate component imported into the component where the vulnerability is located is taken as the source point.
[0086] Optionally, the device also includes:
[0087] The judgment module is used to determine if the location of the vulnerable code is unreachable when the source point is not found; and if the source point is found, it is used to determine if there is a valid path between the sink point and the source point. If there is no valid path, the location of the vulnerable code is unreachable.
[0088] Optionally, the device also includes:
[0089] The analysis module is used to dynamically analyze and verify whether the source point will trigger the vulnerable code; if so, the path building module is used to find a new source point.
[0090] Optionally, a call graph construction module is used to generate a call graph for each component in the application using a call graph generation tool; determine the call relationships between components based on the dependencies between components in the application; and generate the application's call graph based on the call relationships between components and the call graphs of each component.
[0091] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware.
[0092] The apparatus described above is used to implement the corresponding methods in the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.
[0093] Figure 4 This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.
[0094] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.
[0095] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.
[0096] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.
[0097] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).
[0098] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.
[0099] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.
[0100] The electronic devices described above are used to implement the corresponding methods in the foregoing embodiments and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.
[0101] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.
[0102] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.
[0103] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.
[0104] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.
[0105] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this disclosure.
Claims
1. A vulnerability reachability analysis method, characterized in that, include: Construct the application's call graph; wherein, the call graph includes the call graphs of each component in the application and the call relationships between the components; Using the location of the vulnerable code as the sink, find the source point in the call graph of the component containing the vulnerable code that calls the vulnerable code and is called by the upstream component; When the source point is found, it is used as the new sink point. The call graph of the upstream component is searched for a new source point that calls the new sink point and is called by the new upstream component. This process is repeated until the initial source point is found. Based on the initial source point and the location of the vulnerability code, the vulnerability call path is constructed.
2. The method according to claim 1, characterized in that, The process of locating the source point in the call graph that calls the vulnerable code and is invoked by an upstream component includes: Iterate through the import statements in the call graph of the candidate components to determine whether there is a set of package names of the component containing the vulnerability. If present, determine through logical analysis whether the candidate component invokes vulnerable code; If so, the candidate component is used as the upstream component of the component that calls the vulnerable code, and the location of the candidate component imported into the vulnerable component is used as the source point.
3. The method according to claim 1, characterized in that, After locating the source point in the call graph that calls the vulnerable code and is called by an upstream component, the process further includes: If the source point is not found, the location of the vulnerable code is unreachable; If the source point is found, determine whether there is a valid path between the sink point and the source point. If not, the location of the vulnerable code is unreachable.
4. The method according to claim 1, characterized in that, After locating the source point, the process also includes: Dynamic analysis is used to verify whether the source point will trigger the vulnerable code. If so, execute the steps of using the source point as the new sink point, searching in the call graph of the upstream components for the new source point that calls the new sink point and is called by the new upstream component.
5. The method according to claim 1, characterized in that, The call graph for building the application includes: Use a call graph generation tool to generate a call graph for each component in the application; Determine the calling relationships between components based on the dependencies between components in the application; Generate the application's call graph based on the call relationships between components and the call graph of each component.
6. A vulnerability reachability analysis device, characterized in that, include: The call graph construction module is used to construct the call graph of the application; wherein, the call graph includes the call graphs of each component in the application and the call relationships between the components; The search module is used to find the source point that calls the vulnerable code and is called by the upstream component, based on the call graph of the component where the vulnerable code is located, with the location of the vulnerable code as the sink point. The path construction module is used to, when the source point is found, use the source point as the new sink point, search for a new source point that calls the new sink point and is called by the new upstream component in the call graph of the upstream component; follow this process until the initial source point is found, and construct the vulnerability call path based on the initial source point and the location of the vulnerability code.
7. The apparatus according to claim 6, characterized in that, The search module is used to traverse each import statement in the call graph of the candidate component and determine whether there is a set of package names of the component containing the vulnerability; if there is, it determines whether the candidate component calls the vulnerable code through logical analysis. If so, the candidate component is used as the upstream component of the component that calls the vulnerable code, and the location of the candidate component imported into the vulnerable component is used as the source point.
8. The apparatus according to claim 6, characterized in that, Also includes: The judgment module is used to determine that the location of the vulnerable code is unreachable when the source point is not found. When the source point is found, it is determined whether there is a valid path between the sink point and the source point. If not, the location of the vulnerable code is unreachable.
9. The apparatus according to claim 6, characterized in that, Also includes: The analysis module is used to dynamically analyze and verify whether the source point will trigger the vulnerable code. If so, use the path building module to find a new source point.
10. The apparatus according to claim 6, characterized in that, The call graph construction module is used to generate a call graph for each component in the application using a call graph generation tool; determine the call relationships between components based on the dependencies between components in the application; and generate the application's call graph based on the call relationships between components and the call graphs of each component.