A system software package vulnerability export reachability determination method and system

Abstract

The application discloses a system software package vulnerability export reachability judgment method and system, and belongs to the technical field of computer software security and program static analysis. The method comprises the following steps: unpacking a target binary software package to obtain a component list; constructing a function call graph and performing alignment recovery on stripped symbols; fusing each local call graph into a global system call graph; mapping a vulnerability symbol to a target node in the global system call graph; performing path search starting from the export symbol of each component to determine the export reachability state of the vulnerability; and generating a supply chain reachability judgment result based on the export reachability state. The application restores stripped symbols through source code and binary double-side topology alignment, fuses cross-component call relations, and performs bounded static path search, so that the reachability of the export symbol to the vulnerability function is judged under pure static conditions, and the alarm fatigue of traditional binary component analysis is effectively relieved.

Description

Technical Field

[0001] This application relates to the field of computer software security and static program analysis technology, specifically to a method and system for determining the reachability of system software package vulnerabilities. Background Technology

[0002] Software composition analysis plays a crucial role in software supply chain security governance as a means of identifying and managing security risks of third-party components. Traditional binary software composition analysis often uses a logic of matching component versions with the existence of known vulnerabilities. Once a component version within the scope of a vulnerability is identified, a high-risk alert is issued, but it rarely distinguishes whether the vulnerable function can be accessed by external input in the actual runtime environment. For vulnerable functions that are dead code or only called by internal private paths, such tools continue to issue alerts, leading to severe alert fatigue for security operations teams and making it difficult to scientifically prioritize patches.

[0003] For shared library binary software packages without independent entry points, determining whether a vulnerability within the package can be triggered externally hinges on the existence of a static call path from exported functions to the vulnerable internal function. However, release binaries typically undergo symbol stripping, degenerating internal function names into anonymous symbols, making it difficult to establish a correspondence between vulnerable functions and symbol information in the knowledge base. Furthermore, at cross-language call boundaries, call graphs for each language are constructed separately and do not merge, making it impossible to trace cross-boundary control flow on a unified graph model. Moreover, dynamic verification methods heavily rely on specific runtime environments; failure to trigger a vulnerability within a limited timeframe cannot prove its absolute unreachability, making it unreliable as a basis for compliance review conclusions. Therefore, a purely static method for determining the reachability of exported vulnerabilities in binary software packages, capable of handling symbol stripping and integrating multi-component call relationships, is needed. Summary of the Invention

[0004] To address the shortcomings of existing technologies, such as the over-reliance on component version and vulnerability existence matching in binary software component analysis leading to alert fatigue, difficulties in locating vulnerable functions after symbol stripping, and the inability to integrate cross-language call graphs, this application provides a method and system for determining the reachability of exported vulnerabilities in system software packages. This method independently constructs function call graphs for each component within the binary software package, recovers stripped symbols using source code-side topological priors, integrates cross-component call relationships to form a global system call graph, and anchors vulnerable symbols to graph nodes using a multi-level confidence reduction strategy before performing bounded path search. This achieves reachability determination of exported symbols to vulnerable functions under purely static conditions. Specifically, this application provides the following technical solutions: This application provides a method for determining the reachability of system software package vulnerabilities, the method comprising: The target binary software package is unpacked, and the runtime components are scanned based on the unpacking results to obtain a component list; For the components in the component list, construct function call graphs and extract the exported symbols of each component; perform alignment restoration on the stripped symbols based on the topological prior of the source code side call graph to obtain the restored local call graph of each component; Based on the cross-component call relationships between components, the restored local call graphs of each component are merged to obtain the global system call graph; Based on a bridging strategy with decreasing confidence levels, vulnerability symbols on the source code side are mapped to target nodes in the global system call graph to obtain vulnerability anchoring results. Starting from the exported symbols of each component, and based on the vulnerability anchoring results, a path search is performed in the global system call graph to obtain the vulnerability's exported reachability status. Based on the derived reachability status, the supply chain aggregation rules are executed to generate a decision, thereby obtaining the supply chain reachability decision result.

[0005] Optionally, the alignment recovery of the stripped symbols based on the topological prior of the source code-side call graph includes: Based on the known symbols shared by the source code side and the binary side, determine the anchor point set, and based on the anchor point set, perform bounded topological traversal on the call graphs on both sides to obtain the structural position features of each anonymous node. Based on the structural location features and the constant attribute features of the corresponding nodes on the source code side, a multi-dimensional similarity fusion scoring is performed to obtain the comprehensive matching score of each anonymous node. If the overall matching score meets the preset confidence conditions, symbol recovery annotation is performed on the anonymous nodes to obtain the recovered function symbols.

[0006] Optionally, the alignment recovery further includes: Based on the nodes that have completed symbol recovery and their calling edge relationships, propagational naming inference is performed on adjacent unrecovered nodes to expand the coverage of the symbol recovery.

[0007] Optionally, the method further includes: Based on the degree of matching between the vulnerability symbol and the node identifier in the global system call graph, multi-level bridging attempts are performed sequentially according to the confidence level, and subsequent levels are terminated when the current level is successful. If all bridging attempts at all levels fail to meet the preset confidence level, the vulnerability symbol will be marked as pending audit status and excluded from subsequent path searches. Each level of bridging attempt is performed based on symbol matching conditions of different granularities.

[0008] Optionally, the method further includes: Perform a pre-judgment based on the exported attributes of the target node; When the pre-determined exported attributes meet the preset requirements, the reachability determination result is obtained, and graph traversal is skipped; If the pre-determined exported attributes do not meet the preset requirements, then based on the starting point set formed by the exported symbols, a layer-by-layer traversal search is performed in the corresponding subgraph of the global system call graph to obtain the path search results.

[0009] Optionally, the cross-component calling relationship includes at least any one of the following: Upper-level interpreted components call lower-level compiled components, forming cross-level calling relationships; The inter-library calling relationships formed between compiled components.

[0010] This application also provides a system for determining the reachability of system software packages through vulnerability extraction. The system includes: a manifest construction module, a call graph construction module, a global fusion module, a symbol bridging module, a path search module, and a decision output module, which are respectively used to execute the corresponding steps in the above methods.

[0011] Optionally, the path search module is configured to perform a bounded breadth-first search starting from the set of dynamically exported symbols of each component, and to support backtracking search from the entry point for script-type components.

[0012] Optionally, the symbol bridging module adopts a hierarchical matching strategy and generates delayed audit records for ambiguous symbols.

[0013] Optionally, the alignment recovery of the stripped symbols based on the topological prior of the source code-side call graph includes: Based on the known symbols shared by the source code side and the binary side, determine the anchor point set, and based on the anchor point set, perform bounded topological traversal on the call graphs on both sides to obtain the structural position features of each anonymous node. Based on the structural location features and the constant attribute features of the corresponding nodes on the source code side, a multi-dimensional similarity fusion scoring is performed to obtain the comprehensive matching score of each anonymous node. If the overall matching score meets the preset confidence conditions, symbol recovery annotation is performed on the anonymous nodes to obtain the recovered function symbols.

