An intelligent code defect detection method combining static analysis and AI inference

Abstract

This invention discloses an intelligent code defect detection method integrating static analysis and AI reasoning, belonging to the field of artificial intelligence technology. It includes the following steps: S1: Performing static analysis on the code to be detected to construct verifiable static evidence containing defect candidates, evidence paths, variables and constraints, sources and sinks, and environment and configuration; S2: Organizing the static evidence and project context information into a structured evidence package according to the Evidence Constraint Architecture (ECS); S3: Under the evidence constraints, performing defect judgment and attribution on the evidence package through AI reasoning, outputting judgment conclusions, reasoning chains, and remediation suggestions, with each judgment conclusion establishing a traceable binding relationship with its referenced Must-Cite field; S4: Performing consistency verification and confidence assessment on the AI ​​reasoning conclusions, and calculating defect priority. This invention significantly reduces false positives in static analysis and suppresses AI illusionary conclusions through a closed-loop mechanism of "strong evidence constraints + formal consistency verification + conflict rollback."

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an intelligent method for detecting code defects that integrates static analysis and AI reasoning. Background Technology

[0002] As business systems become more complex and delivery pace accelerates, code defects (such as null pointers, resource leaks, concurrency races, injection vulnerabilities, privilege escalation, bounds violations, and logical vulnerabilities) have become a significant source of online incidents and security risks. To detect defects as early as possible during the development phase, the industry typically employs methods such as static analysis, dynamic testing, and code review. However, existing technologies have the following main shortcomings: 1. Traditional static analysis relies on rule / pattern matching or data flow analysis. Its advantage is that it can locate the line of code and provide the path, but it is prone to false alarms (lacking business context, difficult to understand framework / configuration / implicit constraints), and has limited coverage of cross-file, cross-module, and cross-language call chains.

[0003] 2. While AI / large model-based code review or defect detection has semantic understanding capabilities, it is prone to "illusionary" conclusions when verifiable evidence is lacking. Furthermore, the output is difficult to align with evidence such as executable paths, variable constraints, and call stacks, resulting in insufficient feasibility and traceability.

[0004] 3. Static analysis and AI capabilities are often disconnected: static analysis results cannot be effectively interpreted and filtered by AI; AI conclusions lack static evidence support, making it difficult to automatically enter the quality gate (CI) or form closed-loop repair suggestions.

[0005] Therefore, there is a need for an intelligent detection method that deeply integrates the "verifiable evidence" of static analysis with the "semantic understanding and defect attribution" of AI reasoning, in order to reduce false alarms, improve recall, and output interpretable, localizable, and verifiable defect reports and remediation suggestions. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides an intelligent code defect detection method that integrates static analysis and AI reasoning. Through a closed-loop process of "static evidence construction - ECS evidence package organization - constrained reasoning - assertion extraction and entity linking - SAT / SMT consistency verification - conflict rollback - confidence and priority - structured output and backfeeding", it significantly reduces false alarms without sacrificing the traceability of static analysis. Formal consistency verification suppresses AI illusionary conclusions and improves verifiability, and the output can be directly entered into CI access control and defect closed-loop management.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: A code defect intelligent detection method integrating static analysis and AI reasoning includes the following steps: S1: Perform static analysis on the code to be detected to construct verifiable static evidence, including defect candidates, evidence paths, variables and constraints, sources and sinks, environment and configuration; S2: Organize the static evidence and project context information into a structured evidence package according to the Evidence Constraint Architecture (ECS); The Evidence Constraint Architecture (ECS) includes at least: Must-Cite Fields, which limits the evidence fields that must be referenced in each defect determination conclusion of the AI ​​inference output; and Must-HoldConstraints, which limits the program logic constraints that the AI ​​inference output must not conflict with the constraint set. S3: Under the constraint of evidence, the evidence package is defect-determined and attributed through AI reasoning, and the determination conclusion, reasoning chain and repair suggestions are output. Each determination conclusion is traceably bound to the Must-Cite field it references. S4: Perform consistency verification and confidence assessment on the AI ​​reasoning conclusions, and calculate defect priority; The consistency verification includes at least the following: extracting code entities and relation assertions from the inference chain and performing entity linking and relation matching with the structured evidence in the evidence package to detect semantic inconsistencies; formalizing the defect triggering conditions inferred from the inference chain into logical propositions and submitting them together with Must-Hold Constraints to the constraint solver for satisfiability verification; and triggering a conflict handling strategy when the verification is unsatisfiable or an inconsistency is detected. The constraint solver is a SAT or SMT solver; when satisfiability verification fails, the conflict handling strategy includes at least one of the following: (a) downgrading the AI ​​conclusion or marking it as "requiring manual review"; (b) reverting to outputting only a static evidence report; (c) requiring supplementary evidence fields before reasoning. S5: Output a structured defect report and remediation suggestions, and feed back the developer's adoption and verification results to the system for continuous optimization of static analysis rules, evidence fusion strategies and AI inference prompt templates or model parameters; wherein, the structured defect report includes at least defect identifier, location information, evidence package summary, inference chain, confidence level and verification strategy.

