A static vulnerability detection method and system based on a unified cross-language program structure diagram
By constructing a unified cross-language program structure graph and performing interface semantic mapping and path confidence calculation, the semantic alignment and uncertainty problems in cross-language static vulnerability detection are solved, achieving highly accurate and interpretable cross-language vulnerability detection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- GUANGDONG UNIV OF PETROCHEMICAL TECH
- Filing Date
- 2025-12-12
- Publication Date
- 2026-07-03
AI Technical Summary
Existing technologies have shortcomings in cross-language semantic alignment, FFI semantic mapping, uncertainty measurement, and path-level constraint generation, resulting in poor accuracy and interpretability of cross-language static vulnerability detection, making it difficult to effectively apply to mixed language scenarios.
A unified cross-language program structure graph (UPSG) is constructed, interface semantic mapping relationships are established on the edges of cross-language interfaces, uncertain elements are extracted and labeled, path confidence is calculated, and heterogeneous language states are semantically aligned through cross-language abstract domains. Path conditions are converted into logical constraints for satisfiability determination, and a structured evidence chain is generated.
It achieves high-precision cross-language semantic alignment, reduces false alarm rate, systematically annotates uncertainties, provides highly interpretable audit evidence chains, breaks through the limitations of traditional symbolic execution in cross-language environments, and improves the accuracy and credibility of cross-language path analysis.
Smart Images
Figure CN121365405B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software security technology, and in particular relates to a static vulnerability detection method and system based on a unified cross-language program structure graph. Background Technology
[0002] With the continuous growth in performance requirements and functional complexity of modern software systems, multi-language mixed programming (such as combining low-level system languages with high-level scripting languages) has become a common development model to improve development efficiency and system capabilities. Such cross-language code libraries are widely used in cloud services, embedded systems, industrial control systems and other fields, but their complex interaction semantics also bring many challenges to software security analysis and vulnerability detection.
[0003] To ensure software security, industry and academia have proposed various static analysis and symbolic verification techniques, including:
[0004] Static analysis techniques based on a single language perform analysis based on the compiler front-end or intermediate representation of a specific language (such as Clang AST, LLVM IR, etc.). This includes data flow analysis within and between procedures, type and state checks, and memory safety detection. Although these techniques can construct program structures such as control flow graphs and call graphs within a single language and effectively identify specific security vulnerabilities, their analysis scope is limited by language boundaries and they cannot directly model and verify cross-language interaction behaviors.
[0005] Graph and graph matching analysis methods integrate multiple program representations (such as abstract syntax trees, control flow graphs, and program dependency graphs) into a unified graph structure, such as code attribute graphs, and identify potential vulnerabilities through graph traversal or pattern matching. Such methods can be applied in single-language or multilingual environments with similar grammatical structures, but they are insufficient in modeling capabilities when dealing with cross-language interactions with significant semantic differences.
[0006] Symbolic execution and constraint solving tools generate path constraints by symbolically simulating program execution and use SMT solvers to determine satisfiability, thereby detecting specific types of vulnerabilities. However, different languages have different memory models, type systems and execution semantics, and it remains a significant challenge to unify and abstract them into solvable logical constraints.
[0007] Cross-language detection schemes mainly develop in two directions. The first is to build a unified intermediate representation or a general graph structure, converting programs from different languages into a unified intermediate representation before performing pattern matching or data flow analysis. The second is to build enhanced interface recognition and binding analysis, identifying cross-language call relationships by recognizing external function interfaces or binding code, and combining this with cross-boundary static analysis using various single-language analyzers. In addition, some schemes attempt to introduce machine learning methods to assist in identifying suspicious code patterns, but their results usually lack interpretable formal evidence and are difficult to directly apply to security demonstrations in high-confidence scenarios.
[0008] The aforementioned existing technologies have significant shortcomings in cross-language semantic alignment. Unified intermediate representations or program graphs often lose key semantics at language boundaries. For example, the pointer semantics of the low-level language and the object semantics of the high-level language are difficult to align accurately at the boundary of external function interfaces, resulting in inaccurate modeling of state transition functions in cross-language paths, which affects the correctness of subsequent verification. At the same time, the semantic mapping of interfaces and bindings is incomplete, and there is a lack of sufficient modeling for cross-language parameter passing, type conversion, and memory semantics, making it difficult to determine the target function and program state of cross-language call edges. When facing dynamic characteristics such as reflection, indirect calls, or runtime code generation, there is a general lack of mechanisms to quantify and record the sources and confidence of path uncertainty, making it difficult to achieve effective priority ranking and accurate verification. More importantly, there is a lack of a general process to standardize heterogeneous program states on cross-language paths into constraint forms, making formal verification difficult to apply directly to mixed language scenarios.
[0009] In summary, existing technologies have significant shortcomings in four aspects: cross-language semantic alignment, FFI semantic mapping, uncertainty measurement, and path-level constraint generation, which restrict the accuracy and interpretability of cross-language static vulnerability detection. Summary of the Invention
[0010] To address the aforementioned technical problems, this invention proposes a static vulnerability detection method based on a unified cross-language program structure graph, comprising the following steps:
[0011] Based on the source code to be tested and its compilation metadata, a unified cross-language program structure graph including nodes of multiple programming languages is constructed, and interface semantic mapping relationship is established on the cross-language interface edge;
[0012] Extract the cross-language path from the program entry point to the sensitive operation point on the unified cross-language program structure graph, mark the elements with uncertainty in the cross-language path and calculate the path confidence;
[0013] Based on the cross-language abstract domain, the heterogeneous language states on the cross-language path are semantically aligned, and the path conditions and the conditions for the vulnerability to be established are converted into logical constraints.
[0014] The satisfiability of the logical constraints is determined, and the vulnerability detection result is output based on the determination result. A structured evidence chain including path traces, witness information, mapping records and confidence levels is generated.
[0015] Optionally, the specific process of constructing a unified cross-language program structure diagram and its interface semantic mapping relationships includes:
[0016] For different programming languages, abstract syntax trees or intermediate representations are generated separately, and control flow edges, data dependency edges, and call edges are extracted to form local program graphs for each language. The node sets of all local program graphs are merged into a unified cross-language program structure graph node set, preserving the original language type and language-specific attributes of each node. Cross-language interface edges are established between cross-language call points and target functions, and corresponding parameter type mapping rules, memory semantics and ownership rules, and exception or error handling mapping rules are associated with each cross-language interface edge to form an interface semantic mapping table.
[0017] Optionally, the specific process of extracting cross-language paths and calculating path confidence includes:
[0018] The cross-language path is preset as an alternating sequence of nodes and edges, with the starting point of the sequence being the program entry point and the ending point being the sensitive operation point. The sequence includes at least one cross-language interface edge. The maximum local confidence value is assigned to the statically determined elements in the path, and a local confidence value less than the maximum value is assigned to the elements with uncertainties. The uncertainties include multiple candidate targets of indirect calls, reflection mechanisms, or cross-language interface edges. The total confidence of the path is obtained by multiplying the local confidence values of all elements in the path, which is used to prioritize the candidate paths.
[0019] Optionally, the specific process of semantically aligning heterogeneous language states on cross-language paths based on cross-language abstract domains includes:
[0020] The system uniformly maps basic data types across language paths to symbolic variables or constants; it abstracts pointers or memory handles in low-level languages into tuples that include memory region identifiers, offsets within the region, and ownership status; it abstracts objects or buffers in high-level languages into structures that include memory region identifiers, lengths, and primitive language types; and it performs state transitions at the cross-language interface edge based on the interface semantic mapping table to complete parameter type mapping and memory ownership updates.
[0021] Optionally, the process of performing state transitions based on the interface semantic mapping table at the cross-language interface edge includes:
[0022] The application parameter type mapping rules are used to implement type conversion and value passing of symbolic variables; the ownership field of the relevant memory region identifier is updated according to memory semantics and ownership rules, and new memory regions are created or memory region aliases are established according to the parameter passing method.
[0023] Optionally, the specific process of converting path conditions and vulnerability fulfillment conditions into logical constraints includes:
[0024] Abstract state transitions are executed sequentially along the cross-language path, and control flow constraints, state transition constraints, and interface mapping constraints are accumulated into path conditions through conjunction operations. For sensitive operation points, vulnerability conditions are constructed according to vulnerability patterns. The condition for a buffer overflow vulnerability is that the access index is less than zero or greater than or equal to the buffer length, and the condition for a null pointer dereference vulnerability is that the memory region identifier pointed to by the pointer is a null address region. The path conditions and vulnerability conditions are combined into an existence quantifier constraint formula to complete the transformation of logical constraints.
[0025] Optionally, the specific process of performing a satisfiability determination on the logical constraints, outputting vulnerability detection results based on the determination result, and generating a structured chain of evidence including path traces, witness information, mapping records, and confidence levels includes:
[0026] When the logical constraints are satisfied, the specific input values or indices that trigger the vulnerability are extracted from the model returned by the solver as witness information; the complete cross-language program execution path, the witness information, the interface semantic mapping record applied at the cross-language call boundary, the path confidence value, and the solver's judgment result are combined to form a structured chain of evidence.
[0027] This invention also provides a static vulnerability detection system based on a unified cross-language program structure graph, used to implement the method described above, the system comprising:
[0028] The input acquisition and preprocessing module is used to generate abstract syntax trees or intermediate representations for each programming language based on the source code to be detected and its compilation metadata.
[0029] The graph construction and indexing module is used to merge the abstract syntax trees or intermediate representations of various languages into a unified cross-language program structure graph, and to establish interface semantic mapping relationships on the cross-language interface edges;
[0030] The path analysis and priority evaluation module is used to extract cross-language paths from the program entry point to sensitive operation points on the unified cross-language program structure graph, mark elements with uncertainties in the path, and calculate the path confidence.
[0031] The abstract interpretation and formal verification module is used to perform semantic alignment of heterogeneous language states on cross-language paths based on cross-language abstract domains, convert path conditions and vulnerability conditions into logical constraints, and determine the satisfiability of logical constraints.
[0032] The evidence, alarm management and storage module is used to output vulnerability detection results based on the judgment results, and generate a structured evidence chain including path traces, witness information, mapping records and confidence levels.
[0033] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method.
[0034] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method.
[0035] Compared with the prior art, the present invention has the following advantages and technical effects:
[0036] High-precision cross-language semantic alignment: By preserving language-specific semantic nodes and interface semantic mapping tables in UPSG, this invention can accurately model type conversions, memory ownership, and lifecycle changes on FFI boundaries, significantly improving the accuracy of cross-language data flow and control flow analysis and reducing false alarm rates.
[0037] Systematic Uncertainty Labeling: This invention introduces a path confidence mechanism that can systematically label and quantify the uncertainty of the target caused by dynamic characteristics such as indirect calls and reflections. This allows analysis results to be efficiently sorted by confidence level, prioritizing the verification of high-confidence paths, thereby focusing analytical resources on the most suspicious defects.
[0038] Path-level formal verification: This invention defines a special cross-language abstract domain and constraint generation strategy, and for the first time provides a general process for normalizing heterogeneous language mixed states into SMT constraints, realizing automatic formal satisfiability verification of complex cross-language paths, breaking through the limitations of traditional symbolic execution in cross-language environments.
[0039] Highly interpretable audit evidence chain: This invention can output a structured and complete cross-language evidence chain, clearly showing the witness information of the vulnerability path and triggering conditions, as well as the details of cross-language conversion, which strongly supports manual review, vulnerability repair and other work. Attached Figure Description
[0040] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:
[0041] Figure 1 This is a schematic diagram of the method flow according to an embodiment of the present invention;
[0042] Figure 2 This is a schematic diagram of the system structure according to an embodiment of the present invention. Detailed Implementation
[0043] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.
[0044] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.
[0045] Example 1
[0046] like Figure 1 As shown, this embodiment provides a static vulnerability detection method based on a unified cross-language program structure graph, which aims to solve the following technical problems:
[0047] (1) A unified cross-language program structure graph representation (UPSG) is proposed, which can preserve language-specific semantics and is easy to implement in engineering. The representation defines clear interface semantic mappings (including parameter type conversion, memory semantic description, etc.) at language boundaries to achieve traceability and alignment of cross-language semantic states.
[0048] (2) Design a cross-language path extraction mechanism with uncertainty labeling and confidence calculation. When encountering target uncertainty caused by reflection, indirect calls or FFI, this method can identify the source of uncertainty and calculate the confidence value of candidate paths, providing a basis for subsequent path screening and priority ranking.
[0049] (3) Propose a set of rules to map heterogeneous abstract states on cross-language paths to SMT or other constraint forms, determine the satisfiability of candidate paths, and output structured verification evidence for manual review.
[0050] The method specifically includes the following steps:
[0051] Based on the source code to be tested and its compilation metadata, a unified cross-language program structure graph including nodes of multiple programming languages is constructed, and interface semantic mapping relationship is established on the cross-language interface edge;
[0052] Extract the cross-language path from the program entry point to the sensitive operation point on the unified cross-language program structure graph, mark the elements with uncertainty in the cross-language path and calculate the path confidence;
[0053] Based on the cross-language abstract domain, the heterogeneous language states on the cross-language path are semantically aligned, and the path conditions and the conditions for the vulnerability to be established are converted into logical constraints.
[0054] The satisfiability of the logical constraints is determined, and the vulnerability detection result is output based on the determination result. A structured evidence chain including path traces, witness information, mapping records and confidence levels is generated.
[0055] The feasible process for constructing a unified cross-language program structure graph and its interface semantic mapping relationships includes:
[0056] For different programming languages, abstract syntax trees or intermediate representations are generated separately, and control flow edges, data dependency edges, and call edges are extracted to form local program graphs for each language. The node sets of all local program graphs are merged into a unified cross-language program structure graph node set, preserving the original language type and language-specific attributes of each node. Cross-language interface edges are established between cross-language call points and target functions, and corresponding parameter type mapping rules, memory semantics and ownership rules, and exception or error handling mapping rules are associated with each cross-language interface edge to form an interface semantic mapping table.
[0057] As an optional implementation, this embodiment collects necessary information for static analysis to reduce misjudgments caused by missing build information. This mainly includes: source code, compilation metadata, FFI declarations, third-party library symbol tables and type information, configurations, and strategies. For modules lacking build information, they can be recorded as "external / unknown compilation context" and marked with special attributes in UPSG to reduce the confidence level of the corresponding path.
[0058] For different programming languages, generate accurate Abstract Syntax Trees (ASTs) or Intermediate Representations (IRs) respectively, and construct corresponding local program graphs (including CFGs, call edges, data dependencies, etc.). The main operations include: (1) Using corresponding parsers or front-ends for different languages (e.g., Clang / LibTooling for C / C++; ast or typed_ast for Python; JavaParser for Java, etc.) and converting them into a unified format AST or IR. (2) Defining node types (function entry, call point, load / store, allocation / release, array index, member access, return, etc.) and edge types (control flow edge, data dependency edge, call edge, parameter passing edge) and extracting them from the AST / IR.
[0059] To ensure the accuracy of the program graph, type information, including basic types, symbol tables, array and structure layouts, should be preserved as much as possible during the parsing phase.
[0060] The local program graphs of various languages are merged into a UPSG, and semantic mappings are established at language boundaries (FFI, binding functions, script calls to local functions) to preserve cross-language semantic relationships. The core elements of UPSG include node type, edge type, node attributes, and interface semantic mapping table.
[0061] In this embodiment, UPSG is defined as a tuple:
[0062]
[0063] In the formula: The set of nodes in UPSG is the union of all language local graph nodes, and each node... Preserve its original language type and language-specific attributes; It is a set of internal language edges, including control flow edges, data flow edges, and internal call edges within each language; This is a cross-language interface edge set used to connect call points and target functions in code from different languages; This is an interface semantic mapping table, and can be represented as:
[0064]
[0065] in, express A cross-language interface edge in the set, mapping table The relevant semantic transformation rules are stored for this edge; Define cross-language type conversion rules (e.g., conversion rules from Python String to C char*) for parameter type mapping rules. For memory semantics and ownership rules, annotate the ownership, memory allocation, etc. of parameters or return values; Mapping rules for exception or error handling.
[0066] The feasible process for extracting cross-language paths and calculating path confidence includes:
[0067] The cross-language path is preset as an alternating sequence of nodes and edges, with the starting point of the sequence being the program entry point and the ending point being the sensitive operation point. The sequence includes at least one cross-language interface edge. The maximum local confidence value is assigned to the statically determined elements in the path, and a local confidence value less than the maximum value is assigned to the elements with uncertainties. The uncertainties include multiple candidate targets of indirect calls, reflection mechanisms, or cross-language interface edges. The total confidence of the path is obtained by multiplying the local confidence values of all elements in the path, which is used to prioritize the candidate paths.
[0068] As an optional implementation method, the process of cross-language path extraction and uncertainty annotation includes:
[0069] The first step is to extract the cross-language path from the program entry point (source point) to the suspected sensitive operation point (sink point) on the UPSG. The second step is to label any edge or node in the path that generates target uncertainty, and calculate the confidence level for the path based on the labeling results.
[0070] The process of path definition and confidence calculation includes:
[0071] (1) Path definition. This embodiment defines a cross-language path. Given an alternating sequence of nodes and edges:
[0072] ;
[0073] in, and ; As the source point, For the sink; for those containing A path of edges in a set, which represents a path that spans at least two different language contexts.
[0074] (2) Confidence calculation. In this embodiment, it is any element on the path. Assign a local confidence level to a node or edge. For statically defined edges (such as sequential statements or defined function calls), For edges / nodes with uncertainties (such as indirect calls, reflection, target sets) (cross-language interface edge). Take a preset value Alternatively, it can be dynamically calculated based on the size of the target set.
[0075] Total confidence of the entire path Defined as the product of the confidence scores of all elements along the path:
[0076]
[0077] Finally, the paths marked with uncertainty will be... Write the candidate path into the candidate path library for subsequent parallel verification, and use it. Perform priority sorting.
[0078] The feasible process for semantically aligning heterogeneous language states along a cross-language path based on a cross-language abstract domain includes:
[0079] The system uniformly maps basic data types across language paths to symbolic variables or constants; it abstracts pointers or memory handles in low-level languages into tuples that include memory region identifiers, offsets within the region, and ownership status; it abstracts objects or buffers in high-level languages into structures that include memory region identifiers, lengths, and primitive language types; and it performs state transitions at the cross-language interface edge based on the interface semantic mapping table to complete parameter type mapping and memory ownership updates.
[0080] Furthermore, the process of performing state transitions based on the interface semantic mapping table at the cross-language interface edge includes:
[0081] The application parameter type mapping rules are used to implement type conversion and value passing of symbolic variables; the ownership field of the relevant memory region identifier is updated according to memory semantics and ownership rules, and new memory regions are created or memory region aliases are established according to the parameter passing method.
[0082] As an optional implementation method, the process of abstract interpretation and constraint generation includes:
[0083] The heterogeneous runtime states on candidate cross-language paths are normalized into logical constraints that can be judged by the SMT solver, thereby determining whether potential vulnerabilities exist. This step is limited to several vulnerability patterns; this embodiment mainly discusses two types: buffer overflow and null pointer dereference.
[0084] To accurately model heterogeneous state transitions along cross-language paths, this embodiment defines a unified cross-language abstract domain. It aims to solve the semantic alignment problem between low-level languages (such as C / C++) and high-level languages (such as Python / Java).
[0085] (1) Basic Semantic Alignment. (a) Basic Types: Cross-language basic types (such as integers and floating-point numbers) are uniformly mapped to corresponding symbolic variables or constants. (b) Pointers / References: C language pointers T*p, C++ references, or low-level memory handles are uniformly abstracted into symbolic (regionId, offset, owner) tuples. Wherein, regionId represents the memory region identifier, offset represents the offset within the region, and owner is used to record the original allocator of memory or the current ownership status. (c) High-Level Objects / Buffers: Python's bytes / bytearray, Java's arrays, etc., are abstracted into symbolic (regionId, length, type) structures, where length represents a symbolic variable or a specific constant, and type represents the primitive language type.
[0086] (2) Interface semantic mapping Applications. On the side of cross-language interfaces. When performing a state transition, it should be strictly in accordance with The rules in the table are used for abstract state transformation, as follows: (a) Parameter mapping: Apply parameter type mapping rules ( (a) Implementing type conversion and value passing of symbolic variables (e.g., converting a symbolic String in Python to a tuple of char* pointers in C). (b) Memory and Ownership: Based on predefined ownership rules ( Update the owner field of the relevant regionId, and decide whether to create a new memory region or an alias to share an existing region based on the parameter passing method (pass by value or pass by reference).
[0087] The feasible process of converting path conditions and vulnerability fulfillment conditions into logical constraints includes:
[0088] Abstract state transitions are executed sequentially along the cross-language path, and control flow constraints, state transition constraints, and interface mapping constraints are accumulated into path conditions through conjunction operations. For sensitive operation points, vulnerability conditions are constructed according to vulnerability patterns. The condition for a buffer overflow vulnerability is that the access index is less than zero or greater than or equal to the buffer length, and the condition for a null pointer dereference vulnerability is that the memory region identifier pointed to by the pointer is a null address region. The path conditions and vulnerability conditions are combined into an existence quantifier constraint formula to complete the transformation of logical constraints.
[0089] As an optional implementation, along the candidate path The abstract state transitions are executed sequentially (the abstract transition function is executed according to the semantics of the node), and each step of the operation is converted into a set of logical constraints.
[0090] (1) Path conditions (a) Control flow constraints: For each branch node on the path, its condition judgment (such as the condition of if / while) is converted into a logical expression and accumulated through conjunction operation. (b) State transition constraints: based on the node. Semantic execution abstract transfer function And convert variable assignments and memory operations into logical constraints and accumulate them. (c) Interface mapping constraints: when passing through... When using an edge, map the table. In and The rule is coded as Part of it.
[0091] (2) Conditions for a vulnerability to be established The construction of the vulnerability involves constructing a vulnerability based on a predetermined vulnerability pattern, targeting sensitive operations at the path sink. The following sections will illustrate this using buffer overflow and null pointer dereferencing as examples.
[0092] Buffer overflow (BO). This occurs during memory access operations on arrays, including writes. and reading The constraints that can be constructed are:
[0093] ;
[0094] In the formula, From the abstract domain The symbolic length of the corresponding memory region extracted from it.
[0095] Null Pointer Dereference (NPD). This refers to dereference operations. Constraints can be constructed as follows:
[0096] ;
[0097] In the formula, It is a projection function used to extract pointers. A unique identifier pointing to a memory region; NULL_REGION represents an abstract field. The memory region containing null or invalid addresses.
[0098] (3) SMT Problem Construction. This step will define the path conditions. Conditions for the establishment of a vulnerability Combining these into a single constraint satisfaction problem, the SMT formula can be constructed:
[0099]
[0100] In the formula, This represents all relevant symbolic variables (including program input variables and intermediate symbolic variables generated during path execution). The formula is then submitted to the SMT solver for satisfiability determination.
[0101] The feasible process of determining the satisfiability of the logical constraints, outputting vulnerability detection results based on the determination, and generating a structured chain of evidence including path traces, witness information, mapping records, and confidence levels includes:
[0102] When the logical constraints are satisfied, the specific input values or indices that trigger the vulnerability are extracted from the model returned by the solver as witness information; the complete cross-language program execution path, the witness information, the interface semantic mapping record applied at the cross-language call boundary, the path confidence value, and the solver's judgment result are combined to form a structured chain of evidence.
[0103] As an optional implementation, alarm management and priority ranking are performed based on the SMT solver's judgment result on the SMT formula:
[0104] (1) Satisfiable (SAT): indicates that there exists a model satisfy The candidate path can be marked as a "suspected vulnerability" (the specific confidence level depends on the calculated confidence level), and this can be determined from the model. Extract witness information (specific parameters / index values, etc.).
[0105] (2) Unsatisfiable (UNSAT): This means that the path does not hold under the current abstract model and assumptions. This type of path can be marked as "verified non-vulnerable" or low priority information.
[0106] (3) Timeout or Unknown: This indicates that the solution process was interrupted due to timeout or internal reasons and the judgment could not be completed. This type of path can be marked as "to be reviewed".
[0107] Based on the witness information returned by the SMT solver, a structured and auditable cross-language evidence chain is generated. This evidence chain contains the following information: (1) the complete cross-language program execution path; (2) the specific input value or index that triggered the vulnerability (extracted from the witness information); (3) the semantic mapping record of the cross-language call boundary; and (4) the confidence level of the path. (5) The judgment result of the SMT solver.
[0108] Based on the path determination result, the following post-processing operations are performed: (1) For paths that can be satisfied: store the complete evidence chain in the vulnerability knowledge base, generate vulnerability alerts, and perform post-processing based on the path confidence. Prioritize the data. (2) For unsatisfiable paths: store the evidence chain in the knowledge base to reduce the future analysis priority of the corresponding path or constraint. (3) For time-out / unknown paths: submit the existing evidence and path information to the subsequent review queue.
[0109] Example 2
[0110] Based on the same general inventive concept, this invention also provides a static vulnerability detection system based on a unified cross-language program structure graph. The system provided by this invention is described below, and the system described below can be referred to in correspondence with the method described above. The system includes:
[0111] The input acquisition and preprocessing module is used to generate abstract syntax trees or intermediate representations for each programming language based on the source code to be detected and its compilation metadata.
[0112] The graph construction and indexing module is used to merge the abstract syntax trees or intermediate representations of various languages into a unified cross-language program structure graph, and to establish interface semantic mapping relationships on the cross-language interface edges;
[0113] The path analysis and priority evaluation module is used to extract cross-language paths from the program entry point to sensitive operation points on the unified cross-language program structure graph, mark elements with uncertainties in the path, and calculate the path confidence.
[0114] The abstract interpretation and formal verification module is used to perform semantic alignment of heterogeneous language states on cross-language paths based on cross-language abstract domains, convert path conditions and vulnerability conditions into logical constraints, and determine the satisfiability of logical constraints.
[0115] The evidence, alarm management and storage module is used to output vulnerability detection results based on the judgment results, and generate a structured evidence chain including path traces, witness information, mapping records and confidence levels.
[0116] As one specific implementation method, its structural diagram is as follows: Figure 2 As shown. The functions of each module are explained below:
[0117] Input Acquisition and Preprocessing Module: Responsible for code parsing, metadata acquisition, extraction of FFI and binding declarations, generating AST / IR corresponding to each language, and providing standardized program representations for subsequent analysis.
[0118] Graph Construction and Indexing Module: Responsible for merging the ASTs / IRs of various languages into UPSG, creating and maintaining its graph database index, and mapping the interface semantics. Establishing across language boundaries Edges are used to achieve connections between cross-language program structures.
[0119] Path Analysis and Priority Assessment Module: Responsible for performing cross-language data flow and control flow analysis on UPSG, extracting candidate vulnerability paths from the source to the sink; labeling uncertainties in path analysis and determining path confidence. The calculation provides a priority ranking for subsequent verification phases.
[0120] Abstract Interpretation and Formal Verification Module: Responsible for defining and applying cross-language abstract domains. Transform program semantics and vulnerability conditions into logical constraints. The system then calls the SMT solver to determine the satisfiability of the path and verify the existence of vulnerabilities.
[0121] Evidence, Alarm Management and Storage Module: Responsible for receiving SMT solution results, generating structured evidence chains, storing analysis results, vulnerability reports and other information, and providing query and interactive support for manual review.
[0122] It should be understood that the system provided in this embodiment has all the advantages of the method provided in the above embodiments.
[0123] Example 3
[0124] This embodiment also discloses a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method described in Embodiment 1.
[0125] Example 4
[0126] This embodiment also discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in Embodiment 1.
[0127] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology 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 static vulnerability detection method based on a unified cross-language program structure graph, characterized in that, Includes the following steps: Based on the source code to be tested and its compilation metadata, a unified cross-language program structure graph including nodes of multiple programming languages is constructed, and interface semantic mapping relationship is established on the cross-language interface edge; Extract the cross-language path from the program entry point to the sensitive operation point on the unified cross-language program structure graph, mark the elements with uncertainty in the cross-language path and calculate the path confidence; Based on the cross-language abstract domain, the heterogeneous language states on the cross-language path are semantically aligned, and the path conditions and the conditions for the vulnerability to be established are converted into logical constraints. The satisfiability of the logical constraints is determined, and the vulnerability detection result is output based on the determination result. A structured evidence chain including path traces, witness information, mapping records and confidence levels is generated. The specific process of constructing a unified cross-language program structure diagram and its interface semantic mapping relationships includes: For different programming languages, abstract syntax trees or intermediate representations are generated separately, and control flow edges, data dependency edges, and call edges are extracted to form local program graphs for each language. The node sets of all local program graphs are merged into a unified cross-language program structure graph node set, preserving the original language type and language-specific attributes of each node. Cross-language interface edges are established between cross-language call points and target functions, and corresponding parameter type mapping rules, memory semantics and ownership rules, and exception or error handling mapping rules are associated with each cross-language interface edge to form an interface semantic mapping table.
2. The method according to claim 1, characterized in that, The specific process of extracting cross-language paths and calculating path confidence includes: The cross-language path is preset as an alternating sequence of nodes and edges, with the starting point of the sequence being the program entry point and the ending point being the sensitive operation point. The sequence includes at least one cross-language interface edge. The maximum local confidence value is assigned to the statically determined elements in the path, and a local confidence value less than the maximum value is assigned to the elements with uncertainties. The uncertainties include multiple candidate targets of indirect calls, reflection mechanisms, or cross-language interface edges. The total confidence of the path is obtained by multiplying the local confidence values of all elements in the path, which is used to prioritize the candidate paths.
3. The method according to claim 1, characterized in that, The specific process of semantically aligning heterogeneous language states on cross-language paths based on cross-language abstract domains includes: The system uniformly maps basic data types across language paths to symbolic variables or constants; it abstracts pointers or memory handles in low-level languages into tuples that include memory region identifiers, offsets within the region, and ownership status; it abstracts objects or buffers in high-level languages into structures that include memory region identifiers, lengths, and primitive language types; and it performs state transitions at the cross-language interface edge based on the interface semantic mapping table to complete parameter type mapping and memory ownership updates.
4. The method according to claim 3, characterized in that, The process of performing state transitions based on the interface semantic mapping table at the cross-language interface edge includes: The application parameter type mapping rules are used to implement type conversion and value passing of symbolic variables; the ownership field of the relevant memory region identifier is updated according to memory semantics and ownership rules, and new memory regions are created or memory region aliases are established according to the parameter passing method.
5. The method according to claim 1, characterized in that, The specific process of converting path conditions and vulnerability conditions into logical constraints includes: Abstract state transitions are executed sequentially along the cross-language path, and control flow constraints, state transition constraints, and interface mapping constraints are accumulated into path conditions through conjunction operations. For sensitive operation points, vulnerability conditions are constructed according to vulnerability patterns. The condition for a buffer overflow vulnerability is that the access index is less than zero or greater than or equal to the buffer length, and the condition for a null pointer dereference vulnerability is that the memory region identifier pointed to by the pointer is a null address region. The path conditions and vulnerability conditions are combined into an existence quantifier constraint formula to complete the transformation of logical constraints.
6. The method according to claim 1, characterized in that, The specific process of determining the satisfiability of the logical constraints, outputting vulnerability detection results based on the determination results, and generating a structured chain of evidence including path traces, witness information, mapping records, and confidence levels includes: When the logical constraints are satisfied, the specific input values or indices that trigger the vulnerability are extracted from the model returned by the solver as witness information; the complete cross-language program execution path, the witness information, the interface semantic mapping record applied at the cross-language call boundary, the path confidence value, and the solver's judgment result are combined to form a structured chain of evidence.
7. A static vulnerability detection system based on unified cross-language program structure graph, for implementing the method of any one of claims 1-6, characterized in that, The system includes: The input acquisition and preprocessing module is used to generate abstract syntax trees or intermediate representations for each programming language based on the source code to be detected and its compilation metadata. The graph construction and indexing module is used to merge the abstract syntax trees or intermediate representations of various languages into a unified cross-language program structure graph, and to establish interface semantic mapping relationships on the cross-language interface edges; The specific process of constructing a unified cross-language program structure diagram and its interface semantic mapping relationships includes: For different programming languages, abstract syntax trees or intermediate representations are generated separately, and control flow edges, data dependency edges, and call edges are extracted to form local program graphs for each language. The node sets of all local program graphs are merged into a unified cross-language program structure graph node set, preserving the original language type and language-specific attributes of each node. Cross-language interface edges are established between cross-language call points and target functions, and corresponding parameter type mapping rules, memory semantics and ownership rules, and exception or error handling mapping rules are associated with each cross-language interface edge to form an interface semantic mapping table. The path analysis and priority evaluation module is used to extract cross-language paths from the program entry point to sensitive operation points on the unified cross-language program structure graph, mark elements with uncertainties in the path, and calculate the path confidence. The abstract interpretation and formal verification module is used to perform semantic alignment of heterogeneous language states on cross-language paths based on cross-language abstract domains, convert path conditions and vulnerability conditions into logical constraints, and determine the satisfiability of logical constraints. The evidence, alarm management and storage module is used to output vulnerability detection results based on the judgment results, and generate a structured evidence chain including path traces, witness information, mapping records and confidence levels.
8. A computer apparatus comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program, when executed by the processor, causes the processor to perform the method of any one of claims 1 to 7. The processor executes the computer program to implement the steps of the method according to any one of claims 1-6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1-6.