Graph and data flow security verification method and device for bidirectional symbolic execution

Abstract

The application provides a kind of graph and the data stream security verification method and device of bidirectional symbolic execution, method includes: parsing target code repository, build initial code attribute graph of fusion abstract syntax tree, control flow graph and data dependency graph, and create corresponding node for database field and API response field respectively;Activate framework-aware graph rewriting rule base, expand declarative framework abstraction into explicit data flow edge to obtain security-enhanced code attribute graph;Perform bidirectional symbolic execution on security-enhanced code attribute graph, output verification result;For the rule violation node of type checking failure, extract formal repair constraint, match the repair strategy suitable in repair template library, find the optimal repair scheme satisfying constraint using heuristic search, output repair suggestion.

Description

Technical Field

[0001] This application belongs to the field of software security and static program analysis technology, specifically, it relates to a data flow security verification method and apparatus for graph and bidirectional symbolic execution. Background Technology

[0002] With the widespread adoption of microservice architecture and the deepening of enterprise digital transformation, the technology stack of enterprise business systems is becoming increasingly complex. A typical modern enterprise application usually contains hundreds of microservice nodes, and data undergoes dozens of transformations and transfers between multiple layers such as database tables, persistence layer, business logic layer, control layer, API gateway, and front-end presentation. In this complex heterogeneous technology stack, regulated data, including personal identification information, financial data, and health information, may be exposed to the outside world through legitimate API channels without sufficient anonymization or authorization checks, posing a serious data security and compliance risk.

[0003] Current data security management generally adopts a post-event auditing model, which passively discovers data leakage risks after the system goes live through log analysis, network traffic monitoring, and other means. This model has a fundamental flaw: by the time a risk is discovered, the data may have already been leaked; tracing the root cause of the leak relies on manual code review, which is almost impossible when dealing with microservice clusters with millions of lines of code. Furthermore, modern enterprise applications heavily utilize declarative frameworks, such as JPA / Hibernate's object-relational mapping annotations, MyBatis's XML mapping configuration, and MapStruct's object transformation tools. The declarative abstraction of these frameworks makes traditional static analysis tools completely lose their tracing clues at the code level, leading to a systemic break in the data lineage at the framework's abstraction layer. Therefore, how to achieve accurate, automated, and verifiable data flow security analysis during the code development phase, and perform end-to-end data flow tracing and security verification from the database field level to the API response field level, is a core technical challenge that urgently needs to be overcome in the field of data security compliance.

[0004] Existing technologies mainly include the following implementation schemes: Static vulnerability detection schemes based on code attribute graphs, which integrate abstract syntax trees, control flow graphs, and program dependency graphs into a unified code attribute graph representation. However, their graph construction stops at the source code syntax level, and the abstraction of declarative frameworks is represented as isolated nodes in the code attribute graph, unable to be expanded into traceable data flow edges; Program path exploration schemes based on symbolic execution, which use symbolic values ​​to replace specific inputs to execute programs and determine path feasibility through constraint solvers. However, their symbolic execution is all forward unidirectional execution, lacking path search space optimization for security audit scenarios where data flows from a specific source to a specific sink, and lacking the ability to model the runtime behavior of the framework; Static verification schemes based on abstract syntax tree self-synthesis and security assertions. The first type of solution uses syntax tree transformation and assertion insertion to automate the verification of specific security attributes. However, its security verification coverage is limited by predefined assertion templates and security level configurations. It lacks effective modeling and verification methods for complex scenarios such as multi-layer object transformation and API business semantics, and it cannot handle end-to-end data flow paths across files, modules, and frameworks. The second type of solution uses multi-data-flow association analysis to achieve dynamic indexing and association analysis of multiple data flows by constructing association expression graphs between data flows. However, its analysis granularity stops at dynamic index optimization at the network data flow level. It cannot delve into the application source code level to trace the precise propagation path of a single data field from the database to the API, and it lacks formal verification methods for the security attributes of data at the code level. Summary of the Invention

[0005] This application provides a data flow security verification method and apparatus based on security-enhanced code attribute graphs and bidirectional symbolic execution, which at least solves the technical problems in the prior art such as data flow tracing breakage due to declarative framework abstraction, one-way symbolic execution path explosion, lack of formal guarantees for security verification, and inability to close loop repair in security analysis.

[0006] According to one aspect of this application, a data flow security verification method for graph and bidirectional symbolic execution is provided, comprising: Parse the target code repository, construct an initial code attribute graph that integrates an abstract syntax tree, a control flow graph, and a data dependency graph, and create corresponding nodes for database fields and API response fields respectively; Activate the framework-aware graph rewriting rule base to expand the declarative framework abstraction into explicit data flow edges to obtain a security-enhanced code property graph; Bidirectional symbolic execution is performed on the security enhancement code property graph. Symbolic values ​​are injected forward from the database field nodes and propagated along the graph in the forward direction. Reverse symbolic queries are injected backward from the API response field nodes and propagated along the graph in the reverse direction. The constraint solver is used to determine the feasibility of the path. The forward and backward path conditions are merged and combined at intermediate nodes to reconstruct the complete data flow path from the database field to the API response field. Perform a flow-sensitive type check based on the security tag grid for each data flow path, verify the sub-type relationship of the security type node by node along the path, and output the verification result; For violation nodes that fail type checks, extract formal repair constraints, match applicable repair strategies in the repair template library, use heuristic search to find the optimal repair solution that satisfies the constraints, and output repair suggestions.

[0007] In one embodiment, activating a framework-aware graph rewriting rule base expands the declarative framework abstraction into explicit data flow edges, including: Identify object-relational mapping annotations and expand them into data flow edges from database field nodes to field nodes; Parse the elements in the XML mapping configuration and expand the column-attribute mapping relationship into data flow edges; Identify object copy call patterns and insert cross-class data flow edges; Identify serialization framework annotations and establish data flow edges from field nodes to API response field nodes.

[0008] In one embodiment, performing bidirectional symbolic execution on a security-enhanced code property graph includes: Starting from each database field node, the symbolic value is propagated forward along the data flow edge and control flow edge. When a conditional branch is encountered, the constraint solver determines the path satisfiability. Satisfiable paths are continued to be tracked, while unsatisfiable paths are pruned. Simultaneously, starting from each API response field node, reverse symbolic queries are propagated backward along the data flow edge, and reverse symbolic execution and forward symbolic execution are performed independently and in parallel. The path conditions of the forward and reverse symbol states of intermediate nodes are merged. The constraint solver checks the satisfiability of the merged path conditions and constructs a complete path from the database field node through the intermediate node to the API response field node for satisfiable paths.

