A cross-process reproduction type vulnerability detection method based on high-order functions

Abstract

The application discloses a cross-process reproduction vulnerability detection method based on high-order functions and relates to the technical field of program analysis. The application firstly performs path-sensitive symbolic execution on a program to generate a high-order function abstract containing path constraints and stain propagation; in inter-process analysis, the abstract is transmitted along a call chain as an instantiable data unit, constraint solving and path pruning are performed in combination with context arguments, a global symbolic program dependency graph is constructed to screen candidate code segments; further, the application constructs a static symbolic verification framework based on metamorphic relations, extracts parameterizable virtual patches from original patches, and strictly verifies the behavior equivalence before and after the virtual patch is applied to the candidate code on the symbolic level through metamorphic relations such as patch validity and functional consistency. The application overcomes the interference caused by the difference in code structure, and greatly improves the accuracy and interpretability of the reproduction vulnerability detection.

Description

Technical Field

[0001] This invention relates to the field of program analysis technology, specifically to a method for detecting cross-process reproducibility vulnerabilities based on higher-order functions. Background Technology

[0002] Recurring vulnerabilities (RVs) refer to the phenomenon where the same vulnerability reappears in multiple software projects due to code reuse (such as copy-paste, code cloning, and third-party library references). With the rapid development of the open-source software ecosystem, code reuse has become a mainstream software development pattern. However, when a security vulnerability exists in the original code, all projects that reuse that code may inherit the vulnerability, creating a serious software supply chain security risk. Existing methods for detecting recurring vulnerabilities mainly include methods based on code cloning detection, methods based on function signature matching, and methods based on program slicing. These existing detection methods face the following key technical challenges: Balancing accuracy and efficiency in inter-process analysis: Accurate inter-process analysis requires tracing the complete call chain and data flow, but this incurs huge computational overhead; while simplified analysis may miss key vulnerability features.

[0003] Effective identification of code variants: Reused code often undergoes modifications to varying degrees (such as variable renaming, code refactoring, and feature enhancement). Maintaining detection accuracy while tolerating reasonable code changes is a core challenge.

[0004] Generation and matching of multi-granular signatures: Different types of vulnerabilities may involve different ranges of code, requiring support for multi-granular signatures from the statement level to the function level and then to the module level.

[0005] To address this, the present invention proposes a cross-process reproducibility vulnerability detection method based on higher-order functions. Summary of the Invention

[0006] The purpose of this invention is to provide a cross-process reproducible vulnerability detection method based on higher-order functions. By drawing on the characteristics of higher-order functions in functional programming, the summary information of the analyzed function is encapsulated into a transitible higher-order parameter, thereby efficiently realizing the tracking of vulnerability features across processes.

[0007] According to a first aspect of the present invention, in order to achieve the above objective, the present invention provides the following technical solution: a method for detecting cross-process reproducibility vulnerabilities based on higher-order functions, comprising the following steps: The system receives and parses the original vulnerability patch code and the target code to be detected, generates an abstract syntax tree, a control flow graph, and a function call graph, and constructs the intermediate representation required for static analysis. Based on the intermediate representation, the code before and after the vulnerability is fixed is normalized, and the key constraints, branch conditions and state update statements introduced by the patch are extracted to form a parameterizable set of virtual patch rules. Static, path-sensitive symbolic execution is performed on the function control flow graph, taking functions as units. Form parameters and related global variables are initialized as symbolic variables. Path constraints are accumulated along the path and symbolic states are constructed. Unreachable paths are pruned, and instantiable symbolic function summaries are generated based on reachable paths. At the function call point, the call point context is obtained, the call point context is substituted into the symbolic function digest for instantiation, the instantiation result is propagated along the call chain, the symbolic state of the caller is updated, and incremental iteration is used for recursive or loop calls until the digest set and dependency relationship reach a stable fixed point. The instantiation result includes the postconditions after instantiation, the taint propagation effect, and the path constraint return. A global symbolic program dependency graph is constructed based on the symbolic results within and between processes. Multidimensional features are extracted from the program dependency graph. Based on the extracted multidimensional features, the multidimensional similarity score between candidate code fragments and vulnerability behavior signatures is calculated. Candidate code fragments are selected according to a preset threshold. The multidimensional features include call chain, path constraints, cross-process taint propagation, and key postconditions. For each candidate code segment, the virtual patching rules are applied to obtain a candidate repair version. A symbolic constraint formula corresponding to the metamorphic relationship between patch effectiveness and functional consistency is constructed. The code segment of the candidate repair version is verified by solving the constraints. If and only if the candidate code segment satisfies the metamorphic relationship, it is determined to be a reproducible vulnerability. A detection report containing trigger path constraints, call chain and symbolic evidence is output.

[0008] Furthermore, the system receives and parses the original vulnerability patch code and the target code to be detected, generating an abstract syntax tree, control flow graph, and function call graph to construct the intermediate representation required for static analysis, as follows: Analyze the original vulnerability patch to obtain the code before and after the vulnerability is fixed, as well as the set of affected functions; An abstract syntax tree (AST) is generated from the code to be analyzed using an abstract syntax tree parser. The function call graph is generated using program analysis tools, and the function analysis order is determined by reverse topological sorting. A set of core data structures is constructed, including symbolic program dependency graph, vulnerability signature, path-sensitive symbolic function digest, virtual patch rule set, intra-procedure code fingerprint, and inter-procedure code fingerprint.

[0009] Furthermore, based on the intermediate representation, the code before and after the vulnerability fix is ​​normalized, and the key constraints, branch conditions, and state update statements introduced by the patch are extracted to form a parameterizable set of virtual patch rules, as follows: Based on syntax tree comparison, the differences between the code before and after the repair are located, the difference code segments are determined, and the difference code segments are normalized, including identifier standardization, constant abstraction, equivalent syntax expansion and type / alias information completion. Analyze the semantics of the differing code snippets, extract the key security constraints introduced by the patch, the newly added or modified branch conditions, and the key state updates or function calls, and construct a set of virtual patch constraints. The set of virtual patch constraints is encapsulated into virtual patch rules, wherein each rule contains at least a matching pattern, a replacement / injection action and its corresponding symbolic constraints.

