Automatic code generation and optimization method and system based on large model

Abstract

The invention provides an automatic code generation and optimization method and system based on a large model. According to the method, an initial logic framework is generated through a large model analysis function requirement, a symbolized structure is formed through symbolization processing, code intermediate representation with key semantics reserved is generated according to the symbolized structure, and finally source codes are output. An index set is constructed by utilizing a vulnerability knowledge graph, a source code instruction sequence is scanned through parallel computing, and risk instruction positions and vulnerability details are marked in combination with semantic similarity and path pattern matching. And based on the vulnerability information, retrieving a historical case library, establishing a matching relationship, and generating an optimization strategy containing repair operation and constraint. And loading a semantic analysis model at a risk position, constructing an execution mode difference atlas generation feature, constructing an adversarial sample fine-tuning large model parameter according to the feature, and performing vulnerability reinspection on a newly generated code. According to the method, intelligent generation from requirements to codes is realized, and loophole identification, repair strategy generation, large model dynamic optimization and verification after repair are completed in a closed loop manner.

Description

Technical Field

[0001] This application relates to the field of intelligent code generation and collaborative optimization technology, and in particular to an automated code generation and optimization method and system based on a large model. Background Technology

[0002] In applications that utilize large language models to automatically generate code, especially in DevOps processes, low-code platforms, or AI-assisted programming tools that require rapid iteration, ensuring the security of the generated code faces significant challenges. This scenario urgently requires a technical solution capable of automatically and accurately identifying potential security vulnerabilities during or shortly after code generation, generating targeted remediation strategies, and even automatically completing the remediation process. Ideally, this technology should deeply understand the semantics, control flow, and data dependencies of the code, correlate with a vulnerability knowledge base, and possess closed-loop self-optimization capabilities. This means dynamically adjusting the generation model based on detection results to reduce vulnerability recurrence rates from the source, achieving a closed loop of "security upon generation" or "instant remediation."

[0003] To address the aforementioned needs, a representative technical solution currently is to integrate mature static application security testing tools as a post-processing step into the large model code generation pipeline. The process is as follows: after the large model generates complete source code, it triggers the static application security testing tool to scan; the static application security testing tool, based on its predefined, manually maintained vulnerability feature rule base, performs security checks on the generated code using techniques such as pattern matching and taint analysis; finally, it outputs a report containing the vulnerability location, type, and risk level, sometimes accompanied by general remediation suggestions.

[0004] However, this post-processing static analysis toolchain integration scheme has significant drawbacks. Its detection process occurs after code generation, disrupting the continuity of the development workflow, failing to meet real-time requirements, and causing feedback delays. More importantly, the rule base relied upon by static application security testing tools is primarily geared towards traditional manually written code models, making it difficult to effectively cover the unique, novel, or complex vulnerability patterns specific to large-scale model-generated code. Rule updates lag behind the evolution of new vulnerabilities and large-scale model capabilities, resulting in high false negative and false positive rates. Furthermore, its understanding of deep code semantics, data flow, and control flow is limited, especially when facing non-classical code structures that large models may generate. The provided remediation suggestions are often too general and coarse-grained, lacking a precise understanding of specific generation contexts, making reliable self-healing difficult. In addition, this scheme is a one-way process, lacking a closed-loop feedback mechanism; the detection results cannot be used to optimize the generation strategy of large-scale models, failing to continuously improve the security of generated code from the root. Summary of the Invention

[0005] This application provides an automated code generation and optimization method and system based on large models to solve the problems of non-real-time performance, poor rule base adaptability, coarse-grained repair suggestions, and lack of closed-loop feedback optimization mechanism in the code generation scenario of large models by post-static analysis tools in the prior art.

[0006] Firstly, this application provides an automated code generation and optimization method based on a large model, including: Receive functional requirement description, parse the functional requirement description through a large model to generate an initial logical framework, and perform symbolic transformation processing on the initial logical framework to form a symbolic structure; Based on the symbolic structure, a code intermediate representation is generated that preserves the semantics of variable operations, execution path boundaries, and resource access patterns, and the source code is generated by transforming the code intermediate representation. Vulnerability feature vectors are extracted from the vulnerability knowledge graph, a vulnerability knowledge set with weighted index is constructed, and the instruction sequence of the source code is scanned using parallel computing resources. By calculating the semantic similarity between the instruction sequence and the vulnerability feature vectors in the vulnerability knowledge set and matching the path pattern, the location of the target instruction with security risks and the corresponding vulnerability type code and risk level are marked. Based on the vulnerability type encoding and risk level, a historical remediation case library is retrieved. A matching relationship between vulnerability patterns and remediation strategies is established based on the retrieval results. Based on the matching relationship, an optimization strategy set containing remediation operation sequences and constraints is generated. A contextual semantic analysis model is loaded at the target instruction location to parse the data dependencies and control flow relationships between instructions. Combined with the set of optimization strategies, a difference graph between normal execution mode and risky execution mode is constructed to generate semantic features. Based on the semantic features, vulnerability samples with adversarial perturbation factors are constructed to adjust the parameters of the large model and to re-examine the vulnerability in the fine-tuned source code.

[0007] Optionally, the step of constructing vulnerability samples with adversarial perturbation factors based on the semantic features, adjusting the parameters of the large model through the vulnerability samples, and performing vulnerability re-checking on the generated source code after fine-tuning includes: A numerical offset is generated based on the variable difference features in the semantic features, and a path modification point is generated based on the path difference features in the semantic features. The numerical offset and the path modification point are combined to form a perturbation factor. The perturbation factor is injected at the corresponding position in the source code instruction sequence to generate a vulnerability sample containing the original instruction sequence and the modified instruction sequence; The vulnerability sample is input into the large model. The parameters of the large model are adjusted according to the difference between the modified instruction sequence and the original instruction sequence. The large model with adjusted parameters is used to generate a new version of the source code, and the vulnerability is re-checked on the new version of the source code.

[0008] Optionally, the step of inputting the vulnerability sample into a large model, adjusting the parameters of the large model based on the differences between the modified instruction sequence and the original instruction sequence, generating a new version of source code using the parameter-adjusted large model, and performing vulnerability re-checking on the new version of source code includes: The vulnerability sample is input into a large model, and the execution behavior of the modified instruction sequence is compared with that of the original instruction sequence. The behavior change value and the result difference value are extracted. Based on the behavioral change value and the result difference value, a difference degree value is generated, a reverse update operation is performed to adjust the weight of the large model, and a new version of the source code is generated from the adjusted large model. The new version of the source code is subjected to vulnerability re-examination, and the re-examination results are fed back to the vulnerability knowledge graph for continuous feature vector updates, forming a continuously evolving code security generation capability.

[0009] Optionally, the step of loading a contextual semantic analysis model at the target instruction location, parsing data dependencies and control flow relationships between instructions, and constructing a difference graph between normal execution mode and risky execution mode based on the optimization strategy set to generate semantic features includes: At the target instruction location, a context semantic analysis model is loaded to analyze the instruction sequence, and the data dependencies and control flow relationships containing variable generation locations, variable usage locations, and variable propagation paths in the instruction sequence are parsed; Based on the data dependencies and control flow relationships, a normal execution mode containing variable change sequences and control flow order is constructed. Simultaneously, combined with the optimization strategy set, a risky execution mode containing abnormal variable sequences and abnormal control flow paths when vulnerabilities are triggered is simulated and generated. The normal execution mode and the risky execution mode are compared to identify the variable difference locations and control flow difference locations to construct a difference map. Semantic features containing variable difference characteristics and path difference characteristics are extracted from the difference map.

[0010] Optionally, the step of extracting vulnerability feature vectors from the vulnerability knowledge graph, constructing a vulnerability knowledge set with weighted indexes, scanning the instruction sequence of the source code using parallel computing resources, and marking the location of target instructions with security risks and their corresponding vulnerability type codes and risk levels through semantic similarity calculation and path pattern matching between the instruction sequence and the vulnerability feature vectors in the vulnerability knowledge set, includes: Vulnerability records are extracted from the vulnerability knowledge graph and converted into vulnerability feature vectors. Weight values ​​are assigned to each vulnerability feature vector to construct a vulnerability knowledge set with weight index. The source code instruction sequence is divided into multiple instruction segments using parallel computing resources, instruction features are formed for each instruction segment, and the instruction features are converted into numerical features. Calculate the semantic similarity between the numerical features corresponding to different instruction segments in the instruction sequence and the semantic similarity between each vulnerability feature vector in the vulnerability knowledge set, and simultaneously detect the path pattern matching degree between the operation symbol sequence of different instruction segments in the instruction sequence and the vulnerability feature vector. When the semantic similarity value exceeds the corresponding weight value and the path pattern matching degree reaches the set threshold, the position of the instruction segment is marked as the target position, and the vulnerability type code and risk level corresponding to the target position are extracted.