[0009] In one embodiment, a flow sensitivity type check based on a security tag grid is performed on each data flow path, including: Construct a security tag grid, which includes hierarchical tag sets, category tag sets, and combined tags; The initial security type of each database field node is inferred from database schema comments, field name pattern matching, and security annotations. Analyze the annotations and documentation of the target API interface to obtain the security expectation type of the API for the response fields; Perform type checks node by node along each data flow path, apply a data transformation function to each node on the path to calculate the transformed type, and determine whether the transformed type satisfies the subtype relationship of the expected type.

[0010] In one embodiment, for violation nodes that fail type checking, formal repair constraints are extracted, applicable repair strategies are matched in a repair template library, and heuristic search is used to find the optimal repair solution that satisfies the constraints, including: Formal repair constraints are extracted from the type check failure results. The repair constraints are then matched with a predefined repair template library, which contains repair templates for field desensitization insertion, security annotation addition, sensitive field removal, and SQL-level row-level filtering. The repair cost function is defined as a weighted sum of the number of nodes changed in the abstract syntax tree, the risk of disruptive behavior by downstream API consumers, and runtime performance overhead. Among the repair schemes that satisfy the repair constraints, find the repair scheme with the minimum repair cost function value.

[0011] In one embodiment, the method further includes: When changes occur in the code repository, the set of changed files is identified through version control differences. Only the changed files and their direct dependencies are re-executed for parsing and graph rewriting operations. The unaffected security enhancement code attribute graph subgraph structure is cached and reused. The analysis results are output to the continuous integration platform in a structured format.

[0012] According to another aspect of this application, a data stream security verification apparatus for graph and bidirectional symbolic execution is also provided, comprising: The multi-source parsing and security-enhanced code attribute graph construction engine is used to parse the target code repository, build an initial code attribute graph that integrates abstract syntax tree, control flow graph and data dependency graph, and activate the framework-aware graph rewriting rule base to expand the declarative framework abstraction into explicit data flow edges to obtain the security-enhanced code attribute graph. The bidirectional symbolic execution engine is used to perform bidirectional symbolic execution on the security enhancement code property graph. It injects symbolic values ​​from database field nodes forward and propagates them along the graph in the forward direction, and injects reverse symbolic queries from API response field nodes backward and propagates them along the graph in the reverse direction. It uses a constraint solver to determine the feasibility of the path, merges and combines the forward and backward path conditions at intermediate nodes, and reconstructs the complete data flow path from the database field to the API response field. The security tag grid type checker performs flow-sensitive type checks based on security tag grids on each data flow path, verifies the sub-type relationships of security types node by node along the path, and outputs the verification results. The constraint-driven repair synthesizer extracts formal repair constraints from non-compliant nodes that fail type checks, matches applicable repair strategies in the repair template library, uses heuristic search to find the optimal repair solution that satisfies the constraints, and outputs repair suggestions.

[0013] In one embodiment, the multi-source parsing and security-enhanced code property graph construction engine includes: A source code parser used to parse source code files and construct abstract syntax tree nodes and edges; An XML configuration parser is used to parse the mapping configuration file and extract the SQL mapping configuration. A database definition language parser is used to parse database definition language scripts to obtain database schema information; The framework de-abstraction rule engine is used to rewrite rules by defining graphs in a declarative domain-specific language. It supports plug-in extensions to adapt to new object-relational mapping frameworks and object mapping tools.

[0014] In one embodiment, the bidirectional symbolic execution engine includes: A forward symbol propagator is used to propagate symbol values ​​forward from each database field node along the data flow edges and control flow edges; Backward symbol lookup is used to propagate backward symbol lookup from each API response field node along the data flow edge. The constraint solver interface is used to perform path satisfiability analysis and constraint solving.

[0015] In one embodiment, the security tag type checker includes: Security label grid manager, used to maintain the grid structure of hierarchical labels and category labels; A type inferr for inferring safe types based on field name patterns, annotations, and comments; Type conversion calculator, used to simulate the impact of desensitization, filtering, and aggregation operations on security types; The core algorithm module for flow-sensitive type checking is used to perform type checking node by node along the data flow path and output the verification results.

[0016] In one embodiment, the constraint-driven repair synthesizer includes: A repair constraint extractor is used to extract formal repair constraints from type check failure results; The Repair Template Library Manager is used to store and manage various repair templates, including those for desensitization, filtering, removal, aggregation, and encryption. Minimal Repair Searcher, used to find the optimal repair solution in the repair space using heuristic search; Repair the impact analyzer to perform API contract change detection, downstream consumer impact analysis, and security regression testing.

[0017] In one embodiment, the apparatus further includes: The Incremental Analysis and Continuous Integration Continuous Deployment Integration Adapter is used to identify the set of changed files through version control differences when the code repository changes. It re-executes parsing and graph rewriting operations only on the changed files and their direct dependencies, caches and reuses unaffected subgraph structures, and outputs the analysis results to the continuous integration platform in a structured format.

[0018] This application constructs a security-enhanced code property graph and uses framework-aware graph rewriting rules during the construction process to abstract and expand the declarative framework into explicit data flow edges. Bidirectional symbolic execution is performed on the graph to reconstruct the complete data flow path from database fields to API response fields. Flow-sensitive type checks based on security tag lattices are performed on each data flow path to provide provable security guarantees. Formal remediation constraints are extracted from violation nodes that fail type checks, and the optimal remediation scheme is searched, thus realizing a complete closed loop from problem discovery to generating executable remediation suggestions. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 The overall architecture diagram of the data flow security verification system based on security-enhanced code attribute graphs and bidirectional symbolic execution provided in this application.

[0021] Figure 2 A flowchart illustrating the security enhancement code attribute graph construction and framework de-abstraction provided in this application embodiment.

[0022] Figure 3 This is a schematic diagram of bidirectional symbolic execution and path merging provided for embodiments of this application.

[0023] Figure 4 This is a security tag grid structure diagram provided for an embodiment of this application.

[0024] Figure 5 This is a flowchart of constraint-driven repair synthesis provided in an embodiment of this application.

[0025] Figure 6 This is a flowchart of a data flow security verification method for graph and bidirectional symbol execution provided in an embodiment of this application.

[0026] Figure 7 This is a specific implementation of an electronic device in the embodiments of this application. Detailed Implementation

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

