Incremental vulnerability detection method and system based on symbolized function side effect abstract

Abstract

The invention discloses an incremental vulnerability detection method and system based on a symbolized function side effect abstract, and the method comprises the steps: carrying out path sensitive sparse value flow analysis on an initial version, generating a change insensitive side effect abstract in combination with pointer analysis, constructing a sparse value flow graph, mining vulnerability paths such as null pointer dereference, memory leak and the like, and obtaining a sparse value flow graph; a two-layer structure vulnerability search abstract is generated and persisted, in a subsequent version, only bottom-up increment pointer analysis is triggered for a modification function, a cross-function memory object is symbolized and abstracted, and SVFG is updated according to abstract change propagation; and carrying out limited traversal type incremental vulnerability search around a newly added or closed data stream edge. According to the method, through a bottom-to-top increment pointer and vulnerability search mechanism based on abstract change propagation, increment detection of vulnerabilities such as null pointer dereference and memory leak in a software iteration process is realized, repeated analysis is remarkably reduced, and rapid identification of newly introduced vulnerabilities is supported.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and specifically to an incremental vulnerability detection method and system based on symbolic function side effect summaries. Background Technology

[0002] Sparse Value Flow Analysis (SVFA) is a core foundation of many static vulnerability detection techniques in recent years. It can be used to detect vulnerabilities that can be modeled as "source-sink" problems, such as null pointer dereferences and memory leaks. This technique uses pointer analysis results to identify implicit data dependencies, allowing vulnerability detection to be performed sparsely along the flow of data, rather than along the control flow. Compared to other techniques such as symbolic execution and data flow analysis, SVFA demonstrates a better balance between accuracy and scalability in vulnerability detection.

[0003] In recent years, much research has focused on applying SVFA to projects with millions of lines of code with better scalability while ensuring the highest accuracy—path sensitivity. Multiple studies have shown that this accuracy setting is indispensable for a usable vulnerability detection tool. In summary, SVFA-based vulnerability detection has made encouraging progress, enabling the analysis of large-scale projects within a standard overnight build time.

[0004] However, in real-world development environments with rapid code iteration, full vulnerability testing is clearly insufficient to enable developers to quickly obtain analysis results after code modifications, thus hindering the early discovery and fix of vulnerabilities. In such scenarios, an incremental approach is more reasonable: by identifying the parts of the code that have been modified in each iteration, vulnerability testing is only performed on the affected parts, while reusing the analysis results of the unaffected parts, ultimately yielding a report of vulnerabilities that the changed code may have caused and that have been eliminated. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes an incremental vulnerability detection method and system based on symbolic function side effect summaries. By constructing and persisting change-insensitive symbolic function side effect summaries and vulnerability search summaries, it achieves accurate, efficient, and reusable incremental detection of newly introduced and patched vulnerabilities during software iteration.

[0006] On the one hand, incremental vulnerability detection methods based on symbolic function side effect summaries include:

[0007] S1. Obtain the initial commit version of the target program, perform pointer analysis on each function in the initial commit version to generate and store change-insensitive side effect summaries, construct a sparse value flow graph reflecting the program's data dependencies based on the pointer analysis results, perform vulnerability search based on the sparse value flow graph, discover all vulnerability paths, generate vulnerability search summaries for each function of the target program based on all vulnerability paths, and persist the storage.

[0008] S2, For subsequent commits of the target program, identify the set of functions whose code has been modified in the subsequent commits. Starting from the set of modified functions, perform bottom-up incremental pointer analysis based on the stored change-insensitive side effect summary. When the change-insensitive side effect summary of the called function changes, re-analyze the caller function of the called function, update the change-insensitive side effect summary of the caller function and the sparse value flow graph.

[0009] S3 performs incremental vulnerability searches on data flow paths affected by code modifications or changes to insensitive side effect summaries based on the updated sparse value flow graph and persistently stored vulnerability search summaries, identifies and reports new and eliminated vulnerability paths, and synchronously updates the vulnerability search summaries of caller functions.

[0010] Furthermore, in S1, the change-insensitive side effect summary records the location of the memory points pointed to by the parameters of the called function by the called function through the access path.

[0011] Furthermore, in S1, the vulnerability type is a vulnerability type that can be modeled through the source-sink model, including null pointer dereference and memory leak.

[0012] Furthermore, in S2, incremental pointer analysis uses a symbolic approach to abstract memory objects passed across functions. Specifically, this includes creating parameter symbol objects through the memory objects passed as parameters, and creating output symbols for the values ​​modified externally by the called function through the parameters.

[0013] Furthermore, in S3, the vulnerability search summary has a two-layer structure. The first layer is a program dependency graph, which encodes all path condition information. The second layer is a set of path fragment summaries generated based on the program dependency graph and related to a specific vulnerability type, which records the data flow that may cause the vulnerability.