[0008] As a preferred technical solution of the present invention, the static analysis in step S1 includes at least one or more of the following combinations: rule matching, data flow analysis, taint analysis, symbolic execution, constraint solving, and cross-language call graph construction.

[0009] As a preferred technical solution of the present invention, the evidence path in step S1 includes at least one of control flow path, data flow path, cross-function call chain, and cross-module call chain, and each edge in the evidence path carries the path condition or variable constraint that causes the edge to be valid; the Must-Cite Fields in step S2 include at least: the code location that triggers the defect, the corresponding data flow / taint propagation sequence, the key variable identifier and its value or value range at the program point; the Must-Hold Constraints in step S2 include at least: reachability constraints, null value impossibility constraints, resource lifecycle constraints or concurrent mutual exclusion constraints obtained by symbolic execution or constraint solving.

[0010] As a preferred technical solution of the present invention, the AI ​​inference in step S3 includes the following mechanism: Evidence constraint hints: Input evidence paths, variable constraints, and source-sink chains into the AI ​​model in a structured form; Counterexample and exclusion reasoning: Try to construct counterexamples based on static constraints to exclude false positives; Knowledge enhancement: Retrieve framework semantics, historical remediation patterns, and vulnerability database information to assist reasoning; Multi-round reasoning and self-consistency verification: Perform multi-perspective reasoning on the same evidence package and fuse the output; Among them, counterexample and exclusion reasoning includes at least: automatically constructing counterexample conditions that make the defect invalid without violating Must-Hold Constraints, and filtering false positives accordingly.

[0011] As a preferred technical solution of the present invention, the confidence assessment in step S4 is based on at least one of the following factors: static evidence strength, AI reasoning consistency, historical similarity defect hit rate, path solvability, and tool consistency, and the consistency verification pass / fail is used as the key weighting factor of confidence.

[0012] As a preferred technical solution of the present invention, the structured defect report in step S5 includes: defect identifier, location information, evidence package summary, AI inference chain, repair suggestions and verification strategy.

[0013] As a preferred technical solution of the present invention, the detection method also includes an incremental scanning mechanism, which locates the impact range of code changes, reuses historical evidence and cache, and supports layered triggering of fast scanning and deep scanning.

[0014] As a preferred technical solution of the present invention, the repair suggestions in step S5 include automatically generated repair patch candidates, as well as corresponding unit test cases, rule regression verification or differential compilation verification strategies.

[0015] This invention also proposes a code defect intelligent detection system for implementing the above-described method, comprising the following modules: Code acquisition and preprocessing module: acquires the code to be detected, builds the compilation environment / dependency graph, and completes branch merging, macro expansion, formatting, and language recognition; Static analysis evidence construction module: Constructs intermediate representations such as AST / CFG / DFG / PDG for the code, and performs rule analysis, data flow analysis, taint analysis, symbolic execution / constraint solving, etc., to generate verifiable evidence; Context and Knowledge Retrieval Module: Collects context such as project configuration, framework conventions, API semantics, historical defects and fixes, coding standards, and threat models to form a searchable knowledge base; Evidence package organization and fusion module: Normalizes static analysis results into a unified schema (location, path, variables, constraints, source / sink, call chain), and performs deduplication, clustering and merging of results from multiple tools / rules; Reasoning and Judgment Module: Under evidence constraints, it performs defect type identification, false alarm filtering, trigger condition deduction, impact assessment and remediation strategy generation, and can adopt multi-round reasoning / multi-agent collaboration. Consistency verification and confidence assessment module: Verifies whether the AI ​​conclusions are consistent with static evidence, performs counterexample search for critical paths and constraints, and outputs the confidence and priority of defects; Report and remediation suggestion generation module: Outputs structured defect reports, remediation patch candidates, verification steps (unit testing / rule regression / differentiation), and results of integration with CI access control; Feedback and Incremental Learning Module: Feeds back developer adoption / rejection, verification results, and runtime information, and updates rule thresholds, evidence fusion strategies, and prompt templates / model parameters.