[0028] To address the problems existing in the background technology, this application provides a data flow security verification method for graph and bidirectional symbolic execution, such as... Figure 1 As shown, this method takes the target code repository as input and sequentially goes through five stages: SCPG construction and framework de-abstraction, bidirectional symbolic execution and path merging, security tag type checking, constraint-driven repair synthesis, incremental analysis and CI / CD integration. The final output is a structured report containing security verification results and precise repair suggestions. The following uses a Java Spring Boot enterprise application as an example, with detailed explanations of each step in conjunction with the accompanying diagrams. Figure 6 As shown, the method includes: S601: Parse the target code repository, construct an initial code attribute graph that integrates the abstract syntax tree, control flow graph, and data dependency graph, and create corresponding nodes for database fields and API response fields respectively; S602: Activate the framework-aware graph rewriting rule base to expand the declarative framework abstraction into explicit data flow edges to obtain a security-enhanced code property graph; S603: Perform bidirectional symbolic execution on the security enhancement code property graph. Forward, inject symbolic values ​​from database field nodes and propagate them forward along the graph. Backward, inject reverse symbolic queries from API response field nodes and propagate them backward along the graph. Use constraint solvers to determine path feasibility. Merge and combine forward and backward path conditions at intermediate nodes to reconstruct the complete data flow path from database fields to API response fields. S604: Perform a flow-sensitive type check based on security tag grid for each data flow path, verify the sub-type relationship of security type node by node along the path, and output the verification result; S605: For violation nodes that fail type checking, extract formal repair constraints, match applicable repair strategies in the repair template library, use heuristic search to find the optimal repair solution that satisfies the constraints, and output repair suggestions.

[0029] In one embodiment, the process of parsing the target code repository, constructing an initial code attribute graph that integrates an abstract syntax tree, a control flow graph, and a data dependency graph, and creating corresponding nodes for database fields and API response fields includes: All .java files are parsed using a JavaParser to construct AST nodes and edges; the mapper.xml file is parsed using an XML parser to extract SQL mapping configurations; and the database DDL script is parsed to obtain database schema information. Based on the parsing results, an initial code attribute graph is constructed that integrates AST (Syntax Tree), CFG (Control Flow Graph), DDG (Data Dependency Graph), and type information. Simultaneously, a DB_COLUMN node is created for each column of the database table, and an API_FIELD node is created for each response field of the API interface. For example... Figure 2 As shown, the left side displays a source code snippet, and the right side illustrates the corresponding SCPG subgraph evolution process. Step ①: Multi-source parsing generates the initial AST / CFG / DDG fused graph. Steps ② to ④: JPA rules, MyBatis rules, BeanUtils rules, and Jackson rules are applied sequentially, adding a _DATA_FLOW dashed edge to the graph after each rewrite. Ultimately, all DB_COLUMN→FIELD→FIELD→API_FIELD nodes in the SCPG are connected through a complete _DATA_FLOW edge chain. The lower right of the graph shows a declarative DSL text example of the graph rewriting rules.

[0030] In one embodiment, activating a framework-aware graph rewriting rule base expands the declarative framework abstraction into explicit data flow edges, including: It identifies object-relational mapping annotations and expands them into data flow edges from database field nodes to field nodes. Specifically, it identifies @Entity and @Table annotations on classes and @Column annotations on fields, expanding them into _DATA_FLOW edges from DB_COLUMN nodes to FIELD nodes. For example, JPA's @Column(name="user_phone") defines a mapping from a database column to a Java field. This mapping is expanded in SCPG using graph rewriting rules into an explicit _DATA_FLOW edge from DB_COLUMN nodes to FIELD nodes, fundamentally eliminating the data flow "discontinuity" problem caused by the framework abstraction layer. Parse the elements in the XML mapping configuration and expand the column-attribute mapping relationship into data flow edges. Specifically, parse the elements in mapper.xml. <resultmap> <insert> <update> Identify object copy call patterns and insert cross-class data flow edges. Specifically, identify object copy call patterns in the code (BeanUtils.copyProperties, MapperImpl transformation methods generated by MapStruct, map calls of ModelMapper, etc.), and insert cross-class _DATA_FLOW edges for field pairs with matching names and compatible types by analyzing the type definitions of the source and target objects. Identify serialization framework annotations and establish data flow edges from field nodes to API response field nodes. Specifically, identify Jackson annotations (@JsonProperty, @JsonSerialize, etc.) on the Controller return type and the serialization configuration of the DTO class, and establish the _DATA_FLOW edge from the FIELD node to the API_FIELD node.

[0031] The formal definition of SCPG is as follows: G = (V, E, τ_V, τ_E, L) Where V is the set of nodes, E V × V is the set of directed edges. τ_V: V → T_V is a node type mapping, where T_V = {VARIABLE, FIELD, METHOD, ANNOTATION, LITERAL, CLASS, INTERFACE, PARAMETER, RETURN_POINT, DB_COLUMN, API_FIELD} τ_E: E → T_E is an edge type mapping, where T_E = {AST, CFG, DDG, CDG, TYPE, DATA_FLOW}. L: V → 2^{Label} is a function to assign a node's security label, where Label includes {PII, Sensitive, ...} In one embodiment, bidirectional symbolic execution is performed on the security-enhanced code property graph, such as Figure 3 As shown, based on the simplified subgraph of SCPG, the process of bidirectional symbolic execution is illustrated: the upper part is forward propagation—starting from DB_COLUMN, the symbolic value α_phone propagates downwards node by node along the _DATA_FLOW edge; the lower part is backward propagation—starting from API_FIELD, the reverse query β_phone propagates backwards along the _DATA_FLOW edge; the middle layer (usually near the FIELD node in the Service layer) is marked with a circular intersection marker—the forward and reverse states converge here. Simultaneously, combined with the bidirectional symbolic execution path convergence conditions, path convergence and full path reconstruction are performed. The bottom summarizes and outputs the complete path: DB_COLUMN(users.user_phone)→FIELD(UserEntity.phone)→FIELD(UserDTO.phone)→API_FIELD(phone). This step includes: Starting from each database field node, the symbolic value is propagated forward along the data flow and control flow edges. When a conditional branch is encountered, the constraint solver determines the path satisfiability. Satisfiable paths are continued, while unsatisfiable paths are pruned. Specifically, starting from each source node s, the symbolic value α_s is propagated forward along the _DATA_FLOW and CFG edges of the SCPG. When a conditional branch is encountered, the SMT solver is submitted to check its satisfiability. If satisfiable (SAT), the two paths are continued; if unsatisfiable (UNSAT), the path is pruned. When polymorphic calls are encountered, the SMT solver enumerates all possible runtime concrete implementation classes based on known type constraints and the calling context, and establishes a symbolic path for each possibility. When a loop structure is encountered, the SMT solver determines the symbolic range of the loop count based on the loop condition and processes it according to the expansion strategy (default expansion ≤ 3 times). Simultaneously, starting from each API response field node, a reverse symbolic query is propagated backward along the data flow edges. Reverse symbolic execution and forward symbolic execution are performed independently and in parallel. Specifically, starting from each sink node t∈T, a reverse symbolic query β_t is propagated backward along the _DATA_FLOW edge of the SCPG. Backpropagation also uses the SMT solver for path feasibility determination. Reverse symbolic execution and forward symbolic execution are performed independently and in parallel, sharing the same SCPG graph structure. The path conditions for the forward and reverse symbolic states of intermediate nodes are merged. The constraint solver checks the satisfiability of the merged path conditions and constructs a complete path from the database field node through the intermediate node to the API response field node for satisfiable paths. Specifically, for each intermediate node v in SCPG, it is checked whether both the forward symbolic state State_fwd[v] and the reverse symbolic state State_bwd[v] are non-empty. If both are non-empty, the path conditions for each pair of forward-reverse states are merged. The SMT solver is submitted to check the satisfiability of cond_merged. If it is SAT, the complete path Path(s→v) + Path(v→t) is constructed and added to the output path set.