[0014] The technical solution of this application can achieve the following beneficial effects: 1. This application generates discrete reachability states by searching bounded paths with exported symbols as entry points, excluding unreachable vulnerabilities from high-risk alerts, and distinguishing between three types of conclusions: exported reachable, internally reachable only, and insufficient evidence. This alleviates alert fatigue and patch priority confusion caused by matching component versions with vulnerability existence in traditional binary component analysis.

[0015] 2. This application is based entirely on purely static call graph analysis. The decision results are independent of the operating environment and can be independently reproduced. It outputs structured decisions and path details, providing a stable and interpretable technical basis for supply chain security review and patching decisions. In addition, this application adopts a divide-and-conquer strategy of independently building and merging graphs for each component, making the analysis scale related to the complexity of a single component rather than the overall package size, thus balancing the feasibility of the analysis and the completeness of the decisions. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall process of the vulnerability derivation and reachability determination method provided in the embodiments of this application.

[0017] Figure 2 This is a schematic diagram of the system module architecture provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0020] This embodiment provides a method for determining the reachability of system software packages due to vulnerabilities, using .deb binary packages from the Debian distribution as the analysis object for detailed explanation. For example... Figure 1 As shown, the method includes the following steps: S100: Unpack the target binary software package and scan the runtime components within it based on the unpacking results to obtain a component list.

[0021] This step involves analyzing the target binary software package, which is a compiled and packaged operating system-level installation package. Taking the Debian ecosystem as an example, the target binary software package is specifically a .deb format binary installation package, which internally encapsulates compiled shared library files, executable programs, script modules, configuration files, and other runtime resources.

[0022] The unpacking operation expands the archive structure of the target binary software package to a specified directory on the local file system. Specifically, for .deb format packages, the unpacking process extracts all files from its data.tar archive layer, restoring the original directory hierarchy.

[0023] For example, after unpacking the target binary package named libexample1_2.4.1-3_amd64.deb, a complete file tree containing subdirectories such as usr / lib / , usr / bin / , and usr / share / is generated under the local directory unpack / . The usr / lib / x86_64-linux-gnu / directory contains shared library files such as libexample.so.2.4.1, and the usr / bin / directory contains executable program files such as example-cli.

[0024] During unpacking, the system may optionally obtain a debug symbol package of the same version as the target binary software package and merge it into the local unpacking directory. The .symtab symbol table information contained in the debug symbol package can provide enhanced basis for symbol recovery in subsequent steps.

[0025] The unpacking results are then used to perform a depth-first traversal of the expanded file tree, determining the runtime attributes of each file. This scanning process excludes non-runtime components, including static resources that do not participate in program execution, such as documentation files, man pages, license files, and intermediate compilation artifacts. The exclusion rules are based on a combination of file path prefixes and extensions. For example, if a file path contains document-type path segments such as / doc / , / man / , or / share / locale / , or if the file extension is a non-executable type such as .txt, .md, .html, or .css, the file is identified as a non-runtime component and excluded from subsequent analysis.

[0026] The identification process involves classifying and registering runtime components that have passed the scanning screening based on the binary format characteristics and file extensions. The classification system for runtime components includes three types: ELF components, Python script components, and Java bytecode components.

[0027] The identification of ELF components is determined by reading the magic byte sequence in the file header. When the first 4 bytes of the file are 0x7f454c46, it is confirmed to be in ELF format. Furthermore, it is further distinguished into shared library type and executable program type based on the SONAME field and file permission bits in its dynamic segment.

[0028] The identification of Python script artifacts is based on the presence of the Python interpreter path in the .py extension or the shebang declaration at the beginning of the file.

[0029] The identification of Java bytecode components is based on the existence of the .jar extension and its internal META-INF / MANIFEST.MF manifest file.

[0030] While classifying and registering, the identification process extracts and exports symbol information for each component and counts the number of exported symbols.

[0031] For ELF components, the dynamically exported symbol set is obtained by parsing the symbol table entries marked as GLOBAL and of type FUNC in their .dynsym section.

[0032] For example, after performing exported symbol extraction on libexample.so.2.4.1, a set of 127 exported function symbols, including example_init, example_process, example_cleanup, etc., is obtained.

[0033] For Python script artifacts, module-level function definitions and class definitions are treated as their exported interfaces, and all top-level def and class declarations are extracted through abstract syntax tree parsing.

[0034] For Java bytecode artifacts, class methods modified by public are considered as their exported interfaces.

[0035] The final component list is a structured asset registration data, which includes attribute fields such as the type identifier, relative path, number of exported symbols, and file size of each component.

[0036] For example, after a complete scan and identification of the libexample1 package, the resulting component list contains the following entries: The libexample.so.2.4.1 library is of type ELF shared library, with a relative path of usr / lib / x86_64-linux-gnu / libexample.so.2.4.1 and 127 exported symbols. The example-cli is an ELF executable program with a relative path of usr / bin / example-cli and 3 exported symbols. The example_wrapper.py file, which is a Python script, has a relative path of usr / lib / python3 / dist-packages / example_wrapper.py and exports 12 interfaces, and so on.

[0037] S200, for the components in the component list, independently construct function call graphs and extract the exported symbols of each component; perform alignment restoration on the stripped symbols based on the topological prior of the source code side call graph to obtain the restored local call graph of each component.

[0038] This step involves iteratively performing independent function call graph construction and symbol recovery processing for each component registered in the component list. Specifically: S210, construct function call graphs independently for each component in the component list.

[0039] For ELF type artifacts, the function call graph is constructed using static disassembly. Specifically, the .text section of the ELF file is recursively disassembled to identify function entry points and trace the call instructions within each function body. When the disassembler detects a CALL instruction, a directed call edge is established with the current function as the caller node and the function corresponding to the call target address as the callee node. For cases where external symbols are indirectly called through the procedure linking table, call edges are established after resolving the procedure linking table stub functions to their corresponding dynamic symbol names. After traversing and analyzing all function bodies within the artifact, an original function call graph containing a set of function nodes and a set of call edges is generated.

[0040] For example, after performing static disassembly on libexample.so.2.4.1, a total of 342 function entry points were identified, of which 127 were named dynamically exported functions, and 215 were anonymous internal functions whose address identifiers were retained only after symbol stripping. The generated original function call graph contains 342 nodes and 1876 directed call edges, where the anonymous internal functions are marked in the format of sub_ followed by a hexadecimal address, such as sub_0x4a120, sub_0x4b350, etc.

[0041] S220, extract the exported symbols of each component.

[0042] The extraction of exported symbols is performed synchronously with the construction of the function call graph. For ELF components, all entries with binding attributes of GLOBAL or WEAK and symbol type FUNC are selected from their .dynsym dynamic symbol table, and a mapping relationship is established between the names of these symbols and their corresponding virtual addresses. The extracted set of exported symbols serves a dual purpose: firstly, it serves as the starting point set for subsequent bounded path search steps; secondly, it serves as a common anchor point source for both sides of the call graph during the alignment and restoration process in the current step.