[0011] Optionally, the step of retrieving historical remediation case databases based on the vulnerability type encoding and risk level, establishing a matching relationship between vulnerability patterns and remediation strategies based on the retrieval results, and generating an optimization strategy set containing remediation operation sequences and constraints based on the matching relationship includes: Based on the vulnerability type code and risk level, the historical remediation case library is retrieved to obtain vulnerability remediation cases containing vulnerability patterns and remediation strategies, so as to establish a correspondence between the vulnerability patterns and remediation strategies to form a matching relationship. Based on the matching relationship, the repair strategy is parsed, and the sequence of operation actions consisting of multiple operation actions and objects in the order of execution, along with the constraints containing the execution triggering conditions and resource consumption limits, is extracted to generate an optimization strategy set containing the operation action sequence and the constraints.

[0012] Optionally, the step of generating an intermediate code representation based on the symbolic structure, preserving variable operation semantics, execution path boundaries, and resource access patterns, and then generating source code through the intermediate code representation, includes: Based on the symbolic structure, the meaning of the operation of the retained variables containing the object identifier, action type and result identifier is extracted, including the execution path boundary containing the path start position and the path end position, and the resource access method containing the resource type identifier and access action type. Based on the meaning of the reserved variable operations, the execution path boundaries, and the resource access methods, an intermediate code representation is constructed. Traverse the code intermediate representation, convert the meaning of the reserved variable operation into variable assignment statements, and convert the resource access method into resource call statements; Based on the location information of the execution path boundary, flow control statements are added to the variable assignment statement and the resource call statement to form the final source code.

[0013] Secondly, this application provides an automated code generation and optimization system based on a large model, including: The parsing module is used to receive the functional requirement description, parse the functional requirement description through the large model to generate an initial logical framework, and perform symbolic transformation processing on the initial logical framework to form a symbolic structure; The conversion module is used to generate an intermediate code representation based on the symbolic structure, which retains the semantics of variable operations, execution path boundaries, and resource access patterns, and then converts the intermediate code representation to generate source code. The tagging module is used to extract vulnerability feature vectors from the vulnerability knowledge graph, construct a vulnerability knowledge set with weighted indexes, scan the instruction sequence of the source code using parallel computing resources, and mark the target instruction locations with security risks and their corresponding vulnerability type codes and risk levels by calculating the semantic similarity between the instruction sequence and the vulnerability feature vectors in the vulnerability knowledge set and matching the path patterns. The matching module is used to retrieve historical remediation case libraries based on the vulnerability type encoding and risk level, establish a matching relationship between vulnerability patterns and remediation strategies based on the retrieval results, and generate an optimization strategy set containing remediation operation sequences and constraints based on the matching relationship. The generation module is used to load a context semantic analysis model at the target instruction location, parse the data dependencies and control flow relationships between instructions, and combine the set of optimization strategies to construct a difference map between normal execution mode and risky execution mode to generate semantic features; The tuning module is used to construct vulnerability samples with adversarial perturbation factors based on the semantic features, so as to adjust the parameters of the large model through the vulnerability samples, and to perform vulnerability re-examination on the source code generated after fine-tuning.

[0014] Thirdly, this application provides a computing device, including a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement an automated code generation and optimization method based on a large model as described in the first aspect above.

[0015] Fourthly, this application provides a computer storage medium storing a computer program, which, when executed by a computer, implements an automated code generation and optimization method based on a large model as described in the first aspect.

[0016] In this application example, a functional requirement description is received, and an initial logical framework is generated by parsing the functional requirement description through a large model. The initial logical framework is then subjected to symbolic transformation to form a symbolic structure. Based on the symbolic structure, an intermediate code representation is generated that retains variable operation semantics, execution path boundaries, and resource access patterns. This intermediate code representation is then used to generate source code. Vulnerability feature vectors are extracted from a vulnerability knowledge graph, and a vulnerability knowledge set with weighted indexes is constructed. Parallel computing resources are used to scan the instruction sequences of the source code. By calculating the semantic similarity between the instruction sequences and the vulnerability feature vectors in the vulnerability knowledge set, and matching the path patterns, the locations of target instructions with security risks are marked. The system retrieves the corresponding vulnerability type codes and risk levels; it then searches a historical remediation case library based on the vulnerability type codes and risk levels, establishes a matching relationship between vulnerability patterns and remediation strategies based on the search results, and generates an optimization strategy set containing remediation operation sequences and constraints based on the matching relationship; it loads a contextual semantic analysis model at the target instruction location to parse the data dependencies and control flow relationships between instructions, and constructs a difference map between normal execution mode and risky execution mode based on the optimization strategy set to generate semantic features; it constructs vulnerability samples with adversarial perturbation factors based on the semantic features, adjusts the parameters of the large model through the vulnerability samples, and performs vulnerability re-examination on the source code generated after fine-tuning.

[0017] The technical solution of this application has the following beneficial effects: This application generates an initial logical framework by parsing functional requirements using a large model and symbolizing it to form an intermediate representation that retains the semantics of key programs before outputting the source code. Utilizing a weighted, indexed vulnerability knowledge graph and parallel computing resources, it scans the source code instruction sequences for semantic similarity and path pattern matching, accurately marking vulnerability locations, types, and risk levels. Based on a historical remediation case library, it establishes a mapping relationship between vulnerability patterns and remediation strategies, generating optimization strategies containing specific operation sequences and constraints. A contextual semantic analysis model is loaded at the vulnerability location, and a difference graph between normal and risky execution is constructed by parsing data dependencies and control flow, generating samples of adversarial disturbance factors. Finally, these samples are used to dynamically adjust the parameters of the large model, achieving a self-remediation loop for vulnerabilities and completing post-remediation verification. This achieves a closed-loop security enhancement effect throughout the entire code generation process, including detecting security vulnerabilities, intelligently generating accurate remediation solutions, dynamically optimizing model parameters, and ensuring the effectiveness of the remediation.

[0018] Further, numerical offsets are generated based on variable differences in semantic features, and path modification points are generated based on path differences. These two are combined to form a perturbation factor. This perturbation factor is injected into the corresponding position of the source code instruction sequence to construct a comparative vulnerability sample containing the original instruction sequence and the modified instruction sequence. This sample is input into a large model, and the parameters of the large model are adjusted by analyzing the differences between the modified instruction sequence and the original instruction sequence. Subsequently, the fine-tuned large model is used to generate a new version of the source code and perform vulnerability re-checking. This achieves the accurate construction of adversarial perturbation samples based on semantic features, simulates vulnerability triggering conditions by injecting specific numerical offsets and path modification points, and fine-tunes the parameters of the large model by comparing the differences between the instruction sequences before and after modification. This specifically enhances the model's ability to recognize and avoid specific vulnerability patterns. Finally, after generating new code, the re-checking closed-loop verification of the repair effect effectively improves the security of the model-generated code.

[0019] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

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

[0021] Figure 1 A flowchart of an automated code generation and optimization method based on a large model provided in this application is shown; Figure 2 The illustration shows a scenario diagram of an automated code generation and optimization method based on a large model provided in this application; Figure 3 A schematic diagram of the structure of an automated code generation and optimization system based on a large model provided in this application is shown; Figure 4 A schematic diagram of the structure of a computing device provided in this application is shown. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0023] In some of the processes described in the specification, claims, and accompanying drawings of this application, multiple operations appearing in a specific order are included. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not themselves represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first," "second," etc., in this document are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0024] Research indicates that using static application security testing tools as a post-generation detection step in large-scale model code has significant limitations. Detection occurs after code generation, resulting in a disjointed process that fails to meet requirements. The predefined rule base it relies on is primarily geared towards traditional manual coding, making it difficult to cover the complex vulnerability patterns unique to large-scale model-generated code, leading to poor rule adaptability and high false positive / false negative rates. Furthermore, the tool has limited deep semantic understanding of the code, providing overly general and coarse-grained remediation suggestions that are insufficient for precise self-repair. Most importantly, this approach is a one-way process; detection results cannot be fed back to optimize the large-scale model itself, lacking a closed-loop evolution mechanism and failing to continuously improve the security of the generated code.

[0025] To address the aforementioned issues, this application proposes an automated code generation and optimization method based on a large model, constructing a closed-loop system with deeply coupled security intelligence. This method generates an initial framework by parsing requirements using a large model and performs symbolic processing to form an intermediate representation that retains key semantics before outputting the source code. Utilizing a weighted, indexed vulnerability knowledge graph and parallel computing, semantic similarity and path pattern matching are used to scan the source code instructions, achieving accurate vulnerability location and classification. Based on a historical case library retrieved from vulnerability information, refined remediation strategies containing specific operation sequences are generated. A semantic analysis model is loaded at risk locations to parse dependencies and construct an execution pattern difference graph. Finally, adversarial examples are constructed based on the features of this graph to dynamically fine-tune the parameters of the large model, and the newly generated code is subjected to vulnerability re-checking. This scheme overcomes insufficient understanding by preserving deep semantics through symbolic processing, solves rule rigidity through semantic path dual matching, achieves accurate remediation through refined strategies, and innovatively establishes a closed-loop channel for feedback of detection results to optimize model parameters. This not only enables vulnerability detection and precise remediation, but also continuously reduces the vulnerability rate from the source of generation, completely solving the core defects of existing solutions such as non-real-time nature, poor rule adaptability, coarse-grained remediation, and lack of closed-loop evolution.

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