[0032] The path merging condition for bidirectional symbolic execution is: Convergence determination: v ∈ V, (σ_f, pc_f) ∈ State_fwd[v], (σ_b, pc_b) ∈ State_bwd[v] If SMT_Solve(pc_f ∧ pc_b) = SAT, then Paths ← Paths ∪ {CompletePath(s → v → t)} Where: σ_f is the forward symbol state, pc_f is the forward path condition, σ_b is the reverse symbol lookup, and pc_b is the reverse path condition.

[0033] For each complete path, collect the data transformation functions (such as type conversion, JSON serialization, etc.) of all intermediate nodes in sequence along the path, and construct a composite transformation function F_path = F_n from source to sink. F_{n-1} ... F_1. Pass F_path along with the path constraints to subsequent steps for security verification.

[0034] In one embodiment, a flow sensitivity type check based on a security tag grid is performed on each data flow path, such as... Figure 4 As shown, the partial order structure of the security tag grid is illustrated: the top-level node is Public (the smallest element), the bottom-level node is Secret (the largest element), and the middle levels from top to bottom are Internal and Confidential. Information flow is allowed in various directions: data can flow from lower levels to higher levels. The right side expands the category tag dimensions: PII, Financial, Health, Credential, Location, and Communication. The bottom right corner shows an example calculation of combined tags. The bottom left corner shows the tag degradation path of the type constructor. This step includes: Construct a secure label grid, which includes hierarchical label sets, category label sets, and combined labels. Specifically, construct the secure label grid L = (Labels, ... , , , ⊥, ), where: LevelLabels = {Public, Internal, Confidential, Secret}, defining a partial order relation: Public Internal Confidential Secret (partial order, indicating the allowed direction of information flow). The category label set `CategoryLabels = {PII, Financial, Health, Credential, Location, Communication, ...}` represents the business category to which the data belongs. The combined label form is `(level, category_set)`, where `level ∈ LevelLabels`, `category_set`. CategoryLabels. The partial order relation for combined tags is defined as: (l1, C1) (l2, C2) l1 l2 ∧ C1 C2. and The operation returns the minimum upper bound and the maximum lower bound of the two labels, respectively. Infer the initial security type of each database field node from database schema annotations, field name pattern matching, and security annotations. Specifically, the initial security type of each DB_COLUMN node is automatically inferred from database Schema annotations, field name pattern matching (e.g., a field name containing "phone / 手机" is inferred as PII-Contact), @Column annotations and existing security annotations. For example: users.user_phone → RawData (Confidential, {PII, Contact}) ; Analyze the annotations and document information of the target API interface to obtain the expected security type of the API for the response field. Specifically, analyze the annotations and document information of the target API interface to obtain the expected security type of the API for the response field. The sources for expected type inference include: (a) security annotations explicitly declared by developers (e.g., @ApiSecurityLevel(Public)); (b) inference based on API path keywords (e.g., a path containing " / admin" is inferred as Internal); (c) security Schema definitions in OpenAPI / Swagger documents. If no explicit declaration is found, progressive inference is enabled to automatically generate the expected type based on the analysis of API consumers; Perform type checking node by node along each data flow path, apply the data transformation function to each node on the path to calculate the transformed type, and determine whether the transformed type satisfies the subtype relationship of the expected type. Specifically, perform type checking node by node along each data flow path Path = (v_source → v_1 → v_2 → ... → v_sink): Initialization: current_type = infer_initial_type(v_source) For each node v_i on the path: expected_type = get_expected_type(v_i, api_spec) transformed_type = apply_transform(current_type, f_i) if transformed_type expected_type: return FAIL(v_i, expected_type, transformed_type) current_type = transformed_type Path traversal complete: return PASS The `apply_transform` function recursively calculates the transformed type based on the operation type at the node and the frame behavior marked in the SCPG: for the de-identification function, it calls `maskPhone(phone)`. Masked type(phone),PHONE_MASK For the aggregate function COUNT(*) Aggregated type(source), COUNT For row-level filtering operations, filterByOwner() Filtered type(source), isOwner For ordinary assignment / pass operations, the type remains unchanged.

[0035] The extended security type hierarchy (type constructors) is as follows: τ ::= RawData L | Masked τ, strategy | Filtered τ, predicate Aggregated τ, agg_fn Encrypted τ, key_ref

[0036] Subtype rules (examples of key rules) are as follows: Rule T-MASK: ───────────────── Masked RawData (l,C) strategy RawData (Internal, C)

[0037] Rule T-AGGREGATE: ───────────────── Aggregated RawData (l,C) COUNT RawData (Public, )

[0038] Rule T-FILTER: ───────────────── Filtered RawData (l,C) isOwner RawData (l,C)

[0039] The key advantage of type checking is that if it passes, it mathematically guarantees that the data flow path does not violate the security policy defined by the tag grid—a provable security guarantee, rather than the heuristic guessing of LLM. When it fails, the system not only reports the violation event, but also precisely outputs the location of the violation node, the expected type, the actual type, and the difference between the two—this structured information serves directly as input for subsequent remediation steps.