[0010] Furthermore, the parameterized extraction process of the virtual patch (VP) is as follows: By comparing the abstract syntax tree (AST) between the code before and after the patch, the newly added or modified control flow guards are extracted. The specific variables in the control flow guards are mapped to symbolic placeholders. The input parameters and target buffers are identified through data flow analysis. The extracted semantic differences are parameterized to form one or more virtual patch rules.

[0011] Furthermore, static, path-sensitive symbolic execution is performed on the function control flow graph. Formal parameters and related global variables are initialized as symbolic variables. Path constraints are accumulated along the path and symbolic states are constructed. Unreachable paths are pruned, and instantiable symbolic function summaries are generated based on reachable paths, as detailed below: Symbolic state initialization: For the function to be analyzed, its input parameters are initialized as symbolic variables; Static path-sensitive symbolic execution: Without running the target program, without instrumentation, and without relying on any runtime input, static symbolic execution and path exploration are performed on the control flow graph of the function body. Symbolic storage is maintained on each path to record the mapping of variables to symbolic expressions, and the path constraints that must be satisfied to cause the program to execute along the path are collected. Extract path summary: For each statically reachable execution path, generate a path summary, which includes path constraints, preconditions, postconditions, and taint propagation effects on the path; Generate higher-order function summaries: Integrate all path summaries and encapsulate them into a λ expression with function input symbolic variables as parameters, forming a complete higher-order function summary. In the formula, Represents symbolic input parameters.

[0012] Furthermore, at the function call point, the call point context is obtained, and the call point context is substituted into the symbolic function digest for instantiation. The instantiation result is propagated along the call chain to update the caller's symbolic state until the global digest set and dependencies reach a stable fixed point, as detailed below: Identify call relationships: Analyze the function call graph, identify the call chain of functions related to the vulnerability, and obtain the call point context; Path feasibility pruning and summary instantiation: Traverse each path summary in the function summary of the called function and substitute the symbolic expression of the actual argument at the call point into the precondition; Symbolic state update and taint propagation: For all reachable paths, substitute the symbolic expressions of the actual arguments into the postconditions of the path summary to obtain new symbolic expressions of the return value and affected variables in the context of the call point, and update the symbolic storage of the calling function. Substitute the taint properties of the actual arguments into the taint propagation effect to update the taint information of the calling function. Merge the path constraints into the path constraints of the calling function. Constructing inter-process code fingerprints: Integrating the analysis results of all relevant functions on the call chain to generate a cross-process vulnerability feature representation containing precise path conditions.

[0013] Furthermore, for recursive or loop calls, incremental iteration is used until the summary set and dependencies reach a stable fixed point, as follows: Forward propagation: For a function call, if x is a tainted variable, the tainted property is passed to the corresponding formal parameter of the function, and the return value y is determined based on the function digest to determine whether the tainted property is inherited. Backpropagation: For variables modified through pointer or reference parameters, the modification effect inside the called function is propagated back to the actual argument at the call point; Summary Combination and Recursive Processing: When multiple nested calls occur, the summary of the inner function is used as a parameter of the summary of the outer function to form a chain of higher-order function summaries. For recursive calls, an adaptive computation approach is introduced, caching the analysis results of the recursive function in one iteration and performing incremental computation only on the changed parts in the next iteration until a fixed point is reached.

[0014] Furthermore, a global symbolic program dependency graph is constructed based on the symbolic results within and between processes, as follows: Node generation: Transform code snippets obtained from intra-procedural and inter-procedural analysis into nodes in a symbolic program dependency graph; Edge construction: Based on the analysis results, add corresponding dependency edges between nodes, including call edges representing function call relationships, data dependency edges representing data flow relationships between variables, and control dependency edges representing statement execution depending on specific branch conditions; Node labeling and state appending: Normalized code feature labels are appended to each node for subsequent similarity calculations, and the set of symbolic states associated with the node is appended to the node. Simplified diagram: Based on the vulnerability characteristics, remove nodes and edges that are irrelevant to the vulnerability triggering logic, and retain the core vulnerability triggering path.

[0015] Furthermore, based on the extracted multidimensional features, a multidimensional similarity score is calculated between the candidate code snippets and the vulnerability behavior signature, and candidate code snippets are selected according to a preset threshold, as follows: Based on a globally symbolic program dependency graph, a signature feature for reproducible vulnerabilities is defined, and a similarity score is calculated between candidate code and this signature. in As weight, Similarity across different dimensions; The similarity metrics Simk for different dimensions are calculated in the following ways: For call chain similarity Simcall, it is converted into the longest common subsequence (LCS) ratio or edit distance normalized score of the two call sequences; for taint propagation similarity Sim taint, the source, propagation path, and sink node sets of both are extracted, and the intersection-union ratio (IUU) is calculated using the Jaccard similarity coefficient, which is the ratio of the intersection size to the union size of the two taint propagation sets; for path constraint similarity Simpc, the symbolic constraint formula is standardized, and the structural isomorphism of the constraint tree is compared. Filter out scores exceeding the threshold Candidate code snippets.

[0016] Furthermore, for each candidate code segment, the virtual patching rules are applied to obtain candidate repair versions. A symbolic constraint formula corresponding to the metamorphic relationship between patch effectiveness and functional consistency is constructed. The code segments of the candidate repair versions are verified through constraint solving. If and only if the candidate code segment simultaneously satisfies the metamorphic relationship, it is determined to be a reproducible vulnerability. A detection report containing trigger path constraints, call chains, and symbolic evidence is output, as follows: Extract behavioral signatures: Extract symbolic vulnerability behaviors and fix behaviors from the symbolic program dependency graphs of the original vulnerability code and the fix code, respectively; Define metamorphic relationships: Define the metamorphic relationships used for vulnerability verification and remediation logic, including: Patch effectiveness metamorphosis relationship: Requires that any statically reachable path that meets the vulnerability triggering conditions must be unreachable in the candidate fix version after the virtual patch is applied, which is verified by constraint solver assertion; Functional consistency metamorphic relationship: It requires that for all normal paths that do not trigger vulnerabilities, the candidate code remains equivalent to the symbolic postconditions on the selected set of observation variables before and after the virtual patch is applied, and is verified by symbolic equivalence checks; Candidate code screening: Generate a symbolic program dependency graph of the target code, extract multi-dimensional features, calculate similarity scores, and screen candidate codes that meet the threshold τ and whose scores are less than the threshold. Metamorphic verification and vulnerability determination: For each candidate code, a metamorphic relationship-driven symbolic verification is performed. The candidate code is ultimately determined to be a reproducible vulnerability if and only if the behavior of the candidate code is symbolically equivalent to the vulnerability behavior, and the two metamorphic relationships of patch validity and functional consistency are satisfied after the virtual patch is applied.