[0014] Furthermore, in S3, if the starting point of the vulnerability path is not located within the function whose code has been modified, and all vulnerability search summary fragments that the path depends on have not changed, then the existing analysis results are directly reused, and the re-search for the path is skipped.

[0015] Furthermore, in S3, during incremental vulnerability search, by comparing the sparse value flow graph before and after the update, the newly generated or closed data flow edges due to code changes are located, and a finite graph traversal is performed around the newly generated or closed data flow edges due to code changes to complete vulnerability verification.

[0016] On the other hand, incremental vulnerability detection systems based on symbolic function side effect summaries include:

[0017] The summary generation module is used to obtain the initial commit version of the target program, perform pointer analysis on each function in the initial commit version to generate and store change-insensitive side effect summaries, construct a sparse value flow graph reflecting the program's data dependencies based on the pointer analysis results, perform vulnerability search based on the sparse value flow graph to discover all vulnerability paths, and generate and persistently store vulnerability search summaries for each function of the target program based on all vulnerability paths.

[0018] The update module is used to identify the set of functions whose code has been modified in subsequent commits of the target program. Starting from the set of modified functions, it performs bottom-up incremental pointer analysis based on the stored change-insensitive side effect summary. When the change-insensitive side effect summary of the called function changes, it re-analyzes the caller function of the called function and updates the change-insensitive side effect summary and sparse value flow graph of the caller function.

[0019] The vulnerability detection module performs incremental vulnerability searches on data flow paths affected by code modifications or changes to insensitive side effect summaries based on the updated sparse value flow graph and persistently stored vulnerability search summaries. It identifies and reports new and eliminated vulnerability paths and synchronously updates the vulnerability search summaries of the caller functions.

[0020] The present invention adopts the above technical solution and has the following beneficial effects:

[0021] (1) This invention avoids repeated analysis of unchanged functions and their call paths by using symbolic side effect summary and incremental pointer analysis mechanism. Combined with SVFG difference-driven finite graph traversal, the vulnerability search scope is strictly limited to the local data flow affected by code or summary changes, with low time and space overhead.

[0022] (2) This invention uses path-sensitive, sparse value flow modeling and integrates program dependency graphs and vulnerability-oriented path fragment summaries to characterize cross-function memory operations, supporting accurate determination of vulnerability path start points, condition constraints and termination states, effectively reducing false positives and false negatives.

[0023] (3) This invention supports incremental auditing starting from any historical commit version. The persistent storage of the summary and the change propagation mechanism are naturally adapted to the CI / CD pipeline. New vulnerabilities can be identified and vulnerabilities can be fixed without full re-analysis, meeting the continuous security verification needs of modern software under rapid iteration. Attached Figure Description

[0024] Figure 1 This is a flowchart of an incremental vulnerability detection method based on a symbolic function side effect summary, as described in an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of incremental update code according to an embodiment of the present invention;

[0026] Figure 3 This is a schematic diagram of the code memory layout for the incremental update process in an embodiment of the present invention;

[0027] Figure 4 The code example of this invention shows the value flow graphs of each function.

[0028] Figure 5 This is a flowchart illustrating the overall process of incremental vulnerability detection according to an embodiment of the present invention.

[0029] Figure 6 This is a schematic diagram of the SSA language definition method according to an embodiment of the present invention;

[0030] Figure 7 This is a schematic diagram illustrating the abstract domain definition method of an embodiment of the present invention;

[0031] Figure 8 This is a schematic diagram illustrating the update environment and storage rules in an embodiment of the present invention;

[0032] Figure 9 This is a schematic diagram illustrating the allocation of an object for the loaded parameter pointer according to an embodiment of the present invention;

[0033] Figure 10 This is a schematic diagram of algorithm one according to an embodiment of the present invention;

[0034] Figure 11 This is a schematic diagram of Algorithm 2 according to an embodiment of the present invention;

[0035] Figure 12 This is a diagram of an incremental vulnerability detection system based on symbolic function side effect summaries, according to an embodiment of the present invention. Detailed Implementation

[0036] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0037] like Figure 1 As shown, the incremental vulnerability detection method based on symbolic function side effect summaries of the present invention includes:

[0038] S1. Obtain the initial commit version of the target program. Perform pointer analysis on each function in the initial commit version of the target program to generate and store a change-insensitive side effect summary. Based on the pointer analysis results, construct a sparse value flow graph that reflects the program's data dependencies. Perform vulnerability search based on the sparse value flow graph to discover all vulnerability paths. Based on all vulnerability paths, generate and persistently store a vulnerability search summary for each function of the target program.

[0039] Specifically, the change-insensitive side effect summary records the location of the memory point to which the called function's parameters are modified by accessing the path, excluding the specific value stored at that location and subsequent pointer relationships.