[0043] S230 performs alignment restoration on stripped symbols based on the topological prior of the source code side call graph.

[0044] The source code-side call graph is a function-level call relationship graph constructed based on the same version of open-source code of the target binary software package. Specifically, the source code-side call graph is obtained as follows: based on the package name and version identifier of the target binary software package, a source code snapshot matching the binary build version is retrieved from the corresponding open-source code repository. Static call analysis is performed on the range of source files related to the current vulnerability in the source code snapshot to generate a local call relationship graph that only covers the neighborhood of the vulnerability-related functions. The source code-side call graph is pre-generated by the upstream patch analysis process and passed into this method.

[0045] It should be noted that the source code-side call graph used in this embodiment does not replace binary analysis. Instead, it utilizes the complete function symbol names preserved in the source code as a topology reference to address the issue that after symbol stripping, the internal function names in the release version binary degenerate into anonymous address identifiers, making it impossible to establish a correspondence with the vulnerability knowledge base. Pure static source code analysis cannot reflect the impact of compiler optimizations, linker reordering, and release-specific patches on the actual binary call topology. Therefore, this method uses the call graph obtained from the actual disassembly of the binary as the judgment benchmark, and the source code-side call graph is only used as an auxiliary reference for symbol recovery, not as the basis for judgment.

[0046] To address potential differences between the source code version and the binary build version, this method employs the following fault-tolerance mechanisms: First, the alignment recovery uses exported symbols as anchor points. These exported symbols remain highly stable within the same major version (as they constitute an external API contract), ensuring a reliable anchor point set even with minor version patch differences. Second, the comprehensive matching score... The confidence threshold mechanism (automatic recovery can only be performed if the confidence level is not lower than 0.35) has the ability to filter the topological variations introduced by version deviation. That is, when the local topology of the source code and binary is significantly offset due to version difference, the score of the candidate matching pair will be lower than the threshold and will be rejected for recovery, thereby avoiding incorrect labeling. Thirdly, the propagation naming inference only performs one-hop range expansion and strictly requires that the uniqueness conditions on both sides be met at the same time, further limiting the scope of error propagation caused by version difference.

[0047] The topological prior refers to the structural position information of each function node in the call graph on the source code side, including the call and called relationships between nodes, the graph distance of a node from a known anchor point, and topological attributes such as the in-degree and out-degree of a node. Alignment restoration is performed using this topological prior because although the compilation process changes the binary representation of functions, the call topology between functions is highly conservative between the source code and the binary representation; that is, the relationship of function A calling function B in the source code is likely to remain unchanged in the compiled binary representation.

[0048] The specific execution process of alignment restoration includes: determining an anchor point set based on known symbols shared by the source code side and the binary side. This anchor point set consists of exported symbol nodes with identical names in both call graphs. Then, using this anchor point set as a starting reference, a bounded topological traversal is performed on both call graphs to collect the structural position features of each anonymous node relative to the anchor points. This bounded topological traversal expands layer by layer from the anchor points in a breadth-first manner, and the traversal depth is constrained by the maximum number of hops.

[0049] For example, after determining the anchor set for libexample.so.2.4.1 and its corresponding source code-side call graph, an anchor set containing five common exported symbols, such as example_init, example_process, and example_cleanup, is obtained. Taking the anchor example_process as an example, a bounded topological traversal is performed on the source code-side call graph starting from this anchor. Under the constraint of a maximum hop count of 8, the traversed node set includes 23 nodes such as the internal functions parse_header, validate_input, and transform_data. The shortest path hop count, in-degree, and out-degree of each node from the anchor are recorded. The same traversal operation is performed on the same anchor node on the binary-side call graph. Within the constraint range, the node set includes 19 anonymous nodes such as sub_0x4a120, sub_0x4b350, and sub_0x4c780. Their topological position characteristics are also recorded.

[0050] After obtaining the structural location features of each anonymous node, a multi-dimensional similarity fusion score is performed by combining the constant attribute features of the corresponding nodes from the source code side. The constant attribute features here include the set of immediate constants appearing within the function bodies of the source code and the set of immediate constants in the function entry region of the binary representation. The multi-dimensional similarity fusion score calculates the topological similarity for each pair of candidate matching nodes. Similarity to constants To obtain a comprehensive matching score .

[0051] The topological similarity The calculation comprehensively considers the consistency of the structural position of candidate node pairs in their respective call graphs, and is specifically composed of three weighted components: in-degree difference, out-degree difference, and hop count difference from the nearest anchor point.

[0052] For example, for the source code-side node `parse_header` and the binary-side candidate node `sub_0x4a120`, the source code-side node has an in-degree of 2, an out-degree of 4, and a hop count to the nearest anchor of 1, while the binary-side candidate node has an in-degree of 2, an out-degree of 3, and a hop count to the nearest anchor of 1. The calculated topological similarity is... It is 0.87.

[0053] Among them, the constant similarity The intersection-union ratio of the immediate constant sets of the source code side and the binary side nodes is obtained by calculating the Jaccard coefficients.

[0054] For example, the `parse_header` function body on the source code side contains a set of five immediate values, including 0x0D0A, 0x2F, 0x48, 256, and 1024. The `sub_0x4a120` function entry region on the binary side also contains a set of five immediate values, including 0x0D0A, 0x2F, 0x48, 256, and 2048. The intersection of the two sets is four elements, and the union is six elements. The resulting constant similarity... for .

[0055] The overall matching score here is:

[0056] In the formula, This is the topology weight coefficient, with a value of 0.6. For example, for the matching pair of parse_header and sub_0x4a120 mentioned above, .

[0057] When the overall matching score meets a preset confidence level, symbol recovery annotation is performed on the anonymous node. The preset confidence level is that the overall matching score is not lower than a threshold of 0.35, and there are no collisions within the current component where the same source code symbol maps to multiple binary candidates. When the preset confidence level is met, the identifier of the anonymous node on the binary side is renamed from the sub_address format to the function symbol name of the corresponding node on the source code side.

[0058] For example, after alignment and restoration, sub_0x4a120 is labeled as parse_header, and sub_0x4b350 is labeled as validate_input. When the overall matching score is between 0.15 and 0.35, the candidate matching pair is only recorded for subsequent manual review, and automatic renaming is not performed. When the overall matching score is below 0.15, it is judged as a mismatch and the candidate pair is rejected, and so on.

[0059] S240, based on the nodes that have completed symbol recovery and their calling edge relationships, perform propagational naming inference on adjacent unrecovered nodes to expand the coverage of the symbol recovery.

[0060] After completing the alignment recovery based on multidimensional similarity scoring, neighborhood propagation is performed on the nodes of the recovered symbols to expand naming coverage. The triggering condition for the propagation naming inference is: a node of a recovered symbol has one and only one unnamed directly called node in the binary-side call graph, and the corresponding caller node in the source code side also has one and only one directly called node.