[0017] This invention has at least the following beneficial effects: 1. This invention introduces a higher-order function digest mechanism, which abstracts the behavioral model of a function into an instantiable symbolic expression. During inter-procedural analysis, only parameterized instantiation and constraint solving of the digest are required at the call point, without repeatedly expanding the internal implementation of the called function. This design fundamentally avoids the state space explosion problem caused by inline expansion in traditional inter-procedural analysis. At the same time, the context information of cross-procedural calls is preserved through path-sensitive constraint propagation. Compared with existing clone detection or fixed signature-based schemes, this invention can accurately identify complex vulnerability patterns involving multi-layered call chains, significantly reducing false positives and false negatives.

[0018] 2. This invention employs a semantic-based vulnerability detection strategy, rather than relying on syntactic similarity matching. Through normalization, symbolic abstraction, and static verification based on metamorphic relationships, this invention effectively resists interference from common code evolution operations such as variable renaming, code formatting, equivalent control flow transformation, and local functional enhancement. Virtual patch rules extract parameterizable security constraints from specific patches, enabling the remediation logic for the same vulnerability to be migrated to variant code with significant syntactic differences but semantic equivalence. Compared to existing methods that suffer detection failures due to code variants, this invention maintains a high detection rate even after the reproduced code has been reasonably modified.

[0019] 3. After screening candidate code, this invention further introduces a static symbolic verification framework based on metamorphic relationships. This framework uses a constraint solver to perform rigorous symbolic verification of the two metamorphic relationships, "patch effectiveness" and "functional consistency." It not only determines whether the candidate code is a reproducible vulnerability, but also outputs the specific symbolic input constraints, trigger paths, and call chain information that lead to the vulnerability. Compared with the "black box" results of existing methods that only output similarity scores or clone locations, the detection report provided by this invention is interpretable, provides direct symbolic evidence for vulnerability confirmation and remediation, and reduces the cost of manual review.

[0020] 4. This invention constructs a globally symbolic program dependency graph, unifying the analysis results within and between processes into a graph structure containing multi-dimensional features such as call chains, path constraints, cross-process taint propagation, and key postconditions. Based on this, a weighted similarity fusion strategy is employed to calculate call chain similarity, path constraint similarity, taint propagation similarity, and postcondition similarity, respectively. This multi-granularity, multi-dimensional feature representation and fusion mechanism enables this invention to simultaneously adapt to the detection requirements of statement-level fine-grained vulnerabilities and module-level coarse-grained vulnerabilities, overcoming the insufficient expressive power of existing methods due to fixed signature granularity.