[0040] Specifically, the vulnerability types are those that can be modeled using the source-sink model, including null pointer dereferences and memory leaks.

[0041] Specifically, this embodiment uses a code example to illustrate why the current state-of-the-art path-sensitive pointer analysis digests cannot effectively control the impact of changes, and correspondingly, why the digest design is insensitive to code changes, thereby reducing recalculation overhead; it also demonstrates how vulnerability search digests can help perform on-demand vulnerability detection only on the value stream affected by changes.

[0042] Figure 2 The code snippet shown simulates incremental code updates, after which different functions are called according to a preset strategy to initialize parameter o2 (Lines 10-14). Accordingly, Figure 3 They were shown respectively Figure 2 The memory layout after the `alloc` call in the `fun` function and the memory layout at the end of `alloc` are shown. The green part represents newly added parts in the memory layout, light-colored blocks represent memory blocks, and dark-colored blocks represent guarded memory values. Unguarded memory values ​​are defaulted to `True` and omitted. In state-of-the-art path-sensitive pointer analysis, because the `alloc` function rewrites the memory pointed to by parameter `o2` (`out_alloc_null1` and `out_alloc_new1` are stored in the `f1` field of the memory pointed to by `o2` when `phi` is false and true, respectively), this rewrite and the memory layout it points to need to be copied at the `alloc` function call (Line 3) for instantiation, as shown in the example. Figure 3 As shown in the example. It's worth noting that, to avoid overly complex copied memory layouts, Falcon merges guard memory values ​​for the same field within memory blocks, for example... Figure 3In this code, `out_alloc_null1` and `out_alloc_new` are merged into `out_alloc`. To ensure correctness after merging, guard conditions are exposed to pointer edges, just as `phi` and non-`phi` are exposed to `out_alloc` pointing to `escaped_1_alloc` and `escaped_2_alloc` respectively. It can be observed that under this side-effect digest design, any change in guard conditions or pointer relationships in the memory layout returned by the called function will lead to a change in the digest of the called function. This digest design cannot effectively control the impact of changes on the existing digest, thus failing to effectively reduce recalculation overhead. For example... Figure 3 The update to the `alloc` code caused a change in the function's digest, requiring the `fun` function to reanalyze its pointer information. Worse still, because the digest design is overly sensitive to changes in pointer information, the memory layout pointed to by the `fun` function's return value `c1` also changed, requiring reanalysis of all callers of the `fun` function. This continued until no function digests changed during the bottom-up reanalysis along the call graph. As a current performance bottleneck in SVFA, pointer analysis consumes a significant portion of the time in full vulnerability detection. If the recalculation overhead of pointer analysis cannot be effectively reduced in incremental analysis, it will be impossible to complete incremental analysis quickly to adapt to modern continuous integration development scenarios. In modular pointer analysis, which aims to construct precise value flow edges, it is not necessary to know the detailed pointer information passed by the callee; only which values ​​reference the memory layout passed by the callee are needed. This allows for accurate identification of whether and how values ​​originate from the called function when processing the caller's `load` statement. For example, in... Figure 2In the example, although `alloc` changes its implementation, resulting in a change in the memory layout returned by the parameter `o2`, from the perspective of constructing the value stream edge for the function `fun`, it is only necessary to know that `o1->f1` is modified by `callee`, and that the values ​​returned by `callee` and their pointed-to memory layouts are loaded in lines 5 and 6 respectively via Access Paths `o1->f1`, `o1->f1->f2`, and `*(o1->f1->f2)`. The memory layout itself is irrelevant. Note that because of the Access Path as an index, data dependency information can be traced at any time. For example, when concerned with the value stream of `c1`, one can look up the Access Path of the memory passed out by `callee`, i.e., `o1->f1`, and find that it comes from the return values ​​of `alloc_new` and `alloc_null` under both phi and non-phi conditions, respectively. Further tracing reveals that these are `c3` and `c4`. Therefore, only the location of the modified memory pointed to by the parameter in the called function is needed as a summary. This design allows the caller to accurately perceive whether the value stream originates from the called function and how it originates (via the Access Path) when processing load statements. Simultaneously, it significantly reduces recalculation overhead in incremental pointer analysis due to the abstract's insensitivity to code changes. For functions that have undergone code changes, the returned memory layout details may alter; however, for callers who have not changed their code, as long as the modified memory referenced by the parameters in the called function remains unchanged, the Access Path of the pointer returned by the callee remains constant.