[0061] When the above uniqueness conditions are met simultaneously, the unnamed node inherits the symbolic name of the corresponding called node from the source code side. The propagation performs a one-hop range extension, that is, it only performs inference on the directly adjacent unrecovered nodes of the recovered node, without performing multi-hop recursive propagation.

[0062] For example, the recovered node `parse_header` calls only one unnamed node `sub_0x4d210` in the binary-side call graph, and similarly, `parse_header` only calls one internal function `read_chunk` in the source code side. The propagational naming inference marks `sub_0x4d210` as `read_chunk`. After propagational naming inference, the symbol recovery coverage of `libexample.so.2.4.1` in this embodiment is improved.

[0063] After symbol recovery is completed, the system performs neighborhood pruning and edge count budget control on the local call graphs of each component to limit the computational scale of subsequent analysis. Specifically, the neighborhood pruning uses vulnerability symbol nodes and dynamically derived symbol nodes as seed sets. Bounded traversal is performed from the seed nodes along the directions of both the calling and called edges, retaining the nodes reached and edges traversed, and removing nodes and edges outside the reachable range of the seed nodes from the local call graph. This neighborhood pruning ensures that the local call graph retains only the graph structure regions related to vulnerability reachability determination, excluding isolated subgraphs unconnected to the seed nodes.

[0064] When the number of edges in the pruned local call graph exceeds a preset edge count budget, the system gradually shrinks the graph by progressively reducing the traversal depth. In this embodiment, the edge count budget is set to 50,000 edges. When the number of edges in the local call graph exceeds this budget, the system gradually decreases the traversal depth from the initial value. After each decrease, neighborhood pruning is re-executed and the edge count is checked until the edge count does not exceed the budget limit. During the decrease process, the system prioritizes preserving the direct edges of seed nodes; that is, edges with a depth of 1 are always retained and not pruned, ensuring that the direct call and called relationships of seed nodes remain intact and usable.

[0065] For example, for an ELF component containing a large number of internal utility functions, the local call graph after initial pruning contains 67,000 edges, exceeding the budget limit of 50,000. The system then reduces the traversal depth from 8 to 6 and prunes it again, resulting in a local call graph containing 43,000 edges that meets the budget constraint.

[0066] For Python script components and Java bytecode components, the system constructs their internal local call graphs through abstract syntax tree analysis and class method relationship resolution, respectively.

[0067] In the Python script component's local call graph, module-level functions are defined as nodes, and function calls to other functions within the function body are defined as edges.

[0068] The local call graph of a Java bytecode component uses class methods as nodes and call instructions such as invokevirtual and invokestatic within the method body as edges.

[0069] Finally, all nodes in the local call graph of each component are rewritten into a globally unique identifier format carrying a component type prefix and a relative path, in preparation for node merging in the subsequent global fusion step.

[0070] After the complete processing of function call graph construction, exported symbol extraction, alignment restoration, propagational naming inference, and neighborhood pruning and edge count budget control, each component obtains its restored local call graph. The nodes in the restored local call graph carry named symbol identifiers as much as possible and the graph size is subject to budget constraints, providing controllable node identifiers for subsequent global fusion and vulnerability symbol bridging.

[0071] S300, based on the cross-component call relationship between the components, the restored local call graphs of the components are merged to obtain a global system call graph.

[0072] This step merges the independently constructed local call graphs of each component into a unified graph model covering all runtime components of the entire software package by detecting and connecting cross-component call relationships. Specifically: S310, Detect the cross-component calling relationship between the components.

[0073] The cross-component call relationship refers to the function-level call dependency established between different runtime components through specific language mechanisms or operating system mechanisms. Since the components within a software package may be implemented based on different programming languages ​​and run in different execution environments, the call relationship between components cannot be obtained through disassembly analysis within a single component. Therefore, it is necessary to identify it through dedicated cross-component call detection logic.

[0074] The cross-component call relationships here include two main types: cross-layer call relationships formed when upper-level interpreted components call lower-level compiled components through language extension mechanisms, and inter-library call relationships formed between compiled components through dynamic linking mechanisms. The call edges generated by these two types of cross-component call relationships are collectively referred to as glue edges, which are used to break down call graph silos between different language ecosystems.

[0075] For detecting cross-layer call relationships, the system scans import statements and ctypes loading calls in Python script components to identify the script layer's entry point for calling ELF shared libraries. Specifically, when an import statement in a Python script imports a C extension module, the system searches for an ELF shared library file with a name matching that module in the component manifest. It then parses the statement in the Python module calling an exported function of that extension module into a cross-layer call edge from the script-side call node to the ELF-side exported symbol node. Furthermore, calls to the executable program via the subprocess module or the os.system function are also detected as cross-layer call relationships, establishing a call edge from the script call point to the executable program's entry point.

[0076] For example, in the libexample1 package, the Python script example_wrapper.py contains the import _example_native statement. The system detects that the ELF shared library corresponding to _example_native is _example_native.cpython-311-x86_64-linux-gnu.so. Therefore, the call to the _example_native.process_batch function in the script is parsed as a cross-layer call edge, with its source being the example_wrapper.process_batch node on the Python side and its destination being the process_batch_impl function node called internally by the PyInit__example_native exported symbol node on the ELF side.

[0077] For detecting inter-library call relationships, the system parses the NEEDED entries recorded in the .dynamic section of the ELF executable and shared libraries to obtain the dynamic link dependency lists declared by each component. When the NEEDED list of a component contains the SONAME of another ELF component within the same package, the system matches the external symbols referenced in the calling component through the procedure link table with the dynamically exported symbols of the called component, and establishes an inter-library call edge for each successfully matched symbol pair.

[0078] For example, if the executable program example-cli declares a dependency on libexample.so.2 in its .dynamic section, the system will match the references to external symbols such as example_init and example_process in example-cli with the exported symbols of the same name in libexample.so.2.4.1, and establish three inter-library call edges, and so on.

[0079] S320, the restored local call diagrams of each component are merged to obtain a global system call diagram.

[0080] The fusion process first rewrites the globally unique identifiers of all nodes in the local call graph after each component is restored. The globally unique identifier consists of three parts: the component type prefix, the component relative path, and the original function symbol name, separated by colons.

[0081] For example, the `parse_header` function in `libexample.so.2.4.1` is rewritten as `elf:usr / lib / x86_64-linux-gnu / libexample.so.2.4.1:parse_header`, and the `process_batch` function in the Python script is rewritten as follows: py:usr / lib / python3 / dist-packages / example_wrapper.py:process_batch Rewriting the globally unique identifier here can eliminate the ambiguity of functions with the same name that may exist in different components, and ensure that each node has a unique addressable identifier in the merged global graph.

[0082] After rewriting the node identifiers, the fusion process performs a union of the node sets and edge sets of the local call graphs of each component, and adds all cross-component call edges detected above to the merged edge set. The resulting graph is the global system call graph, whose node set covers the function nodes of all runtime components within the software package, and whose edge set includes both function call relationships within each component and cross-component call relationships.