[0021] 5. This invention introduces a loop unrolling threshold and a widening operator. When the number of basic block visits exceeds a preset threshold during analysis, the system automatically stops precise unrolling, widens the range of values ​​for variables within the loop to the entire set, and removes precise path constraints dependent on those variables. This mechanism forces the symbolic state to reach a stable fixed point within a finite number of iterations, ensuring the termination of the entire program analysis while preserving key information of the cross-process data flow through the widening strategy, thus avoiding critical path loss due to simple truncation. Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a flowchart illustrating the overall process of the detection method described in this invention. Figure 2 This is a schematic diagram of the symbolic program dependency graph (SPDG) of this invention; Figure 3 This is a schematic diagram of the instantiation and propagation mechanism of higher-order function summaries in this invention; Figure 4 This is a schematic diagram of the static symbolic verification process based on metamorphic relationships in this invention. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] Please see Figure 1 This invention provides a technical solution: a cross-process reproducibility vulnerability detection method based on higher-order functions, comprising the following steps: Step 1: Program preprocessing: Parse the original vulnerability patch code and the target code to be detected, generate an abstract syntax tree, control flow graph and function call graph, and construct the intermediate representation required for static analysis; Step 1.1 Code parsing and representation: Using syntax analysis tools such as tree-sitter, the input vulnerability patch code (including the pre-fix version VulCode and the post-fix version FixCode) and the target code to be detected (TargetCode) are parsed into an abstract syntax tree (AST). Step 1.2 Control Flow and Call Relationship Modeling: Based on the Abstract Syntax Tree (AST), a control flow graph (CFG) is constructed for each function, and the call relationships between functions are identified to build an initial function call graph. These graph structures form the basis for subsequent path sensitivity analysis. Step 1.3 Intermediate Representation and Data Structure Initialization: Convert the code into a unified intermediate representation (IR) and initialize the core data structures used to store the analysis results, such as the set Sum for storing function summaries and the symbolic program dependency graph (SPDG) for representing program dependencies, thus constructing the core data structure set. , , , , , , Their meanings are as follows: Symbolic program dependency graph ,in Represents a set of nodes (functions, statements). Represents a set of edges (call relationships, data dependencies, control dependencies). Indicates node label, Represents the set of symbolic states associated with a node; Vulnerability Signature , representing the symbolic program dependency graph of the original vulnerability and its hash value; Summary of constructing path-sensitive symbolic functions: ,in For summary parameters, This is a set of behavior summaries for the function under different statically reachable execution paths. Each path summary contains at least the path constraints, preconditions, postconditions, and taint propagation effects. Virtual patch rule set ,in This is a set of parameterizable program transformation / constraint injection rules extracted from FixCode relative to VulCode. Syntax elements or symbolic variables used to map placeholders in rules to candidate code; In-process code fingerprint , Includes normalized statement sequences, dependency graphs, and tainted paths; Inter-procedural code fingerprint It includes call chain and cross-function taint propagation information; Step 2: Patch Difference Extraction and Virtual Patch Rule Construction: Normalize the code before and after the vulnerability fix, extract the key constraints, branch conditions and state update statements introduced by the patch, and form a parameterizable set of virtual patch rules. Step 2.1 Difference Location and Normalization: Using techniques such as syntax tree comparison, accurately locate the differences between VulCode and FixCode. Normalize the differing code snippets, such as standardizing variable naming and code formatting, to eliminate irrelevant noise at the syntax level; Step 2.2 Semantic Difference Extraction: Analyze the semantics of the difference code and extract key security constraints introduced by the patch (such as boundary checks), newly added or modified branch conditions, key state updates or function calls; Step 2.3 Virtual Patch (VP) Generation: The parameterized extraction process of the virtual patch (VP) is as follows: The system compares the abstract syntax tree (AST) of VulCode and FixCode, extracts newly added or modified control flow guards (such as len>sizeof(temp)), maps the specific variables in the guard (such as len, temp) to symbolic placeholders (such as ARG_1, BUF_OBJ), and identifies len as the input parameter and temp as the target buffer through data flow analysis. The extracted semantic differences are parameterized to form one or more virtual patch rules. For example, a patch to fix a buffer overflow might have a VP that is abstracted as "check if the input length is less than the buffer size before executing memcpy". These rules are stored in the virtual patch set VP. The VP rule generated in step 2.4 is characterized by: Matching pattern: There is a memory copy operation to BUF_OBJ; Injection action: The assertion Assert(ARG_1<= Capacity(BUF_OBJ)) is injected before the copy. Through this promotion from specific variables to symbolic placeholders, the cross-project generalization of virtual patches is realized. Step 3: Static process path-sensitive symbolic execution and summary generation: Perform static, path-sensitive symbolic execution on the function control flow graph, initialize formal parameters and related global variables as symbolic variables, accumulate path constraints along the path and construct symbolic states, prune unreachable paths, and generate instantiable symbolic function summaries based on reachable paths. Step 3.1 Path-Sensitive Symbolic Execution: Explore paths for the CFG of each function, replace specific inputs with symbolic variables, execute along each path, and represent the calculation results and branch conditions as mathematical constraints on the symbolic variables; Step 3.2 Constraint Solving and Path Pruning: Use a constraint solver (such as Z3) to determine the satisfiability of path constraints, and prune unreachable paths (constraints with no solution) to avoid path explosion. Step 3.3 Generation of Symbolic Function Summary (Sum_f) : in Representing symbolic input parameters, this summary precisely describes the function's behavior and data flow under different input conditions. The core content of the summary is a set {PS1, ..., PS}. n}, where each PS represents a summary of a specific execution path inside function f. Therefore, the essence of this formula is: to use an abstract function containing all path possibilities to equivalently represent the original function f, thereby realizing inter-process analysis; For each reachable path of function f, generate a symbolic digest. This digest contains the path's preconditions (path constraints), postconditions (return value, global variable state), and taint propagation relationships. The digests of all paths together constitute the complete digest Sum_f of function f, which is stored in the digest set Sum. S4: Static inter-procedural summary instantiation and propagation: Obtain the call point context at the function call point, substitute the symbolic arguments, path constraints and necessary alias information into the called function summary to complete the instantiation, and return the instantiated postconditions, taint propagation effect and path constraints to update the caller's symbolic state. For recursive or loop calls, incremental iteration is used until the summary set and dependencies reach a stable fixed point. Step 4.1 Call point context acquisition: When analyzing a function call point (e.g., g() calling f(a, b)), obtain the current state of the call point, including path constraints and symbolic expressions of arguments a and b; Step 4.2 Summary Instantiation: Substitute the calling context (actual arguments) into the summary Sum_f of the called function f, replacing the formal parameters in the summary. The constraint solver will then verify again whether the instantiated path constraints are compatible with the path constraints of the calling point, filtering out paths to the called function that are unreachable in the current context; Step 4.3 State Merging and Propagation: Merge the postconditions, taint propagation effects, etc. of the instantiation summary of f back into the current state of the caller g, thereby realizing the cross-process propagation of program behavior information (especially taints); Step 5: Symbolic Program Dependency Graph Construction and Candidate Localization: Construct a global symbolic program dependency graph based on the symbolic results within and between processes, and extract multi-dimensional features such as call chains, path constraints, cross-process taint propagation, and key postconditions from the program dependency graph; calculate the multi-dimensional similarity score between candidate code fragments and vulnerability behavior signatures based on the extracted multi-dimensional features, and filter candidate code fragments according to a preset threshold; Step 5.1 Fixed-point iteration: Due to the potential for loops in function call relationships, inter-process analysis requires repeated iterations until the summaries of all functions (Sum) and the global SPDG no longer change, reaching a stable "fixed point." To ensure convergence, a widening / truncation strategy can be adopted. During static symbolic execution and inter-process fixed-point iteration, the system introduces a loop unrolling threshold (e.g., K=3) and a widening operator (∇) for loop structures and recursive calls. When the number of accesses to a basic block exceeds the threshold K, the system stops precise unrolling, widens the value range of the modified symbolic variable (e.g., accumulator i) within the loop to the entire set interval (e.g., [−∞, +∞] or the corresponding type extreme value), and clears precise path constraints dependent on this variable. Through this structured widening mechanism, the symbolic state is forced to reach a fixed point within a finite number of iterations, fundamentally ensuring the termination of the entire program analysis and avoiding path explosion and memory exhaustion. The higher-order function transfer mechanisms for cross-process taint tracing include: (1) Forward propagation: For a function call, if x is a tainted variable, the tainted attribute is passed to the corresponding formal parameter of the function, and the return value y is determined to inherit the tainted attribute based on the function summary; (2) Backpropagation: For variables modified through pointer or reference parameters, the modification effect inside the called function is backpropagated to the actual parameter at the calling point; (3) Summary combination and recursive processing: When multiple nested calls are made, the summary of the inner function is used as the parameter of the summary of the outer function to form a chain of higher-order function summaries; For recursive calls, an adaptive computation idea is introduced to cache the analysis results of the recursive function in one iteration, and only the changed parts are incrementally calculated in the next iteration until a fixed point is reached; Step 5.2 Symbolic Program Dependency Graph (SPDG) Construction: During the iteration process, the SPDG is constructed synchronously. This graph not only contains traditional control and data dependencies, but also symbolic information such as cross-procedure call chains, path constraints, and taint propagation paths obtained through digest propagation; Step 5.3 Candidate code screening: Based on SPDG, define the feature signature of reproducible vulnerabilities. For example, a vulnerability may be manifested as "a taint generated from source A, passing through the function call chain f->g->h, and finally reaching sink B, and the path lacks specific security checks"; By calculating the similarity score between the candidate code and this signature: in As weight, For different dimensions of similarity, the Simk similarity metric employs the following specific calculation methods: For call chain similarity (Simcall), it is converted into the longest common subsequence (LCS) ratio or edit distance normalized score of the two call sequences; for taint propagation similarity (Sim taint), the source, propagation path, and sink node sets of both are extracted, and the intersection-union ratio (IUU) is calculated using the Jaccard similarity coefficient: that is, the ratio of the intersection size to the union size of the two taint propagation sets; for path constraint similarity (Simpc), the symbolic constraint formula is standardized (e.g., converted to conjunctive normal form CNF), and the structural isomorphism of the constraint tree is compared. Filter out scores exceeding the threshold Candidate code snippets; Step 6: Static symbolic verification and result output based on metamorphic relationship: Apply the virtual patching rules to each candidate code segment to obtain the candidate repair version, construct the symbolic constraint formula corresponding to the metamorphic relationship between patch effectiveness and functional consistency, and verify it by constraint solving. If and only if the candidate segment satisfies the metamorphic relationship at the same time, it is determined to be a reproducible vulnerability, and a detection report containing trigger path constraints, call chain and symbolic evidence is output. Step 6.1 Candidate patch version generation: For each candidate vulnerability code snippet, apply the virtual patch (VP) generated in step 2 to obtain a hypothetical "patched" version; Step 6.2 Metamorphic Relationship (MR) Construction: In order to verify whether the candidate vulnerability is a true "reproduction" of the original vulnerability, this embodiment defines a set of specialized metamorphic relations to characterize the consistency of the "fix" transformation behavior. The core idea is: if a candidate code CandCode is a reproduction of the original vulnerability VulCode, then after applying the virtual patch VP extracted from the original patch to CandCode, its behavior change should be consistent with the behavior change of VulCode after applying the real patch FixCode. 1. Symptom concordance relationship (MR_Symptom) Objective: To verify that candidate code can reproduce the key "symptoms" of the original vulnerability.