[0043] Specifically, the generation of the summary is driven by the updates to the abstract domain S by the rules Store and Call. Specifically: when a value is written to an object locator belonging to L_symp, it indicates that "some memory object passed as an argument has been modified." The summary generation rules are formally given in the rules Store and Call. The Store statement: through symbolic design, it abstracts all memory and values ​​passed between procedures in the Load rule. When the modified field belongs to L_symp, the locator is added to the side effect summary M of the current function fun. The Call statement: when applying the change-insensitive side effect summary, to accurately model side effects, for all modified memory locations recorded in the summary, the modified location corresponding to the passed argument is indexed, and a symbol is allocated and stored at that location. If this location happens to be the memory referenced by the function parameter of the current function, the current function summary is also updated.

[0044] S2, for subsequent commits of the target program, identify the set of functions whose code has been modified in the subsequent commits. Starting from the set of modified functions, perform bottom-up incremental pointer analysis based on the stored change-insensitive side effect summary. When the change-insensitive side effect summary of the called function changes, reanalyze the caller function of the called function, update the change-insensitive side effect summary of the caller function and the sparse value flow graph.

[0045] Specifically, incremental pointer analysis uses a symbolic approach to abstract memory objects passed across functions, including: creating parameter symbol objects through the memory objects passed as parameters, and creating output symbols for the values ​​modified externally by the called function through the parameters.

[0046] Specifically, Figure 4 Showing Figure 2 The value flow graphs of the functions in the code examples omit some edges and nodes. Instead of copying the detailed pointer information from the callees (such as `alloc_new` and `alloc_null`) as a digest to the caller, a higher-level abstract `AccessPath` is used as the digest to represent the influence of the callees on the caller. Before `alloc` is modified, it only contains calls to `alloc_new`, returning the modification of `o3->f1->f2` in `alloc_new` as a digest to `alloc`. `alloc` then creates an abstract symbol to receive this digest. Figure 6 The auxiliary return node on the alloc_new side and the abstract symbol node on the alloc side are omitted in the diagram. Its corresponding AccessPath is o2->f1->f2, indicating that alloc_new modified the memory it points to, but the pointer analysis phase does not concern itself with its specific layout. Similarly, alloc_new's modification of o3->f1 will also produce a similar summary and abstract symbol, which are omitted in the diagram. Likewise, for alloc, its modification of the memory regions represented by o2->f1 and o2->f1->f2 will also cause its caller fun to create two abstract symbols outsym1 and outsym2 to represent its impact. These two symbols correspond to the AccessPaths o1->f1 and o1->f1->f2, respectively. When alloc occurs as follows... Figure 2When the code change shown in green occurred, pointer analysis was required for both `alloc` and `alloc_null` functions because `alloc` itself was modified and the `alloc_null` function was called. Since `alloc_null` modifies the region pointed to by `o4->f1->f2`, and `alloc_new` modifies the memory region mapped to `o2->f1->f2` in `alloc`, both modify the memory region pointed to by the `o2->f1->f2` AccessPath. Therefore, although `o2->f1->f2` might have been added to `alloc`, the AccessPath of the modified memory region itself did not change. Thus, from the perspective of function `fun`, the digest of `alloc` remained unchanged. The digest change did not need to propagate to function `fun` and higher-level functions, thus avoiding the need for extensive pointer analysis in higher-level functions. Although the `fun` function was not re-analyzed, the null pointer dereference vulnerability in line 5 of function `fun` caused by the call to `alloc_null` could still be detected. Figure 4 As shown, after the value flow graph is constructed, the null pointer vulnerability source nullptr appears inside the function alloc_null and propagates to the digest o4->f1->f2 via path ⑥->⑦. It then propagates to node 15 inside the function fun via the mapping from o4->f1->f2 to o2->f1->f2 and from o2->f1->f2 to o1->f1->f2. There is a reusable propagation path 15->16 inside the function fun that leads to the pointer dereference point. Thus, the null pointer dereference vulnerability path 6->7->8->12->15->16 was incrementally detected.

[0047] S3 performs incremental vulnerability searches on data flow paths affected by code modifications or changes to insensitive side effect summaries based on the updated sparse value flow graph and persistently stored vulnerability search summaries, identifies and reports new and eliminated vulnerability paths, and synchronously updates the vulnerability search summaries of affected functions.

[0048] Specifically, the vulnerability search summary has a two-layer structure. The first layer is a program dependency graph, which encodes all path condition information. The second layer is a set of path fragment summaries generated based on the program dependency graph and related to a specific vulnerability type, which records the data flow that may cause the vulnerability.

[0049] Specifically, if the starting point of the vulnerability path is not located within the function whose code has been modified, and all vulnerability search summary fragments that the path depends on have not changed, then the existing analysis results are directly reused, and the re-search for the path is skipped.

[0050] Specifically, in the incremental vulnerability search, by comparing the sparse value flow graph before and after the update, the data flow edges newly generated or closed due to the code change are located, and a finite graph traversal is performed around the data flow edges newly generated or closed due to the code change to complete the vulnerability verification.