[0083] For example, after global fusion processing of the libexample1 package, the resulting global system call graph contains 389 nodes and 1923 directed edges. Of these, 342 nodes are from the restored local call graph of the ELF component libexample.so.2.4.1, 35 nodes are from the local call graph of the Python script component example_wrapper.py, and 12 nodes are from the local call graph of the ELF executable example-cli. The 1923 edges include 1876 internal call edges of ELF components, 28 internal call edges of Python scripts, 8 internal call edges of example-cli, 8 cross-layer call edges, and 3 inter-library call edges. This global system call graph serves as a unified analysis carrier for subsequent vulnerability symbol bridging and path search steps.

[0084] S400, based on a bridging strategy with decreasing confidence levels at multiple levels, maps vulnerability symbols from the source code side to target nodes in the global system call graph to obtain vulnerability anchoring results.

[0085] This step maps the vulnerability symbols from the source code side, passed in from the upstream patch analysis process, one by one to nodes with globally unique identifiers in the global system call graph, thus determining the endpoint for subsequent path searching. The vulnerability symbols are a set of function symbol names identified through patch difference analysis and associated with specific CVE vulnerabilities. Specifically: S410, based on the degree of matching between the vulnerability symbol and the node identifier in the global system call graph, perform multi-level bridging attempts sequentially from high to low confidence, so as to terminate the subsequent levels when the current level is successful.

[0086] In this embodiment, the alignment recovery in step S230 and the symbol bridging in step S410 have a clear hierarchical distinction in their functional positioning. The alignment recovery in S230 is a batch naming recovery operation for component call graph nodes, aiming to restore named identifiers for as many anonymous nodes as possible to improve the interpretability of subsequent global fusion and path search. The symbol bridging in S410, on the other hand, is a precise location operation for specific vulnerability symbols, aiming to determine a unique target node as the endpoint for each vulnerability symbol in the path search. When the results of both involve the same vulnerability symbol, this method uses the bridging result of S410 as the final decision-making basis, with the specific decision-making rules as follows: When S410 performs bridging, the system first checks if a node with the same name as the vulnerability symbol exists in the global system call graph after being restored and annotated by S230. If it exists and the node is within the target component where the vulnerability symbol is expected to be located, S410's precise matching layer directly hits the restored node, and the results of S230 and S410 are naturally consistent. If S410 locates a node different from the restored result of S230 through a higher confidence matching layer (such as dynamic exported symbol matching), the high confidence matching result of S410 is taken as the standard, because dynamic exported symbol matching is based on deterministic evidence of the actual exported table at runtime, and its reliability is higher than that of the restored annotation based on topological similarity scoring. In this case, the restored annotation of S230 is regarded as background enhancement information of the component call graph rather than the final conclusion of vulnerability location, and does not affect the determination of the path search endpoint.

[0087] In this embodiment, the multi-level confidence-decreasing bridging strategy divides the symbol mapping process into multiple levels, with each level attempting the mapping sequentially in descending order of confidence. When a level successfully completes mapping, subsequent levels with lower confidence will not attempt to bridge the symbol again. This strategy ensures that the bridging result for each vulnerable symbol is always taken from the highest available confidence match, preventing low-confidence matches from overwriting high-confidence results.

[0088] The highest confidence level of the multi-level bridging attempt is the exact match layer. At this layer, the system sequentially performs three exact match attempts for each vulnerability symbol: 1) Intra-component unique identifier exact match: searching for node identifiers with the exact same name as the vulnerability symbol within the target component where the vulnerability symbol is expected to be located; 2) Dynamically exported symbol match: checking whether the vulnerability symbol directly appears in the dynamic exported symbol set of a certain ELF component; 3) Source package name anchoring main library unique match: using the package name information of the vulnerability source package to locate the main shared library component, and searching for a unique match within that main library. Success in any of the three attempts terminates subsequent attempts at that layer.

[0089] For example, for the vulnerability symbol example_vulnerable_func, the system performs a unique identifier exact match within the component at the exact match layer. A unique matching node elf:usr / lib / x86_64-linux-gnu / libexample.so.2.4.1:example_vulnerable_func is found in the node set of the expected target component libexample.so.2.4.1. The bridging is successful, and the symbol will not enter the subsequent level of processing.

[0090] It should be noted that the method for determining the target component where the vulnerability symbol is expected to be located is as follows: The system matches the affected source package name recorded in the CVE vulnerability announcement associated with the vulnerability symbol with the source package name of each component in the component list obtained in step S100. Components whose source package name matches the affected package name in the CVE are identified as the expected target components of the vulnerability symbol. The source package name is obtained by parsing the metadata file of the binary software package (such as the Source field in a Debian-format control file or the Source RPM field in RPM format). When multiple components originating from the same source package exist within the same software package, all matching components are included in the target component scope. When the affected package name recorded in the CVE announcement cannot match the source package name of any component in the component list, the system expands the target component scope to all ELF type components within the software package and marks the component location as extended mode in the bridging result to prompt subsequent auditors to pay attention to the reliability of such bridging results.

[0091] In addition, to address the possibility that CVE announcement information may be inaccurate or coarse-grained, this method mitigates its impact through the following fault-tolerance mechanism: First, when the exact matching layer does not find a match within the target component range specified by the CVE, the system automatically enters the globally unique matching layer. This layer performs a search in all nodes of the global system call graph without being limited by the target component, thereby bypassing the impact of CVE component location errors. Secondly, although the topology alignment bridging layer is limited to execution within the target component, its matching basis is the similarity of the topology structure rather than the CVE text information. Even if the component granularity described by the CVE does not completely correspond to the actual component division, as long as the vulnerable function does exist in the call graph of a certain component and the topology features meet the threshold, bridging can still be completed. Third, the delayed audit log generated when all levels fail contains an analysis of the reasons for the failure, which security operations personnel can use to identify bridging failures caused by CVE information discrepancies and make manual corrections.

[0092] When the exact matching layer fails, the system activates the second-highest confidence level, namely the globally unique matching layer. At this level, the system searches for nodes matching the vulnerability symbol name across the entire set of nodes in the global system call graph. Bridging is considered successful if and only if a unique matching node exists globally, and that symbol name does not belong to a predefined set of generic function names. This set of generic function names includes generalized function names such as init, setup, parse, main, process, handle, and callback, which frequently appear in various software projects. These names lack specificity and are unsuitable as criteria for globally unique matching. When a vulnerability symbol belongs to the set of generic function names, even if only one matching node exists globally, the system still marks the symbol as ambiguous and refuses bridging.

[0093] For example, for the vulnerability symbol calc_overflow_boundary, after the exact matching layer fails due to no complete match within the target component range, it enters the globally unique matching layer. The system searches for the only node containing the name calc_overflow_boundary among the 389 nodes in the global system call graph: The code `elf:usr / lib / x86_64-linux-gnu / libexample.so.2.4.1:calc_overflow_boundary` indicates that the name is not part of the generic function name set, and the bridging is successful.