[0040] In one embodiment, for violation nodes that fail type checking, formal repair constraints are extracted, applicable repair strategies are matched in the repair template library, and heuristic search is used to find the optimal repair solution that satisfies the constraints, such as... Figure 5 The diagram illustrates the complete decision-making process from type check failure to remediation suggestion output: Starting point: S3 Type Check FAIL → Step ① Violation Constraint Extraction → Step ② Remediation Template Matching → Step ③ Minimal Remediation Search → Step ④ Remediation Impact Analysis → End point: Remediation suggestion output. If the security regression detection FAIL, a feedback arrow returns to Step ② to re-search for alternative remediation solutions. This step includes: Formal repair constraints are extracted from the type check failure results. These constraints are then matched against a predefined repair template library, which includes templates for field masking and insertion, security annotation addition, sensitive field removal, and SQL-level row-level filtering. Specifically, from the S3 type check failure result FAIL(v_i, τ_expected, τ_actual), the formal repair constraint is extracted as: repair_constraint(v_i) := fix ∈ FixSpace, apply(fix,v_i) (τ_transformed (τ_expected). This transforms the violation into a constraint satisfaction problem: "Find a code modification operation that makes the modified data transformation satisfy a subtype relationship." The fix constraint is matched against a predefined fix template library. The fix template library contains standardized fix templates for different violation patterns. Each template defines: applicable conditions, AST transformation operation, impact on security type, and expected side effects. Main template categories include: Template T1 – Field Masking Insertion: Applicable when actual_type contains PII or Contact category and expected_type is Public; Template T2 – Security Annotation Addition: Applicable when DTO fields or API response fields lack security tags; Template T3 – Sensitive Field Removal: Applicable when the returned field exceeds the API security level and the field is not needed in the business; Template T4 – SQL Layer Row-Level Filtering: Applicable when data access control should be implemented at the query level. The repair cost function is defined as a weighted sum of the number of AST change nodes, the disruptive risk to downstream API consumers, and runtime performance overhead. Specifically, the repair cost function is defined as: Cost(fix) = w_1 × AST_Distance(fix) + w_2 × BreakingChangeRisk(fix) + w_3 × PerformanceImpact(fix). Where AST_Distance is the number of AST change nodes caused by the repair (prioritizing single-point changes), BreakingChangeRisk is the disruptive risk to downstream API consumers (analyzed through API call graph analysis in SCPG, with a value between 0 and 1), and PerformanceImpact is the runtime performance overhead introduced by the repair. The search identifies the repair scheme with the minimum repair cost function value among those that satisfy the repair constraints. Specifically, the search target is the repair scheme with the minimum cost that satisfies the repair_constraint. If the minimum cost still exceeds the configurable threshold, the violation is marked as "requires manual review".

[0041] Perform a comprehensive impact analysis on the selected remediation plan: (a) API contract change detection – analyze whether the remediation changes the type, format, or existence of API response fields; (b) Downstream consumer impact – search the SCPG for all code locations referencing the modified fields / methods; (c) Security regression testing – re-enter the remediated code into the S1-S3 pipeline to verify whether the violation has been eliminated and no new violations have been added. The final output format of the remediation recommendation includes: code snippet before remediation, code snippet after remediation, explanation of the remediation principle, scope of impact, and alternative solutions.

[0042] In one embodiment, the method further includes: When the code repository changes, the system identifies the set of changed files through version control diffs and re-executes parsing and graph rewriting operations only on the changed files and their direct dependencies. Unaffected security enhancement code attribute graph subgraph structures are cached and reused. Specifically, when the code repository changes, the system identifies the set of changed files through Git diffs and re-executes S1-S2 parsing and graph rewriting operations only on the changed files and their direct dependencies. Unaffected SCPG subgraph structures are cached and reused, decoupling analysis time from the total size of the code repository—incremental analysis of millions of lines of code is controlled within one minute. The analysis results are output to the continuous integration platform in a structured format. Specifically, the entire analysis workflow runs in headless mode and can be integrated as a Jenkins / GitLab CI / GitHub Actions plugin. The analysis results are output to Pipeline Artifact in structured JSON format, including: a list of violations (accurate to the file + line number + field name), remediation suggestions (including code changes in diff format), remediation impact assessment, and analysis statistics (number of files, number of paths, number of violations, analysis time).

[0043] Corresponding to the above method, this invention also provides a data flow security verification system based on security-enhanced code attribute graphs and bidirectional symbolic execution. This system is implemented by a processor in a computer device executing instructions from memory and includes the following cooperative modular components: (1) Multi-source parsing and SCPG construction engine: This includes a Java source code parser (based on JavaParser / EclipseJDT), an XML configuration parser (parsing MyBatis mapper and Spring configuration), a DDL parser (parsing database schema), and a framework de-abstraction rule engine. The rule engine rewrites rules using a declarative DSL to define the graph, supporting plug-in extensions to adapt to new ORM frameworks and object mapping tools. This module takes the target code repository path as input and outputs the complete SCPG graph structure. For example... Figure 1 As shown, the corresponding module (1) of this engine receives the "target code repository" input and performs multi-source parsing and SCPG construction; (2) Bidirectional Symbolic Execution Engine: Includes a forward symbolic propagator, a backward symbolic queryer, and an SMT solver interface (integrated with Z3 Prover by default). This module takes SCPG and source / sink node sets as input, executes the parallel bidirectional symbolic execution and path merging algorithm described in S2, and outputs a precise set of data flow paths. For example... Figure 1 As shown, the corresponding module (2) of this engine receives the SCPG output and performs bidirectional symbolic execution; (3) Security Label Grid Type Checker: This module includes a security label grid manager (maintaining the grid structure of hierarchical and category labels), a type inferrer (inferring security types based on field name patterns, annotations, and comments), a type transformation calculator (simulating the impact of desensitization, filtering, aggregation, and other operations on security types), and a core algorithm for flow-sensitive type checking (described in S3). This module takes the data flow path as input and outputs the type check verification results (PASS / FAIL and detailed difference information when FAIL). Figure 1 As shown, the inspector corresponds to module (3), which performs security verification on the data flow path; (4) Constraint-Driven Remediation Synthesizer: This module includes a remediation constraint extractor, a remediation template library manager (storing and managing various remediation templates such as desensitization, filtering, removal, aggregation, and encryption), an A* minimal remediation searcher, and a remediation impact analyzer (API contract change detection, downstream consumer impact analysis, and security regression detection). This module takes type check failure results as input and outputs a complete remediation report containing remediation suggestions and impact analysis. Figure 1 As shown, the corresponding module (4) of the synthesizer provides suggestions for fixing violations; (5) Incremental Analysis and CI / CD Integration Adapter: Includes a Git change detector, an incremental dependency calculator (based on SCPG method call edges), an SCPG cache manager, and CI / CD plugin interfaces (Jenkins Plugin, GitLab CITemplate, GitHub Action). This module decouples the analysis time of the entire system from the size of the codebase and supports real-time security verification of each code commit. Figure 1 As shown, the adapter corresponds to module (5) and outputs a "structured security report".

[0044] The following description uses a specific deployment environment to illustrate the operational configuration of the system of the present invention, but the present invention is not limited to the following implementation. In this embodiment, the system can be deployed on a physical server, a virtual machine environment, a containerized environment, or a cloud computing platform.

[0045] Preferably, the computer device includes a processor, a memory, a network communication interface, and an input / output interface. The processor executes program instructions stored in the memory to implement the various functional modules of the present invention; the memory stores source code parsing results, SCPG graph data, intermediate analysis states, and security verification results; the network communication interface is used for data interaction with code repositories, database servers, and continuous integration platforms.

[0046] In an exemplary deployment environment, the system runs on a Linux server with the following configuration: (1) Processor: multi-core CPU; (2) Memory: no less than 32GB; (3) Storage device: solid-state drive or other non-volatile storage medium; (4) Operating system: Linux, Unix or other operating system that supports Java runtime environment; (5) Runtime environment: JDK, graph database components and SMT constraint solver.

[0047] Preferably, the system adopts the following software environment: (1) a source code parsing component for parsing Java source code files; (2) an XML configuration parsing component for parsing MyBatis mapping files, Spring configuration files and other configuration resources; (3) a database schema parsing component for parsing DDL scripts and database metadata; (4) a graph storage component for storing and managing security enhancement code attribute graphs (SCPG); (5) an SMT solver component for execution path satisfiability analysis and constraint solving; (6) a version management interface component for interacting with Git code repositories; and (7) a continuous integration interface component for integrating with continuous integration platforms such as Jenkins, GitLabCI, and GitHub Actions.

[0048] During system runtime, the target code repository is imported into the analysis environment through the code management system. The multi-source parsing and SCPG build engine reads source code files, configuration files, and database schema definition files to construct a security-enhanced code attribute graph. Subsequently, the bidirectional symbolic execution engine performs forward and backward symbolic analysis based on the SCPG and completes path reachability verification through the SMT solver to obtain a complete set of data flow paths. The security tag grid type checker performs security verification on the data flow paths and outputs the verification results. When a security violation is detected, the constraint-driven remediation synthesizer generates corresponding remediation suggestions and impact analysis results. Finally, the analysis results are output to the continuous integration platform or code review platform through incremental analysis and the CI / CD integration adapter, achieving automated data flow security verification.

[0049] Furthermore, the system supports single-machine deployment, distributed deployment, and containerized deployment. In a containerized deployment scenario, each functional module can be encapsulated as an independent service and communicate through a network interface, thereby supporting parallel analysis and elastic scaling of large-scale code repositories.

[0050] The hardware configuration, software environment, and deployment method described in this embodiment are merely examples. Those skilled in the art can make adjustments according to actual application scenarios without departing from the scope of protection of this invention.

[0051] Based on the same inventive concept, this application also provides a graph and bidirectional symbolic execution data stream security verification device, which can be used to implement the method described in the above embodiments, as described in the following embodiments. Since the principle of solving the problem by this graph and bidirectional symbolic execution data stream security verification device is similar to that of the graph and bidirectional symbolic execution data stream security verification method, the implementation of the graph and bidirectional symbolic execution data stream security verification device can refer to the implementation of the graph and bidirectional symbolic execution data stream security verification method, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0052] According to another aspect of this application, a data stream security verification apparatus for graph and bidirectional symbolic execution is also provided, comprising: The multi-source parsing and security-enhanced code attribute graph construction engine is used to parse the target code repository, build an initial code attribute graph that integrates abstract syntax tree, control flow graph and data dependency graph, and activate the framework-aware graph rewriting rule base to expand the declarative framework abstraction into explicit data flow edges to obtain the security-enhanced code attribute graph. The bidirectional symbolic execution engine is used to perform bidirectional symbolic execution on the security enhancement code property graph. It injects symbolic values ​​from database field nodes forward and propagates them along the graph in the forward direction, and injects reverse symbolic queries from API response field nodes backward and propagates them along the graph in the reverse direction. It uses a constraint solver to determine the feasibility of the path, merges and combines the forward and backward path conditions at intermediate nodes, and reconstructs the complete data flow path from the database field to the API response field. The security tag grid type checker performs flow-sensitive type checks based on security tag grids on each data flow path, verifies the sub-type relationships of security types node by node along the path, and outputs the verification results. The constraint-driven repair synthesizer extracts formal repair constraints from non-compliant nodes that fail type checks, matches applicable repair strategies in the repair template library, uses heuristic search to find the optimal repair solution that satisfies the constraints, and outputs repair suggestions.