[0051] Specifically, Figure 5 This demonstrates the overall process of incremental vulnerability detection. For several commits to be detected, a full analysis is first performed on the first commit; subsequently, incremental vulnerability searches are performed on each subsequent commit. During the full analysis phase, the system generates pointer analysis summaries for all functions, constructs a sparse value flow graph, and identifies corresponding vulnerability paths. In the incremental analysis phase, the change identification module first locates the functions whose code has been modified in the current commit. Incremental pointer analysis is performed starting from these modified functions to obtain all functions whose summaries have changed, and the sparse value flow graphs of these functions are updated accordingly. Based on the updated sparse value flow graphs, the incremental vulnerability analysis module identifies and reports new vulnerability paths and invalidated vulnerability paths. For functions whose summaries have changed in the current commit, their latest summaries are written back to the summary database, preparing for incremental analysis of subsequent commits.

[0052] Specifically, in this embodiment, a simplified C-like SSA language is used, the syntax of which is as follows: Figure 6 As shown. In this language, `uniop` and `binop` represent unary and binary operations, respectively; the specific details of these operations are irrelevant to the subsequent formal derivation. The `alloc` statement is used to allocate memory. Its operands are an "array of type sizes" because the total size of an aggregate type (such as a struct or array) can be decomposed into the sizes of a series of atomic types. Thus, only the sizes of the atomic types need to be processed. Without loss of generality, it is assumed that all `call` statements do not return values ​​directly, but rather obtain the return value through parameters. For example, the following two code snippets are semantically equivalent. Furthermore, to formally define symbolic pointer analysis, a series of concepts and abstract fields are introduced, such as... Figure 7 As shown, the field S contains all symbols generated during pointer parsing. It is divided into two subsets: S_param and S_out. S_param contains a series of symbols "related to actual arguments," which are used to abstract all possible values ​​of the actual parameters passed at runtime. For example, in Figure 2In the example, the formal parameter `o2` actually acts as a symbolic abstraction of all possible arguments passed to `alloc`. Additionally, values ​​in memory accessible through parameters are also abstracted symbolically to uniformly handle "content flowing in through parameters." `S_out` contains a series of symbols related to "write results visible to the outside world of the called function." These symbols abstract values ​​that are not new objects allocated locally by the function, but rather values ​​that the caller needs to "see" at the return point after the memory location indirectly pointed to by the parameters is written to or updated inside the function. Intuitively, the symbols in `S_out` depict "the visible effect of modifications made to the memory pointed to by the arguments inside the called function on the caller after return." The value field V consists of the values ​​defined in the program and the symbol field. The values ​​in the symbol field are the abstractions of the values ​​defined in the program. The object field O represents various memory objects allocated during pointer parsing. Specifically, O_con represents concrete objects created during `alloc` statements, corresponding to the objects pointed to by program values ​​in the value field; O_sym represents symbolic objects used to abstract memory objects passed between procedures, corresponding to the objects pointed to by symbols in the symbol field, further divided into: O_symp represents symbolic objects pointed to by parameter symbols in S_param; and O_symo represents symbolic objects pointed to by output symbols in S_out. The field locator field L represents the field locator. Each object in the object field consists of several fields, uniquely identified by a locator. The field `L` is divided into: L_symp: the field locator for objects in O_symp; L_symo: the field locator for objects in O_symo; and L_con: the field locator for objects in O_con. Each locator `l ∈ L` uniquely locates "an object + a field within that object". The path condition field Ψ represents the set of first-order logical formulas consisting of the value v ∈ V and logical operators. It is used to describe path conditions (guards), such as combinations of branch conditions. Location mapping: L→(object, field_index) maps each locator `l` to its parent object and its field index. The control dependency mapping C records the results of control dependency analysis, mapping each statement to its execution conditions (i.e., part of the path conditions). Context E and storage S (two key structures in pointer analysis): Context E records under what conditions each value might point to which field locators, and can be formally viewed as: `E(v) = { (l, π)}`, indicating that under the path condition `π`, the value `v` might point to the field locator `l`.The storage S records which values ​​each locator stores under what conditions, i.e., `S(l) = { (v, π)}` indicates that under the path condition `π`, the locator `l` stores the value `v`. Intuitively, `E` describes the "value → location" information (points-to information + guard); `S` describes the "location → value" information (store content + guard); together, they encode the relationship between memory read / write and path conditions. Furthermore, some operators are defined to assist pointer analysis, especially Solve_φ (as shown below): given the constraint φ, it filters the set with guards, where Sat is a constraint solving process that uses simple and effective rules to quickly determine and prune constraints that are "obviously unsatisfactory".