[0094] When the globally unique matching layer also fails, the system activates the lowest confidence level, namely the topology alignment bridging layer. At this layer, the system reuses the alignment scoring mechanism established in step S230 to perform similarity scoring on the topological position of the vulnerability symbol in the source code-side call graph and on candidate nodes in the global system call graph that have not yet been bridged. When a candidate node has a comprehensive matching score... A successful bridging is determined when the similarity is not less than 0.35 and the node is located within the component where the vulnerability symbol is expected to be. The topology alignment bridging layer introduces structural similarity constraints, which have higher uncertainty than the deterministic matching conditions of the previous two levels, and are therefore placed with the lowest priority.

[0095] Furthermore, regarding the aforementioned vulnerability symbol calc_overflow_boundary, assuming that in step S230, the binary side node sub_0x4c780 is restored to be labeled as calc_overflow_boundary based on topology alignment (the overall matching score is 0.52), during the execution of step S410, the system enters the globally unique matching layer and searches for the node in all nodes of the global system call graph: elf:usr / lib / x86_64-linux-gnu / libexample.so.2.4.1:calc_overflow_boundary This node is the sub_0x4c780 node after restoration of the annotation in S230. Both point to the same physical node, and the results are consistent. If the restored annotation node in S230 and the matching node in S410 point to different addresses due to differences in component trimming boundaries, the system uses the matching result obtained by S410 based on global graph search as the final target node.

[0096] S420, if all bridging attempts at all levels fail to meet the preset confidence conditions, the vulnerability symbol is marked as pending audit status and excluded from subsequent path searches.

[0097] For vulnerability symbols that fail to map successfully after all three levels of bridging attempts, the system marks them as pending audit status and generates a delayed audit record. The delayed audit record includes the vulnerability symbol name, associated CVE identifier, reasons for failure of each level of bridging attempts, and a list of candidate matching nodes, for subsequent manual review and judgment by security operations personnel. Vulnerability symbols marked as pending audit status do not participate in subsequent path search steps, and their final reachability status will be categorized as unknown in the graph.

[0098] For example, for the vulnerability symbol `internal_helper_v2`, the exact matching layer fails to match due to a collision caused by the existence of two nodes with the same name within the target component (located in two different versions of the internal helper function). The globally unique matching layer fails because there are multiple matching candidates. The topology alignment bridging layer fails because the highest candidate score is only 0.28, which does not reach the 0.35 threshold. The system marks this symbol as pending auditing and outputs a delayed audit record, recording the failure reasons as multiple candidate collisions and low confidence scores.

[0099] After the multi-level confidence-decreasing bridging strategy is applied, each successfully bridged vulnerability symbol obtains a globally unique identifier for its corresponding target node in the global system call graph. The vulnerability anchoring result is the mapping set of all successfully bridged vulnerability symbols and their target nodes.

[0100] S500, based on the vulnerability anchoring result, starting from the exported symbols of each component, perform a path search that satisfies depth constraints in the global system call graph, and obtain the vulnerability's exported reachability status based on whether there is a path to the target node.

[0101] This step uses the exported symbols of each component as the starting point of the search and the target node determined in the vulnerability anchoring results as the search endpoint. A depth-constrained path search is performed in the global system call graph to determine whether a static path exists from the exported symbol to the vulnerable function via the function call chain. Specifically: S510, perform a pre-judgment based on the exported attributes of the target node itself, so as to directly obtain the reachability determination result when the exported attributes are satisfied, and skip graph traversal.

[0102] The pre-judgment is a rapid screening mechanism before path search execution. For each target node successfully anchored via bridging, the system checks whether the function symbol corresponding to the node also exists in the dynamic exported symbol set of its component. When the target node itself is an exported symbol, it means that the vulnerable function is directly exposed in the component's external interface, and external callers can directly access the function without any intermediate call chain. Therefore, its exported reachability status can be directly determined as reachable without performing a graph traversal search.

[0103] For example, the vulnerable symbol example_vulnerable_func is anchored to the target node elf:usr / lib / x86_64-linux-gnu / libexample.so.2.4.1:example_vulnerable_func after bridging. The system checks the set of dynamically exported symbols of libexample.so.2.4.1 and finds that example_vulnerable_func exists in the set. The system directly determines that the exported reachability status of the vulnerable symbol is reachable, and the path evidence record is zero-hop direct reachable.

[0104] S520, if the pre-judgment is not satisfied, then based on the starting point set formed by the derived symbols, perform a depth-constrained layer-by-layer traversal search in the corresponding subgraph of the global system call graph to obtain the path search results from the starting point to the target node.

[0105] When the target node does not have exported attributes, the system performs a bounded breadth-first search. The bounded breadth-first search starts from the set of nodes consisting of all dynamically exported symbols of the component to which the target node belongs. Within the subgraph corresponding to the component in the global system call graph, it expands layer by layer deeper along the call edges, starting simultaneously from each starting node. The bounded breadth-first search has a maximum jump step constraint; in this embodiment, the maximum jump step is 12, meaning the search depth does not exceed the range of 12 function call jumps from the starting point.

[0106] The maximum number of jump steps is determined based on the following: In typical shared library binary components, the average call depth from the exported function entry point to any internal function is usually distributed in the range of 3 to 8 jumps. Call chains exceeding 12 jumps in actual software typically correspond to recursive calls, callback loops, or deeply nested utility functions. These ultra-deep paths often do not constitute externally controllable linear triggering paths in actual operation. Setting the maximum number of jump steps to 12 can cover the vast majority of call paths with actual external triggering significance, while avoiding search space explosion caused by unconstrained traversal in large-scale call graphs.

[0107] It should be noted that the maximum number of jump steps is a configurable parameter and can be adjusted according to the call graph characteristics of the target software package in different application scenarios. When the search depth exceeds the maximum number of jump steps and the target node is still not reached, the system does not directly determine it as unreachable, but distinguishes and processes it based on the existence of the target node: if the target node does exist in the current component subgraph but is not reached by the search frontier within the depth constraint, its export reachability status is marked as internal call only. This mark indicates that no path to the export interface was found within the currently set search depth, rather than an assertion of absolute unreachability; if the target node is missing in the subgraph due to incompleteness in the graph construction stage, it is marked as graph unknown.

[0108] In addition, both the "internal call only" and "graph unknown" states are retained in the final decision output, allowing security operations personnel to review the results when necessary by increasing the depth parameters or supplementing with manual analysis.

[0109] When the search front reaches the target node within the depth constraint, the path is recorded and the search continues until all possible paths are exhausted or the maximum number of paths is reached. In this embodiment, a maximum of three shortest paths are retained for each vulnerability symbol as auditable evidence.