[0016] This invention also proposes a code defect intelligent detection system, which supports integration with continuous integration (CI), implements automated quality access control based on confidence and priority, and the consistency verification and confidence evaluation module is configured to perform assertion extraction entity linking and satisfiability verification as described in S4.

[0017] The beneficial effects of this invention are as follows: 1. The false positive rate of this invention is significantly reduced: AI reasoning is constrained by static evidence and combined with the project context (dependencies, framework, configuration, historical fixes) to make judgments, reducing false positives from rule-based static analysis. Thus, AI performs context-aware reasoning under the constraint of static evidence, effectively filtering out false positives caused by a lack of business semantics or framework understanding.

[0018] 2. This invention has strong interpretability and traceability: It outputs an "evidence package" (data flow / control flow path, relevant variable constraints, call chain, constraint conditions) and an "inference chain" (judgment basis, counterexample exclusion) for each defect, which helps developers to quickly locate and reproduce the defect. Thus, each defect is accompanied by an "evidence package" and an "inference chain", which makes it easy for developers to quickly locate, understand and reproduce the defect.

[0019] 3. Improved defect recall rate of this invention: By concatenating cross-language call chains, completing library / API semantics, propagating taints and solving constraints, the detection capability of security and logic defects is improved, thereby supporting cross-language and cross-module call chain concatenation and constraint propagation, and enhancing the detection capability of complex security vulnerabilities and logic defects.

[0020] 4. This invention forms a quality closed loop: It supports the automatic generation of repair patch candidates and verification strategies (single test / rule regression / differential compilation), and feeds back the adoption and verification results to continuously optimize the model and rules, so as to achieve continuous self-optimization of the system.

[0021] 5. This invention has good feasibility for implementation: it provides incremental analysis, cache reuse, layered scanning (fast / deep) and resource budget control, and is suitable for large-scale codebases and CI scenarios; 6. By employing the "Evidence Constraint Architecture (ECS)" and the dual mechanisms of "must be cited" and "cannot be violated", this invention forces the AI ​​model's reasoning process to be anchored to the precise and verifiable logical state within the program, fundamentally limiting the AI's freedom to generate "illusions", thereby achieving the technical effect of significantly reducing the false alarm rate. Attached Figure Description

[0022] Figure 1 This is a block diagram of the system structure of the present invention; Figure 2 This is the overall flowchart of the present invention; Figure 3 This is a schematic diagram of the evidence package of the present invention; Figure 4 This is a schematic diagram of the static evidence fusion process of the present invention; Figure 5 This is a schematic diagram of the AI ​​inference and consistency verification process of the present invention; Figure 6 This is a schematic diagram illustrating the output of the defect report and repair suggestion of the present invention; Figure 7 This is a flowchart illustrating the steps of an intelligent code defect detection method that integrates static analysis and AI reasoning, as proposed in this invention. Detailed Implementation

