A cross-language source code auditing method based on deep learning

Abstract

This invention discloses a cross-language source code auditing method based on deep learning, belonging to the interdisciplinary fields of software security and artificial intelligence. This invention standardizes variable definitions, sensitive operations, and data flow paths in multi-language source code to construct a unified abstract expression, and combines this with natural language templates to complete structured transcription, thereby eliminating language differences and achieving unified analysis of mixed C / C++, Java, and Python projects. The transcription results are integrated with a large language model, utilizing a multi-layered prompting mechanism to enhance the model's semantic understanding and contextual reasoning capabilities, improving the detection effect of complex vulnerabilities such as deep data flow dependencies and sensitive path propagation. Simultaneously, a semantic equivalence test set is used to verify the consistency of multi-language analysis results, and the template and prompting strategy are automatically optimized when the deviation exceeds a threshold, giving the system good stability and adaptability.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a cross-language source code auditing method based on deep learning. Background Technology

[0002] Source code auditing is a crucial means of ensuring software security, widely used in vulnerability detection, backdoor investigation, and security compliance checks. Traditional source code auditing methods primarily rely on static analysis, abstract syntax tree analysis, data flow analysis, and control flow graph construction. While these methods are practical for handling structured, single-language source code, they suffer from limitations such as insufficient semantic understanding, poor language adaptability, and difficulties in cross-language transfer, especially in large-scale multilingual projects where they struggle to cover all potential vulnerability paths.

[0003] With the widespread adoption of open-source components and microservice architectures, modern software systems are increasingly being developed using multiple programming languages. For example, C / C++ handles the underlying interfaces, Java is used for service logic, and Python is used for scheduling and script orchestration. In such complex systems, the semantic, type system, and calling convention differences between languages ​​significantly increase the design difficulty and applicability of source code auditing tools. Traditional language-specific analyzers struggle to establish a unified data flow tracing path across language environments, leading to fragmented analysis results, a lack of contextual consistency, and consequently, false positives and false negatives.

[0004] In recent years, the rapid development of deep learning, especially Large Language Models (LLMs), has provided new insights for source code semantic understanding and vulnerability detection. Large Language Models possess cross-textual contextual understanding capabilities and demonstrate strong performance in tasks such as natural language and code generation, completion, and interpretation. This has made model-driven code auditing a research hotspot. However, most existing models are trained on single-language corpora or specific project contexts, lacking multilingual alignment capabilities and failing to accurately identify semantically equivalent but syntactically different program fragments in different languages, especially performing poorly in scenarios involving cross-language data flow.

[0005] Furthermore, existing deep learning methods rely on language-specific encoding methods during data preprocessing, making it difficult for models to generalize to new languages. At the same time, existing models lack in-depth modeling of variable scope, function call relationships, and input / output data flow, and do not possess the ability to accurately perceive critical paths and sensitive operations, making them unsuitable for sophisticated security auditing tasks.

[0006] Therefore, a method is needed that integrates the advantages of static analysis and deep learning, enabling language-independent unified semantic modeling and leveraging natural language transcription to enhance the model's understanding of program behavior. This method should possess good cross-language adaptability, high accuracy, and sustainable optimization capabilities to meet the demands of automated and intelligent source code security auditing in today's complex software systems. Summary of the Invention

[0007] To address the aforementioned issues, this invention provides a deep learning-based cross-language source code auditing method. Through data flow semantic abstraction and natural language transcription technology, it converts multilingual source code into a unified semantic representation and utilizes a large language model for vulnerability detection, achieving truly language-independent automated auditing. Furthermore, it incorporates layered hints to achieve high-precision vulnerability identification.

[0008] To achieve the above objectives, the present invention is implemented through the following technical solution: In a first aspect, this invention provides a deep learning-based cross-language source code auditing method, comprising: S1: performing static analysis on multi-language source code, extracting variable definitions, external inputs, and sensitive operation information, and tracing data propagation paths starting from sensitive operations, marking corresponding danger convergence points, and forming a source code semantic structure set containing semantic dependencies; S2: using the source code semantic structure set as input, mapping each data propagation path to a unified structured language-independent intermediate representation template, and semantically merging cross-function or cross-file association paths to generate an intermediate representation set representing a complete data flow chain; S3: transcribing the data propagation paths represented in the intermediate representations into structured corpus, and simultaneously generating repair path descriptions corresponding to each danger convergence point, obtaining a structured corpus set adapted for large language model analysis; S4: based on the structured corpus set, performing vulnerability analysis using a hierarchical hint strategy, generating language analysis results containing vulnerability types and repair paths, and verifying the analysis results based on the consistency of repair paths under different languages, and outputting cross-language source code auditing results.