[0110] For example, for the vulnerable symbol `calc_overflow_boundary`, its anchored target node is `elf:usr / lib / x86_64-linux-gnu / libexample.so.2.4.1:calc_overflow_boundary`, which does not belong to the dynamically exported symbol set. The system uses all 127 exported symbol nodes of `libexample.so.2.4.1` as the starting point set and performs a bounded breadth-first search on the subgraph consisting of 342 nodes and 1876 edges of this component. During the search, starting from the starting node `example_process`, a path of 3 hops is found: 1 hop to `validate_input`, 2 hops to `parse_header`, and 3 hops to `calc_overflow_boundary`. Continuing the search, another path is found that leads from the starting node `example_init` to the same target node via 4 hops. The system retains these two paths as audit evidence.

[0111] S530 determines the export reachability status of a vulnerability based on path search results.

[0112] The derived reachability state is a discrete three-valued state classification result: When path search finds at least one path from the derived symbol to the target node that satisfies the depth constraint, the derived reachability state is determined to be reachable. When the target node exists in the subgraph but all derived symbol starting points cannot reach the target node within the depth constraint range, the derived reachability state is determined to be internal call only, indicating that although the vulnerable function exists in the component, it cannot be reached through the derived interface. When a definitive conclusion cannot be reached due to an incomplete graph structure or insufficient evidence of symbolic bridging, the derived reachability state is determined to be graph unknown.

[0113] For example, the vulnerable symbol calc_overflow_boundary is found to have a reachable path of length 3 hops through a bounded breadth-first search, and its derived reachability status is determined to be reachable. For another vulnerable symbol internal_debug_trace, its anchored target node exists in the subgraph, but none of the 127 derived symbol origins can reach the node within a 12-hop depth range, and its derived reachability status is determined to be internal call only.

[0114] S600, based on the derived reachability status, execute the supply chain aggregation rules to generate a decision, so as to obtain the supply chain reachability decision result.

[0115] This step, based on the exported reachability status, overlays multi-dimensional aggregation rules under the supply chain scenario to generate structured judgment results oriented towards secure operation decisions.

[0116] The supply chain aggregation rules include three levels of judgment dimensions, each level being distinct in terms of the judgment objects and granularity, and exhibiting a hierarchical progression: The first layer of judgment determines the landing type of the vulnerability symbol based on the component type attribute of the bridging anchor node, whether it is a shared library, main executable program, script layer, or unknown. This layer provides the type context of the component where the vulnerability is located.

[0117] The second-level judgment dimension targets software packages containing a main program. It checks whether the entry point of the main executable program can reach the target component containing the vulnerability symbol through cross-component call edges. Its judgment object is the dependency reachability between components rather than the function-level reachability within the component. This dimension is marked as not applicable to pure library software packages.

[0118] The third-level judgment dimension is consistent with the exported reachability status obtained in step S500, and its judgment object is the reachability of the function-level call path from the exported symbol to the vulnerable function within the target component.

[0119] It should be noted that there is a fundamental difference between the second and third layers in terms of the granularity of the judgment: The second layer answers the question "Does the main program depend on and call the component where the vulnerability resides?", which is a component-level dependency reachability determination. The third layer answers the question "Can the exported interface of the component where the vulnerability resides reach the vulnerable function through the internal call chain?", which is a function-level path reachability determination. The combination of the two provides a complete reach chain view from the external entry point of the software package to the vulnerable function: the second layer determines the connectivity from the external entry point to the component, and the third layer determines the connectivity from the component entry point to the vulnerable function.

[0120] When the second layer is determined to be "unreachable" (the main program entry point cannot reach the target component via cross-component call edges) and the third layer is determined to be "reachable" (exported symbols within the component can reach the vulnerable function via the call chain), the two conclusions are not contradictory: the third layer indicates that if an external caller directly links to the shared library and calls its exported functions, the vulnerability can be reached; while the second layer indicates that the main program within the current software package does not use the target component via this path. This combination is recorded in the final judgment as "exports within the component are reachable, but the main program does not use it," and security operations personnel comprehensively assess the actual risk based on whether the shared library is called by the main programs of other software packages in the system. The second layer determination is not a pre-gating condition for the third layer; the two are evaluated independently and output in parallel, jointly forming a multi-dimensional risk profile.

[0121] For example, for the vulnerability symbol calc_overflow_boundary in the libexample1 package, the first layer determines that its landing point type is a shared library (because it is anchored to libexample.so.2.4.1). In the second layer, since the example-cli executable program depends on libexample.so.2.4.1 through inter-library call edges and the entry point of example-cli can reach the exported interface of libexample.so.2.4.1 through the call chain, it is determined to affect the main program's execution surface. The third layer determines that it is reachable, consistent with the path search conclusion.

[0122] The supply chain reachability determination results are output in the form of structured records. Each record includes the CVE identifier of the vulnerability symbol, the value of the three-layer summary indicator, the bridging confidence level, and the specific node sequence of the derived path evidence. The system persists all determination records in JSONL format and outputs delayed audit records of bridging failures as auxiliary audit products, jointly supporting patch prioritization and supply chain risk assessment decisions.

[0123] like Figure 2 As shown in the figure, this embodiment also provides a system for determining the reachability of system software packages through vulnerability export. The system includes a manifest construction module, a call graph construction module, a global fusion module, a symbol bridging module, a path search module, and a decision output module.

[0124] The manifest construction module is used to unpack the target binary software package, scan and identify runtime components based on the unpacking results, and obtain a component manifest. The manifest construction module receives the file path of the target binary software package as input, performs processing operations such as archive unpacking, file traversal scanning, non-runtime component filtering, and runtime component classification and registration, and outputs a structured component manifest containing the type, path, and number of exported symbols for each component. The manifest construction module can be implemented by a processor executing corresponding program instructions from memory.

[0125] The call graph construction module is used to independently construct function call graphs for each component in the component list and extract the exported symbols of each component. Based on the topological prior of the call graph on the source code side, alignment and restoration are performed on the stripped symbols to obtain the restored local call graph of each component.

[0126] The call graph construction module receives the component list output by the list construction module and the externally input source code-side call graph as input. It performs static disassembly graph construction, symbol extraction, bilateral topological alignment scoring and symbol restoration annotation, and neighborhood propagation naming inference on each component, outputting the restored local call graph for each component. The call graph construction module can be implemented by the processor executing corresponding program instructions from memory.

[0127] The global fusion module is used to fuse the restored local call graphs of each component according to the cross-component call relationship between the components, so as to obtain a global system call graph.

[0128] The global fusion module receives the restored local call graphs of each component from the call graph construction module as input, performs cross-component call relationship detection, node global unique identifier rewriting, and graph merging operations, and outputs a global system call graph covering all runtime components. The global fusion module can be implemented by the processor executing corresponding program instructions in memory.

[0129] The symbol bridging module is used to map source code-side vulnerability symbols to target nodes in the global system call graph based on a multi-level confidence-decreasing bridging strategy, so as to obtain vulnerability anchoring results.