[0023] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0024] Example 1, referring to Figure 7 and Figure 3-6 A code defect intelligent detection method that integrates static analysis and AI reasoning includes the following steps: S1: Perform static analysis on the code to be detected to construct verifiable static evidence, including defect candidates, evidence paths, variables and constraints, sources and sinks, environment and configuration; S2: Organize static evidence and project context information into a structured evidence package according to the Evidence Constraint Framework (ECS). Organize and encode static evidence and project context information according to the preset Evidence Constraint Framework (ECS) to generate a structured evidence package; wherein, the ECS defines at least one "Must-Cite" field set and one "Must-Hold" constraint set; S3: Under the constraint of evidence, the evidence package is defect-determined and attributed through AI reasoning, and the determination conclusion, reasoning chain and repair suggestions are output. Each determination conclusion is traceably bound to the Must-Cite field it references. S4: Perform consistency verification and confidence assessment on the AI ​​reasoning conclusions, and calculate defect priority; The consistency verification includes at least the following: extracting code entities and relation assertions from the inference chain and performing entity linking and relation matching with the structured evidence in the evidence package to detect semantic inconsistencies; formalizing the defect triggering conditions inferred from the inference chain into logical propositions and submitting them together with Must-Hold Constraints to the constraint solver for satisfiability verification; and triggering a conflict handling strategy when the verification is unsatisfiable or an inconsistency is detected. The constraint solver is a SAT or SMT solver; when satisfiability verification fails, the conflict handling strategy includes at least one of the following: (a) downgrading the AI ​​conclusion or marking it as "requiring manual review"; (b) reverting to outputting only a static evidence report; (c) requiring supplementary evidence fields before reasoning. S5: Outputs structured defect reports and remediation suggestions, and feeds back the developer adoption and verification results to the system for continuous optimization of models and rules.

[0025] Furthermore, in step S3, the structured evidence package is processed by an AI reasoning model. The AI ​​reasoning model's prompt or input layer is configured to: prioritize extracting information from the "must-cite" field set as the basis for reasoning, and automatically associate each defect judgment conclusion in its output with the specific evidence field cited. At the same time, the model's reasoning process is required to explicitly declare in its output natural language reasoning chain or internal representation how its conclusion satisfies the conditions in the "cannot be violated" constraint set, or why certain constraints can be safely ignored in this context.

[0026] Furthermore, the "structured evidence package" in step S2 follows an Evidence Constraint Architecture (ECS), which explicitly defines the set of evidence fields that the AI ​​inference model must reference (Must-Cite Fields) and the set of procedural logic constraints that the inference conclusion must not violate (Must-Hold Constraints). In step S3, the output of the AI ​​inference model contains a natural language inference chain. The consistency verification in step S4 includes: automatically extracting code entities and relational assertions from the natural language inference chain, linking them with the structured evidence in the evidence package, and matching them with the relationships to detect semantic inconsistencies. Step S4 also includes: formalizing the defect triggering conditions inferred from the AI ​​inference chain into logical propositions, submitting them together with the procedural constraints in the evidence package to the constraint solver for satisfiability verification, and using the verification result as one of the core factors for confidence assessment.

[0027] Furthermore, the "must-reference" field set in step S2 may include: the precise line location of the defect trigger, the taint propagation path sequence, and the names of the key variables involved. The "cannot be violated" constraint set may include: proof that a variable cannot be null at a specific program point, proof that two threads cannot simultaneously hold the same lock, and proof that the resource must have been released before the sink. When the AI ​​model outputs the conclusion "a null pointer exception may exist," it must cite the data flow fact provided in the evidence package that "the value of variable X at line N is NULL," and explain in the inference chain how it excludes the potential but infeasible counterexample that "variable X was reassigned before line N."

[0028] Furthermore, the consistency verification and confidence assessment in step S4 specifically include: Evidence backtracking and verification: Analyze the natural language description generated by the AI ​​inference chain, automatically extract the code locations, variable names, and relational assertions mentioned, and automatically match and verify them with the original structured evidence in the evidence package. If a mismatch is found (e.g., the AI ​​mentions a non-existent variable) or a direct contradiction exists (e.g., the AI ​​claims a path is reachable while static symbolic execution proves it is unreachable), a consistency conflict alert is triggered. Dynamic constraint solution verification: The defect triggering conditions inferred by the AI ​​(e.g., "when input Y>100 and the cache is empty") are formalized into logical constraints, and together with the existing "unbreakable" constraints in the evidence package, they are input into the constraint solver for satisfiability (SAT) solving. If the solution is successful, the credibility of the AI's conclusion is enhanced; if the solution fails (i.e., the conditions cannot be satisfied simultaneously), it indicates that there may be logical errors in the AI's reasoning, and the confidence of the conclusion will be significantly reduced. Confidence quantification formula: An exemplary confidence calculation function is disclosed.