[0026] Formal description: Let I_vul be the symbolic input that triggers the original vulnerability, and Prop_vul be the symbolic attribute representing the vulnerability (such as memory access out of bounds, specific exception throwing, etc.). This relationship requires that I_vul can also trigger the same symptoms in the candidate code.

[0027] Explanation: This relationship ensures that the candidate vulnerability we are discussing has the same surface-level behavior as the original vulnerability, which can be captured by symbolic execution. This forms the basis for subsequent verification.

[0028] 2. Therapeutic Conformity Relationship (MR_Cure) Objective: To verify that the "treatment" (i.e., virtual patch VP) extracted from the original patch is also effective for candidate code.

[0029] Formal description: Let VulCode_fix be the original patched code. This relationship requires that the VP be able to eliminate the vulnerability symptoms triggered by I_vul in the candidate code, just like a real patch.

[0030] Explanation: This relationship establishes behavioral equivalence from the "original fix" to the "virtual fix." It proves that the VP accurately captures the essence of the original patch's fix, and that this essence also applies to the candidate code.

[0031] 3. Side Effect Consistency Relationship (MR_SideEffect) Objective: To verify that when a virtual patch is applied to candidate code, the "side effects" it introduces are consistent with those of the original patch (ideally, there are no side effects).

[0032] Formal Description: Let I_normal be normal input that will not trigger a vulnerability. This relationship requires that, for normal business logic, the impact of the VP on the candidate code should be equivalent to the impact of the actual patch on the original code.

[0033] Explanation: This relationship is a deepening of MR_FC, which requires not only that the patch for candidate code not break normal functionality, but also that it maintains functionality in a way consistent with the original patch. For example, if the original patch handles boundary cases by returning an error code, then VP should also guide the candidate code to return the same error code, rather than throwing an exception.

[0034] Through the joint verification of these three sets of specialized transformation relationships, this invention can determine with extremely high accuracy whether a code snippet is a true reproduction of a known vulnerability, because it ensures a high degree of consistency between the two in terms of the transformation of "fix" in the three dimensions of "symptoms", "treatment" and "side effects". Step 6.3 Constraint Solution Verification: The above metamorphic relations are converted into symbolic constraint formulas and submitted to the constraint solver for judgment. For example, for MR_PE, the solver needs to prove that there exists a symbolic input such that the original code path reaches the vulnerability point, while the corresponding path of the fixed code is blocked by VP. If MR_PE satisfies the condition and MR_FC also satisfies the condition, then the candidate segment is determined to be a real reproducible vulnerability, and the symbolic input leading to the vulnerability is output as evidence. In summary, Step 1, through unified syntax, control flow, and call relationship modeling, constructs the foundational intermediate representation and core data structures upon which subsequent static analysis and symbolic execution rely, enabling comparison of code from different projects and versions within the same analysis framework. Step 2 abstracts the differences between the code before and after patching into parameterized virtual patch rules, decoupling the specific patch implementation from the vulnerability semantics, facilitating the migration and reuse of the same fix logic in heterogeneous codebases. Steps 3 and 4 generate instantiable higher-order function summaries from both intra-process and inter-process dimensions, respectively, and through context-sensitive instantiation and propagation mechanisms, form a fine-grained symbolic behavioral description covering cross-function call chains.

[0035] Building upon this, step 5 utilizes fixed-point iteration and symbolic program dependency graph (SPDG) construction to unify the symbolic results from different functions and paths into a single graph structure. Furthermore, it measures the similarity of candidate code segments using multi-dimensional features such as call chains, path constraints, cross-process taint propagation, and critical postconditions, thus achieving preliminary screening of reproducible vulnerabilities. Finally, step 6, based on the metamorphic relationship between patch effectiveness and functional consistency, directly verifies at the symbolic level whether the behavior of candidate code before and after applying a virtual patch remains consistent with the original vulnerability and its remediation logic. This provides an interpretable vulnerability determination result without relying on runtime testing.