[0053] In one embodiment, the multi-source parsing and security-enhanced code property graph construction engine includes: A source code parser used to parse source code files and construct abstract syntax tree nodes and edges; An XML configuration parser is used to parse the mapping configuration file and extract the SQL mapping configuration. A database definition language parser is used to parse database definition language scripts to obtain database schema information; The framework de-abstraction rule engine is used to rewrite rules by defining graphs in a declarative domain-specific language. It supports plug-in extensions to adapt to new object-relational mapping frameworks and object mapping tools.

[0054] In one embodiment, the bidirectional symbolic execution engine includes: A forward symbol propagator is used to propagate symbol values ​​forward from each database field node along the data flow edges and control flow edges; Backward symbol lookup is used to propagate backward symbol lookup from each API response field node along the data flow edge. The constraint solver interface is used to perform path satisfiability analysis and constraint solving.

[0055] In one embodiment, the security tag type checker includes: Security label grid manager, used to maintain the grid structure of hierarchical labels and category labels; A type inferr for inferring safe types based on field name patterns, annotations, and comments; Type conversion calculator, used to simulate the impact of desensitization, filtering, and aggregation operations on security types; The core algorithm module for flow-sensitive type checking is used to perform type checking node by node along the data flow path and output the verification results.

[0056] In one embodiment, the constraint-driven repair synthesizer includes: A repair constraint extractor is used to extract formal repair constraints from type check failure results; The Repair Template Library Manager is used to store and manage various repair templates, including those for desensitization, filtering, removal, aggregation, and encryption. Minimal Repair Searcher, used to find the optimal repair solution in the repair space using heuristic search; Repair the impact analyzer to perform API contract change detection, downstream consumer impact analysis, and security regression testing.