[0029] Further as Figure 3 The unified representation of static analysis evidence (evidence schema) includes at least the following: (1) Defect candidates: defect category, severity level, file / function / row / column position, related code snippets and context window; (2) Evidence path: control flow path (CFG path), data flow path (def-use chain / taint propagation chain), cross-function / cross-module call chain; (3) Variables and constraints: key variable value range, null / alias relationship, lock / thread relationship, resource lifecycle constraints, input validation conditions, etc.; (4) Source and sink (security defects): source point (input), propagation, sink point (dangerous call / API), and necessary purification / validation conditions; (5) Environment and configuration: compiler macros, dependency versions, configuration items, framework annotations / conventions, etc., which affect whether the defect is valid.

[0030] The aforementioned evidence can be generated and fused using various static analysis techniques, including but not limited to: pattern matching, data flow / taint analysis, symbolic execution and constraint solving, cross-language call graph splicing, SSA / IR analysis, etc.

[0031] Furthermore, the static analysis in step S1 includes at least one or more of the following combinations: rule matching, data flow analysis, taint analysis, symbolic execution, constraint solving, and cross-language call graph construction.

[0032] Furthermore, in step S1, the evidence path includes at least one of control flow path, data flow path, cross-function call chain, and cross-module call chain, and each edge in the evidence path carries a path condition or variable constraint that causes the edge to be valid; in step S2, the Must-Cite Fields include at least: the code location where the defect is triggered, the corresponding data flow / taint propagation sequence, the key variable identifier and its value or value range at the program point; in step S2, the Must-Hold Constraints include at least: reachability constraints, null value impossibility constraints, resource lifecycle constraints or concurrent mutual exclusion constraints obtained by symbolic execution or constraint solving.

[0033] Furthermore, the AI ​​inference in step S3 includes the following mechanisms: Evidence constraint hints: Input evidence paths, variable constraints, and source-sink chains into the AI ​​model in a structured form; Counterexample and exclusion reasoning: Try to construct counterexamples based on static constraints to exclude false positives; Knowledge enhancement: Retrieve framework semantics, historical remediation patterns, and vulnerability database information to assist reasoning; Multi-round reasoning and self-consistency verification: Perform multi-perspective reasoning on the same evidence package and fuse the output. Among them, counterexample and exclusion reasoning includes at least: automatically constructing counterexample conditions that make the defect invalid without violating Must-Hold Constraints, and filtering false positives accordingly.

[0034] Furthermore, in step S4, the confidence assessment is based on at least one of the following factors: static evidence strength, AI reasoning consistency, historical similarity defect hit rate, path solvability, and tool consistency, with consistency verification pass / fail as the key weighting factor for confidence.

[0035] Furthermore, to ensure feasibility, this invention introduces consistency verification and confidence calculation for AI conclusions in step S4, including: (1) Evidence consistency: verify whether the code location and propagation chain cited by the AI ​​match the static evidence; if there is a contradiction, the weight is reduced or it is rolled back to static reporting only; (2) Verifiability: generate minimum triggering conditions (MTC) and verification suggestions (single test input, concurrent scheduling, resource boundary) for key defects, and automatically generate verification test cases when feasible; (3) Confidence modeling: calculate the confidence score by comprehensively considering the strength of static evidence (path length, constraint solvability, tool consistency), AI inference consistency, historical similar defect hit rate, etc.; (4) Priority ranking: rank based on confidence, scope of impact (downstream of the call chain, exposure surface), severity level, security compliance requirements and repair cost estimate.

[0036] Furthermore, the structured defect report in step S5 includes: defect identifier, location information, evidence package summary, AI inference chain, remediation suggestions and verification strategy.

[0037] Furthermore, in step S5, the defect report and remediation suggestion output, the structured report output by the system shall include at least the following: (1) Defect identifier: defect category, CWE mapping (if applicable), severity level, confidence level, priority; (2) Location information: file / function / row / column, related call chain, key code snippet; (3) Evidence package summary: data flow / control flow path, variable constraints, source-sink chain and triggering conditions; (4) AI inference chain: reasons for defect establishment, exclusion conditions, possible business impact and security consequences; (5) Remediation suggestions: remediation strategy (verification / locking / relevant resource release / parameterized SQL, etc.), patch candidates (optional), regression verification suggestions.