[0036] The technical solution of the present invention will be further described below with reference to specific embodiments: Example 1: Overall Process Taking the reproduction of detecting the existence of the CVE-2021-3156 vulnerability in a certain open-source project as an example, the specific implementation steps of this invention are explained as follows: Step 1: Program Preprocessing First, obtain patch information for CVE-2021-3156 from vulnerability databases (such as NVD), including the code before the fix (VulCode) and the code after the fix (FixCode). Then, use tools such as tree-sitter to parse these two types of code and the code of the target project to be detected, generate their respective abstract syntax trees (ASTs) and initial function call graphs, and determine the analysis order. Step 2: Patch Difference Extraction and Virtual Patch Rule Construction VulCode and FixCode are normalized and key patch constraints are extracted. Taking the example patch, FixCode introduces a boundary check constraint of len <= sizeof(temp). The constraint is extracted and encapsulated into parameterizable virtual patch rules (e.g., "when a copy class call exists, inject an upper bound constraint related to the target buffer size and update the copy length symbolic expression accordingly"). Step 3: Path-sensitive symbolic execution and summary generation within a static process (no dynamic execution) Perform static, path-sensitive symbolic execution on the process_input function: In VulCode, len is modeled as an unconstrained symbolic variable, and there exists a path such that len ​​> sizeof(temp) is still reachable, thus forming a symbolic behavior of potential out-of-bounds copying; In FixCode, due to the boundary constraints introduced by the patch, len is limited to no more than sizeof(temp) on the critical path; Generate separately and Its path summary includes: path constraints, preconditions, postconditions (e.g., the relationship between temp write range and len), and taint propagation effects from input to sensitive operations; Step 4: Static inter-procedural summary instantiation and propagation If the upper-level function handle_request calls process_input(req->data, req->len), then when analyzing handle_request, the call point context (symbolic expressions of req->data and req->len, call point path constraints) will be substituted into it. or Instantiate the instance and post-conditions and taint propagation effects of the instantiation back to the caller state to achieve cross-process, context-sensitive static propagation; Step 5: Fixed-point iteration and SPDG construction / candidate localization The results of intra-process and inter-process analysis are integrated into a global SPDG, and the function summary set is cached and incrementally iterated until the summary set and SPDG are stable. Define candidate similarity: in ,when When necessary, include the candidate set (e.g., path segments containing similar copy calls and lacking upper bound constraints) as objects for subsequent verification; Step 6: Static Symbolic Verification and Result Output Based on Metamorphic Relations Apply a virtual patch to each candidate fragment to obtain a candidate repair version, and construct the constraint formulas corresponding to MR_PE and MR_FC: MR_PE: Verifies that the vulnerability trigger path is unreachable in the candidate patch version; MR_FC: Verify the symbolic postconditional equivalence of candidate fixes on the set of observed variables before and after the fix on non-vulnerability paths; If a candidate fragment satisfies the above metamorphic relationship, it is determined to be a reproducible vulnerability of CVE-2021-3156, and a detection report containing trigger path constraints, call chains, and symbolic evidence is output; otherwise, it is determined to be unreproducible. Example 2: Generation and Transmission of Higher-Order Function Summary Consider the following code example: The function analysis order (reverse topological order) is: alloc_buffer → process_data → handler Summary of alloc_buffer functions: Where -AFE stands for "Allocation From Extern", meaning the function allocates memory and returns.

[0037] Summary of functions in process_data: -ETF stands for "Extern To Function," indicating a sensitive function for external data inflows; Inter-process analysis of the handler: 1. Upon encountering an alloc_buffer(size) call, instantiate the buffer: Get the taint property of the ptr 2. Upon encountering a call to process_data(ptr, size), instantiate the data: 3. The complete path of the taint from alloc_buffer to process_data was traced. 4. Build ICPC: alloc_buffer → handler → process_data Example 3: Static Symbolic Verification Based on Metamorphic Relations For code variant matching, this invention employs a static symbolic verification framework based on metamorphic relationships, replacing matching methods that rely solely on syntactic similarity or graph structure similarity. Its core principle is to directly verify at the symbolic level, without running the target program, whether the candidate code, before and after applying a "virtual patch," satisfies the same set of metamorphic relationships as the original vulnerability / fix logic.

[0038] 1. Extract Behavioral Signatures - Extract symbolic vulnerability behaviors from the original vulnerability code (VulCode) and the fix code (FixCode). (Including path constraints that trigger the vulnerability) ) and repair behavior .

[0039] 2. Define Metamorphic Relations (MRs) - Patch Validity (MR_PE): Verifies that the patching logic actually prevents the vulnerability. This is proven by asserting IsUnsat(PC_vul ∧ PC_fix). Functional Consistency (MR_FC): Verifies that the patching logic does not introduce new errors. For any normal input I_normal, Behav_vul(I_normal) ⇔ Behav_fix(I_normal) should be satisfied.

[0040] 3. Candidate Code and Metamorphosis Verification (Static) A candidate code, CandCode, similar to VulCode was found. Source test: Verify that the behavior of CandCode is symbolically equivalent to... -Derivative Tests: (1) Construct a virtual repaired code CandCode', which is logically equivalent to applying the patch in FixCode to CandCode; (2) Verify that the behavior of CandCode' satisfies the two metamorphic relations MR_PE and MR_FC; (3) It is determined that CandCode passed all tests, and its behavior is consistent with the original vulnerability under the modified fix. (4) Final determination: This reproducible vulnerability exists in CandCode.

[0041] Example 4: Construction and Iterative Fixed-Point Analysis of Symbolic Program Dependency Graph (SPDG) The core of this invention lies in iterative analysis to continuously refine the function summary and global SPDG until the system state converges to a fixed point. The following specific example illustrates this iterative process in natural language.

[0042] First, consider a simplified service processing flow with potential vulnerabilities. The `log_error` function is responsible for writing error messages to the log. If user input is directly used as a formatted string parameter, it may introduce a formatted string vulnerability. The `get_user_input` function reads user input from the request object and returns it, corresponding to a typical taint source. The `process_request` function combines the above two functions, deciding whether to call `log_error` on different paths based on the request type. In the initial state, the analysis order is reverse topological order from `log_error`, `get_user_input` to `process_request`. At this time, the global SPDG only reflects static call relationships, and the function digest set `Sum` is empty.

[0043] In the first iteration, the system first performs in-process path-sensitive symbolization analysis on log_error and get_user_input. For log_error(char... The input parameter (msg) is modeled as a symbolic variable. Upon detecting a call to the sensitive function `printf`, this parameter is marked as a taint leading to the sensitive sink, and a function summary `Sum_log_error` is generated based on this, summarizing it as "input parameters on any reachable path will propagate to the sensitive sink". For `get_user_input(Request)`... The analysis of req) suggests that the return value always comes from a data field in the request object, and this return value is regarded as a new source of taint. Based on this, a function summary Sum_get_user_input is generated, which is described as "the return value is equivalent to the input parameter field and carries taint attributes".