[0027] Figure 1 A flowchart of an automated code generation and optimization method based on a large model is provided in this application embodiment, such as... Figure 1 As shown, the method includes: 101. Receive the functional requirement description, parse the functional requirement description through the large model to generate an initial logical framework, and perform symbolic transformation processing on the initial logical framework to form a symbolic structure; In the above scheme, the functional requirements description refers to the software functional goals proposed by the user and expressed in natural language. It includes the intent description of the operations to be implemented and business rule constraints, serving as the raw input to drive the code generation process. The initial logical framework is a semi-structured logical expression generated after the large language model parses the functional requirements. It includes the topological relationships of condition judgment nodes, loop control nodes, and operation action nodes, forming an abstract blueprint for code implementation. The symbolic structure is a machine-computable logical representation formed through conversion processing. It consists of condition judgment expressions constructed from mathematical symbols, program variables mapped by unified identifiers, and encoded execution path sequences, providing unambiguous standardized input for subsequent code generation.

[0028] In this embodiment, the functional requirement description is first parsed using natural language processing (NLP) technology. The attention mechanism of a pre-trained large model is then used to identify key operational entities such as input data, output data, and loop conditions to generate an initial logical framework. For example, given the input "If the user's age is less than 18, payment is prohibited," the model identifies "age" as the judgment variable, "18" as the threshold, and "prohibit payment" as the action, generating an initial logical framework containing the condition node age<18 and the action node block_payment. Next, a symbolic transformation is performed on this framework: natural language variables are replaced with unified symbols using abstract syntax tree rules, logical operators are converted into mathematical symbols, and a unique path code is assigned to each execution path. Finally, a machine-computable symbolic structure is output. For example, "user age" is replaced with $AGE, "less than" is replaced with <, and a unique path code of the form P001 is assigned to each execution path, ultimately outputting a symbolic structure. .

[0029] In a practical application, a development team submitted a requirement: "Secondary verification is required when a user's daily transaction amount exceeds 5000 yuan." The large model identified the core condition as needing to trigger verification when the transaction amount > 5000 yuan, and generated the following logic framework: The symbolization conversion maps the "transaction amount" to the symbol $TX_AMT, while numerical constants are preserved as numbers, generating a symbolic structure: .

[0030] The aforementioned overall solution (101) transforms functional requirements described in natural language into a structured initial logical framework through a large model, and further performs symbolic transformation processing. This process eliminates semantic ambiguity and expression ambiguity in the original requirement description, generating a machine-resolvable structure composed of mathematical symbolic expressions, unified identifier variables, and coded execution paths. This symbolic structure provides a precise and unambiguous foundation for standardized logical expression, ensuring that subsequent code generation stages can accurately understand and implement user intent, and establishing a computable and traceable logical framework foundation for the vulnerability detection and analysis phase.

[0031] 102. Generate an intermediate code representation based on the symbolic structure, which preserves the semantics of variable operations, execution path boundaries, and resource access patterns, and then generate source code through the intermediate code representation. Optionally, step 102 may specifically include the following steps: 1021. Based on the symbolic structure, extract the meaning of the operation of the retained variables containing the object identifier, action type and result identifier, the execution path boundary containing the path start position and the path end position, and the resource access method containing the resource type identifier and access action type. 1022. Based on the meaning of the reserved variable operations, the execution path boundaries, and the resource access methods, construct an intermediate code representation; 1023. Traverse the intermediate representation of the code, convert the meaning of the reserved variable operation into variable assignment statements, and convert the resource access method into resource call statements; 1024. Based on the location information of the execution path boundary, add flow control statements to the variable assignment statement and the resource call statement to form the final source code.

[0032] In the above scheme, the semantics of reserved variable operations refer to the logical description of the operations performed on data entities in the program. This includes the unique identifier of the object being acted upon, the type of action applied, and the relationship between the operation result and the target. It can be used to ensure that the generated code accurately conveys the data processing intent in the original requirements. Execution path boundaries refer to the definition of the start and end range of logical branches in the program control flow. This includes the location markers of the path's start and end positions. It can be used to accurately construct flow control structures such as branches and loops during code generation. Resource access patterns refer to the operational specifications for program interaction with external systems. This includes the type identifier of the accessed resource and the type of access action. It can be used to map abstract resource operations to specific system call statements. Intermediate code representation refers to a transitional program expression form between symbolic logic and final code. It can be used to establish a reliable bridge from requirement logic to executable code. Source code refers to program text that can be directly compiled or interpreted and executed. It can be used to implement the functional behaviors described in the requirement within the target environment.

[0033] In this embodiment, in step 1021, the system performs a deep scan and analysis of the input symbolic structure using a semantic parsing engine. First, it identifies and extracts the semantics of retained variable operations describing data changes in the program. Specifically, this includes the identifier of the object being operated on, the type of action applied to that object, and the result identifier indicating the operation's outcome. This information is then combined into structured triplet data. Next, the engine locates key nodes in the program control flow and determines the execution path boundaries, i.e., capturing the starting and ending points of logical branches to form coordinate information identifying the path range. Finally, the engine parses the program's interaction with external systems, extracting resource access patterns, i.e., identifying the type of resource being accessed and the type of access action performed on that resource, generating resource operation methods. For example, when processing the symbolic structure of an "order payment" function, this step will extract variable operation triples. Mark the cycle boundary as And identify the resource access method This allows for the complete capture of the core behavioral elements of the functional block.

[0034] Next, in step 1022, the semantic elements extracted in step 1021 are integrated and structurally expressed using a structured assembler. This encapsulates the triplet information, which preserves the semantics of variable operations, into independent nodes with clearly defined attributes, for example, generating nodes of the form... The nodes precisely describe the data operation logic; corresponding path container nodes are created using the start and end position information of the execution path boundaries, for example... This node acts as a logical wrapper layer, accommodating other nodes within its scope; subsequently, the combination of resource access method elements is mapped to standardized resource access template nodes, such as... Finally, based on the context of the program logic, the system embeds the previously generated variable operation nodes and resource access template nodes into the corresponding path container nodes in an orderly manner, and establishes the necessary reference associations, thereby constructing a hierarchical tree-structured intermediate code representation that fully preserves the original semantics. For example, when processing the logic for calculating logistics transportation costs, this step will construct a container node containing path start and end markers, which embeds a description... variable manipulation nodes and an external call API resource access node.

[0035] Then, step 1023 uses a syntax converter to perform a depth-first traversal of the intermediate code representation generated in step 1022, processing each node sequentially to generate executable basic code statements. When encountering a variable operation node, the converter precisely maps it to the corresponding variable operation statement based on the action type and object identifier recorded in the node, combined with the syntax rules of the target programming language; for example, an action type of "decrease" and an object of... The node will be converted in Python. This is a subtraction assignment statement. Then, when iterating through resource access nodes, the converter automatically matches a preset code template library based on the resource type identifier and access action type defined in the node, generating standard resource operation statements that conform to the target environment's calls; for example, for a node with a resource type of "database" and an action of "insert," it will generate something like... The SQL execution statement. During the entire traversal, the path container node temporarily retains its structure, but the child nodes inside are recursively transformed. This ensures that the final output is a discrete basic code snippet that retains the original operation semantics but has been converted into the target language syntax, preparing for the flow control integration of subsequent steps; for example, a variable operation node for "patient count increase" in a medical system. It will be directly converted And a "send email" resource node Then generate The calling statement.

[0036] Finally, in step 1024, the basic code statements generated in step 1023 are structurally reorganized using the control flow integration engine. The execution path boundary information marked in the intermediate code representation is parsed to determine the logical control block scope to which these basic statements belong and their physical location range in the source code. Based on the contextual characteristics of the path boundaries, the required flow control statement type is automatically determined; for example, a for or while loop is selected when the start and end points mark a repetitive execution region, and an if or else loop is selected when a conditional branch is marked. Then, the engine inserts the corresponding control structure start statement at the path start point and embeds all variable assignment statements and resource call statements generated in step 1023 associated with the path into the control structure in logical order, while automatically adding necessary indentation levels according to programming language specifications to reflect the hierarchical relationship. Finally, at the path end point, the engine intelligently adds the closing marker of the control structure, ensuring that the generated code block syntax is complete and the execution logic is strictly consistent with the original symbolic structure, thus forming a fully functional final source code. For example, in a financial approval scenario, when a conditional decision block corresponding to the path boundary (L5, L10) is detected, and the block contains variable assignment and database save operations, the system will insert a new line at line 5. Lines 6-7 contain indented assignment and save statements, and the conditional block ends on line 10, outputting the complete and runnable code segment.