[0009] As a preferred embodiment of the deep learning-based cross-language source code auditing method of the present invention, the generation of the source code semantic structure set includes: calling a static analysis tool corresponding to the source code programming language to obtain syntax structure and control flow information; marking code entities according to preset semantic classification rules, marking variable definitions as data source entities, marking external input operations as external input entities, and marking operations that call security-sensitive functions as sensitive operation entities; using the sensitive operation entities as sensitive sources, tracking the data propagation process along the control flow and call relationships, and marking the propagation termination position as a danger convergence point, thereby constructing a source code semantic structure set containing entity labels, dependencies, and propagation order.

[0010] As a preferred embodiment of the deep learning-based cross-language source code auditing method of the present invention, the construction of the source code semantic structure set further includes semantic completion and conflict filtering; the semantic completion completes missing data dependency information by combining statement hierarchy relationships and context dependencies; the conflict filtering is used to eliminate duplicate nodes or logical contradiction markers existing in the same data propagation path.

[0011] As a preferred embodiment of the deep learning-based cross-language source code auditing method of the present invention, the generation of the intermediate representation set includes: pre-setting a unified structured intermediate representation template corresponding to multiple vulnerability scenarios and a mapping rule library of vulnerability features and intermediate representations; for each data propagation path in the source code semantic structure set, extracting sensitive operation function types and propagation path features, matching the corresponding intermediate representation template according to the mapping rule library, and filling the template fields with sensitive source, data propagation path, and dangerous convergence point information to generate a basic intermediate representation; for multiple basic intermediate representations with cross-function or cross-file relationships, if the data flow endpoint of one basic intermediate representation and the data flow starting point of another basic intermediate representation have a variable alias relationship or a direct parameter passing relationship, then the two are semantically associated and merged to form an intermediate representation set representing a complete data flow chain.

[0012] As a preferred embodiment of the deep learning-based cross-language source code auditing method of the present invention, the generation of the structured corpus includes: based on the field types and context dependencies in the intermediate representation set, selecting corresponding natural language templates from a pre-defined multi-level natural language template library for placeholder filling according to a predefined node type-template mapping table to generate a preliminary structured description; performing semantic completion and logical reorganization on the preliminary structured description according to variable dependencies and control flow order to obtain a data flow semantic description with consistent structure; based on the data flow semantic description, and based on a pre-defined vulnerability repair pattern knowledge base, synchronously generating a repair path description for each dangerous convergence point, wherein the repair path description is used to characterize the key code locations and processing order involved in the repair operation.

[0013] As a preferred embodiment of the deep learning-based cross-language source code auditing method of the present invention, the hierarchical prompting strategy includes: basic instruction information for limiting the scope of the analysis task; context information for providing a semantic description of the data flow to be analyzed; and reasoning constraint information for constraining the vulnerability determination logic. The hierarchical prompting strategy uses a structured corpus as the sole input to generate language analysis results containing vulnerability types, descriptions of danger convergence points, and descriptions of remediation paths.

[0014] As a preferred embodiment of the deep learning-based cross-language source code auditing method of the present invention, the step of verifying the analysis results based on the consistency of the repair paths under different languages ​​includes: obtaining the language analysis results obtained for the same vulnerability scenario under at least two different programming languages, acquiring the structured corpus and repair path description corresponding to each language; combining the repair path description of the first programming language with the structured corpus of the second programming language to construct a first cross-validation hint, inputting it into the large language model to obtain a first verified repair description for the second programming language; combining the repair path description of the second programming language with the structured corpus of the first programming language to construct a second cross-validation hint, inputting it into the large language model to obtain a second verified repair description for the first programming language; calculating the first verified repair description and the second... The semantic similarity between the original repair path descriptions in the first programming language is used to obtain a first similarity score, and the semantic similarity between the second verification repair description and the original repair path description in the first programming language is used to obtain a second similarity score. When both the first and second similarity scores are higher than a preset similarity threshold, the cross-language analysis results of the vulnerability scenario are determined to be consistent, and the language analysis results are output as the final audit results. When either similarity score is lower than the preset similarity threshold, the structured corpora of the first and second programming languages, the repair path descriptions, and the corresponding verification repair descriptions are merged to construct an arbitration prompt, which is input into the large language model for conflict resolution. The arbitration-resolved repair path description is output, and the language analysis results are updated based on the arbitration-resolved repair path description. The final cross-language source code audit results are then output.

[0015] In a second aspect, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein: when the computer program instructions are executed by the processor, they implement the steps of the deep learning-based cross-language source code auditing method described in the first aspect of the present invention.

[0016] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program instructions are executed by a processor, they implement the steps of the deep learning-based cross-language source code auditing method described in the first aspect of the present invention.

[0017] The beneficial effects of this invention are as follows: This invention standardizes the processing of key information such as variable definitions, sensitive operations, and data flow paths in multi-language source code, constructing a unified abstract expression form; on this basis, it further combines natural language templates for structured transcribing, avoiding differences in syntax, structure, and calling methods between different languages, enabling the vulnerability detection process to break free from dependence on specific language toolchains, possessing good cross-language adaptability, and effectively adapting to mixed projects composed of multiple programming languages ​​such as C / C++, Java, and Python, significantly improving the coverage and versatility of source code auditing in complex systems.