[0044] After obtaining the summaries of the two functions mentioned above, the system continues to analyze process_request(Request). req). When the symbol is executed to the statement char When `input = get_user_input(req);`, `Sum_get_user_input` is instantiated in the current call context. The actual argument `req` is substituted into the digest to obtain the symbolic expression and taint state of the local variable `input`, which is then recorded in the caller's symbolic storage. Subsequently, symbolic execution encounters the conditional branch `if (req->type == 1)`. On the path where `req->type == 1`, the program directly passes `input` to `log_error`. At this point, the system performs another digest instantiation based on `Sum_log_error` at this call point, confirming that the tainted data from `get_user_input` flows along the path `get_user_input → process_request → log_error` to the sensitive sink, and adds a cross-process data dependency edge controlled by the path condition `req->type == 1` in the global SPDG. On the path where `req->type != 1`, since the sensitive sink is not further called, the taint will not continue to propagate. Based on the analysis results of the two paths, the system generates or updates the function summary Sum_process_request of process_request, explicitly characterizing whether the data fields in the parameter req can reach the sensitive sink under different branch conditions.

[0045] In subsequent iterations, the system re-examines the function summary set Sum generated in the previous round to check for any new cross-process propagation effects or dependencies that need to be added. When analyzing process_request again, since its dependencies Sum_get_user_input and Sum_log_error have stabilized and remained unchanged since the previous round, the process_request's own summary and related SPDG structure are no longer updated. Globally, since neither the function summary set nor the SPDG generates new information after the second iteration, it indicates that the system state has converged and reached a fixed point, and the iteration process ends.

[0046] In the fixed-point state, the final SPDG contains a complete cross-process dependency path from the taint source to the taint sink, and the path conditions are precisely recorded. This path and its constraint information are sent to the static symbolic verification stage based on metamorphic relations described in step S6, and compared with the original vulnerability signature at the symbolic behavior level to determine whether there is a reproducible vulnerability in the target code that is equivalent to a known vulnerability. Through the above iterative and verification process, this invention can systematically and automatically construct a cross-process vulnerability feature map containing precise path conditions, providing a solid foundation for subsequent high-precision vulnerability verification and localization.

[0047] In the description of this specification, the references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0048] The foregoing has shown and described the basic principles, main features, and advantages of this application. Those skilled in the art should understand that this application is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of this application. Various changes and modifications can be made to this application without departing from the spirit and scope thereof, and all such changes and modifications fall within the scope of the claims of this application.

Claims

1. A method for detecting cross-process reproducible vulnerabilities based on higher-order functions, characterized in that, Includes the following steps: The system receives and parses the original vulnerability patch code and the target code to be detected, generates an abstract syntax tree, a control flow graph, and a function call graph, and constructs the intermediate representation required for static analysis. Based on the intermediate representation, the code before and after the vulnerability is fixed is normalized, and the key constraints, branch conditions and state update statements introduced by the patch are extracted to form a parameterizable set of virtual patch rules. Static, path-sensitive symbolic execution is performed on the function control flow graph, taking functions as units. Form parameters and related global variables are initialized as symbolic variables. Path constraints are accumulated along the path and symbolic states are constructed. Unreachable paths are pruned, and instantiable symbolic function summaries are generated based on reachable paths. At the function call point, the call point context is obtained, the call point context is substituted into the symbolic function digest for instantiation, the instantiation result is propagated along the call chain, the symbolic state of the caller is updated, and incremental iteration is used for recursive or loop calls until the digest set and dependency relationship reach a stable fixed point. The instantiation result includes the postconditions after instantiation, the taint propagation effect, and the path constraint return. A global symbolic program dependency graph is constructed based on the symbolic results within and between processes. Multidimensional features are extracted from the program dependency graph. Based on the extracted multidimensional features, the multidimensional similarity score between candidate code fragments and vulnerability behavior signatures is calculated. Candidate code fragments are selected according to a preset threshold. The multidimensional features include call chain, path constraints, cross-process taint propagation, and key postconditions. For each candidate code segment, the virtual patching rules are applied to obtain a candidate repair version. A symbolic constraint formula corresponding to the metamorphic relationship between patch effectiveness and functional consistency is constructed. The code segment of the candidate repair version is verified by solving the constraints. If and only if the candidate code segment satisfies the metamorphic relationship, it is determined to be a reproducible vulnerability. A detection report containing trigger path constraints, call chain and symbolic evidence is output.

2. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 1, characterized in that: The system receives and parses the original vulnerability patch code and the target code to be detected, generating an abstract syntax tree, control flow graph, and function call graph to construct the intermediate representation required for static analysis, as follows: Analyze the original vulnerability patch to obtain the code before and after the vulnerability is fixed, as well as the set of affected functions; An abstract syntax tree (AST) is generated from the code to be analyzed using an abstract syntax tree parser. The function call graph is generated using program analysis tools, and the function analysis order is determined by reverse topological sorting. A set of core data structures is constructed, including symbolic program dependency graph, vulnerability signature, path-sensitive symbolic function digest, virtual patch rule set, intra-procedure code fingerprint, and inter-procedure code fingerprint.

3. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 1, characterized in that: Based on the intermediate representation, the code before and after the vulnerability patch is normalized, and the key constraints, branch conditions, and state update statements introduced by the patch are extracted to form a parameterizable set of virtual patch rules, as follows: Based on syntax tree comparison, the differences between the code before and after the repair are located, the difference code segments are determined, and the difference code segments are normalized, including identifier standardization, constant abstraction, equivalent syntax expansion and type / alias information completion. Analyze the semantics of the differing code snippets, extract the key security constraints introduced by the patch, the newly added or modified branch conditions, and the key state updates or function calls, and construct a set of virtual patch constraints. The set of virtual patch constraints is encapsulated into virtual patch rules, wherein each rule contains at least a matching pattern, a replacement / injection action and its corresponding symbolic constraints.

4. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 3, characterized in that: The parameterized extraction process of the virtual patch (VP) is as follows: By comparing the abstract syntax tree (AST) between the code before and after the patch, the newly added or modified control flow guards are extracted. The specific variables in the control flow guards are mapped to symbolic placeholders. The input parameters and target buffers are identified through data flow analysis. The extracted semantic differences are parameterized to form one or more virtual patch rules.

5. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 1, characterized in that: Static, path-sensitive symbolic execution is performed on the function control flow graph. Formal parameters and related global variables are initialized as symbolic variables. Path constraints are accumulated along the path and symbolic states are constructed. Unreachable paths are pruned, and instantiable symbolic function summaries are generated based on reachable paths, as detailed below: Symbolic state initialization: For the function to be analyzed, its input parameters are initialized as symbolic variables; Static path-sensitive symbolic execution: Without running the target program, without instrumentation, and without relying on any runtime input, static symbolic execution and path exploration are performed on the control flow graph of the function body. Symbolic storage is maintained on each path to record the mapping of variables to symbolic expressions, and the path constraints that must be satisfied to cause the program to execute along the path are collected. Extract path summary: For each statically reachable execution path, generate a path summary, which includes path constraints, preconditions, postconditions, and taint propagation effects on the path; Generate higher-order function summaries: Integrate all path summaries and encapsulate them into a λ expression with function input symbolic variables as parameters, forming a complete higher-order function summary. In the formula, Represents symbolic input parameters.

6. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 5, characterized in that: At the function call point, the call point context is obtained, and the call point context is substituted into the symbolic function digest for instantiation. The instantiation result is propagated along the call chain to update the symbolic state of the caller until the global digest set and dependencies reach a stable fixed point, as follows: Identify call relationships: Analyze the function call graph, identify the call chain of functions related to the vulnerability, and obtain the call point context; Path feasibility pruning and summary instantiation: Traverse each path summary in the function summary of the called function and substitute the symbolic expression of the actual argument at the call point into the precondition; Symbolic state update and taint propagation: For all reachable paths, substitute the symbolic expressions of the actual arguments into the postconditions of the path summary to obtain new symbolic expressions of the return value and affected variables in the context of the call point, update the symbolic storage of the calling function, substitute the taint properties of the actual arguments into the taint propagation effect, update the taint information of the calling function, and merge the path constraints into the path constraints of the calling function. Constructing inter-process code fingerprints: Integrating the analysis results of all relevant functions on the call chain to generate a cross-process vulnerability feature representation containing precise path conditions.

7. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 1, characterized in that: For recursive or loop calls, incremental iteration is used until the summary set and dependencies reach a stable fixed point, as detailed below: Forward propagation: For a function call, if x is a tainted variable, the tainted property is passed to the corresponding formal parameter of the function, and the return value y is determined based on the function digest to determine whether the tainted property is inherited. Backpropagation: For variables modified through pointer or reference parameters, the modification effect inside the called function is propagated back to the actual argument at the call point; Summary Combination and Recursive Processing: When multiple levels of nested calls occur, the summary of the inner function is used as a parameter for the summary of the outer function, forming a chain of higher-order function summaries; For recursive calls, an adaptive computation concept is introduced, which caches the analysis results of the recursive function in one iteration and performs incremental computation only on the changed parts in the next iteration until a fixed point is reached.

8. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 1, characterized in that: A global symbolic program dependency graph is constructed based on the symbolic results within and between procedures, as follows: Node generation: Transform code snippets obtained from intra- and inter-process analysis into nodes in a symbolic program dependency graph; Edge construction: Based on the analysis results, add corresponding dependency edges between nodes, including call edges representing function call relationships, data dependency edges representing data flow relationships between variables, and control dependency edges representing statement execution depending on specific branch conditions; Node labeling and state appending: Normalized code feature labels are appended to each node for subsequent similarity calculations, and the set of symbolic states associated with the node is appended to the node. Simplified diagram: Based on the vulnerability characteristics, remove nodes and edges that are irrelevant to the vulnerability triggering logic, and retain the core vulnerability triggering path.

9. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 8, characterized in that: Based on the extracted multidimensional features, a multidimensional similarity score is calculated between the candidate code snippets and the vulnerability behavior signature. Candidate code snippets are then selected according to a preset threshold, as follows: Based on a globally symbolic program dependency graph, a signature feature for reproducible vulnerabilities is defined, and a similarity score is calculated between candidate code and this signature. in As weight, Similarity across different dimensions; The similarity metrics Simk for different dimensions are calculated in the following ways: For call chain similarity Simcall, it is converted into the longest common subsequence (LCS) ratio or edit distance normalized score of the two call sequences; for taint propagation similarity Sim taint, the source, propagation path, and sink node sets of both are extracted, and the intersection-union ratio (IUU) is calculated using the Jaccard similarity coefficient, which is the ratio of the intersection size to the union size of the two taint propagation sets; for path constraint similarity Simpc, the symbolic constraint formula is standardized, and the structural isomorphism of the constraint tree is compared. Filter out scores exceeding the threshold Candidate code snippets.

10. The cross-process reproducibility vulnerability detection method based on higher-order functions according to claim 9, characterized in that: For each candidate code snippet, the virtual patching rules are applied to obtain candidate patch versions. A symbolic constraint formula corresponding to the metamorphic relationship between patch effectiveness and functional consistency is constructed. The code snippets of the candidate patch versions are verified by solving the constraints. If and only if the candidate code snippet simultaneously satisfies the metamorphic relationship, it is determined to be a reproducible vulnerability. A detection report containing trigger path constraints, call chains, and symbolic evidence is output, as follows: Extract behavioral signatures: Extract symbolic vulnerability behaviors and fix behaviors from the symbolic program dependency graphs of the original vulnerability code and the fix code, respectively; Define metamorphic relationships: Define the metamorphic relationships used for vulnerability verification and remediation logic, including: Patch effectiveness metamorphosis relationship: requires that any statically reachable path that meets the vulnerability triggering conditions must be unreachable in the candidate fix version after the virtual patch is applied, which is verified by constraint solver assertion; Functional consistency metamorphic relationship: It requires that for all normal paths that do not trigger vulnerabilities, the candidate code remains equivalent to the symbolic postconditions on the selected set of observation variables before and after the virtual patch is applied, and is verified by symbolic equivalence checks; Candidate code screening: Generate a symbolic program dependency graph of the target code, extract multidimensional features, calculate similarity scores, and screen candidate codes that meet the threshold τ and whose scores are less than the threshold. Metamorphic verification and vulnerability determination: For each candidate code, a metamorphic relationship-driven symbolic verification is performed. The candidate code is ultimately determined to be a reproducible vulnerability if and only if the behavior of the candidate code is symbolically equivalent to the vulnerability behavior, and the two metamorphic relationships of patch validity and functional consistency are satisfied after the virtual patch is applied.

Images