[0038] Furthermore, the detection method also includes an incremental scanning mechanism, which locates the impact of code changes based on the scope of impact, reuses historical evidence and cache, and supports layered triggering of fast scanning and deep scanning.

[0039] Furthermore, the repair recommendations in step S5 include automatically generated repair patch candidates, as well as corresponding unit test cases, rule regression verification, or differential compilation verification strategies.

[0040] Example 2, refer to Figure 1 This embodiment is an optimization based on Embodiment 1. Specifically, this embodiment also proposes a code defect intelligent detection system to implement the method of Embodiment 1, including the following modules: M1 code acquisition and preprocessing module: acquires the code to be detected, builds the compilation environment / dependency graph, and completes branch merging, macro expansion, formatting and language recognition; M2 Static Analysis Evidence Building Module: Constructs intermediate representations of code such as AST / CFG / DFG / PDG, and performs rule analysis, data flow analysis, taint analysis, symbolic execution / constraint solving, etc., to generate verifiable evidence; M3 Context and Knowledge Retrieval Module: Collects context such as project configuration, framework conventions, API semantics, historical defects and fixes, coding standards, and threat models to form a searchable knowledge base; The M4 evidence package organization and fusion module normalizes static analysis results into a unified schema (location, path, variables, constraints, source / sink, call chain), and performs deduplication, clustering, and merging of results from multiple tools / rules. M5 Reasoning and Judgment Module: Under evidence constraints, it performs defect type identification, false alarm filtering, trigger condition deduction, impact assessment and remediation strategy generation, and can adopt multi-round reasoning / multi-agent collaboration. M6 Consistency Verification and Confidence Assessment Module: Verifies whether AI conclusions are consistent with static evidence, performs counterexample search for critical paths and constraints, and outputs defect confidence and priority. M7 Report and Remediation Recommendation Generation Module: Outputs structured defect reports, remediation patch candidates, verification steps (unit testing / rule regression / differentiation), and results of integration with CI access control. The M8 feedback and incremental learning module feeds back developer adoption / rejection data, verification results, and runtime information, and updates rule thresholds, evidence fusion strategies, and prompt templates / model parameters.

[0041] In addition, the system supports integration with continuous integration (CI), and implements automated quality access control based on confidence and priority. The consistency verification and confidence assessment module is configured to perform assertion extraction entity linking and satisfiability verification as described in S4.

[0042] Furthermore, the AI-based reasoning and judgment module receives "evidence package + project context + knowledge retrieval results" as input and outputs "judgment conclusion + reasoning chain + repair suggestions". Key mechanisms include: (1) Evidence constraint hints: Provide the AI ​​with evidence paths, variable constraints, source-sink chains, call chains, etc. in a structured form, and require the conclusion to cite evidence fields (traceable); (2) Counterexample and exclusion reasoning: After the AI ​​generates the conditions for the defect to be established, it automatically attempts to construct counterexamples to exclude false alarms by combining static constraint solving and rule counterproof (e.g., verified / locked / closed resources); (3) Knowledge enhancement: By searching the framework API semantics, historical repair patterns, and CWE / vulnerability pattern library, the abstract defect is attributed to specific semantics (e.g., misuse of a specific library); (4) Multi-round reasoning and self-consistency: Perform multi-perspective reasoning (security / concurrency / resources / logic) on the same evidence package, and perform self-consistent voting or weighted fusion to output a stable conclusion.

[0043] Reference Figure 2 The workflow of this invention is as follows: S1: Receives the code to be inspected and build information, parses the language and dependencies, and generates a unified project structure index.

[0044] S2: Construct intermediate representations (AST / CFG / DFG / call graph, etc.) and perform rule analysis, data flow / taint analysis, and symbolic execution when necessary to obtain defect candidates and evidence paths.

[0045] S3: Collect and retrieve project context and knowledge base information (configuration, framework semantics, historical fixes, vulnerability pattern library, etc.) to form a queryable context set.

[0046] S4: Cluster, deduplicatize, and fuse evidence from multiple sources to form a standardized evidence package (including path, variable constraints, source-sink, etc.).