[0053] Specifically, Figure 8 Rules for updating the environment E and storage S are given. For simplicity, the following notation is used: E[v ↦ locs] means: update the mapping of v in E to the set locs; E[v ⊒ locs] means: increment each element in locs into the existing mapping of E(v); similar notation is used for M (side effect summary): M↦ locs means rewrite, and M ⊒ locs means increment addition. The handling of the `Alloc`, `Phi`, and `GEP` instructions follows standard practices. The processing of the Store, Load, and Call instructions involves generating and applying change-insensitive side effect summaries. Specifically, by applying rules `Load-1` through `Load-4` sequentially, symbolic objects and symbols (belonging to the object field O_sym and the symbol field S, respectively) are allocated as needed. These are used to abstract the concrete objects and program values ​​(belonging to the object fields O_con and VS, respectively) propagated across procedures. The Store rule monitors modifications to the memory referenced by the function's parameters to update the change-insensitive side effect summary. The Call rule applies the change-insensitive side effect summary generated by Callee, allocates and stores symbolic values ​​to simulate side effects, and updates the side effect summary if the storage location is the memory referenced by the current function's parameters.

[0054] Specifically, rule Load-1 handles the case where the loaded "parameter pointer" has no record in environment E. In this case, a "symbolic object" is allocated for the pointer to abstract all the concrete objects that the parameter might point to at runtime. For example, in Figure 2In the analysis, when the `load` statement on line 10 is reached, an object `objSym2` is allocated for the loaded parameter pointer `o2`, as shown in the figure. Rule Load-2 handles a further case: the loaded "symbolic locator" has no record in storage `S`. In this case, a symbol is allocated for it. More specifically: if the symbol object to which the locator belongs is used to abstract "a memory object passed through a parameter", then this symbol represents "the value that may appear in the current field in memory accessible through that parameter"; if the symbol object to which the locator belongs is used to abstract "a collection of objects returned by a called function to the caller", then this symbol represents "a value exposed by the called function through the return result". Rule Load-3 establishes a corresponding value flow for each "guarded value" retrieved from `E` and `S`. Furthermore, if the value itself is a pointer symbol and has no record in environment `E`, then a symbol object is allocated for it. For example, in... Figure 2 In the analysis, when the Load statement `c1->f2 (o1->f1->f2)` on line 5 is reached, a symbol object `objOut` will be allocated for the loaded symbol `outSym1`, as shown below. Figure 9 As shown. This process ensures that environment E has been correctly updated when rule Load-4 is applied; rule Load-4 directly adopts the approach from the fusion method to support sparse propagation of points-to information.

[0055] Specifically, the application of the summary is given by the rule `Call`. For each possible called function `f`, its side effect summary `M(f)` is first queried. For each locator in the summary, its access path `[param_i,off_1,...,off_k]` is computed, where `param_i` is the i-th formal parameter of the called function `f`. The operator `Load_AP` receives this access path as input to compute "those locators actually modified by the called function": specifically, "those locators obtained by adding the offset `off_k` to the objects pointed to by `arg_i->off_1->...->off_(k-1)`". Since these locators are the target locations of the side effects, a symbol is then assigned to these locations and written into the corresponding locator. Figure 2 Taking line 8 before the code change as an example: For the expression `o4->f1` in the function `alloc_new`, a summary of a side effect of `alloc_new` indicates that this field will be written when it is called. Therefore, at the point where the `alloc` function calls `alloc_new`, such as... Figure 9 As shown, the field f1 of the object pointed to by the actual parameter o2 is assigned the symbol outSym3 and written into the field; that is, the symbol outSym3 is stored in the f1 field of the object objSym2.