[0037] In practical applications, when a warehouse management system receives a requirement to "shut down the equipment and log when the temperature exceeds the threshold," after generating a symbolic structure through large-scale model parsing, it first extracts the key semantics, and the variable operation semantics are... The execution path boundary is from the start line L15 of the if condition block to the end line L21. The resource access mode is device control interface shutdown and log database insertion. Then, an intermediate representation is constructed: creation. Container nodes, with embedded variable manipulation nodes and two resource nodes , Next, transform the basic statements: traversing the middle indicates converting variable operations into... Transform equipment control into Convert database access to Finally, integrate the process control: insert on line L15. The three transformed statements are indented and embedded within the conditional block, and the logic is closed on line L21 to generate the final source code.

[0038] The overall solution described above (102) fully preserves the core behavioral semantics of the program through the conversion from symbolic structure to intermediate representation. When generating the final code, it ensures that variable operation logic is not lost, execution path boundaries are clear and traceable, and resource access patterns are accurately mapped to actual calls. This process avoids the semantic deviation problems commonly encountered when directly generating code from large models, significantly improving the functional correctness and maintainability of the generated code.

[0039] 103. Extract vulnerability feature vectors from the vulnerability knowledge graph, construct a vulnerability knowledge set with weighted index, scan the instruction sequence of the source code using parallel computing resources, and mark the location of target instructions with security risks and the corresponding vulnerability type code and risk level by calculating the semantic similarity between the instruction sequence and the vulnerability feature vectors in the vulnerability knowledge set and matching the path pattern. Optionally, step 103 may specifically include the following steps: 1031. Extract vulnerability records from the vulnerability knowledge graph and convert them into vulnerability feature vectors, and assign weight values ​​to each vulnerability feature vector to construct a vulnerability knowledge set with weight index; 1032. Using parallel computing resources, the instruction sequence of the source code is divided into multiple instruction segments, instruction features are formed for each instruction segment, and the instruction features are converted into numerical features; 1033. Calculate the semantic similarity between the numerical features corresponding to different instruction segments in the instruction sequence and the semantic similarity between each vulnerability feature vector in the vulnerability knowledge set, and at the same time detect the path pattern matching degree between the operation symbol sequence of different instruction segments in the instruction sequence and the vulnerability feature vector; 1034. When the semantic similarity value exceeds the corresponding weight value and the path pattern matching degree reaches the set threshold, mark the position of the instruction segment as the target position, and extract the vulnerability type code and risk level corresponding to the target position.

[0040] In the above scheme, the vulnerability feature vector refers to the mathematical expression representing the core attributes of a vulnerability, containing a multi-dimensional numerical combination of key features such as vulnerability triggering conditions and severity, which can be used to quantify the semantic similarity matching of vulnerabilities. The weight value refers to the influencing factor reflecting the priority of vulnerability matching, which can be used to dynamically adjust the sensitivity threshold of vulnerability matching. The instruction segment refers to the continuous operation unit of the source code execution logic, which can be used for parallel vulnerability scanning. Numerical features refer to quantitative indicators reflecting the behavioral patterns of instruction segments, which can be used for vectorized computation in machine learning. Semantic similarity refers to the measure of the correlation strength between instruction behavior and vulnerability features, which can be used to identify the semantic relevance of potential vulnerabilities. Path pattern matching degree refers to the degree of conformity between the instruction operation sequence and the vulnerability execution path, which can be used to verify the logical necessity of vulnerability triggering. The set threshold is the baseline for determining the existence of a vulnerability, which can be used to filter out low-confidence false positives. The target location refers to the identifier of the code location confirmed to be at risk, which can be used to accurately locate the anchor point for remediation operations.

[0041] In this embodiment, firstly, specific vulnerability records are extracted from a pre-built vulnerability knowledge graph in step 1031. These records contain textual descriptions of the vulnerabilities. Next, natural language processing (NLP) techniques are used to parse these textual descriptions, identify key semantic features, and transform these features into a fixed-dimensional numerical array to form a vulnerability feature vector. Then, a weight value is calculated for each generated vulnerability feature vector. This weight combines the vulnerability's general risk level using a standard CVSS score with the frequency of the vulnerability's occurrence in a specific enterprise or domain's historical vulnerability database, using a predefined weighting formula: Calculations are performed, for example, a vulnerability with a CVSS score of 8.5 and an occurrence frequency of 0.9, Finally, all processed vulnerability feature vectors are combined with their corresponding weight values ​​to construct a structured, indexed vulnerability knowledge set in key-value pair form. ,For example This provides a benchmark library for subsequent vulnerability scanning that can be quickly retrieved and matched.

[0042] Next, in step 1032, the complete instruction sequence generated by compiling the source code is divided into multiple instruction segments of fixed length using a distributed parallel computing framework. Then, multi-dimensional behavioral features are extracted from each instruction segment: operator frequency is statistically analyzed (i.e., the proportion of high-risk instructions such as CALL in the segment), data flow complexity is analyzed (i.e., the maximum depth of cross-instruction variable propagation paths), and resource access density is recorded (i.e., the number of times sensitive operations such as file read / write or network communication are triggered). Then, using Min-Max normalization, the original values ​​of these three types of features are linearly mapped to the [0,1] interval, ultimately generating a standardized three-dimensional numerical feature vector, providing a quantifiable behavioral description model for subsequent vulnerability matching. For example, in the payment verification module of logistics system B, a certain instruction segment containing 15 CALL instructions, a data flow depth of 7, and 12 file operations is transformed into a vector [0.3, 0.7, 0.24] through this process.

[0043] Then, in step 1033, for each instruction segment numerical feature vector generated in step 1032, semantic similarity is calculated between it and all vulnerability feature vectors in the vulnerability knowledge set constructed in step 1031. A cosine similarity algorithm is used; specifically, the calculation process involves multiplying and summing the values ​​of each dimension of the two vectors, then calculating the square root of the sum of the squares of the magnitudes of each vector. The final similarity value is the sum of the products divided by the product of the magnitudes. For example, the instruction segment vector of the payment module in logistics system B is... The buffer overflow vulnerability vector is The sum of their products is The square root of the modulus is respectively and The calculated similarity value is Simultaneously perform path pattern matching: extract the original operator sequence of the instruction segment, such as... , and the standard path to vulnerabilities, such as The longest common subsequence is calculated using a dynamic programming algorithm, and then calculated according to the formula: Calculate the matching degree, for example, the common sequence is With a length of 2, the calculated matching degree is 0.67. In this stage, all instruction segments and vulnerability vectors are matched simultaneously through parallel computing. The semantic similarity value and path matching degree value corresponding to each instruction segment are output. For example, the output for the segment of logistics system B is [similarity 0.98, matching degree 0.67], providing two-dimensional evidence for vulnerability determination.

[0044] Finally, after obtaining the semantic similarity value and path pattern matching degree of the instruction segment in step 1034, the system performs vulnerability determination: the instruction segment is determined to have a security risk if and only if the semantic similarity value of the instruction segment is greater than the weight value of the vulnerability in the knowledge set and the path matching degree exceeds a preset threshold. Subsequently, the system automatically extracts the line number range of the instruction segment in the source code as the target location, and retrieves the associated vulnerability attribute information from the vulnerability knowledge base, including the standard vulnerability type code and risk level label, and finally generates a structured tagging result containing location information, vulnerability type, and risk level. For example, an instruction segment of medical system D has a similarity of 0.95 and a path matching degree of 0.67 with "command injection vulnerability". The similarity exceeds the weight value of 0.93 and the matching degree exceeds the threshold of 0.6, so it is determined to have a risk. The system then extracts the line number range of the instruction (lines 305-355), the vulnerability type code CWE-78, and the risk level label "severe", and outputs... This provides precise target location and classification basis for subsequent repairs.

[0045] In practical applications, during the complete vulnerability detection of an access control module, the process begins by extracting records of missing permission verification vulnerabilities from a vulnerability knowledge graph. A natural language processing model is then used to transform the textual feature descriptions of these vulnerabilities into three-dimensional numerical vectors of 0.4, 0.6, and 0.2. Based on the vulnerability's general risk score of 8.0, converted to a 10-point scale, and combined with its historical frequency of 0.85, a weighted formula is used to calculate the weight: the risk coefficient of 0.7 multiplied by 0.8 yields 0.56, and the frequency coefficient of 0.3 multiplied by 0.85 yields 0.255. These are summed to obtain a final weight of 0.815, forming a weighted vulnerability feature entry. Next, the 1500 compiled instruction sequences are processed, and a parallel computing framework is used to equally divide them into 30 instruction segments, each containing 50 instructions. Feature extraction was performed on the fifth instruction segment: 18 function call instructions were counted, and normalized to the preset maximum value of 50, resulting in 18 divided by 50 equaling 0.36; the data stream depth was measured to be 12 levels, and normalized to the maximum value of 20, resulting in 12 divided by 20 equaling 0.6; 8 permission operation instructions were recorded, and normalized to the maximum value of 15, resulting in 8 divided by 15 approximately equaling 0.533. Finally, the instruction segment feature vectors were generated as 0.36, 0.6, and 0.533. Then, a double matching is performed: the semantic similarity between the instruction segment vector and the vulnerability vectors 0.4, 0.6, and 0.2 is calculated. First, the sum of the products of each dimension is calculated: 0.36 multiplied by 0.4 equals 0.144, 0.6 multiplied by 0.6 equals 0.36, and 0.533 multiplied by 0.2 equals 0.1066, with a total sum of 0.6106. Then, the product of the magnitudes of the two vectors is calculated: the square root of the sum of the squares of 0.36, 0.6, and 0.533 is approximately 0.786, and the square root of the sum of the squares of 0.4, 0.6, and 0.2 is approximately 0.748, with a product of approximately 0.588. Finally, the similarity of 0.6106 divided by 0.588 is approximately 1.038, with an actual upper limit of 1.0. Simultaneously, path matching is performed: extracting the operator sequence of the instruction segment for verification and modification, comparing it with the standard path of the vulnerability for verification and detection, and calculating the longest common subsequence for verification, totaling two steps. The matching degree 2 divided by 3 is approximately equal to 0.667. Final judgment stage: when the semantic similarity (1.0) is greater than the vulnerability weight (0.815) and the path matching degree (0.667) exceeds the preset threshold (0.6), the instruction segment is confirmed to have a vulnerability. The system automatically locates its corresponding source code line numbers 210 to 260, associates it with the vulnerability type code CWE-862 and the risk level "high risk," and generates structured detection results.