[0018] This invention deeply integrates natural language transcription results with a large language model and combines a multi-layered prompting mechanism to guide the model's reasoning process. This enables the model to have stronger semantic understanding and contextual association capabilities in vulnerability analysis tasks. It not only enhances the interpretability of the auditing process but also significantly improves the detection capability for complex scenarios such as deep data flow dependencies and sensitive path propagation. Compared with traditional static analysis techniques based on rules or graph structures, it has significant advantages in terms of accuracy, recall, and ability to identify complex vulnerabilities.

[0019] This invention verifies the consistency of multilingual implementation results by constructing a semantic equivalence test set, and automatically optimizes natural language templates and prompting strategies when the consistency deviation exceeds a threshold, thereby achieving continuous optimization of model performance. This effectively reduces the problem of deviation propagation in the cross-language auditing process, enhances the stability and adaptability of the system, and improves the engineering reliability and practicality in long-term deployment. Attached Figure Description

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

[0021] Figure 1 This is a flowchart illustrating a cross-language source code auditing method based on deep learning according to the present invention.

[0022] Figure 2 This is a flowchart of the vulnerability analysis process combining a large language model and layered hints in this invention. Detailed Implementation

[0023] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0024] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0025] Secondly, the term "one embodiment" or "example" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the invention. The appearance of an embodiment in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that mutually excludes other embodiments.

[0026] This invention presents a deep learning-based cross-language source code auditing method. Through data flow semantic abstraction and natural language transcription technology, it transforms multi-language source code into a unified semantic representation and utilizes Large Language Models (LLM) for vulnerability detection, achieving truly language-independent automated auditing. Specifically, it includes: extracting variable definitions, propagation paths, and sensitive operations through static analysis and standardizing them into language-independent semantic representations; converting data flows into structured natural language descriptions based on preset templates to eliminate grammatical differences; achieving high-precision vulnerability determination by combining layered hints; and improving audit consistency across different languages ​​through semantic equivalence testing and feedback loops.

[0027] Figure 1 This is a flowchart illustrating a deep learning-based cross-language source code auditing method according to an embodiment of the present invention. Figure 1 and Figure 2 As shown, the deep learning-based cross-language source code auditing method includes: S1: Perform static analysis on multi-language source code, extract variable definitions, external inputs and sensitive operation information, and trace the data propagation path starting from the sensitive operation, mark the corresponding dangerous convergence points, and form a source code semantic structure set containing semantic dependencies.

[0028] S1.1: Call the static analysis tool corresponding to the source code programming language to obtain syntax structure and control flow information.

[0029] First, a programming language identifier is built to identify the programming language type of the source code based on file extensions, code identifiers, and syntax features, including but not limited to Java, Python, C / C++, JavaScript, Go, etc. Simultaneously, a static analysis tool selection table is constructed, recording the static analysis tools and configuration parameters corresponding to each programming language.

[0030] During the call, corresponding analysis parameters are set according to the characteristics of the target programming language, including whether to enable inter-process analysis, maximum analysis depth, and whether to perform alias analysis. Through a unified tool call interface, source code from different languages ​​is input into the corresponding static analysis tool to obtain standardized analysis output.

[0031] After invoking static analysis tools, the syntax structure and control flow information are extracted and normalized. Specifically, this includes: 1) obtaining the abstract syntax tree and converting it into a unified tree structure representation, recording the type, location information, and attribute values ​​of each node; 2) extracting the control flow graph, treating each function or method as an independent control flow unit, and recording the jump relationships between basic blocks, including sequential execution, conditional branches, loops, and function calls; 3) generating a data dependency graph, identifying the definition-usage relationships between variables, and labeling the lifecycle and scope of variables.

[0032] S1.2: Mark code entities according to preset semantic classification rules, mark variable definitions as data source entities, mark external input operations as external input entities, and mark operations that call security-sensitive functions as sensitive operation entities.

[0033] Specifically, the preset semantic classification rules include: the first layer consists of general security rules independent of programming languages, defining common security-related operation patterns; the second layer consists of language-specific adaptation rules, considering API naming and calling habits of different languages; and the third layer consists of user-defined rules, supporting the extension of new security patterns. Each rule in the rule base includes: 1) a matching pattern, described using AST node types and attributes; 2) an entity category, including data source entities, external input entities, sensitive operation entities, etc.; and 3) a confidence weight, reflecting the credibility of the rule. When applying rules, a depth-first traversal of the abstract syntax tree is used to match each node sequentially with patterns from the rule base.

[0034] The matching process supports both fuzzy matching and regular expression matching to accommodate different naming styles and coding habits. For example, for Java's HttpServletRequest.getParameter() call, it matches external input entity rules; for Runtime.exec() call, it matches sensitive operation entity rules.