[0047] S5: Under the constraints of evidence, invoke AI reasoning to output the judgment conclusion, the conditions for establishment, the conditions for exclusion, and the repair suggestions for each evidence package.

[0048] S6: Perform consistency checks and counterexample searches on the AI ​​conclusions, calculate confidence and priority; roll back / de-weight inconsistent conclusions if necessary.

[0049] S7: Outputs structured reports and integrates with CI access control; collects and feeds back developer processing and verification results for incremental updates of rules, fusion strategies, and prompt templates.

[0050] In summary, the present invention achieves the following corresponding technical effects: K1: A unified schema and evidence package organization method for static analysis evidence: It unifies the structured expression of control flow / data flow / source-sink chain / variable constraints / environmental conditions and supports cross-language call chain splicing.

[0051] K2: A mechanism for fusing and clustering deduplication of multi-source static results: It associates, merges, and resolves conflicts among candidates from different rules and analyzers to form a high-quality evidence package.

[0052] K3: AI reasoning judgment method under evidence constraints: AI output must reference evidence fields and be subject to constraint solving / proof by contradiction verification, reducing "illusionary" conclusions and improving interpretability.

[0053] K4: Consistency Verification and Confidence Modeling: Integrating evidence strength, reasoning consistency, historical similarity, and verifiability, it provides confidence scores and priority rankings for CI access control decisions.

[0054] K5: Verifiable Repair Suggestion Generation: Generates repair patch candidates and verification strategies (single test / rule regression / differential analysis) based on defect type and evidence path, and supports backfeed closed-loop optimization.

[0055] K6 (optional): Incremental scanning and resource budget control: Locate the impact of changes in a large-scale codebase, reuse caches and evidence, and trigger rapid / deep analysis in layers.

[0056] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A code defect intelligent detection method integrating static analysis and AI reasoning, characterized in that, Includes the following steps: S1: Perform static analysis on the code to be detected to construct verifiable static evidence, including defect candidates, evidence paths, variables and constraints, sources and sinks, environment and configuration; S2: Organize the static evidence and project context information into a structured evidence package according to the Evidence Constraint Architecture (ECS); The Evidence Constraint Architecture (ECS) includes at least: Must-Cite Fields, which limits the evidence fields that must be referenced in each defect determination conclusion of the AI ​​inference output; and Must-HoldConstraints, which limits the program logic constraints that the AI ​​inference output must not conflict with the constraint set. S3: Under the constraint of evidence, the evidence package is defect-determined and attributed through AI reasoning, and the determination conclusion, reasoning chain and repair suggestions are output. Each determination conclusion is traceably bound to the Must-Cite field it references. S4: Perform consistency verification and confidence assessment on the AI ​​reasoning conclusions, and calculate defect priority; The consistency verification includes at least the following: extracting code entities and relation assertions from the inference chain and performing entity linking and relation matching with the structured evidence in the evidence package to detect semantic inconsistencies; formalizing the defect triggering conditions inferred from the inference chain into logical propositions and submitting them together with Must-Hold Constraints to the constraint solver for satisfiability verification; and triggering a conflict handling strategy when the verification is unsatisfiable or an inconsistency is detected. The constraint solver is a SAT or SMT solver; when satisfiability verification fails, the conflict handling strategy includes at least one of the following: (a) downgrading the AI ​​conclusion or marking it as "requiring manual review"; (b) reverting to outputting only a static evidence report; (c) requiring supplementary evidence fields before reasoning. S5: Output a structured defect report and remediation suggestions, and feed back the developer's adoption and verification results to the system for continuous optimization of static analysis rules, evidence fusion strategies and AI inference prompt templates or model parameters; wherein, the structured defect report includes at least defect identifier, location information, evidence package summary, inference chain, confidence level and verification strategy.

2. The intelligent code defect detection method integrating static analysis and AI reasoning according to claim 1, characterized in that, The static analysis in step S1 includes at least one or more of the following combinations: rule matching, data flow analysis, taint analysis, symbolic execution, constraint solving, and cross-language call graph construction.