[0046] The aforementioned 103 overall solution achieves millisecond-level scanning of source code by constructing a vulnerability feature library with dynamic weights and combining instruction segmentation and parallel computing technologies. Utilizing a dual matching mechanism of semantic similarity and path patterns, it accurately identifies the location and type of potential vulnerabilities, significantly reducing the false positive rate. Simultaneously, it outputs standardized vulnerability codes, risk levels, and line number locations, providing a clear basis for remediation. Its closed-loop design ensures that detection results can directly drive subsequent remediation processes, comprehensively improving the security assurance efficiency of code generated from large models.

[0047] 104. Based on the vulnerability type encoding and risk level, retrieve the historical remediation case library, establish a matching relationship between vulnerability patterns and remediation strategies according to the retrieval results, and generate an optimization strategy set containing remediation operation sequences and constraints based on the matching relationship; Optionally, step 104 may specifically include the following steps: 1041. Based on the vulnerability type code and risk level, retrieve the historical remediation case library to obtain vulnerability remediation cases containing vulnerability patterns and remediation strategies, so as to establish a matching relationship between the vulnerability patterns and remediation strategies; 1042. Based on the matching relationship, parse the repair strategy, extract the sequence of operation actions consisting of multiple operation actions and objects in the order of execution, and the constraints containing the execution triggering conditions and resource consumption limits, so as to generate an optimization strategy set containing the sequence of operation actions and the constraints.

[0048] In the above scheme, the historical remediation case library refers to a structured database storing a large number of successfully remediated vulnerability instances from the past. It includes descriptions of the specific manifestations of the vulnerabilities, the remediation methods used, and records of their execution effects. This database can be used to provide proven and effective remediation references for similar vulnerabilities currently detected. A vulnerability pattern refers to a set of features describing the specific existence of a particular type of security vulnerability in program code. This can be used for pattern matching during code scanning to identify similar vulnerabilities. A remediation strategy is a general description of a solution designed and verified to be effective for a specific vulnerability pattern. This strategy can be used to guide the generation of specific code remediation operations. A matching relationship refers to the association mapping between vulnerability patterns and their corresponding effective remediation strategies established in the historical remediation case library. This can be used to automatically recommend suitable remediation strategies for currently detected vulnerabilities. A remediation operation sequence refers to a series of ordered code modification actions to be executed when implementing a specific vulnerability remediation. This can be used to guide developers or automation tools to complete the code remediation step by step. Constraints refer to the prerequisite rules or restrictions that must be strictly followed when executing the remediation operation sequence. These can be used to ensure the security and correctness of the remediation process and avoid introducing new problems or damaging existing functionality. An optimization strategy set refers to a collection of one or more feasible remediation solutions generated to address currently detected vulnerabilities, providing clear, secure, and actionable guidance for subsequent automated or manual remediation.

[0049] In this embodiment, step 1041 first uses the currently detected vulnerability type code and assessed risk level as search criteria to perform a matching query in the historical remediation case database. This involves finding historical successful cases that have patched the same or highly similar types of vulnerabilities with similar risk levels. It also identifies proven and effective remediation experiences. For example, if the system detects a "high-risk" SQL injection vulnerability in the current code, coded as SQLI-HIGH-001, it will search the case database for all historical cases that have patched the SQL injection vulnerability with a "high" risk level. From these matched cases, the specific vulnerability manifestation (vulnerability pattern) and the specific remediation method (remediation strategy) used at the time are extracted for each case. Finally, a matching relationship is established between the currently detected vulnerability characteristics and historically successful remediation strategies.

[0050] Secondly, based on the matching relationships established in step 1041, step 1042 performs in-depth analysis on each matched effective repair strategy. The system carefully analyzes these strategy texts or structured data to extract the core elements constituting the strategy: one is the repair operation sequence, that is, a series of specific code modification actions that need to be executed in a specific order and their target objects, such as "finding the position where the input variable is used" and "inserting before it". "Function call" and then " Function replacement The first is the "function"; the second is the constraint, which is the prerequisite or restriction that must be met when these operations are performed, such as "insertion". The call must be completed before any database operation; the replaced The system ensures that the function's parameters are correctly bound and that the total number of new lines of code added during the entire repair process does not exceed 5 lines. The system organizes and encapsulates these extracted operation sequences and constraints, ultimately generating an optimization strategy set containing one or more feasible repair solutions.

[0051] In a practical application, suppose the system detects a high-risk authentication bypass vulnerability, type-coded AUTH-BYPASS-HIGH-003, when generating code for a user profile management module for an online shopping website A. Based on this vulnerability type and risk level, the system searches the historical remediation case library. It might find three related cases: Case B fixed a similar bypass vulnerability by adding additional session token verification; Case C fixed another variant by strengthening the user permission detection logic; and Case D refactored the authentication process. The system analyzes the vulnerability patterns of these cases and finds that Case B's pattern best matches the current vulnerability. A matching relationship is established, and the current vulnerability pattern corresponds to Case B's remediation strategy. Next, the remediation strategy text of Case B is parsed. It extracts the operation sequence: 1. Locate the session object at the entry point of the user request processing function; 2. Insert the function call. 3. If If the operation fails, a 401 error response will be returned. The following constraints will also be extracted: a. The new validation must occur before any business logic is executed; b. Function calls must take less than 50 milliseconds; c. The internal structure of existing session objects must not be modified. Finally, the system generates a set of optimization strategies, containing a specific strategy item that details the above operation sequence and constraints for subsequent steps.

[0052] The aforementioned 104-point overall solution intelligently matches proven and effective remediation strategies by searching a historical remediation case library based on vulnerability type and risk level. It parses these strategies, generating an operational sequence containing specific, ordered code modification instructions and the rules that must be followed to execute these instructions, forming an optimized strategy set. This is equivalent to automatically generating a detailed "remediation description" and "security precautions checklist" for each detected vulnerability, transforming abstract remediation suggestions into precise guidelines that engineers can directly execute or that the system can automate. This significantly improves the remediation's relevance, operability, and security, avoiding blind modifications or the introduction of new problems.

[0053] 105. Load the context semantic analysis model at the target instruction location, parse the data dependency relationship and control flow relationship between instructions, and combine the optimization strategy set to construct a difference map between the normal execution mode and the risk execution mode to generate semantic features; Optionally, step 105 may specifically include the following steps: 1051. At the target instruction location, load the context semantic analysis model to analyze the instruction sequence, and parse the data dependency relationship and control flow relationship containing the variable generation location, variable usage location and variable transmission path in the instruction sequence; 1052. Based on the data dependency relationship and control flow relationship, construct a normal execution mode that includes variable change sequence and control flow order. At the same time, combine the optimization strategy set to simulate and generate a risky execution mode that includes abnormal variable sequence and abnormal control flow path when the vulnerability is triggered. 1053. Compare the normal execution mode and the risky execution mode to identify the variable difference position and the control flow difference position to construct a difference map, and extract semantic features containing variable difference features and path difference features from the difference map.

[0054] In the above scheme, the context semantic analysis model refers to an AI tool specifically designed to analyze program code logic. It tracks how variables are created, modified, and passed, and how the program determines its execution path based on conditional statements and loop control. Data dependency relationships refer to the dynamic links reflecting the transmission of variable values ​​in the instruction sequence, including the complete transmission path from the declaration location to the modification location and then to the usage location. This is used to identify unverified data flows leading to risky nodes. Control flow relationships describe the decision logic characteristics of the program's execution path, including the constraints of conditional statements and loop control points on the code execution order. This is used to locate abnormal branches where permission checks are missing or boundary detection fails. Normal execution mode refers to the standard operating state of the program that meets functional expectations, constituting the baseline behavior template for business logic. Risky execution mode refers to the abnormal operating state that simulates the triggering of vulnerabilities, used to compare the precise location of exposed security flaws. The difference map is a visual mapping that identifies the deviation features between the normal and risky modes, forming a spatial localization model of the core vulnerability behavior. Semantic features refer to the quantified vulnerability fingerprint extracted from the difference map, including variable difference features and path difference features, providing an actionable set of defect parameters for generating remediation strategies.