[0035] After identifying code entities that conform to the rules, semantic tags are added to each entity and associated with relevant attributes. The tags adopt a structured format, including entity type, location information, confidence level, and context. For variable definitions, they are tagged as data source entities, and the data type, initial value, and scope are recorded; for external input operations, they are tagged as external input entities, and the input source (such as HTTP request, file read, network socket, etc.) and possible attack surface information are recorded; for sensitive operation function calls, they are tagged as sensitive operation entities, and the operation type (such as command execution, database access, file operation, etc.) and related security risk levels are recorded.

[0036] Simultaneously, referencing relationships between entities are established, such as tracing the data flow path from external input entities to sensitive operation entities. The labeling results are stored as an attributed graph structure, where nodes represent labeled entities and edges represent data dependencies and control dependencies between entities.

[0037] S1.3: Using the sensitive operation entity as the sensitive source, track the data propagation process along the control flow and call relationship, mark the propagation termination position as the danger convergence point, and construct a source code semantic structure set containing entity tags, dependencies and propagation order.

[0038] In practice, firstly, for each marked sensitive operation entity (sensitive source), the data sources of the parameters and receivers are analyzed, and backward slice analysis is performed to identify all variables and expressions that may affect the operation. Then, forward propagation analysis is performed on these variables and expressions to track the propagation process throughout the program. The analysis process maintains a tainted state set, recording the tainted state, propagation path, and transformation operation of each variable.

[0039] During data flow tracing, dangerous convergence points are identified and marked. Dangerous convergence points are defined as: 1) points where data is ultimately used insecurely, such as being used directly for sensitive operations without verification; 2) points where security boundary transitions occur along the data flow path, such as flowing from a low-privilege domain to a high-privilege domain; 3) points where multiple contaminated data converge, potentially leading to combined attacks. Each dangerous convergence point records its location, involved variables, type of security risk, and severity. Based on the data flow tracing results and dangerous convergence point markings, a source code semantic structure set is constructed.

[0040] Furthermore, the construction of the source code semantic structure set also includes semantic completion and conflict filtering: The semantic completion method fills in missing data dependency information by combining statement hierarchy relationships and contextual dependencies. In this embodiment of the invention, semantic completion includes: 1) when direct data flow analysis cannot identify certain dependencies, inferring possible implicit data flow relationships by analyzing variable type conversions, container operations (such as array access and set iteration), and object attribute access; 2) analyzing conditional statements, loops, and exception handling structures to identify data dependencies indirectly passed through control flow; and 3) using a pre-built security knowledge base to perform semantic inference on specific API call patterns, such as identifying the relationship between encryption function output and key input.

[0041] The conflict filtering is used to eliminate duplicate nodes or logically contradictory markers in the same data propagation path. In this embodiment of the invention, conflict filtering includes: 1) analyzing the conditional constraints on the data flow path through a constraint solver to identify and exclude logically infeasible paths; 2) merging multiple nodes representing the same program entity based on code location and semantic equivalence judgment; 3) retaining the most accurate path representation for multiple data flow paths with containment relationships; 4) when the same entity has contradictory markers on different paths (e.g., one path is marked as cleaned up and another is marked as not cleaned up), a conservative strategy is adopted to retain the marker with higher risk and record the reason for the contradiction for subsequent analysis.

[0042] The filtering process is based on a rule engine and heuristic algorithms to ensure the consistency and simplicity of the final semantic structure set.

[0043] S2: Taking the source code semantic structure set as input, map each data propagation path to a unified structured language-independent intermediate representation template, and perform semantic merging on cross-function or cross-file association paths to generate an intermediate representation set representing the complete data flow chain.

[0044] S2.1: Pre-configures a unified structured intermediate representation template and a mapping rule library between vulnerability features and intermediate representations for various vulnerability scenarios.

[0045] Specifically, each intermediate representation template uses a multi-layered nested JSON-LD structure to achieve semantic representation. Each intermediate representation template contains four core components: 1) Metadata layer: defines the template's unique identifier, corresponding CWE number, vulnerability category, and applicable language range; 2) Structural constraint layer: uses a property graph-based pattern definition, specifying the required set of node types (including input source nodes, propagation operation nodes, cleansing nodes, and sink nodes) and edge types (including data flow edges, control dependency edges, and call edges); 3) Semantic annotation layer: defines semantic constraints for each node and edge, such as input source nodes must have externally controllable attributes, and sink nodes must have enumerated values ​​for dangerous operation types; 4) Extended slot layer: reserves extensible fields to carry language-specific adaptation information. For example, in the template for an SQL injection vulnerability, the structural constraint layer specifies that there must be a complete path from the user input node to the SQL query construction node and then to the database execution node, and if there are parameterized processing nodes in the path, they are marked as cleansed.

[0046] Among them, the mapping rule base is a vulnerability feature mapping mechanism based on a hybrid decision tree and rule engine.