[0057] In one embodiment, the apparatus further includes: The Incremental Analysis and Continuous Integration Continuous Deployment Integration Adapter is used to identify the set of changed files through version control differences when the code repository changes. It re-executes parsing and graph rewriting operations only on the changed files and their direct dependencies, caches and reuses unaffected subgraph structures, and outputs the analysis results to the continuous integration platform in a structured format.

[0058] This application constructs a security-enhanced code property graph and uses framework-aware graph rewriting rules during the construction process to abstract and expand the declarative framework into explicit data flow edges. Bidirectional symbolic execution is performed on the graph to reconstruct the complete data flow path from database fields to API response fields. Flow-sensitive type checks based on security tag lattices are performed on each data flow path to provide provable security guarantees. Formal remediation constraints are extracted from violation nodes that fail type checks, and the optimal remediation scheme is searched, thus realizing a complete closed loop from problem discovery to generating executable remediation suggestions.

[0059] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0060] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0061] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0062] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0063] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

[0064] This application also provides a specific implementation of an electronic device capable of implementing all the steps in the methods described above. See [link to implementation details]. Figure 7 The electronic device specifically includes the following: Figure 7 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application. The electronic device includes: a processor 1001, a memory 1002, and a bus 1003.

[0065] The processor 1001 and the memory 1002 communicate with each other via the bus 1003.

[0066] The processor 1001 is used to call a computer program stored in the memory 1002. When the processor executes the computer program, it implements all the steps in the method described in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: S601: Parse the target code repository, construct an initial code attribute graph that integrates the abstract syntax tree, control flow graph, and data dependency graph, and create corresponding nodes for database fields and API response fields respectively; S602: Activate the framework-aware graph rewriting rule base to expand the declarative framework abstraction into explicit data flow edges to obtain a security-enhanced code property graph; S603: Perform bidirectional symbolic execution on the security enhancement code property graph. Forward, inject symbolic values ​​from database field nodes and propagate them forward along the graph. Backward, inject reverse symbolic queries from API response field nodes and propagate them backward along the graph. Use constraint solvers to determine path feasibility. Merge and combine forward and backward path conditions at intermediate nodes to reconstruct the complete data flow path from database fields to API response fields. S604: Perform a flow-sensitive type check based on security tag grid for each data flow path, verify the sub-type relationship of security type node by node along the path, and output the verification result; S605: For violation nodes that fail type checking, extract formal repair constraints, match applicable repair strategies in the repair template library, use heuristic search to find the optimal repair solution that satisfies the constraints, and output repair suggestions.

[0067] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the methods in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the methods in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: S601: Parse the target code repository, construct an initial code attribute graph that integrates the abstract syntax tree, control flow graph, and data dependency graph, and create corresponding nodes for database fields and API response fields respectively; S602: Activate the framework-aware graph rewriting rule base to expand the declarative framework abstraction into explicit data flow edges to obtain a security-enhanced code property graph; S603: Perform bidirectional symbolic execution on the security enhancement code property graph. Forward, inject symbolic values ​​from database field nodes and propagate them forward along the graph. Backward, inject reverse symbolic queries from API response field nodes and propagate them backward along the graph. Use constraint solvers to determine path feasibility. Merge and combine forward and backward path conditions at intermediate nodes to reconstruct the complete data flow path from database fields to API response fields. S604: Perform a flow-sensitive type check based on security tag grid for each data flow path, verify the sub-type relationship of security type node by node along the path, and output the verification result; S605: For violation nodes that fail type checking, extract formal repair constraints, match applicable repair strategies in the repair template library, use heuristic search to find the optimal repair solution that satisfies the constraints, and output repair suggestions.

[0068] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, for hardware + program embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. Although the embodiments in this specification provide the method operation steps as shown in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible execution order among many steps and does not represent the only execution order. In actual device or terminal product execution, the methods can be executed in the order shown in the embodiments or drawings or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, it is not excluded that other identical or equivalent elements may exist in the processes, methods, products, or devices that include the aforementioned elements. For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing the embodiments of this specification, the functions of each module can be implemented in one or more software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed between each other may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. This invention is described with reference to flowchart illustrations and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the invention. It should be understood that each block of a flowchart and / or block diagram, and combinations of blocks in a flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0069] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The various embodiments in this specification are described in a progressive manner, with reference to each other for similar or identical parts. Each embodiment focuses on describing the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to in the description of the method embodiments. In the description of this specification, the reference to terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., means 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 the embodiments of this specification.

[0070] In this specification, the illustrative expressions of the terms used do not necessarily refer to the same embodiments or examples. Furthermore, those skilled in the art can combine and integrate different embodiments or examples described in this specification, as well as features of different embodiments or examples, without contradiction. The above descriptions are merely embodiments of this specification and are not intended to limit the embodiments of this specification. Various modifications and variations can be made to the embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of this specification should be included within the scope of the claims of the embodiments of this specification.< / update> < / insert> < / resultmap>

Claims

1. A data flow security verification method using graphs and bidirectional symbolic execution, characterized in that, include: Parse the target code repository, construct an initial code attribute graph that integrates an abstract syntax tree, a control flow graph, and a data dependency graph, and create corresponding nodes for database fields and API response fields respectively; Activate the framework-aware graph rewriting rule base to expand the declarative framework abstraction into explicit data flow edges to obtain a security-enhanced code property graph; Bidirectional symbolic execution is performed on the security enhancement code property graph. Symbolic values ​​are injected forward from the database field node and propagated along the graph in the forward direction. Reverse symbolic queries are injected backward from the API response field node and propagated along the graph in the reverse direction. The constraint solver is used to determine the feasibility of the path. The forward and backward path conditions are merged and combined at the intermediate nodes to reconstruct the complete data flow path from the database field to the API response field. Perform a flow-sensitive type check based on the security tag grid for each data flow path, verify the sub-type relationship of the security type node by node along the path, and output the verification result; For violation nodes that fail type checks, extract formal repair constraints, match applicable repair strategies in the repair template library, use heuristic search to find the optimal repair solution that satisfies the constraints, and output repair suggestions.