[0055] In this embodiment, firstly, in step 1051, at the identified target instruction location with security risks, the system loads a context semantic analysis model to perform a deep scan of the instruction sequence at that location. This model first uses program slicing technology to meticulously trace the complete lifecycle of each variable in the instruction sequence: clearly identifying the source location where the variable is initially created or assigned a value, the key node location where the variable's value is modified or calculated, and the destination location where the variable is ultimately passed or used, thus clearly depicting the complete transmission path of how variables flow and change in the code, forming a data dependency network. Simultaneously, the model applies a control flow graph construction algorithm to systematically scan and mark all key decision points affecting the program's execution direction, including logical condition judgment locations for branch selection and loop control locations controlling the number of loop executions, thereby outlining the possible execution path framework of the program.

[0056] Secondly, based on the detailed data dependencies and control flow relationships established in step 1051, the system first constructs a normal execution mode that conforms to the expected business logic. This mode accurately depicts the legal change sequence that variable values ​​should follow and the correct execution order that the control flow should follow under secure operation. Next, the system combines the set of optimization strategies retrieved from the historical remediation case library to reverse-simulate the abnormal scenarios when the vulnerability is triggered, thereby proactively constructing a risky execution mode. In this mode, the system intentionally violates security rules, generating abnormal variable sequences containing dangerous values ​​and abnormal control flow paths that deviate from the expected paths.

[0057] Finally, after constructing the normal execution mode and the risky execution mode in step 1053, the system initiates a deep comparative analysis of the two. Specifically, by comparing the variable change sequence line by line, the system identifies key locations where variable values ​​undergo abnormal mutations. For example, in the normal mode, a certain input variable should be safely filtered to a null value, but in the risky mode, this variable retains a malicious string. Simultaneously, by traversing the control flow path, the system marks key nodes that are illegally bypassed or missing in the risky mode. For example, the file type verification step, which is essential in the normal process, completely disappears in the risky process. Based on these identified variable value mutation points and control flow path breakpoints, the system automatically constructs a structured difference graph, which uses code location as nodes and difference type as edges for visual mapping. Finally, the system extracts semantic features with clear security significance from this difference graph. These features mainly include variable difference features and path difference features reflecting the core behavior of the vulnerability, providing directly actionable quantitative basis for subsequently generating accurate vulnerability remediation samples.

[0058] In practical applications, after the code section handling passwords in the social platform user registration module is identified as a security risk location, the system first loads a contextual semantic analysis model to scan this code segment. The model identifies that the password variable originates at the user input receiving point, and this variable is directly passed to the password storage function call point without any processing, forming a critical data dependency chain. Simultaneously, the model discovers a conditional check point in the code, used to check whether the password length meets the minimum requirement. Next, based on these dependencies and control flow relationships, the system constructs a normal execution mode: the password variable obtains a value at the input receiving point, for example, a valid password containing 11 characters. This value is then passed to the length check point. After calculation confirms that its length of 11 is greater than or equal to 8, the condition is met, and the password is then securely passed to the storage point for encryption and conversion before being saved. Simultaneously, the system, combining strategies for plaintext storage vulnerabilities from the historical remediation database, proactively simulates a risky execution mode: At the input receiving point, the password variable receives a short password value, such as an invalid password containing only 3 characters. This value bypasses security processing and is directly passed to the storage point for plaintext storage. Furthermore, the system deliberately tampers with the logic of the length detection point, changing its condition to require a password length greater than or equal to 100. Thus, when the system detects that the calculated length of the input password string is only 3 characters, the condition judgment result is false, causing the length detection step to be completely bypassed. Ultimately, the system compares the two modes: it finds the variable difference lies in the fact that in the risky mode, the password is directly stored at the storage point without encryption, while in the normal mode it is encrypted. The system records this variable difference as a missing encryption conversion feature. It also finds the control flow difference in the risky mode where the verification rules at the length detection point are maliciously modified, causing a short password of 3 characters that should have been blocked to be allowed to pass because the calculated result is less than 100. The system records this path difference as a failed password strength verification. Based on this, the system constructs a difference graph to locate the failed verification point and the unencrypted storage point as core risk nodes, and extracts the aforementioned semantic features for subsequent remediation.

[0059] The overall solution described above, through in-depth analysis of code logic dependencies, accurately constructs normal and risky dual-mode operating scenarios, intuitively exposing variable tampering points and control flow defects when vulnerabilities are triggered; based on semantic features extracted from the difference graph, it provides quantifiable vulnerability behavior fingerprints for subsequent generation of adversarial samples, significantly improving the targeting of remediation strategies, while avoiding misjudgments caused by traditional tools ignoring contextual relationships.

[0060] 106. Construct vulnerability samples with adversarial perturbation factors based on the semantic features, so as to adjust the parameters of the large model through the vulnerability samples, and perform vulnerability re-examination on the source code generated after fine-tuning.

[0061] Optionally, step 106 may specifically include the following steps: 1061. Generate a numerical offset based on the variable difference features in the semantic features, generate a path modification point based on the path difference features in the semantic features, and combine the numerical offset and the path modification point to form a perturbation factor. 1062. Inject the perturbation factor at the corresponding position in the source code instruction sequence to generate a vulnerability sample containing the original instruction sequence and the modified instruction sequence; 1063. Input the vulnerability sample into the large model, adjust the parameters of the large model according to the difference between the modified instruction sequence and the original instruction sequence, use the large model with adjusted parameters to generate a new version of source code, and perform vulnerability re-checking on the new version of source code.

[0062] Specifically, step 1063 may include the following process: inputting the vulnerability sample into a large model, comparing the execution behavior of the modified instruction sequence with that of the original instruction sequence, and extracting behavior change values ​​and result difference values; generating a degree of difference value based on the behavior change values ​​and result difference values, performing a reverse update operation to adjust the weights of the large model, and generating a new version of the source code through the adjusted large model; performing a vulnerability re-examination on the new version of the source code, and feeding the re-examination results back to the vulnerability knowledge graph for continuous feature vector updates, forming a continuously evolving code security generation capability.

[0063] In the above scheme, variable difference characteristics refer to dynamic data characteristics reflecting the differences in the numerical changes of key variables under safe and risky execution modes of the program, which can be used to identify the numerical boundary conditions for vulnerability triggering. Path difference characteristics refer to the topological structure characteristics reflecting the logical divergence between the normal control flow and the attack path of the program, which can be used to locate the process breakthrough point for vulnerability exploitation. Perturbation factors refer to composite instruction units composed of numerical offsets generated by variable difference characteristics and logical modification points generated by path difference characteristics, which can simulate vulnerability triggering conditions to construct adversarial samples. Behavioral change values ​​refer to the dynamic difference in runtime resource consumption between the code injected with perturbation factors and the original code, which can quantify the potential harm of the vulnerability. Result difference values ​​refer to the deviation of the output results of the perturbation code from the original code, which can verify the effectiveness of vulnerability remediation.

[0064] In this embodiment, firstly, step 1061 extracts key data reflecting the difference between secure and risky execution from semantic features: the numerical boundary offset pattern is parsed from the variable difference features, and a specific numerical offset is generated accordingly; simultaneously, control flow branch misalignment points are identified from the path difference features, and path modification points are generated accordingly. Secondly, the numerical offset and path modification points are logically combined to form a composite perturbation factor with vulnerability simulation capabilities. For example, for SQL injection vulnerabilities, when it is detected that user input does not filter single quotes and directly concatenates SQL statements, the offset "input length limit increased from 50 to 70" and the modification point "insert escape function before SQL concatenation" are generated, and finally combined into the perturbation factor "lengthen input and force escape".

[0065] Next, step 1062 locates the high-risk instruction positions marked in the source code, and then the perturbation factor generated in step 1061 is precisely injected into these positions: for the numerical offset portion, the key parameter values ​​in the original instruction are directly modified; for the path modification point portion, logical jumps or function call instructions are inserted before the target instruction. After injection, the system synchronously retains the original instruction sequence and stores the modified instruction sequence alongside it, thereby generating a comparative vulnerability sample containing two versions of code. For example, when the original code is... At that time, numerical offsets and path modification points are injected to limit the input length to 70 characters, escape functions are inserted, and then a comparison sample is generated: the original sequence is preserved. Modify the sequence to become The vulnerability repair logic is presented intuitively through the difference between the two sequences.