[0047] The mapping rule base adopts a three-layer architecture: the first layer is the syntax feature rule set, which identifies basic features through abstract syntax tree pattern matching, such as the function call pattern `executeQuery` (non-parameterized string); the second layer is the data flow feature rule set, which defines rules based on the structural features of the taint propagation graph, such as the existence of an unpurified path from source to sink with a path length greater than 3; the third layer is the semantic feature rule set, which calculates the semantic similarity of code entities through a pre-trained word embedding model, such as mapping `mysql_query()` and `pg_execute()` to the same semantic cluster. The rule base uses the Rete algorithm for efficient matching and configures confidence weights, priority coefficients, and conflict resolution strategies for each rule. The rule base supports an incremental update mechanism; when a new vulnerability pattern is discovered, features are automatically extracted and candidate rules are generated through a feedback mechanism, which are then added to the database after review by security experts.

[0048] S2.2: For each data propagation path in the source code semantic structure set, extract the sensitive operation function type and propagation path features, match the corresponding intermediate representation template according to the mapping rule library, and fill the sensitive source, data propagation path and danger convergence point information into the template field to generate a basic intermediate representation.

[0049] For each data propagation path in the source code semantic structure set, after conversion into an attribute graph representation, a graph attention network is used for feature learning. Specifically, this includes: 1) Node feature encoding: Converting the type (input source, propagation operation, danger convergence point, etc.), code location, variable type, and operation semantics of each node into a 256-dimensional feature vector using a pre-trained word embedding model; 2) Edge feature encoding: Encoding the edge type (data flow, control dependency, alias relationship) and propagation direction using one-hot encoding; 3) Graph structure encoding: Using a 3-layer graph attention network to aggregate features of the entire path, generating a global representation vector for the path. Simultaneously, traditional features are extracted as supplementary features, including statistical features such as path length, number of branches, loop depth, and number of cleanup operations.

[0050] The final generated feature vector contains 512 dimensions, with the first 256 dimensions coming from a graph neural network and the last 256 dimensions coming from statistical features.

[0051] Furthermore, the cosine similarity between the path feature vector and the template feature vector is calculated in the embedding space. The matching process consists of three steps: 1) First, the template library is indexed using local sensitive hashing to quickly filter out candidate templates with a similarity greater than 0.6; 2) Second, the precise similarity is calculated for the candidate templates, taking into account both structural similarity (based on graph edit distance) and semantic similarity (based on feature vector); 3) A weighted voting mechanism is adopted, and when multiple templates have similarities, the most likely template is selected based on historical data on the distribution of vulnerability categories.

[0052] Once a template is matched, intelligent fill is performed: a two-way alignment mapping is established from path nodes to template fields. Using an attention-based sequence-to-sequence model, specific information from the path (variable names, function names, code locations) is filled into the corresponding slots in the template, while a fill confidence score is generated. For fields that cannot be aligned, context-based inference is used for completion.

[0053] S2.3: For multiple basic intermediate representations that have cross-function or cross-file relationships, if the data flow endpoint of one basic intermediate representation has a variable alias relationship or a direct parameter passing relationship with the data flow starting point of another basic intermediate representation, then the two are semantically associated and merged to form an intermediate representation set that represents the complete data flow chain.

[0054] Specifically, by querying the source code semantic structure set, if two base variables, IR_A and IR_B, are identified in the semantic structure set as pointing to the same memory address or having reference equivalence, then a variable alias relationship exists between them. If the data flow starting point corresponding to IR_B is located inside a function, and variable Y is a formal parameter of that function; while the data flow ending variable X of IR_A is passed as an actual parameter to Y at the call point of a function, then a direct parameter passing relationship exists between them. The system maintains a queue to be merged; when an IR pair (IR_A, IR_B) satisfying any of the above relationships is detected, it is added to this queue.

[0055] Furthermore, the merging process includes: first, appending the data propagation path node sequence of IR_B to the data propagation path node sequence of IR_A to form a sequential extended node sequence. The data flow start point is inherited from the start point of IR_A, and the data flow end point is updated to the end point of IR_B; the union of all sensitive sources in IR_A and IR_B is taken as the merged sensitive source set; the dangerous convergence point of IR_B is taken as the main dangerous convergence point after merging, while retaining the unique, uncovered dangerous convergence points in IR_A. If contradictory markers are found at the same program location during the merging process, a conservative security strategy is adopted, prioritizing the retention of markers with higher risk. Finally, a unified intermediate representation containing the complete cross-boundary data flow link is generated, and this representation replaces the original scattered IR_A and IR_B, and is stored in the intermediate representation set.

[0056] S3: Translate the data propagation path represented in the intermediate representation into a structured corpus, and simultaneously generate a repair path description corresponding to each danger convergence point to obtain a structured corpus set adapted for large language model analysis.

[0057] S3.1: Based on the field types and context dependencies in the intermediate representation set, and according to the predefined node type-template mapping table, select the corresponding natural language template from the pre-set multi-level natural language template library to fill in placeholders and generate a preliminary structured description.