[0056] Specifically, such as Figure 10 As shown, Algorithm 1 presents the overall process of incremental pointer analysis based on the side effect summary design. Initially, `changedFunc` records the set of functions whose code has been modified in this commit. The framework traverses each function in the program in bottom-up order of the call graph. For the current function `f`, if it is not in `changedFunc`, it is skipped directly; otherwise, `ExecPointerAnalysis(f)` is called to recalculate its current version's environment `E_f`, storage `S_f`, and side effect summary `M_f`, and then `LoadPointerAnalysis(f)` reads the result persisted in the previous version [`E'_f`, `S'_f`, `M'_f`]. In the incremental scenario, only the "set of modified locations" that the parameters can reach in memory remains unchanged: if `M_f` = `M'_f`, then all callers can safely reuse the existing pointer analysis results without reanalysis; conversely, if `M_f` ≠ `M'_f`, then all functions that call `f` are added to `changedFunc`, and pointer analysis is re-executed for these callers in the subsequent bottom-up traversal, thereby gradually propagating the impact of the changes upward along the call graph.

[0057] Specifically, such as Figure 11As shown, Algorithm 2, "Incremental checking," illustrates how this invention, within the path-sensitive SVFA framework, only re-searches for vulnerability paths related to changes for each commit. Based on a vulnerability search digest design and working on the results of incremental pointer analysis, the algorithm achieves a fine-grained propagation chain of "pointer digest change – vulnerability digest change – vulnerability path change." In summary, Algorithm 2 constructs a two-tiered, path-sensitive incremental vulnerability detection master control process. Its core idea is to achieve efficient on-demand reanalysis through "change propagation + digest reuse + precise pruning": The master control function IncCheck first calls the incremental pointer analysis module PTA to update pointer relationships and reconstruct the program dependency graph (PDG) based on the changed function set changedFunc, and then starts the incremental vulnerability search SearchForProgram; the latter adopts a bottom-up call graph traversal strategy, using changedFunc as the initial seed, and only searches for affected functions and their callers, and dynamically propagates the actual changes in the vulnerability digest upwards along the call chain through the HasSmryCreated mechanism to ensure that the change semantics are not missed; at the function level, SearchForFunction enumerates the relevant starting point and source node based on the PDG and distinguishes between two types of paths—for functions that are modified themselves (useChangedSmry=true), all starting point paths need to be expanded; for functions triggered by downstream digest changes (useChangedSmry=false), only when the path is concatenated with smryChanged=true. The algorithm only expands upon outputting or inputting a summary; otherwise, it skips. At the path level, the Search function further refines the control: when the path reaches the input node of the calling point, it prioritizes reusing the unchanged InSmry and TransSmry summaries, concatenating only the summaries containing changes to generate new Input / Transfer / Source-Sink summaries. Crucially, if the entire path never triggers any change flag (useChangedSmry), it terminates directly, completely avoiding unnecessary computation. Once the path is marked as change-related (useChangedSmry=true), the algorithm generates Transfer / Output summaries at the return point and Input / Source-Sink summaries at the sink node, and uniformly marks smryChanged=true, thereby driving the upper-level caller to re-analyze. Finally, through the synergistic effect of changedFunc, useChangedSmry, and smryChanged triple boolean flags, the algorithm strictly limits the scope of re-analysis to the data flow paths truly affected by code changes, while ensuring path sensitivity and field sensitivity, significantly improving the analysis efficiency and practicality in iterative scenarios.

[0058] Specifically, this embodiment demonstrates that the present application designs a novel side effect summary design and a corresponding pointer analysis rule, wherein the summary design is insensitive to the impact of code changes, thereby significantly reducing the recomputation overhead of pointer analysis during incremental updates; an algorithm for on-demand vulnerability search for changed code, which only detects value flows related to the changed code, thereby skipping meaningless graph traversal and reachability verification; and an incremental vulnerability detection prototype system based on sparse value flow analysis technology is implemented and subjected to detailed experimental evaluation. In tests on five open-source projects with code volumes ranging from 27,000 to 699,000 lines, an average speedup of 9.96 times was achieved compared to full analysis, with a maximum speedup of 14.93 times in commits with small-scale code changes.

[0059] Specifically, all experiments in this embodiment were conducted on a server running Ubuntu 20.04, equipped with an Intel(R) Xeon(R) Gold 6230R processor (2.10GHz, 40 cores) and 512GB of memory. Following the convention of previous studies, a 12-hour timeout threshold was set, consistent with typical nighttime build durations. The vulnerability types selected were null pointer dereference (NPD) and memory leak (ML), representing two distinct classic defect types within the source-sink framework: "source-must-not-sink" defects and "source-must-sink" vulnerabilities. Baselines were established using full analysis (compared to the time consumption of full-program analysis using state-of-the-art path-sensitive sparse value flow analysis techniques) and naive incremental analysis (a variant of this work that, instead of using a summary of the side effects involved to prematurely stop the re-analysis of the parent functions of the modified function, re-analyzes all parent functions of the modified function).

[0060] like Figure 12 As shown, this embodiment also discloses an incremental vulnerability detection system based on symbolic function side effect summaries, including:

[0061] The summary generation module 121 is used to obtain the initial submission version of the target program, perform pointer analysis on each function in the initial submission version of the target program to generate and store change-insensitive side effect summaries, construct a sparse value flow graph reflecting the program data dependencies based on the pointer analysis results, perform vulnerability search based on the sparse value flow graph, discover all vulnerability paths, and generate and persistently store vulnerability search summaries for each function of the target program based on all vulnerability paths.

[0062] The update module 122 is used to identify the set of functions whose code has been modified in subsequent commits of the target program. Starting from the set of modified functions, it performs bottom-up incremental pointer analysis based on the stored change-insensitive side effect summary. When the change-insensitive side effect summary of the called function changes, it re-analyzes the caller function of the called function and updates the change-insensitive side effect summary and sparse value flow graph of the caller function.

[0063] The vulnerability detection module 123 is used to perform incremental vulnerability searches on data flow paths affected by code modifications or changes to insensitive side effect summaries based on the updated sparse value flow graph and persistently stored vulnerability search summaries, identify and report new vulnerability paths and eliminated vulnerability paths, and synchronously update the vulnerability search summaries of affected functions.

[0064] The specific implementation of the incremental vulnerability detection system based on symbolic function side effect summaries is the same as that of the incremental vulnerability detection method based on symbolic function side effect summaries, and will not be described again in this embodiment.

[0065] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.

Claims

1. An incremental vulnerability detection method based on symbolic function side effect summaries, characterized in that, Includes the following steps: S1. Obtain the initial commit version of the target program, perform pointer analysis on each function in the initial commit version to generate and store change-insensitive side effect summaries, construct a sparse value flow graph reflecting the program's data dependencies based on the pointer analysis results, perform vulnerability search based on the sparse value flow graph, discover all vulnerability paths, generate vulnerability search summaries for each function of the target program based on all vulnerability paths, and persist the storage. S2, For subsequent commits of the target program, identify the set of functions whose code has been modified in the subsequent commits. Starting from the set of modified functions, perform bottom-up incremental pointer analysis based on the stored change-insensitive side effect summary. When the change-insensitive side effect summary of the called function changes, re-analyze the caller function of the called function, update the change-insensitive side effect summary of the caller function and the sparse value flow graph. S3 performs incremental vulnerability searches on data flow paths affected by code modifications or changes to insensitive side effect summaries based on the updated sparse value flow graph and persistently stored vulnerability search summaries, identifies and reports new and eliminated vulnerability paths, and synchronously updates the vulnerability search summaries of caller functions.

2. The incremental vulnerability detection method based on symbolic function side effect digests according to claim 1, characterized in that, In S1, the change-insensitive side effect summary records the location of the memory points pointed to by the parameters of the called function by the called function through the access path.

3. The incremental vulnerability detection method based on symbolic function side effect digests according to claim 1, characterized in that, In S1, the vulnerability type is a vulnerability type that can be modeled through the source-sink model, including null pointer dereference and memory leak.

4. The incremental vulnerability detection method based on symbolic function side effect digests according to claim 1, characterized in that, In S2, incremental pointer analysis uses a symbolic approach to abstract memory objects passed across functions. Specifically, this includes creating parameter symbol objects through the memory objects passed as parameters, and creating output symbols for the values ​​modified externally by the called function through the parameters.

5. The incremental vulnerability detection method based on symbolic function side effect digests according to claim 1, characterized in that, In S3, the vulnerability search summary has a two-layer structure. The first layer is the program dependency graph, which encodes all path condition information. The second layer is a set of path fragment summaries generated based on the program dependency graph and related to a specific vulnerability type, which records the data flow that may cause the vulnerability.

6. The incremental vulnerability detection method based on symbolic function side effect digests according to claim 1, characterized in that, In S3, if the starting point of the vulnerability path is not located within the function whose code has been modified, and all vulnerability search summary fragments that the path depends on have not changed, then the existing analysis results are directly reused, and the re-search for the path is skipped.

7. The incremental vulnerability detection method based on symbolic function side effect digests according to claim 1, characterized in that, In S3, during incremental vulnerability search, the sparse value flow graph before and after the update is compared to locate the data flow edges that have been newly generated or closed due to the code change. A finite graph traversal is then performed around the data flow edges that have been newly generated or closed due to the code change to complete the vulnerability verification.

8. An incremental vulnerability detection system based on symbolic function side effect summaries, characterized in that, include: The summary generation module is used to obtain the initial commit version of the target program, perform pointer analysis on each function in the initial commit version to generate and store change-insensitive side effect summaries, construct a sparse value flow graph reflecting the program's data dependencies based on the pointer analysis results, perform vulnerability search based on the sparse value flow graph to discover all vulnerability paths, and generate and persistently store vulnerability search summaries for each function of the target program based on all vulnerability paths. The update module is used to identify the set of functions whose code has been modified in subsequent commits of the target program. Starting from the set of modified functions, it performs bottom-up incremental pointer analysis based on the stored change-insensitive side effect summary. When the change-insensitive side effect summary of the called function changes, it re-analyzes the caller function of the called function and updates the change-insensitive side effect summary and sparse value flow graph of the caller function. The vulnerability detection module performs incremental vulnerability searches on data flow paths affected by code modifications or changes to insensitive side effect summaries based on the updated sparse value flow graph and persistently stored vulnerability search summaries. It identifies and reports new and eliminated vulnerability paths and synchronously updates the vulnerability search summaries of the caller functions.

Images