[0066] Finally, in step 1063, the comparison vulnerability sample generated in step 1062 is input into the large model to perform dynamic analysis of the dual-version code: The original and modified instruction sequences are monitored in parallel runtime to capture key behavioral differences. For example, if the memory usage is stable at 80MB during the original code execution and suddenly increases to 120MB after modification, the behavioral change value +40MB is recorded. Simultaneously, the output results are compared; for example, the original code returns a user data list, while the modified code returns a permission error message. The calculated difference is 90%. Based on these differences, the system calculates a comprehensive difference value according to preset weights. The calculation formula is as follows: When this value exceeds a set threshold, a reverse adjustment mechanism for the large model parameters is triggered. This mechanism quantifies the vulnerability's severity through the degree of difference, guiding the model to reduce the probability of generating similar risky code. The fine-tuned large model is then used to regenerate the source code, and a full-process vulnerability review is performed. Finally, the review results are fed back to the vulnerability knowledge graph, forming a continuously evolving code security generation capability. For example, after a financial system generates payment interface code, this process discovers a value verification vulnerability. After fine-tuning, the new code automatically adds negative number verification logic, and the review confirms the fix and updates the knowledge base.

[0067] In a practical application, when the order system of e-commerce platform A used this solution to generate payment amount verification code, an overflow vulnerability was detected in the amount processing function. The solution involves extracting variable difference features and threshold offsets. The numerical offset "reduces the threshold to 9,000 yuan" is generated, and the calculation process is as follows: Simultaneously, path difference features are extracted to generate path modification points "in". "Insert unconditional redirect to payment failure". Inject a perturbation factor into the amount verification line: the original instruction is... The modified command becomes Insert above Generate a comparison sample containing two sequences. Perform dynamic analysis: The original code allowed an order of 20,000 yuan; after modification, the code redirects to refuse payment. A 15MB reduction in memory usage was detected, and the output results were 100% inconsistent. Calculate the overall degree of difference based on weights. If the value exceeds a threshold of 50, model parameter adjustments are triggered to reduce the probability of generating unverified amount codes. After fine-tuning, the new code generated by the large model automatically adds double verification logic. The vulnerability was re-examined and confirmed to be fixed, and the feature "the threshold can be dynamically adjusted to 90% of the original value to block overflow" was fed back to the vulnerability knowledge graph.

[0068] The above-mentioned 106 overall solution guides the large model to understand the vulnerability triggering mechanism by accurately constructing adversarial samples; it quantifies the vulnerability's harm by utilizing the runtime differences between the code before and after modification, and adjusts the model parameters accordingly; the newly generated code not only fixes the original vulnerability in real time, but also continuously strengthens the knowledge graph through review feedback, forming a closed-loop evolution capability of "vulnerability discovery - model learning - security generation", thereby reducing the recurrence rate of similar vulnerabilities from the root.

[0069] The following is a complete example for steps 101-106, such as Figure 2 As shown, during the development of a payment system, the product manager submitted a requirement description: "Implement a payment verification function, which needs to verify that the account balance is sufficient, the single transaction amount does not exceed 10,000 yuan, and record the transaction log." The large model analyzes the requirements to generate the initial logic framework: The framework is then subjected to symbolic transformation: monetary variables are converted to symbols ranging from 0 to 10,000 ($AMT), and database operations are converted to symbols ($DB_INSERT), thus forming a symbolic structure. Based on this structure, an intermediate representation is generated: The amount variable `amount` is defined, retaining a semantic range of 0 to 10000. Execution path boundaries are set; if these limits are exceeded, an error is reported. The database resource access mode is declared as a write operation. Finally, the source code is converted: The function first checks if `amount > 10000` and returns an error, then queries the balance and compares it, and finally executes the operation. .

[0070] Extracting SQL injection feature vectors from vulnerability knowledge graphs Along with integer overflow vectors [boundary detection: single-point verification], parallel computing resources were used to scan the source code instruction sequences. The scan revealed that the database execution lines and SQL injection vectors had a semantic similarity of 92%, both directly concatenated without filtering, marking them as high-risk vulnerability locations. Simultaneously, the amount verification line was only detected at the front end, allowing attackers to bypass it by sending 20,000, marking it as a medium-risk location and associating it with vulnerability type codes CWE-89 and CWE-190. Subsequently, a historical remediation case library was searched. For SQL injection type code CWE-89, the matching operation sequence [replacing parameterized queries, adding filtering] and constraint [maintaining log compatibility] were found; for CWE-190, the matching operation sequence [adding server-side verification, adding type conversion] and constraint [response time ≤ 50ms] were found, forming a set of optimization strategies.

[0071] Loading a semantic analysis model at the marked location and performing row parsing on the database revealed that `amount` was directly concatenated with the SQL string without any pre-filtering function, indicating a missing control flow. Upon analysis of the amount verification line, it was found that there was only one comparison and negative numbers were allowed, indicating a lack of server-side verification in the control flow. Based on this, a difference graph between normal and risky execution modes was constructed, generating core semantic features: SQL injection points require the addition of escape functions and parameterization modifications, and amount points require the addition of negative number verification and server-side verification.

[0072] Constructing perturbation factors based on semantic features: For SQL injection points, generating numerical offsets from variable difference features. The function generates modification points from path difference features, changing concatenation to parameterized query; for amount points, it generates numerical offsets, adds amount>=0 check, and inserts modification points. "Function". Injecting a perturbation factor into the source code, the original amount verification line... Modified to Original database rows Replaced with A comparison sample containing the original and modified sequences was generated. Dynamic analysis was then performed: when the attack data amount=-5000 was input, the original code paid successfully, while the modified code returned "illegal amount." Memory usage was detected to decrease from 35MB to 17MB, the behavior change value was -18MB, and the output results were 100% inconsistent. The difference was calculated using the formula: behavior change weight 0.4×(18 / 35)=0.206, result difference weight 0.6×1=0.6, and the total 0.806 exceeded the threshold of 0.5. Based on this, the parameters of the large model were adjusted, and a new code was generated after fine-tuning: the amount verification was upgraded to if not(0<=amount<=10000) and a new function was added. The database operation was changed to parameterized query + sanitize(amount). The final vulnerability review confirmed that the message amount="1;DROP TABLE logs" was filtered, and the message 20000 was intercepted by the server. At the same time, the features of "double boundary check to block overflow" and "parameterized + filtering to block injection" were fed back to update the vulnerability knowledge graph, forming a closed-loop security enhancement mechanism.

[0073] Figure 3 This application provides a schematic diagram of the structure of an automated code generation and optimization system based on a large model, as shown in the embodiments of this application. Figure 3 As shown, the system includes: Parsing module 31 is used to receive functional requirement descriptions, parse the functional requirement descriptions through a large model to generate an initial logical framework, and perform symbolic transformation processing on the initial logical framework to form a symbolic structure; The conversion module 32 is used to generate an intermediate code representation based on the symbolic structure, which retains the semantics of variable operations, execution path boundaries and resource access patterns, so as to generate source code through the intermediate code representation. The tagging module 33 is used to extract vulnerability feature vectors from the vulnerability knowledge graph, construct a vulnerability knowledge set with weighted index, scan the instruction sequence of the source code using parallel computing resources, and mark the target instruction location with security risk and the corresponding vulnerability type code and risk level by calculating the semantic similarity between the instruction sequence and the vulnerability feature vector in the vulnerability knowledge set and matching the path pattern. The matching module 34 is used to retrieve historical remediation case libraries based on the vulnerability type encoding and risk level, establish a matching relationship between vulnerability patterns and remediation strategies based on the retrieval results, and generate an optimization strategy set containing remediation operation sequences and constraints based on the matching relationship. The generation module 35 is used to load a context semantic analysis model at the target instruction location, parse the data dependency relationship and control flow relationship between instructions, and combine the set of optimization strategies to construct a difference map between normal execution mode and risky execution mode to generate semantic features; The tuning module 36 is used to construct vulnerability samples with adversarial perturbation factors based on the semantic features, so as to adjust the parameters of the large model through the vulnerability samples, and to perform vulnerability re-examination on the source code generated after fine-tuning.

[0074] Figure 3 The aforementioned automated code generation and optimization system based on a large model can execute... Figure 1 The implementation principle and technical effects of the automated code generation and optimization method based on a large model described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit performs operations in the automated code generation and optimization system based on a large model in the above embodiments have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0075] In one possible design, Figure 3 The automated code generation and optimization system based on a large model, as shown in the embodiment, can be implemented as a computing device, such as... Figure 4 As shown, the computing device may include a storage component 41 and a processing component 42; The storage component 41 stores one or more computer instructions, wherein the one or more computer instructions are invoked and executed by the processing component 42.

[0076] The processing component 42 is used for the above Figure 1 The embodiment describes an automated code generation and optimization method based on a large model.

[0077] The processing component 42 may include one or more processors to execute computer instructions to complete all or part of the steps in the above-described method. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described method.

[0078] Storage component 41 is configured to store various types of data to support operations at the terminal. The storage component can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0079] Of course, computing devices may also include other components, such as input / output interfaces, display components, communication components, etc.

[0080] Input / output interfaces provide interfaces between processing components and peripheral interface modules, which can be output devices, input devices, etc.

[0081] The communication components are configured to facilitate wired or wireless communication between computing devices and other devices.