3. The intelligent code defect detection method integrating static analysis and AI reasoning according to claim 1, characterized in that, In step S1, the evidence path includes at least one of control flow path, data flow path, cross-function call chain, and cross-module call chain, and each edge in the evidence path carries a path condition or variable constraint that causes the edge to be valid; in step S2, the Must-Cite Fields include at least: the code location where the defect is triggered, the corresponding data flow / taint propagation sequence, the key variable identifier and its value or value range at the program point; in step S2, the Must-Hold Constraints include at least: reachability constraints, null value impossibility constraints, resource lifecycle constraints or concurrent mutual exclusion constraints obtained by symbolic execution or constraint solving.

4. The intelligent code defect detection method integrating static analysis and AI reasoning according to claim 1, characterized in that, The AI ​​inference in step S3 includes the following mechanisms: Evidence constraint hints: Input evidence paths, variable constraints, and source-sink chains into the AI ​​model in a structured form; Counterexample and exclusion reasoning: Try to construct counterexamples based on static constraint solutions to exclude false positives; Knowledge Enhancements: Retrieval framework semantics, historical remediation patterns, and vulnerability database information assist in reasoning; Multi-round reasoning and self-consistency verification: Perform multi-perspective reasoning on the same evidence package and fuse the output; among which, counterexample and exclusion reasoning includes at least: automatically constructing counterexample conditions that make the defects invalid without violating Must-Hold Constraints, and filtering false alarms accordingly.

5. The intelligent code defect detection method integrating static analysis and AI reasoning according to claim 1, characterized in that, In step S4, the confidence assessment is based on at least one of the following factors: static evidence strength, AI reasoning consistency, historical similarity defect hit rate, path solvability, and tool consistency, with consistency verification pass / fail as the key weighting factor for confidence.

6. The intelligent code defect detection method integrating static analysis and AI reasoning according to claim 1, characterized in that, The structured defect report in step S5 includes: defect identifier, location information, evidence package summary, AI inference chain, remediation suggestions and verification strategy.

7. The intelligent code defect detection method integrating static analysis and AI reasoning according to claim 1, characterized in that, It also includes an incremental scanning mechanism, which locates the impact of code changes based on the scope of the changes, reuses historical evidence and cache, and supports layered triggering of fast and deep scans.

8. The intelligent code defect detection method integrating static analysis and AI reasoning according to claim 1, characterized in that, The repair suggestions in step S5 include automatically generated repair patch candidates, as well as corresponding unit test cases, rule regression verification, or differential compilation verification strategies.

9. A code defect intelligent detection system, used to implement the method as described in any one of claims 1-8, characterized in that, It includes the following modules: Code acquisition and preprocessing module: acquires the code to be detected, builds the compilation environment / dependency graph, and completes branch merging, macro expansion, formatting, and language recognition; Static analysis evidence construction module: Constructs intermediate representations of code using AST / CFG / DFG / PDG, and performs rule analysis, data flow analysis, taint analysis, symbolic execution / constraint solving, etc., to generate verifiable evidence; Context and Knowledge Retrieval Module: Collects context such as project configuration, framework conventions, API semantics, historical defects and fixes, coding standards, and threat models to form a searchable knowledge base; Evidence package organization and fusion module: Normalizes static analysis results into a unified schema, and performs deduplication, clustering and merging of results from multiple tools / rules; Reasoning and Judgment Module: Under evidence constraints, it performs defect type identification, false alarm filtering, trigger condition deduction, impact assessment and remediation strategy generation, and can adopt multi-round reasoning / multi-agent collaboration. Consistency verification and confidence assessment module: Verifies whether the AI ​​conclusions are consistent with static evidence, performs counterexample search for critical paths and constraints, and outputs the confidence and priority of defects; The report and remediation suggestion generation module outputs a structured defect report, remediation patch candidates, verification steps, and the results of integration with the CI access control system. Feedback and Incremental Learning Module: Feeds back developer adoption / rejection, verification results, and runtime information, and updates rule thresholds, evidence fusion strategies, and prompt templates / model parameters.

10. The intelligent code defect detection system according to claim 9, characterized in that, The system supports integration with continuous integration (CI), implements automated quality access control based on confidence and priority, and the consistency verification and confidence assessment module is configured to perform assertion extraction entity linking and satisfiability verification as described in S4.

Images