2. The method according to claim 1, characterized in that, The activation framework-aware graph rewriting rule base expands the declarative framework abstraction into explicit data flow edges, including: Identify object-relational mapping annotations and expand them into data flow edges from database field nodes to field nodes; Parse the elements in the XML mapping configuration and expand the column-attribute mapping relationship into data flow edges; Identify object copy call patterns and insert cross-class data flow edges; Identify serialization framework annotations and establish data flow edges from field nodes to API response field nodes.

3. The method according to claim 1, characterized in that, The step of performing bidirectional symbolic execution on the security-enhanced code property graph includes: Starting from each database field node, the symbolic value is propagated forward along the data flow edge and control flow edge. When a conditional branch is encountered, the constraint solver determines the path satisfiability. Satisfiable paths are continued to be tracked, while unsatisfiable paths are pruned. Simultaneously, starting from each API response field node, a reverse symbol query is propagated backward along the data flow edge, and the reverse symbol execution is performed independently and in parallel with the forward symbol execution. The path conditions of the forward and reverse symbol states of intermediate nodes are merged. The constraint solver checks the satisfiability of the merged path conditions and constructs a complete path from the database field node through the intermediate node to the API response field node for satisfiable paths.

4. The method according to claim 1, characterized in that, The process of performing a flow-sensitive type check based on security tag grids on each data flow path includes: Construct a security tag grid, which includes a hierarchical tag set, a category tag set, and combined tags; The initial security type of each database field node is inferred from database schema comments, field name pattern matching, and security annotations. Analyze the annotations and documentation of the target API interface to obtain the security expectation type of the API for the response fields; Perform type checks node by node along each data flow path, apply a data transformation function to each node on the path to calculate the transformed type, and determine whether the transformed type satisfies the subtype relationship of the expected type.

5. The method according to claim 1, characterized in that, For the violation nodes that fail type checks, formal repair constraints are extracted, applicable repair strategies are matched in the repair template library, and heuristic search is used to find the optimal repair solution that satisfies the constraints, including: Formal repair constraints are extracted from the type check failure results, and the repair constraints are matched with a predefined repair template library, which contains repair templates for field desensitization insertion, security annotation addition, sensitive field removal, and SQL layer row-level filtering. The repair cost function is defined as a weighted sum of the number of nodes changed in the abstract syntax tree, the risk of disruptive behavior by downstream API consumers, and runtime performance overhead. Among the repair schemes that satisfy the repair constraints, find the repair scheme with the minimum repair cost function value.

6. The method according to claim 1, characterized in that, Also includes: When changes occur in the code repository, the set of changed files is identified through version control differences. Only the changed files and their direct dependencies are re-executed for parsing and graph rewriting operations. The unaffected security enhancement code attribute graph subgraph structure is cached and reused. The analysis results are output to the continuous integration platform in a structured format.

7. A data stream security verification device for graph and bidirectional symbolic execution, characterized in that, include: The multi-source parsing and security-enhanced code attribute graph construction engine is used to parse the target code repository, build an initial code attribute graph that integrates abstract syntax tree, control flow graph and data dependency graph, and activate the framework-aware graph rewriting rule base to expand the declarative framework abstraction into explicit data flow edges to obtain the security-enhanced code attribute graph. A bidirectional symbolic execution engine is used to perform bidirectional symbolic execution on the security enhancement code property graph. It injects symbolic values ​​from database field nodes forward and propagates them forward along the graph, and injects reverse symbolic queries from API response field nodes backward and propagates them backward along the graph. It uses a constraint solver to determine path feasibility, merges and combines forward and backward path conditions at intermediate nodes, and reconstructs the complete data flow path from the database field to the API response field. The security tag grid type checker performs flow-sensitive type checks based on security tag grids on each data flow path, verifies the sub-type relationships of security types node by node along the path, and outputs the verification results. The constraint-driven repair synthesizer extracts formal repair constraints from non-compliant nodes that fail type checks, matches applicable repair strategies in the repair template library, uses heuristic search to find the optimal repair solution that satisfies the constraints, and outputs repair suggestions.

8. The apparatus according to claim 7, characterized in that, The multi-source parsing and security-enhanced code property graph construction engine includes: A source code parser used to parse source code files and construct abstract syntax tree nodes and edges; An XML configuration parser is used to parse the mapping configuration file and extract the SQL mapping configuration. A database definition language parser is used to parse database definition language scripts to obtain database schema information; The framework de-abstraction rule engine is used to rewrite rules by defining graphs in a declarative domain-specific language. It supports plug-in extensions to adapt to new object-relational mapping frameworks and object mapping tools.

9. The apparatus according to claim 7, characterized in that, The bidirectional symbolic execution engine includes: A forward symbol propagator is used to propagate symbol values ​​forward from each database field node along the data flow edges and control flow edges; Backward symbol lookup is used to propagate backward symbol lookup from each API response field node along the data flow edge. The constraint solver interface is used to perform path satisfiability analysis and constraint solving.

10. The apparatus according to claim 7, characterized in that, The security tag type checker includes: Security label grid manager, used to maintain the grid structure of hierarchical labels and category labels; A type inferr for inferring safe types based on field name patterns, annotations, and comments; Type conversion calculator, used to simulate the impact of desensitization, filtering, and aggregation operations on security types; The core algorithm module for flow-sensitive type checking is used to perform type checking node by node along the data flow path and output the verification results.

11. The apparatus according to claim 7, characterized in that, The constraint-driven repair synthesizer includes: A repair constraint extractor is used to extract formal repair constraints from type check failure results; The Repair Template Library Manager is used to store and manage various repair templates, including those for desensitization, filtering, removal, aggregation, and encryption. Minimal Repair Searcher, used to find the optimal repair solution in the repair space using heuristic search; Repair the impact analyzer to perform API contract change detection, downstream consumer impact analysis, and security regression testing.

12. The apparatus according to claim 7, characterized in that, Also includes: The Incremental Analysis and Continuous Integration Continuous Deployment Integration Adapter is used to identify the set of changed files through version control differences when the code repository changes. It re-executes parsing and graph rewriting operations only on the changed files and their direct dependencies, caches and reuses unaffected subgraph structures, and outputs the analysis results to the continuous integration platform in a structured format.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the data flow security verification method for graph and bidirectional symbol execution as described in any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the data stream security verification method for graph and bidirectional symbol execution as described in any one of claims 1 to 6.

Images