[0058] It should be noted that the pre-built multi-level natural language template library is divided into three layers according to the level of abstraction: syntax structure layer template, data flow semantic layer template, and security logic layer template.

[0059] The syntax structure layer template describes basic code operations, such as assigning a value to a variable name at a location. The data flow semantic layer template expresses the propagation relationship between variables, such as data flowing from a source variable through a propagation path to the target variable. The security logic layer template expresses security-related semantics, such as using unverified input data directly for dangerous operations, which poses a risk of vulnerability type.

[0060] The node type-template mapping table specifies the template level and specific template ID to be used for various types of nodes in the intermediate representation (such as variable definition nodes, function call nodes, and conditional judgment nodes). For example, for sensitive operation call nodes, the mapping table specifies the use of the security logic layer template; for variable assignment nodes, the mapping table specifies the use of the syntax structure layer template.

[0061] Selecting a corresponding natural language template from a pre-built multi-level natural language template library to fill placeholders involves the following steps: First, query the node type-template mapping table based on the node type to determine the appropriate template level and template ID; then retrieve the template from the corresponding template library.

[0062] After template retrieval, placeholder filling is performed: based on the specific attribute values ​​of the nodes, the placeholders in the template are replaced with the actual content. For example, if the security logic layer template [input data] is used directly for [dangerous operation] without verification, there is a risk of [vulnerability type]. The input data variable name, dangerous operation function name, and vulnerability type inferred from the context are extracted from the current node and filled into the corresponding placeholder positions.

[0063] During the filling process, the filling results of multiple templates on the same path are concatenated to form a preliminary structured description of the path.

[0064] S3.2: Perform semantic completion and logical reorganization on the preliminary structured description according to variable dependencies and control flow order to obtain a data flow semantic description with consistent structure.

[0065] The completion process follows these rules: For two adjacent data flow steps in the description, if there is an unmentioned intermediate propagation node in the data flow graph, the corresponding description statement is added according to the type of the intermediate propagation node; for data flows involving conditional branches, the context description of the condition judgment is added; for loop structures, the description of the loop control conditions and iteration variables is added.

[0066] The completion operation inserts necessary connecting statements, such as "following," "next," and "in this process," while maintaining the original main structure of the description, ensuring the integrity of the data flow logic. All completed content comes from information already contained in the intermediate representation set and does not introduce new inference content.

[0067] The reorganization rules include: ensuring that the order of description is consistent with the actual execution order of the program; using conjunctions such as "simultaneously" and "on the other hand" to clarify the relationship for parallel or independent data flow branches; and using hierarchical expression for nested structures (such as conditional branches within loops) to ensure clear logic.

[0068] During the reorganization process, linguistic redundancy that may result from template concatenation is identified and eliminated, such as repeated subjects or excessive conjunctions, to make the final description concise and fluent. The reorganized description forms logically coherent paragraphs, fully presenting the data flow process from the sensitive source to the danger convergence point.

[0069] Semantic completion only supplements information that already exists in the data flow graph but was missed during template filling, without speculative completion. Logical reorganization is entirely based on the control flow dependencies recorded in the intermediate representation, without changing the essential logic of the data flow.

[0070] S3.3: Based on the data flow semantic description, and based on the pre-built vulnerability repair mode knowledge base, a repair path description is generated synchronously for each danger convergence point. The repair path description is used to characterize the key code locations and processing order involved in the repair operation.

[0071] The vulnerability remediation pattern knowledge base is indexed by vulnerability type and stores standardized remediation solutions. Each remediation pattern includes: the applicable vulnerability type (such as SQL injection, XSS, etc.), the sequence of remediation steps, the code operation mode corresponding to each step, and the recommended security function or API.

[0072] The remediation patterns in the knowledge base are built upon industry security best practices and security documentation for common frameworks. When a remediation path needs to be generated for a specific vulnerability convergence point, the knowledge base is first searched for matching remediation patterns based on the vulnerability type associated with that convergence point. If multiple matching patterns exist, the most suitable pattern is selected based on the code context (such as the programming language and framework type used).

[0073] It should be noted that the repair path generation is based on pattern matching and instantiation, and does not involve complex repair strategy reasoning. The repair pattern knowledge base is a pre-built static knowledge base and does not contain machine learning models.

[0074] S4: Based on the structured corpus, a layered suggestion strategy is used to perform vulnerability analysis, generate language analysis results containing vulnerability types and remediation paths, and verify the analysis results based on the consistency of remediation paths in different languages, outputting cross-language source code audit results.

[0075] The hierarchical prompting strategy includes: basic instruction information for limiting the scope of the analysis task; contextual information for providing a semantic description of the data stream to be analyzed; and reasoning constraint information for constraining the vulnerability determination logic. The hierarchical prompting strategy uses a structured corpus as the sole input to generate language analysis results.