[0082] The computing device can be a physical device or an elastic computing host provided by a cloud computing platform. In this case, the computing device can refer to a cloud server, and the aforementioned processing components, storage components, etc., can be basic server resources rented or purchased from the cloud computing platform.

[0083] This application also provides a computer storage medium storing a computer program, which, when executed by a computer, can perform the above-described functions. Figure 1 The illustrated embodiment presents an automated code generation and optimization method based on a large model.

[0084] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0085] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0086] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An automated code generation and optimization method based on a large model, characterized in that, include: Receive functional requirement description, parse the functional requirement description through a large model to generate an initial logical framework, and perform symbolic transformation processing on the initial logical framework to form a symbolic structure; Based on the symbolic structure, a code intermediate representation is generated that preserves the semantics of variable operations, execution path boundaries, and resource access patterns, and the source code is generated by transforming the code intermediate representation. Vulnerability feature vectors are extracted from the vulnerability knowledge graph, a vulnerability knowledge set with weighted index is constructed, and the instruction sequence of the source code is scanned using parallel computing resources. By calculating the semantic similarity between the instruction sequence and the vulnerability feature vectors in the vulnerability knowledge set and matching the path pattern, the location of the target instruction with security risks and the corresponding vulnerability type code and risk level are marked. Based on the vulnerability type encoding and risk level, a historical remediation case library is retrieved. A matching relationship between vulnerability patterns and remediation strategies is established based on the retrieval results. Based on the matching relationship, an optimization strategy set containing remediation operation sequences and constraints is generated. A contextual semantic analysis model is loaded at the target instruction location to parse the data dependencies and control flow relationships between instructions. Combined with the set of optimization strategies, a difference graph between normal execution mode and risky execution mode is constructed to generate semantic features. Based on the semantic features, vulnerability samples with adversarial perturbation factors are constructed to adjust the parameters of the large model and to re-examine the vulnerability in the fine-tuned source code.

2. The method according to claim 1, characterized in that, The process of constructing vulnerability samples with adversarial perturbation factors based on the semantic features, adjusting the parameters of the large model using the vulnerability samples, and performing vulnerability re-checks on the generated source code after fine-tuning includes: A numerical offset is generated based on the variable difference features in the semantic features, and a path modification point is generated based on the path difference features in the semantic features. The numerical offset and the path modification point are combined to form a perturbation factor. The perturbation factor is injected at the corresponding position in the source code instruction sequence to generate a vulnerability sample containing the original instruction sequence and the modified instruction sequence; The vulnerability sample is input into the large model. The parameters of the large model are adjusted according to the difference between the modified instruction sequence and the original instruction sequence. The large model with adjusted parameters is used to generate a new version of the source code, and the vulnerability is re-checked on the new version of the source code.

3. The method according to claim 2, characterized in that, The process of inputting the vulnerability sample into a large model, adjusting the parameters of the large model based on the differences between the modified instruction sequence and the original instruction sequence, generating a new version of source code using the parameter-adjusted large model, and performing vulnerability re-checking on the new version of source code includes: The vulnerability sample is input into a large model, and the execution behavior of the modified instruction sequence is compared with that of the original instruction sequence. The behavior change value and the result difference value are extracted. Based on the behavioral change value and the result difference value, a difference degree value is generated, a reverse update operation is performed to adjust the weight of the large model, and a new version of the source code is generated from the adjusted large model. The new version of the source code is subjected to vulnerability re-examination, and the re-examination results are fed back to the vulnerability knowledge graph for continuous feature vector updates, forming a continuously evolving code security generation capability.

4. The method according to claim 1, characterized in that, The process involves loading a contextual semantic analysis model at the target instruction location to parse data dependencies and control flow relationships between instructions, and combining this model with the set of optimization strategies to construct a difference graph between normal and risky execution modes to generate semantic features, including: At the target instruction location, a context semantic analysis model is loaded to analyze the instruction sequence, and the data dependencies and control flow relationships containing variable generation locations, variable usage locations, and variable propagation paths in the instruction sequence are parsed; Based on the data dependencies and control flow relationships, a normal execution mode containing variable change sequences and control flow order is constructed. Simultaneously, combined with the optimization strategy set, a risky execution mode containing abnormal variable sequences and abnormal control flow paths when vulnerabilities are triggered is simulated and generated. The normal execution mode and the risky execution mode are compared to identify the variable difference locations and control flow difference locations to construct a difference map. Semantic features containing variable difference characteristics and path difference characteristics are extracted from the difference map.

5. The method according to claim 1, characterized in that, The process of extracting vulnerability feature vectors from a vulnerability knowledge graph, constructing a weighted indexed vulnerability knowledge set, scanning the instruction sequences of the source code using parallel computing resources, and marking the locations of target instructions with security risks and their corresponding vulnerability type codes and risk levels through semantic similarity calculation and path pattern matching between the instruction sequences and the vulnerability feature vectors in the vulnerability knowledge set includes: Vulnerability records are extracted from the vulnerability knowledge graph and converted into vulnerability feature vectors. Weight values ​​are assigned to each vulnerability feature vector to construct a vulnerability knowledge set with weight index. The source code instruction sequence is divided into multiple instruction segments using parallel computing resources, instruction features are formed for each instruction segment, and the instruction features are converted into numerical features. Calculate the semantic similarity between the numerical features corresponding to different instruction segments in the instruction sequence and the semantic similarity between each vulnerability feature vector in the vulnerability knowledge set, and simultaneously detect the path pattern matching degree between the operation symbol sequence of different instruction segments in the instruction sequence and the vulnerability feature vector. When the semantic similarity value exceeds the corresponding weight value and the path pattern matching degree reaches the set threshold, the position of the instruction segment is marked as the target position, and the vulnerability type code and risk level corresponding to the target position are extracted.

6. The method according to claim 1, characterized in that, The process involves retrieving historical remediation case libraries based on the vulnerability type encoding and risk level, establishing a matching relationship between vulnerability patterns and remediation strategies based on the retrieval results, and generating an optimization strategy set containing remediation operation sequences and constraints based on the matching relationship, including: Based on the vulnerability type code and risk level, the historical remediation case library is retrieved to obtain vulnerability remediation cases containing vulnerability patterns and remediation strategies, so as to establish a correspondence between the vulnerability patterns and remediation strategies to form a matching relationship. Based on the matching relationship, the repair strategy is parsed, and the sequence of operation actions consisting of multiple operation actions and objects in the order of execution, along with the constraints containing the execution triggering conditions and resource consumption limits, is extracted to generate an optimization strategy set containing the operation action sequence and the constraints.

7. The method according to claim 1, characterized in that, The process of generating a code intermediate representation based on the symbolic structure, including reserved variable operation semantics, execution path boundaries, and resource access patterns, and then using this intermediate representation to generate source code, includes: Based on the symbolic structure, the meaning of the operation of the retained variables containing the object identifier, action type and result identifier is extracted, including the execution path boundary containing the path start position and the path end position, and the resource access method containing the resource type identifier and access action type. Based on the meaning of the reserved variable operations, the execution path boundaries, and the resource access methods, an intermediate code representation is constructed. Traverse the code intermediate representation, convert the meaning of the reserved variable operation into variable assignment statements, and convert the resource access method into resource call statements; Based on the location information of the execution path boundary, flow control statements are added to the variable assignment statement and the resource call statement to form the final source code.

8. An automated code generation and optimization system based on a large model, characterized in that, include: The parsing module is used to receive the functional requirement description, parse the functional requirement description through the large model to generate an initial logical framework, and perform symbolic transformation processing on the initial logical framework to form a symbolic structure; The conversion module is used to generate an intermediate code representation based on the symbolic structure, which retains the semantics of variable operations, execution path boundaries, and resource access patterns, and then converts the intermediate code representation to generate source code. The tagging module is used to extract vulnerability feature vectors from the vulnerability knowledge graph, construct a vulnerability knowledge set with weighted indexes, scan the instruction sequence of the source code using parallel computing resources, and mark the target instruction locations with security risks and their corresponding vulnerability type codes and risk levels by calculating the semantic similarity between the instruction sequence and the vulnerability feature vectors in the vulnerability knowledge set and matching the path patterns. The matching module is used to retrieve historical remediation case libraries based on the vulnerability type encoding and risk level, establish a matching relationship between vulnerability patterns and remediation strategies based on the retrieval results, and generate an optimization strategy set containing remediation operation sequences and constraints based on the matching relationship. The generation module is used to load a context semantic analysis model at the target instruction location, parse the data dependencies and control flow relationships between instructions, and combine the set of optimization strategies to construct a difference map between normal execution mode and risky execution mode to generate semantic features; The tuning module is used to construct vulnerability samples with adversarial perturbation factors based on the semantic features, so as to adjust the parameters of the large model through the vulnerability samples, and to perform vulnerability re-examination on the source code generated after fine-tuning.

9. A computing device, characterized in that, It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement an automated code generation and optimization method based on a large model as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The system contains a computer program that, when executed by a computer, implements an automated code generation and optimization method based on a large model as described in any one of claims 1 to 7.

Images