[0130] The symbol bridging module receives a set of vulnerability symbols from external input and a global system call graph output by the global fusion module as input. It performs bridging attempts sequentially in descending order of confidence: precise matching layer, globally unique matching layer, and topology alignment bridging layer. For successfully bridged symbols, it outputs their target node mappings; for symbols that fail to bridge, it outputs delay audit records. The symbol bridging module employs a hierarchical matching strategy and generates delay audit records for ambiguous symbols. The symbol bridging module can be implemented by a processor executing corresponding program instructions from memory.

[0131] The path search module is used to perform a path search that satisfies depth constraints in the global system call graph, starting from the exported symbols of each component, based on the vulnerability anchoring results, and to obtain the vulnerability's exported reachability status based on whether there is a path to the target node.

[0132] The path search module is used to perform a bounded breadth-first search starting from the set of dynamically exported symbols of each component, and supports backtracking search from the entry point for script-type components.

[0133] Specifically, for ELF artifacts, the path search module performs a breadth-first search starting from the set of all exported functions in the dynamically exported symbol table; for Python script artifacts, when no ELF export path is available, the path search module falls back to performing a bounded search from the entry point function of the script module towards the vulnerability node. The path search module can be implemented by the processor executing corresponding program instructions from memory.

[0134] The decision output module is used to generate a decision based on the derived reachability status by executing the supply chain aggregation rules, so as to obtain the supply chain reachability decision result and output it.

[0135] The decision output module receives the reachability status of each vulnerability symbol and path evidence output by the path search module as input, and performs a comprehensive judgment by overlaying the three-layer supply chain aggregation rules. It then generates a structured decision record containing multi-dimensional indicators and outputs it persistently in JSONL format. The decision output module can be implemented by a processor executing corresponding program instructions from memory.

[0136] The modules described above are sequentially connected via data interfaces: the output of the inventory construction module serves as the input of the call graph construction module; the output of the call graph construction module serves as the input of the global fusion module; the output of the global fusion module serves as the common input of the symbol bridging module and the path search module; the output of the symbol bridging module serves as another input of the path search module; and the output of the path search module serves as the input of the decision output module. The system schedules and executes each module in a pipelined manner.

[0137] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

[0138] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for determining the reachability of a system software package vulnerability, the method comprising: The target binary software package is unpacked, and the runtime components are scanned based on the unpacking results to obtain a component list; Build a function call graph for the components in the component list and extract the exported symbols for each component; Based on the topological prior of the source code side call graph, alignment restoration is performed on the stripped symbols to obtain the restored local call graph of each component; Based on the cross-component call relationships between components, the restored local call graphs of each component are merged to obtain the global system call graph; Based on a bridging strategy with decreasing confidence levels, vulnerability symbols on the source code side are mapped to target nodes in the global system call graph to obtain vulnerability anchoring results. Starting from the exported symbols of each component, and based on the vulnerability anchoring results, a path search is performed in the global system call graph to obtain the vulnerability's exported reachability status. Based on the derived reachability status, the supply chain aggregation rules are executed to generate a decision, thereby obtaining the supply chain reachability decision result.

2. The method according to claim 1, characterized in that, The alignment restoration of stripped symbols based on the topological prior of the source code-side call graph includes: Based on the known symbols shared by the source code side and the binary side, determine the anchor point set, and based on the anchor point set, perform bounded topological traversal on the call graphs on both sides to obtain the structural position features of each anonymous node. Based on the structural location features and the constant attribute features of the corresponding nodes on the source code side, a multi-dimensional similarity fusion scoring is performed to obtain the comprehensive matching score of each anonymous node. If the overall matching score meets the preset confidence conditions, symbol recovery annotation is performed on the anonymous nodes to obtain the recovered function symbols.

3. The method according to claim 2, characterized in that, The alignment restoration also includes: Based on the nodes that have completed symbol recovery and their calling edge relationships, propagational naming inference is performed on adjacent unrecovered nodes to expand the coverage of the symbol recovery.

4. The method according to claim 1, characterized in that, The method further includes: Based on the degree of matching between the vulnerability symbol and the node identifier in the global system call graph, multi-level bridging attempts are performed sequentially according to the confidence level, and subsequent levels are terminated when the current level is successful. If all bridging attempts at all levels fail to meet the preset confidence level, the vulnerability symbol will be marked as pending audit status and excluded from subsequent path searches. Each level of bridging attempt is performed based on symbol matching conditions of different granularities.

5. The method according to claim 1, characterized in that, The method further includes: Perform a pre-judgment based on the exported attributes of the target node; When the pre-determined exported attributes meet the preset requirements, the reachability determination result is obtained, and graph traversal is skipped; If the pre-determined exported attributes do not meet the preset requirements, then based on the starting point set formed by the exported symbols, a layer-by-layer traversal search is performed in the corresponding subgraph of the global system call graph to obtain the path search results.

6. The method according to claim 1, characterized in that, The cross-component calling relationship includes at least one of the following: Upper-level interpreted components call lower-level compiled components, forming cross-level calling relationships; The inter-library calling relationships formed between compiled components.

7. A system for determining the reachability of system software packages through vulnerability extraction, the system comprising: The manifest building module is used to unpack the target binary package and scan the runtime components within it based on the unpacking results to obtain a component manifest; The graph construction module is used to construct a function call graph for the components in the component list and extract the exported symbols of each component. Based on the topological prior of the source code side call graph, alignment restoration is performed on the stripped symbols to obtain the restored local call graph of each component; The global fusion module is used to fuse the restored local call graphs of each component according to the cross-component call relationship between each component, so as to obtain the global system call graph; The symbol bridging module is used to map vulnerability symbols from the source code side to target nodes in the global system call graph based on a bridging strategy with decreasing confidence levels, so as to obtain vulnerability anchoring results. The path search module is used to perform a path search in the global system call graph, starting from the exported symbols of each component and based on the vulnerability anchoring results, so as to obtain the export reachability status of the vulnerability. The decision output module is used to generate a decision by executing the supply chain aggregation rules based on the derived reachability status, so as to obtain the supply chain reachability decision result.

8. The system according to claim 7, characterized in that, The path search module is also used to perform a bounded breadth-first search starting from the set of dynamically exported symbols of each component, and supports backtracking search from the entry point for script-type components.

9. The system according to claim 7, characterized in that, The symbol bridging module employs a hierarchical matching strategy and generates delayed audit records for ambiguous symbols.

10. The system according to claim 7, characterized in that, The alignment restoration of stripped symbols based on the topological prior of the source code-side call graph includes: Based on the known symbols shared by the source code side and the binary side, determine the anchor point set, and based on the anchor point set, perform bounded topological traversal on the call graphs on both sides to obtain the structural position features of each anonymous node. Based on the structural location features and the constant attribute features of the corresponding nodes on the source code side, a multi-dimensional similarity fusion scoring is performed to obtain the comprehensive matching score of each anonymous node. If the overall matching score meets the preset confidence conditions, symbol recovery annotation is performed on the anonymous nodes to obtain the recovered function symbols.

Images