[0076] For example, the constructed layered hints are as follows: You are a professional source code security auditor. Please analyze the given code context to determine if any security vulnerabilities exist, and strictly adhere to the subsequent reasoning format requirements. The semantic description of the code to be analyzed is as follows: "The user input data user_cmd is obtained in the function get_input() and directly passed to the function system() for execution without any validity check, filtering or security cleanup."

[0077] Please follow the steps below to reason and provide your answer step by step: 1. Identify the source in the data stream, i.e., the starting point of external input, and the sink, i.e., the ending point of performing potentially dangerous operations; Identify the source in the data stream, i.e., the starting point of external input, and the sink, i.e., the ending point of performing potentially dangerous operations.

[0078] 2. Analyze the data propagation path from source to sink to determine whether it has undergone verification, filtering, encoding or other security purification processes.

[0079] 3. Based on the types of the source and sink and their cleanup status, match known security vulnerability patterns.

[0080] 4. Based on the above analysis, determine whether there are any security vulnerabilities; if so, clearly indicate the corresponding vulnerability type.

[0081] Based on your analysis, please output the final results in the following JSON format. It must include a confidence field (value range 0.0-1.0) and a reasoning field (briefly describing the key reasoning basis).

[0082] Format example: { verdict: "exists / does not exist", vulnerability_type: "Vulnerability type name or empty", confidence: 0.95 Reasoning: "User input data is passed directly to system() for execution without validation, which matches the characteristics of a command injection vulnerability." }

[0083] It should be noted that the hierarchical prompts are a pre-designed text template assembly process, without dynamic generation or complex decision-making. The large language model is used as the analysis engine, and the output is standardized and extracted by a subsequent rule parser to ensure machine readability and consistency of the results.

[0084] Furthermore, verifying the analysis results based on the consistency of repair paths across different languages ​​includes the following steps: For the same vulnerability scenario, language analysis results obtained in at least two different programming languages ​​are used to obtain the structured corpus and remediation path description for each language.

[0085] The repair path description for the first programming language is combined with the structured corpus of the second programming language to construct a first cross-validation hint, which is then input into the large language model to obtain a first verification repair description for the second programming language.

[0086] The repair path description for the second programming language is combined with the structured corpus of the first programming language to construct a second cross-validation hint, which is then input into the large language model to obtain a second verification repair description for the first programming language.

[0087] A first similarity score is obtained by calculating the semantic similarity between the first verification repair description and the original repair path description in the second programming language, and a second similarity score is obtained by calculating the semantic similarity between the second verification repair description and the original repair path description in the first programming language.

[0088] Specifically, a pre-trained sentence embedding model (such as Sentence-BERT) is used to calculate the text vectors of the first verification repair description and the original repair path description of language B, and the first similarity score is obtained by calculating the cosine similarity; the similarity between the second verification repair description and the original repair path description of language A is calculated to obtain the second similarity score.

[0089] When both the first similarity score and the second similarity score are higher than the preset similarity threshold (e.g., 0.85), it is determined that the cross-language analysis results of the vulnerability scenario are consistent, and the language analysis results are output as the final audit result.

[0090] When any similarity score is lower than the preset similarity threshold, the structured corpora of the first and second programming languages, the repair path description, and the corresponding verification repair description are merged to construct an arbitration prompt, which is input into the large language model for conflict resolution. The arbitration-resolved repair path description is output, and the language analysis result is updated based on the arbitration-resolved repair path description. Finally, the cross-language source code audit result is output.

[0091] An arbitration directive might be as follows: The above materials present code analysis results and remediation suggestions for the same security issue implemented in two different programming languages, which contain inconsistencies. Please review all information as a security expert and provide a description of the most reasonable and universally applicable remediation solution. Input this arbitration prompt into a large language model, and the parsed output will serve as the remediation path description after arbitration. This path will be used to update or replace the original inconsistent remediation suggestions, ultimately forming a unified audit conclusion.

[0092] It's important to note that cross-validation essentially uses the repair approach of one language to verify the rationality of the analysis results of another language. The arbitration mechanism, when cross-validation fails, gathers all conflicting information and requests the large language model to act as a higher-level arbitrator to make a final ruling. The entire process relies on the understanding and generation capabilities of the large language model, but the process is deterministic and repeatable.

[0093] This embodiment also provides a computer device applicable to the cross-language source code auditing method based on deep learning, including a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the cross-language source code auditing method based on deep learning as proposed in the above embodiment.

[0094] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0095] This embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, it implements the cross-language source code auditing method based on deep learning as proposed in the above embodiments.

[0096] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cross-language source code auditing method based on deep learning, characterized in that: include: S1: Static analysis of multi-language source code is performed to extract variable definitions, external inputs and sensitive operation information. Starting from the sensitive operation, the data propagation path is traced, the corresponding dangerous convergence points are marked, and a semantic structure set of source code containing semantic dependencies is formed. S2: Taking the source code semantic structure set as input, map each data propagation path to a unified structured language-independent intermediate representation template, and perform semantic merging on cross-function or cross-file association paths to generate an intermediate representation set representing the complete data flow chain; S3: Translate the data propagation path represented in the intermediate representation into a structured corpus, and simultaneously generate a repair path description corresponding to each danger convergence point to obtain a structured corpus set adapted for large language model analysis; S4: Based on the structured corpus, a layered suggestion strategy is used to perform vulnerability analysis, generate language analysis results containing vulnerability types and remediation paths, and verify the analysis results based on the consistency of remediation paths in different languages, outputting cross-language source code audit results.

2. The cross-language source code auditing method based on deep learning as described in claim 1, characterized in that: The generation of the source code semantic structure set includes: Call the static analysis tool corresponding to the source code programming language to obtain syntax structure and control flow information; Code entities are marked according to preset semantic classification rules, variable definitions are marked as data source entities, external input operations are marked as external input entities, and operations that call security-sensitive functions are marked as sensitive operation entities; Using the sensitive operation entity as the sensitive source, the data propagation process is tracked along the control flow and call relationship, and the propagation termination position is marked as the danger convergence point. A source code semantic structure set containing entity tags, dependencies and propagation order is constructed.

3. The cross-language source code auditing method based on deep learning as described in claim 2, characterized in that: The construction of the source code semantic structure set also includes semantic completion and conflict filtering; The semantic completion fills in missing data dependency information by combining statement hierarchy relationships and contextual dependencies; The conflict filtering is used to eliminate duplicate nodes or logically contradictory markers that exist in the same data propagation path.

4. The cross-language source code auditing method based on deep learning as described in claim 3, characterized in that: The generation of the intermediate representation set includes: It includes a pre-built unified structured intermediate representation template for various vulnerability scenarios and a mapping rule library between vulnerability features and intermediate representations; For each data propagation path in the source code semantic structure set, the sensitive operation function type and propagation path features are extracted, the corresponding intermediate representation template is matched according to the mapping rule library, and the sensitive source, data propagation path and danger convergence point information are filled into the template field to generate a basic intermediate representation; For multiple basic intermediate representations that have cross-function or cross-file relationships, if the data flow endpoint of one basic intermediate representation has a variable alias relationship or a direct parameter passing relationship with the data flow starting point of another basic intermediate representation, then the two are semantically associated and merged to form an intermediate representation set that represents the complete data flow chain.

5. The cross-language source code auditing method based on deep learning as described in claim 4, characterized in that: Generating the structured corpus includes: Based on the field types and context dependencies in the intermediate representation set, and according to the predefined node type-template mapping table, the corresponding natural language template is selected from the pre-set multi-level natural language template library to fill in placeholders and generate a preliminary structured description. The preliminary structured description is semantically completed and logically reorganized according to variable dependencies and control flow order to obtain a data flow semantic description with consistent structure. Based on the semantic description of the data flow, and using a pre-built vulnerability remediation pattern knowledge base, a remediation path description is generated synchronously for each danger convergence point. The remediation path description is used to characterize the key code locations and processing order involved in the remediation operation.

6. The cross-language source code auditing method based on deep learning as described in claim 5, characterized in that: The hierarchical suggestion strategy includes: Basic instruction information used to define the scope of the analysis task; Used to provide contextual information for providing a semantic description of the data stream to be analyzed; Reasoning constraint information used to constrain vulnerability determination logic; The hierarchical prompting strategy uses a structured corpus as the sole input to generate language analysis results that include vulnerability types, descriptions of hazard convergence points, and descriptions of remediation paths.

7. The cross-language source code auditing method based on deep learning as described in claim 6, characterized in that: The verification of the analysis results based on the consistency of the repair paths across different languages ​​includes: For the same vulnerability scenario, obtain the language analysis results in at least two different programming languages, and acquire the structured corpus and remediation path description for each language; The repair path description for the first programming language is combined with the structured corpus of the second programming language to construct a first cross-validation hint, which is then input into the large language model to obtain a first verification repair description for the second programming language. The repair path description for the second programming language is combined with the structured corpus of the first programming language to construct a second cross-validation hint, which is then input into the large language model to obtain a second verification repair description for the first programming language. A first similarity score is obtained by calculating the semantic similarity between the first verification repair description and the original repair path description in the second programming language, and a second similarity score is obtained by calculating the semantic similarity between the second verification repair description and the original repair path description in the first programming language. When both the first similarity score and the second similarity score are higher than the preset similarity threshold, it is determined that the cross-language analysis results of the vulnerability scenario are consistent, and the language analysis results are output as the final audit result. When any similarity score is lower than the preset similarity threshold, the structured corpora of the first and second programming languages, the repair path description, and the corresponding verification repair description are merged to construct an arbitration prompt, which is input into the large language model for conflict resolution. The arbitration-resolved repair path description is output, and the language analysis result is updated based on the arbitration-resolved repair path description. Finally, the cross-language source code audit result is output.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the deep learning-based cross-language source code auditing method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the deep learning-based cross-language source code auditing method as described in any one of claims 1 to 7.

Images