Method for synchronizing multilingual code specifications with security vulnerability scans

Abstract

This application provides a method for simultaneous scanning of multilingual code standards and security vulnerabilities, comprising: Step 1, performing cross-language syntax adaptation and syntax tree feature entropy extraction on a multilingual code set to generate a multilingual code syntax tree feature set; Step 2, constructing a vulnerability feature belief propagation network based on known vulnerability samples and a code standard library; Step 3, inputting the multilingual code syntax tree feature set into the vulnerability feature belief propagation network to simultaneously perform code standard compliance verification and security vulnerability detection, thereby generating scan results; Step 4, calculating a standard-vulnerability co-verification factor to correct missed scans and misjudgments in the scan results; Step 5, iteratively updating the vulnerability feature belief propagation network based on the corrected results to calibrate and eliminate biases in the scan results, thereby generating vulnerability risk classification and standard violation classification outputs. This solution features a shorter overall scanning cycle, better meeting the high-efficiency requirements of agile development of core systems.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and more specifically, to a method for simultaneously scanning multilingual code standards and security vulnerabilities. Background Technology

[0002] In the development of core systems in industries such as finance and the internet, multi-language mixed programming (e.g., Java for business logic, C++ for low-level interaction, and Python for scripting tools) has become the mainstream approach, with code sizes often exceeding tens of millions of lines. These systems must meet industry security standards (such as preventing SQL injection and memory overflow vulnerabilities) and conform to unified coding standards (such as variable naming and exception handling formats). Therefore, extremely high demands are placed on the synchronization and accuracy of security vulnerability detection and coding standard verification for multi-language code, in order to adapt to the actual needs of rapid iterative development and proactive risk prevention.

[0003] In existing technologies, vulnerability and code standard checks for multi-language code often employ a phased processing strategy. Vulnerability detection typically relies on a pre-defined single-language vulnerability feature library, identifying known vulnerability types by statically matching grammatical patterns in code snippets. Meanwhile, code standard verification separately calls language-specific syntax analysis tools to perform isolated checks on code structure, comment integrity, and other aspects based on fixed format rules.

[0004] In existing solutions of this type, on the one hand, the serial processing logic of vulnerability detection and specification verification significantly prolongs the overall scanning cycle, making it difficult to adapt to the high-efficiency requirements of agile development; on the other hand, when the two are executed independently, no correlation analysis mechanism between vulnerabilities and specifications is established, which can easily lead to missed detections due to ignoring the implicit relationship between specification violations and vulnerabilities, or to misjudgments due to the lack of cross-validation; at the same time, the detection logic of existing solutions is mostly based on static rules, which cannot dynamically optimize the identification capability based on historical scan results, making it difficult to cope with the constantly emerging new vulnerability forms and updated coding specification requirements in multi-language code. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method for simultaneously scanning multilingual code standards and security vulnerabilities, thereby at least mitigating the aforementioned technical issues.

[0006] The technical solutions provided in this application are as follows:

[0007] This application provides a method for simultaneously scanning multilingual code standards and security vulnerabilities, which includes:

[0008] Step 1: Perform cross-language syntax adaptation and syntax tree feature entropy extraction on the multilingual code set to generate a multilingual code syntax tree feature set;

[0009] Step 2: Based on known vulnerability samples and code style libraries, construct a vulnerability feature belief propagation network;

[0010] Step 3: Input the multi-language code syntax tree feature set into the vulnerability feature belief propagation network to simultaneously perform code style compliance verification and security vulnerability detection, thereby generating scan results;

[0011] Step 4: Calculate the specification-vulnerability co-verification factor to correct for missed and false positives in the scan results.

[0012] Step 5: Iteratively update the vulnerability feature confidence propagation network based on the correction results to calibrate and eliminate biases in the scan results, thereby generating vulnerability risk classification and specification violation classification outputs.

[0013] The technical solution in this application has the following technical advantages:

[0014] This solution inputs the feature set of multilingual code syntax trees into the vulnerability feature confidence propagation network, simultaneously executing code style compliance verification and security vulnerability detection. These two types of checks are performed in parallel through the same network, eliminating the need for phased waiting and resulting in a shorter overall scanning cycle, better suited to the high-efficiency requirements of agile development of core systems. This solution establishes a correlation between the two types of checks through simultaneous execution, ensuring that vulnerability and style issue analysis are linked within the same technical framework. Furthermore, by calculating style-vulnerability co-verification factors, the scan results are corrected for missed detections and false positives. Compared to traditional isolated checks lacking cross-validation, this approach more comprehensively identifies implicit correlations, resulting in a relatively lower probability of missed or false positives. This solution iteratively updates the vulnerability feature confidence propagation network based on the corrected results, allowing the network's detection logic to continuously optimize with historical corrections, rather than remaining fixed like traditional static rules. Therefore, it has a stronger adaptability to emerging new vulnerability types and updated coding style requirements in multilingual code, maintaining high scanning effectiveness over the long term. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a method for simultaneously scanning multilingual code standards and security vulnerabilities according to an embodiment of this application.

[0016] Figure 2 This application provides a schematic diagram of the structure of a device for simultaneously scanning multilingual code specifications and security vulnerabilities. Detailed Implementation

[0017] Figure 1 This is a flowchart illustrating a method for simultaneously scanning multilingual code standards and security vulnerabilities according to an embodiment of this application. Figure 1 As shown, it includes:

[0018] Step 1: Perform cross-language syntax adaptation and syntax tree feature entropy extraction on the multilingual code set to generate a multilingual code syntax tree feature set;

[0019] Step 2: Based on known vulnerability samples and code style libraries, construct a vulnerability feature belief propagation network;

[0020] Step 3: Input the multi-language code syntax tree feature set into the vulnerability feature belief propagation network to simultaneously perform code style compliance verification and security vulnerability detection, thereby generating scan results;

[0021] Step 4: Calculate the specification-vulnerability co-verification factor to correct for missed and false positives in the scan results.

[0022] Step 5: Iteratively update the vulnerability feature confidence propagation network based on the correction results to calibrate and eliminate biases in the scan results, thereby generating vulnerability risk classification and specification violation classification outputs.

[0023] Optionally, step 1 involves performing cross-language syntax adaptation and syntax tree feature entropy extraction on the multilingual code set to generate a multilingual code syntax tree feature set, specifically including:

[0024] Step 11: Call the cross-language syntax deconstruction module to perform syntactic gene sequencing on the multi-language code set to identify the differences in syntactic representations between different programming languages;

[0025] Step 12: Construct a language adaptation rule graph based on grammatical representation differences, and transform the adaptation graph into executable dynamic adaptation logic through rule distillation.

[0026] Step 13: Based on dynamic adaptation logic, generate a unified abstract syntax tree containing syntax gene tags, where syntax gene tags are used to record the original language features of code snippets;

[0027] Step 14: Perform hierarchical deconstruction of node features on the unified abstract syntax tree to extract the syntactic relation entropy, type dependency entropy and execution path entropy of the nodes, and generate composite syntax tree feature entropy accordingly;

[0028] Step 15: Associate and map the feature entropy of the composite syntax tree with the syntax gene markers to construct a multilingual code syntax tree feature set.

[0029] Preferably, the specific implementation process of step 11 is as follows: The cross-language syntax deconstruction module is invoked to scan the multi-language code set line by line, extracting basic syntax units such as syntax keywords, expression structures, and statement block separators for each programming language to form a syntax unit set. Syntax gene sequencing is performed on the syntax unit set, decomposing the syntax rules of each language into the smallest indivisible "syntax gene fragments," where syntax gene fragments include keyword genes (such as "class" in Java and "def" in Python), structure genes (such as "{}" code blocks in C++ and indented code blocks in Go), and type genes (such as explicit type declarations in strongly typed languages ​​and implicit type conversion rules in weakly typed languages). By constructing a syntax gene comparison matrix (row dimension representing programming language type, column dimension representing syntax gene fragment type, and matrix elements representing the frequency of occurrence of the corresponding syntax gene fragment in that language), the overlap and difference of syntax gene fragments between different languages ​​are calculated, identifying syntactic representation differences used to distinguish multi-language characteristics, such as the variable no-declaration gene unique to dynamically typed languages ​​and the higher-order function gene unique to functional languages.

[0030] Preferably, in one scenario, step 12 is specifically implemented as follows: Based on the differences in grammatical representations, a three-dimensional language adaptation rule graph is constructed. The nodes of this graph are grammatical gene fragments, the edges are the mapping relationships between grammatical gene fragments in different languages, and the edge weights are the mapping confidence (obtained based on historical cross-language conversion case statistics). For mapping rules with conflicts in the graph (such as the same grammatical function having multiple implementations in different languages), rule distillation technology is used for optimization: First, the mapping rules are ranked by importance using a decision tree algorithm, retaining the core rules that have a greater impact on cross-language grammatical conversion; then, the grammar parsing process in different language environments is simulated using an adversarial generative network to verify the validity of the rules; finally, the verified rules are transformed into executable dynamic adaptation logic. This dynamic adaptation logic includes a condition judgment module (used to identify the language type of the current code), a gene replacement module (used to replace grammatical gene fragments according to the mapping rules), and a context verification module (used to ensure the consistency of the syntax of the replaced code). The output of the dynamic adaptation logic is a standardized intermediate grammar representation.

[0031] Preferably, in the specific technical implementation of step 13: dynamic adaptation logic is applied to the syntax parsing process of multi-language code sets, and syntax gene replacement and recombination are performed on code fragments of each language. During the generation of the unified abstract syntax tree, a syntax gene marker is added to each syntax node. This syntax gene marker consists of three parts: the original language identifier (e.g., "JAVA", "PYTHON"), the syntax gene fragment ID (corresponding one-to-one with the syntax gene fragments in step 11), and the language characteristic coefficient (used to quantify the degree to which the node is affected by the original language characteristics). The hierarchical structure of the unified abstract syntax tree is constructed using neutral syntax rules, such as uniformly representing the loop structure of all languages ​​as a combination of three nodes: "loop condition - loop body - iterator," while preserving the original language features of each node through the syntax gene marker. After generating the unified abstract syntax tree, a syntax consistency checker checks whether the parent-child and sibling relationships of the nodes in the tree conform to the neutral syntax rules. For nodes that do not conform, the dynamic adaptation logic is called for secondary adjustments until a unified abstract syntax tree with a complete structure and syntax gene markers is generated.

[0032] Preferably, the specific implementation process of step 15 is as follows: Obtain the feature entropy of the composite syntax tree (including the fusion result of syntax relation entropy, type dependency entropy, and execution path entropy), and establish an association mapping table with the syntax gene markers in the unified abstract syntax tree generated in step 13. The row dimension of the association mapping table is the node ID of the unified abstract syntax tree, and the column dimension includes three fields: "composite syntax tree feature entropy value", "syntax gene marker", and "node position information in the original code". Perform feature aggregation on the association mapping table, and perform weighted summation of the feature entropy values ​​of nodes belonging to the same code segment (the weight is the node's contribution to the semantics of the code segment) to obtain the composite feature entropy at the code segment level. Combine the aggregated composite feature entropy with the corresponding syntax gene marker to form the basic unit of the multilingual code syntax tree feature set. Finally, construct a feature indexing mechanism, using the original language identifier in the syntax gene marker as the first-level index and the numerical range of the composite feature entropy as the second-level index, to achieve efficient storage and querying of the multilingual code syntax tree feature set. This feature set can be directly used for subsequent vulnerability detection and specification verification processes.

[0033] Optionally, step 14 involves performing a hierarchical deconstruction of node features on the unified abstract syntax tree to extract the syntactic relation entropy, type dependency entropy, and execution path entropy of the nodes, and generating composite syntax tree feature entropy accordingly. This specifically includes:

[0034] Step 141: Using the nodes of the unified abstract syntax tree as the center, construct the grammatical neighborhood network of the nodes and count the frequency and distribution pattern of different grammatical relations in the grammatical neighborhood network, and use the distribution entropy value of the grammatical relations as the grammatical relation entropy.

[0035] Step 142: Perform hierarchical destructuring of the type dependency layer on the nodes of the unified abstract syntax tree to parse the variable types, function return value types and parameter types involved in the nodes and construct type dependency chains accordingly. Calculate the distribution entropy value of type dependency as type dependency entropy by statistically analyzing the conversion probability distribution between different types on the type dependency chain.

[0036] Step 143: Perform hierarchical deconstruction of the execution path layer of the nodes of the unified abstract syntax tree to extract the execution path set of the nodes under different branch conditions and calculate the path length distribution entropy and the branch trigger probability distribution entropy respectively. Then, fuse the path length distribution entropy and the branch trigger probability distribution entropy to generate the execution path entropy.

[0037] Step 144: Weight the distribution of syntactic relation entropy, type dependency entropy, and execution path entropy, and then normalize the sum to generate the feature entropy of the composite syntax tree.

[0038] Preferably, the specific implementation process of step 141 is as follows: Taking each node in the unified abstract syntax tree as the center, traverse the parent node, direct child nodes, indirect child nodes (depth of 3 levels), and sibling nodes of that node to construct a syntax neighborhood network containing "node-relationship-node" triples. The relation types in the syntax neighborhood network include four categories: inheritance (such as class inheritance), call relationship (such as function call), containment relationship (such as code block containment statement), and dependency relationship (such as variable dependency). Count the occurrence frequency of the four types of relations in the syntax neighborhood network to form a relation frequency vector (dimension 4, element value is the number of times the corresponding relation occurs). Calculate the distribution entropy value based on the relation frequency vector: First, normalize the frequency vector to a probability distribution (each element value divided by the total frequency), and then obtain the distribution entropy value of the syntax relation using the entropy calculation formula (H=-Σp_ilogp_i). This value is the syntax relation entropy. The syntax relation entropy is used to quantify the complexity of the syntax structure surrounding the node; the higher the value, the more diverse the syntax relations involved in the node.

[0039] Preferably, in the specific technical implementation of step 142: Type dependency layer deconstruction is performed on the nodes of the unified abstract syntax tree, parsing the variable declaration statements, function definition statements, and parameter lists associated with the nodes, extracting variable types (such as int, String), function return value types (such as void, List), and parameter types (such as int[], Map), forming a type set. Using the execution logic of the nodes as a guide, a type dependency chain is constructed: the starting node is the input type, subsequent nodes are intermediate types after operation / conversion, and the ending node is the output type. Adjacent types in the chain are connected by operators (such as type casting, implicit conversion, and assignment). The number of conversions for each pair of adjacent types in the type dependency chain is counted, and a type conversion matrix is ​​constructed (rows and columns are elements in the type set, and matrix elements are the number of times the row type is converted to the column type). The type conversion matrix is ​​normalized into a conversion probability matrix (element value divided by the total number of conversions in that row), and the distribution entropy value (H=-ΣΣp_ijlogp_ij) is calculated based on the probability matrix. This value is the type dependency entropy. The type dependency entropy is used to characterize the uncertainty of type conversion; a higher value indicates a more complex type conversion path.

[0040] The formula H = -ΣΣp_ijlogp_ij is essentially a combination of probability statistics and entropy calculation to transform the discrete and diverse type conversion behaviors in multi-language code into a quantifiable uncertainty index (type-dependent entropy H).

[0041] First, use a type conversion matrix (row i is the original type, column j is the target type) to sort out all conversion scenarios and ensure that the cross-type and cross-language conversion needs of multi-language mixed programming are covered;

[0042] Then, p_ij is used to convert the number of transformations into probabilities, eliminating the interference of the difference in the total number of transformations on the quantization results (e.g., 2 out of 10 transformations and 20 out of 100 transformations both have a probability of 0.2, which can be compared uniformly).

[0043] Finally, the entropy value is calculated by -ΣΣp_ijlogp_ij to highlight the impact weight of rare conversions and more accurately capture the type conversion risk points that are prone to vulnerabilities in multi-language code.

[0044] The final generated type dependency entropy H is merged with the syntax relation entropy and execution path entropy to form a composite syntax tree feature entropy, which provides more accurate type dimension feature support for the vulnerability-specification synchronous scanning in step 3, and solves the technical pain point of difficulty in quantifying multi-language type conversion features in traditional scanning.

[0045] The above formula is the core operation for calculating type dependency entropy in step 142. It quantifies the uncertainty of type conversion in code snippets, taking into account the type conversion characteristics of multi-language code (such as mixed programming of Java, C++, Python, etc.). The physical meaning of each letter, combined with specific scenarios, is explained below:

[0046] 1.H: Type Dependency Entropy

[0047] Type dependency entropy is the result of this formula. In this method scenario, its physical meaning is a quantitative indicator of the uncertainty of type conversion behavior in multilingual code snippets.

[0048] Specifically, the value of H directly reflects the complexity of the conversion paths between variable types, function parameter types, and return value types in the code: the higher the H value, the more diverse the type conversion paths and the more complex the conversion logic in the code (such as frequent implicit type conversions in the weakly typed language Python, or parent-child class type conversions in polymorphic scenarios in the strongly typed language C++); the lower the H value, the simpler the type conversion path and the simpler the logic (such as fixed explicit conversions of basic types in Java).

[0049] This metric is ultimately used to generate the feature entropy of the compound syntax tree, providing type-dimensional feature support for subsequent vulnerability feature matching (such as memory out-of-bounds vulnerability detection caused by type mismatch) and specification verification (such as violation detection of type conversion without compatibility judgment).

[0050] 2. ΣΣ: Double summation operator

[0051] In this scenario, ΣΣ represents summing all elements in the type conversion matrix, which physically means covering all possible combinations of type conversions in the code snippet.

[0052] Specifically, in step 142, a type conversion matrix is ​​first constructed (the row dimension represents the original type, the column dimension represents the target type, and the matrix elements represent the number of times the original type is converted to the target type). ΣΣ means that each row of the matrix is ​​traversed first (all original types, corresponding to the range of values ​​of index i), and then each column in each row is traversed (all target types corresponding to the original type, corresponding to the range of values ​​of index j). This ensures that all conversion combinations of original type i → target type j are included in the calculation, avoiding the omission of the impact of certain conversions on uncertainty (such as different conversion scenarios such as int → long long → String in Java).

[0053] 3. p_ij: Conversion probability from primitive type i to target type j

[0054] p_ij is the core variable in the formula. In this scenario, its physical meaning is the probability value of converting the original type i to the target type j in the multilingual code snippet, where:

[0055] The meaning and range of the subscript 'i': It represents the row index of the type conversion matrix, corresponding to the original type in the code (i.e., the type before conversion), and its range is the multi-language type set S. This set S covers all types that can be used as conversion sources in the currently scanned multi-language code set, including two categories: ① Multi-language built-in basic types (such as Java's int and String, C++'s std::string and int*, and Python's list and dict); ② Multi-language custom business types (such as Java's User class, C++'s DataInfo struct, and Python's BusinessData class decorated with @dataclass). For example, if the code contains Java's int, Python's list, and C++'s std::vector, then i can correspond to these three original types respectively, i.e., i∈{Java_int, Python_list, C++_vector}.

[0056] The meaning and range of the subscript j: It represents the column index of the type conversion matrix, corresponding to the target type in the code (i.e., the converted type). Its range is completely consistent with the range of the original type i, i.e., j ∈ the multilingual type set S. This is because type conversion in multilingual code can only be performed between types supported by the code; there is no situation where the original type comes from S and the target type exceeds S (e.g., Java's int cannot be converted to an undefined UnknownType in the code). For example, when i is Java_int, j can take values ​​from all types in S, such as Java_String, Python_list (if the code supports cross-language type conversion), and C++_vector.

[0057] The value of p_ij is obtained by dividing the number of conversions from the original type i to the target type j in the type conversion matrix by the sum of all conversions of the original type i (i.e., p_ij = number of conversions from type i to j / total number of conversions of type i), and the value range is [0,1].

[0058] For example, if the Java_int type undergoes 100 conversions in the code (including 20 to Java_long, 30 to Python_str, and 50 to C++_int), then p_Java_int→Java_long = 20 / 100 = 0.2, meaning the conversion probability of Java_int to Java_long is 0.2; p_Java_int→Python_str = 30 / 100 = 0.3, meaning the conversion probability of Java_int to Python_str is 0.3.

[0059] 4. log: Logarithmic operator

[0060] In this scenario, log represents the logarithmic operation with base 2 or the natural base (e) (the two bases only affect the numerical range of the entropy value and do not change the physical meaning of quantifying uncertainty). Its physical meaning is to convert the linear relationship of the conversion probability into a logarithmic relationship, amplifying the contribution of low-probability conversion to uncertainty.

[0061] Specifically, when p_ij is small (e.g., a certain type of conversion rarely occurs in the code, such as Python_str→C++_char[] being uncommon in cross-language code), the absolute value of logp_ij is large (and negative), which becomes positive after multiplying by the negative sign, making the contribution of this type of low-probability conversion to H (type-dependent entropy) more significant; when p_ij is large (e.g., Java_int→Java_long being common in strongly typed code), the absolute value of logp_ij is small, and its contribution to H is also small.

[0062] This approach can more accurately reflect the impact of rare type conversions on vulnerabilities / violations in multilingual code (e.g., rare conversions can easily lead to vulnerabilities due to developers neglecting compatibility checks).

[0063] Preferably, in one scenario, step 143 is specifically implemented as follows: The execution path layer of the unified abstract syntax tree is deconstructed. Control flow analysis is used to identify the branch statements (such as if-else, switch-case, and for loops) where the nodes are located. The complete execution path from entry to exit of each branch condition is extracted, forming an execution path set. The number of statements contained in each path in the execution path set (i.e., path length) is counted, and a path length distribution histogram is constructed (the horizontal axis represents the path length value, and the vertical axis represents the frequency of occurrence of paths of the corresponding length). After normalizing the histogram, the distribution entropy value is calculated to obtain the path length distribution entropy. Simultaneously, based on code coverage data (or static branch analysis), the trigger probability of each branch condition is determined, and a branch trigger probability vector is constructed (the dimension is the number of branches, and the element value is the trigger probability of the corresponding branch). The distribution entropy value of this vector is calculated to obtain the branch trigger probability distribution entropy. A weighted average method is used to fuse the two entropy values ​​(the path length distribution entropy weight is 0.6, and the branch trigger probability distribution entropy weight is 0.4) to obtain the execution path entropy. Execution path entropy is used to quantify the diversity of node execution processes; a higher value indicates a more complex path branch.

[0064] Preferably, the specific implementation process of step 144 is as follows: Obtain the syntax relation entropy generated in step 141, the type dependency entropy generated in step 142, and the execution path entropy generated in step 143. Assign weights to the three entropy values ​​based on the characteristics of multi-language code: for strongly typed language code snippets, the weight of the type dependency entropy is 0.4, the weight of the syntax relation entropy is 0.3, and the weight of the execution path entropy is 0.3; for weakly typed language code snippets, the weight of the type dependency entropy is 0.2, the weight of the syntax relation entropy is 0.4, and the weight of the execution path entropy is 0.4 (the weight values ​​can be dynamically adjusted according to the actual language type). The three entropy values ​​are weighted and summed to obtain the initial composite entropy value. The initial composite entropy value is mapped to the [0,1] interval (using the formula: normalized value = (initial value - minimum value) / (maximum value - minimum value), where the maximum and minimum values ​​are obtained based on statistics from the historical code repository), generating the composite syntax tree feature entropy. The composite syntax tree feature entropy comprehensively reflects the syntactic structure, type conversion, and execution path characteristics of the nodes and can be directly used in the subsequent matching process with vulnerability features and specification features.

[0065] Optionally, step 2, based on known vulnerability samples and code style libraries, constructs a vulnerability feature belief propagation network, specifically including:

[0066] Step 21: Call the vulnerability feature distillation module to perform code slicing and parsing on known vulnerability samples to extract the syntax pattern features, execution path features and data flow features that trigger the vulnerability, and generate a vulnerability feature gene library accordingly;

[0067] Step 22: The code specification library is parsed through the specification feature extraction module, and the specification requirements described in natural language are transformed into computable syntactic constraint features, semantic constraint features and temporal constraint features to construct a specification feature rule chain;

[0068] Step 23: Calculate the vulnerability association confidence of each vulnerability feature in the vulnerability feature gene library and the compliance verification confidence of each normative feature in the normative feature rule chain, respectively;

[0069] Step 24: Analyze the collaborative association patterns of vulnerability features and specification features to obtain the cross-modal feature association strength, and calculate the mutual information gain between vulnerability features and specification features based on the cross-modal feature association strength, so as to construct a vulnerability feature belief propagation network topology with vulnerability features as nodes and mutual information gain as edge weights;

[0070] Step 25: Inject the vulnerability association confidence and compliance verification confidence into the vulnerability feature confidence propagation network topology to obtain the constructed vulnerability feature confidence propagation network.

[0071] Preferably, in the specific technical implementation of step 22: First, the scope of the code specification library is determined, prioritizing the selection of industry code specifications and multilingual general specifications corresponding to the target application scenario, forming a target code specification library that integrates industry characteristics and language characteristics (the specific specification items in the target code specification library can be added or deleted according to scenario requirements; for example, the financial scenario requires additional sensitive data encryption transmission specifications, and the embedded scenario requires memory resource efficient utilization specifications). Natural language parsing is performed on the target code specification library through the specification feature extraction module: NLP (Natural Language Processing) technology is used to perform word segmentation, part-of-speech tagging, and entity recognition on the specification clauses, extracting the core elements in the specification requirements (such as the business meaning of variable naming in the context of variable naming, and the medical data encryption algorithm in the context of medical data transmission encryption), forming a set of core specification elements. The core elements of the specification are transformed into computable features: For example, the requirement that variable names must include business meaning is transformed into syntactic constraint features (defining naming format regular expressions, such as a combination of business identifier + variable type + purpose; specific regular expressions can be adjusted according to the scenario, for example: bizType_varType_func in the financial scenario, medicalData_varType_usage in the medical scenario), forming a list of syntactic constraint features; for example, the requirement that sensitive data transmission must be encrypted before transmission is transformed into semantic constraint features (defining sensitive data identification rules and encrypted function call verification rules; sensitive data types can be expanded according to the scenario, for example: bank card number and ID card number in the financial scenario, medical record number and patient name in the medical scenario), forming a list of semantic constraint features; for example, the requirement that log printing must be executed at the function entry / exit point is transformed into temporal constraint features (defining the order rules for log printing in the function execution flow; log printing nodes can be added or deleted according to the scenario, for example: additional log printing rules for key business logic nodes are required in high-concurrency scenarios), forming a list of temporal constraint features. The three feature lists are linked together according to the structure of standard clause ID-feature type-feature verification rule-violation consequence to construct a standard feature rule chain. This standard feature rule chain can be directly used for the calculation of subsequent compliance verification confidence. Among them, the standard entries in the target code standard library and the specific parameters of the feature verification rules are not uniquely limited and can be flexibly set according to the industry regulatory requirements and code operation environment requirements of the target application scenario.

[0072] Preferably, in a scenario, step 23 is specifically implemented as follows: First, the vulnerability feature gene library generated in step 21 and the normative feature rule chain generated in step 22 are obtained, respectively, as the basis for calculating vulnerability association confidence and compliance verification confidence. When calculating vulnerability association confidence, a preset number of historical vulnerability samples containing the corresponding vulnerability features are selected as the positive example set, and a preset number of normal code samples (from the historical compliant code library of the target application scenario) without the vulnerability feature are selected as the negative example set (the preset number can be adjusted according to the feature stability requirements; for example, 500-1000 samples are selected for scenarios with a small amount of code, and 1000-3000 samples are selected for scenarios with a large amount of code); the percentage of occurrences of the vulnerability feature in the positive example set is counted (positive example rate; for example, a certain SQL injection syntax pattern feature appears in 85%-90% of the positive example set in the financial scenario). In the internet scenario, positive examples account for 75%-80% of the vulnerability features. The percentage of times this vulnerability feature is misidentified as a vulnerability feature in the negative example set is calculated (false positive rate, example: the false positive rate for this feature in the financial scenario is 1%-3% in the negative example set, and the false positive rate in the internet scenario is 2%-5%). The vulnerability association confidence score of this vulnerability feature is calculated by vulnerability association confidence score = positive example rate / (positive example rate + false positive rate) (example: the calculation result is 96.6%-97.8% in the financial scenario and 93.8%-94.1% in the internet scenario). This value is then bound to the vulnerability feature gene library and updated. When calculating the compliance verification confidence score, a preset number of compliant code samples conforming to the corresponding specification features are selected as the compliance set, and a preset number of non-compliant code samples violating the specification features are selected as the non-compliance set (the preset number setting logic is consistent with the number of samples for vulnerability-related confidence scores). The percentage of occurrences of the specification feature in the compliance set is calculated (compliance rate, example: sensitive data encryption specification features appear 90%-95% in the financial scenario compliance set and 88%-92% in the medical scenario compliance set). The percentage of times the specification feature is misidentified as a compliance feature in the non-compliance set is calculated (false positive rate, example: the false positive rate of this feature in the financial scenario non-compliance set). The false positive rate is 2%-4%, with a 3%-5% misidentification rate in the medical scenario. The compliance verification confidence score of the regulatory feature is calculated as compliance rate / (compliance rate + false positive rate) (example: 95.7%-96.9% for the financial scenario and 94.6%-95.7% for the medical scenario). This value is then bound to the regulatory feature rule chain and updated. The preset quantities of positive examples, negative examples, compliance sets, and violation sets, as well as the specific numerical ranges of the positive rate, compliance rate, and false positive rate, are not uniquely limited and can be flexibly set according to the sample accumulation and feature discrimination requirements of the target application scenario.

[0073] Preferably, the specific implementation process of step 25 is as follows: First, obtain the vulnerability feature confidence propagation network topology (with vulnerability features as nodes and mutual information gain as edge weights) generated in step 24 and the vulnerability association confidence and compliance verification confidence calculated in step 23. Perform confidence injection: Inject the vulnerability association confidence of each vulnerability feature in the vulnerability feature gene library into the corresponding vulnerability feature node in the vulnerability feature confidence propagation network topology one by one (example: inject 96.6%-97.8% vulnerability association confidence into the SQL concatenation variable vulnerability feature node in the financial scenario, and inject 92.3%-94.5% vulnerability association confidence into the array subscript without verification vulnerability feature node in the industrial scenario), as the basic confidence attribute of the node; Inject the compliance verification confidence of each normative feature in the normative feature rule chain into the vulnerability feature node in the topology associated with the normative feature (example: inject the compliance verification confidence of the normative feature of unencrypted sensitive data in the financial scenario into the data leakage vulnerability feature node associated with the normative feature; inject the compliance verification confidence of the normative feature of unde-identified medical record data in the medical scenario into the privacy leakage vulnerability feature node associated with the normative feature), as the association confidence attribute of the node. After injection, perform network validity verification: check whether the confidence value of all nodes is in the range [0,1] (if it exceeds, it is truncated to [0,1] and the correction logic can be fine-tuned according to the scenario. For example, in high-precision scenarios, retain 4 decimal places, and in normal scenarios, retain 2 decimal places). Test the confidence propagation between any two vulnerability feature nodes (calculate the confidence after propagation through the mutual information gain of edge weights. The propagation attenuation coefficient can be set according to the scenario. For example, the attenuation coefficient between strongly associated nodes is 0.1-0.3, and the attenuation coefficient between weakly associated nodes is 0.5-0.7). Ensure that the propagation result conforms to the feature association logic (for example, the confidence attenuation of the propagation from the loop without boundary check node to the buffer overflow node is controlled at 10%-30%, and the confidence attenuation of the propagation from the node with missing permission verification to the node with unauthorized access is controlled at 5%-20%). After verification, a complete vulnerability feature confidence propagation network is generated. This network can be directly used for synchronous scanning of the multilingual code syntax tree feature set in step 3. The number of decimal places retained for node confidence, the attenuation coefficient of confidence propagation, and the reasonable attenuation range of propagation results are not uniquely limited and can be flexibly set according to the scanning accuracy requirements and feature association strength requirements of the target application scenario.

[0074] Optionally, step 24 involves analyzing the collaborative association patterns between vulnerability features and canonical features to obtain the cross-modal feature association strength, and calculating the mutual information gain between vulnerability features and canonical features based on the cross-modal feature association strength, in order to construct a vulnerability feature belief propagation network topology with vulnerability features as nodes and mutual information gain as edge weights. Specifically, this includes:

[0075] Step 241: Modal attribute annotation is performed on vulnerability features and specification features to construct a cross-modal feature co-occurrence matrix;

[0076] Step 242: Calculate the original mutual information values ​​between features based on the cross-modal feature co-occurrence matrix, and normalize the original mutual information values ​​to obtain the cross-modal feature association strength;

[0077] Step 243: Perform cluster analysis on the cross-modal feature association strength to obtain multiple feature clusters, and extract the association paths between features within each feature cluster to construct a cross-modal feature association subgraph with modal attribute annotation;

[0078] Step 244: Perform topology fusion on the cross-modal feature association subgraph to calculate the mutual information gain between the vulnerability features when they are nodes and assign it as the edge weight between the nodes to obtain the vulnerability feature belief propagation network topology.

[0079] Preferably, in the specific technical implementation of step 242: based on the cross-modal feature co-occurrence matrix generated in step 241, firstly, the total number of rows (total number of vulnerability features, denoted as A), the total number of columns (total number of canonical features, denoted as B), and the sum of all elements (total number of occurrences, denoted as S) of the matrix are counted. The co-occurrence probability c(a,b) of each vulnerability feature a-canonical feature b pair is calculated as matrix element (a,b) / S (where a is the vulnerability feature index, ranging from 1 to A; b is the canonical feature index, ranging from 1 to B); the individual occurrence probability r(a) of vulnerability feature a is calculated as the sum of all elements in the a-th row of the matrix / S; the individual occurrence probability s(b) of canonical feature b is calculated as the sum of all elements in the b-th column of the matrix / S. The original mutual information value is calculated based on the above probability: the original mutual information value is calculated by accumulating [c(a,b)×log(c(a,b) / (r(a)×s(b)))] for all vulnerability features a and canonical features b (no mathematical formula, only textual description of the calculation logic), quantifying the degree of correlation between vulnerability features and canonical features. The higher the original mutual information value, the stronger the correlation between the two in the code snippet. For example, in financial scenarios, the original mutual information values ​​of the F2-R-buffer overflow vulnerability feature and the G2-C-array index unvalidated canonical feature are relatively high, because the latter often directly leads to the former. Then, normalization is performed on all original mutual information values: the maximum value among the original mutual information values ​​is selected as the benchmark value (denoted as Max_K), and each original mutual information value is divided by this benchmark value to obtain the cross-modal feature correlation strength (denoted as K(a,b)) with a value range between [0,1]. For example, if the maximum value of the original mutual information Max_K is 2.3, and the original mutual information value of a vulnerability feature a-canonical feature b pair is 1.84, then its cross-modal feature association strength K(a,b) = 1.84 / 2.3 = 0.8. This cross-modal feature association strength K(a,b) is directly used for the cluster analysis in step 243.

[0080] Preferably, in a given scenario, step 243 is specifically implemented as follows: using the cross-modal feature association strength generated in step 242 as input, an improved Louvain clustering algorithm is used to perform clustering analysis. The improvement of this algorithm compared to the traditional Louvain algorithm lies in the addition of a modality weight factor (risk modality weight denoted as α, combined modality weight denoted as β, α+β=1). The modality weight factor is set according to the target application scenario: for scenarios with extremely high security requirements, such as finance and healthcare, α is set to 0.6-0.7 (risk modality is more important); for ordinary internet business scenarios, α is set to 0.5-0.55 (more balanced modality weights). During clustering, the cross-modal feature association strength × modality weight factor is used as the clustering similarity criterion. Features with association strength higher than a preset threshold (e.g., 0.6 for financial scenarios, 0.5 for internet scenarios) are grouped into the same feature cluster, ultimately resulting in multiple feature clusters (each cluster contains 2-10 features to avoid clusters being too large or too small, affecting subsequent analysis). For each feature cluster, extract the association paths between all features: starting with the feature with the highest association strength, traverse the features within the cluster in descending order of association strength, forming association paths such as vulnerability feature → canonical feature → vulnerability feature or canonical feature → vulnerability feature → canonical feature. For example, the association path for a certain cluster might be F3-R-Unauthorized Access → G3-C-Missing Permission Verification → F4-R-Data Out-of-Bounds Access. Construct a cross-modal feature association subgraph with modal attribute annotations based on these association paths: the nodes of the subgraph represent vulnerability features and canonical features within the cluster, and each node is labeled with its corresponding modal attribute (R or C); the edges of the subgraph represent the cross-modal feature association strength between features, with the edge thickness corresponding to the magnitude of the association strength. This cross-modal feature association subgraph is directly used for topology fusion in step 244.

[0081] Preferably, the specific implementation process of step 244 is as follows: First, formulate topology fusion rules for cross-modal feature association subgraphs. The rules include core path priority retention (retaining the top 30% of association paths with the highest association strength to avoid redundant paths affecting network efficiency), modal complementarity priority fusion (prioritizing the fusion of subgraphs with a high proportion of risk modal features and a high proportion of merged modal features to ensure modal balance of the fused subgraphs), and scenario adaptation filtering (filtering subgraphs that are irrelevant to the target scenario, such as filtering subgraphs containing Web form validation specification features in industrial control scenarios). Based on the above rules, perform topology fusion on all cross-modal feature association subgraphs generated in step 243: merge subgraphs that have common features (such as subgraphs A and B both containing G3-C-authorization verification missing specification features), and calculate the mutual information gain between vulnerability feature nodes after fusion—mutual information gain = the sum of cross-modal feature association strengths of the two vulnerability features indirectly associated through specification features after fusion - the direct association strength of the two vulnerability features before fusion (if there is no direct association before fusion, the direct association strength is recorded as 0). For example, before fusion, vulnerability features F3 and F4 have no direct association (strength 0). After fusion, the sum of their indirect association strengths through G3 is 0.8 + 0.7 = 1.5, so their mutual information gain is 1.5. This mutual information gain is assigned as the edge weight between vulnerability feature nodes to construct an initial vulnerability feature confidence propagation network topology. The initial topology is then validated: the average clustering coefficient (reflecting the clustering degree of vulnerability feature nodes; in financial scenarios, the average clustering coefficient must be ≥0.7 to ensure the clustering of security-related vulnerability nodes) and the feature association path coverage rate (reflecting the cross-modal feature coverage ratio of the topology, which must be ≥90% to avoid missing key associations) are calculated. For topologies with coverage rates below the threshold, the path with the second-highest association strength is added; for topologies with abnormal clustering coefficients, excessively large feature clusters are split. After successful validation, a vulnerability feature confidence propagation network topology with vulnerability features as nodes and mutual information gain as edge weights is finally generated. This topology is directly used for confidence injection in step 25.

[0082] Optionally, step 3 involves inputting the multilingual code syntax tree feature set into the vulnerability feature confidence propagation network to simultaneously perform code style compliance verification and security vulnerability detection, thereby generating scan results. Specifically, this includes:

[0083] Step 31: Perform semantic similarity matching between the composite syntax tree feature entropy in the multilingual code syntax tree feature set and the node features of the vulnerability feature belief propagation network to generate a feature matching mapping table;

[0084] Step 32: Trigger the confidence propagation of the vulnerability feature confidence propagation network based on the feature matching mapping table, so as to calculate the joint confidence value of feature matching through the mutual information gain between nodes in the vulnerability feature confidence propagation network;

[0085] Step 33: Perform dual-channel verification on the joint confidence value: In the vulnerability detection channel, the vulnerability risk level of the code segment is determined based on the vulnerability association confidence level to obtain the joint confidence level of vulnerability risk; in the specification verification channel, the specification compliance degree of the code segment is determined based on the compliance verification confidence level to obtain the joint confidence level of specification risk.

[0086] Step 34: Based on the joint confidence of vulnerability risk and the joint confidence of regulatory risk, the feature association parsing module is used to identify the causal mapping relationship between vulnerability risk and regulatory violation, so as to generate scanning results containing the association labels between vulnerability risk features and regulatory violation features.

[0087] Preferably, the specific implementation process of step 31 is as follows: Obtain the multi-language code syntax tree feature set (including composite syntax tree feature entropy and syntax gene markers) and the vulnerability feature belief propagation network constructed in step 25 (including vulnerability feature nodes and node features), using both as the basic data for semantic similarity matching. Perform feature hierarchical deconstruction on the composite syntax tree feature entropy: decompose it into syntactic relation entropy components, type dependency entropy components, and execution path entropy components. Label each component with a corresponding weight coefficient (the weight is set according to the scenario characteristics; for example, in financial scenarios, the execution path entropy component is given a higher weight of 0.4-0.5 because path integrity affects the logic of fund security), forming a hierarchical feature entropy vector. Perform the same hierarchical deconstruction on each node feature of the vulnerability feature belief propagation network to obtain a node hierarchical feature vector (containing components that correspond one-to-one with the hierarchical feature entropy vector). An improved cosine similarity algorithm is used to calculate the matching degree: Traditional cosine similarity only calculates the angle between vectors. This method introduces a grammatical gene adaptation coefficient (value 0-1, with a matching coefficient of 0.9-1.0 for features within the same language and 0.6-0.8 for cross-language features; for example, the grammatical gene adaptation coefficient for Java and Python is set to 0.7). The final matching degree is obtained through the formula: Similarity = Cosine Similarity × Grammatical Gene Adaptation Coefficient (textual description logic). The matching degree of all composite syntax tree feature entropies and node features is recorded in the structure of Feature Entropy ID - Node ID - Matching Degree Value - Grammatical Gene Label. Records with matching degrees higher than the scenario threshold (0.75 for financial scenarios and 0.65 for internet scenarios) are selected to generate a feature matching mapping table. This mapping table directly serves as the input for triggering confidence propagation in step 32.

[0088] Preferably, in the specific technical implementation of step 33: a dual-channel parallel verification mechanism is initiated based on the joint confidence value of feature matching as the basic data. In the vulnerability detection channel, the calculated vulnerability association confidence score is used as the benchmark threshold (each vulnerability feature node is bound to the corresponding vulnerability association confidence score, such as the SQL injection node being bound to a benchmark threshold of 0.92). The joint confidence value is compared with the benchmark threshold: if the joint confidence value ≥ benchmark threshold × scenario risk coefficient (the coefficient for high-risk scenarios is 1.0, and for medium-risk scenarios it is 0.9), it is determined to be high-risk; if the joint confidence value is between benchmark threshold × 0.5 and benchmark threshold × scenario risk coefficient, it is determined to be medium-risk; otherwise, it is determined to be low-risk, forming a vulnerability risk level sequence. Weighted aggregation is performed on this sequence (the weight is the proportion of mutual information gain between nodes) to obtain the vulnerability risk joint confidence value (value ranges from 0 to 1, with higher values ​​indicating higher confidence in risk assessment). In the compliance verification channel, the compliance verification confidence score calculated in step 23 is used as the benchmark threshold (each compliance feature is bound to a corresponding compliance verification confidence score, such as a benchmark threshold of 0.95 for sensitive data encryption). The joint confidence value is compared with the benchmark threshold: if the joint confidence value ≥ benchmark threshold × scenario compliance coefficient (the coefficient is 1.0 for financial scenarios and 0.85 for ordinary scenarios), it is determined to be fully compliant; if the joint confidence value is between benchmark threshold × 0.6 and benchmark threshold × scenario compliance coefficient, it is determined to be partially compliant; otherwise, it is determined to be non-compliant, forming a compliance degree sequence. Weighted aggregation is performed on this sequence (the weight is the priority of the compliance feature in the rule chain) to obtain the joint confidence value of compliance risk (value ranges from 0 to 1, with higher values ​​indicating higher credibility of compliance judgment). The joint confidence value of vulnerability risk and the joint confidence value of compliance risk are used together as input data for the correlation analysis in step 34.

[0089] Preferably, in one scenario, step 34 is specifically implemented as follows: using the joint confidence value of vulnerability risk and the joint confidence value of normative risk generated in step 33 as input, the feature association parsing module is called to perform causal mapping relationship identification. First, a risk-compliance association strength matrix is ​​constructed: the matrix row dimension represents vulnerability risk features (specific features corresponding to high / medium / low risk), the column dimension represents normative violation features (specific features corresponding to non-compliance / partial compliance), and the element value at the intersection of rows and columns is the co-occurrence frequency of vulnerability risk features and normative violation features × mutual information gain (statistics derived from the cross-modal feature association strength in step 24). For example, in a financial scenario, the cross value between the high-risk SQL injection row and the sensitive data verification non-compliance column is 0.89, indicating a close association between the two. Based on this matrix, strong association pairs are extracted (element value ≥ scenario association threshold, set to 0.7 for financial scenarios and 0.6 for internet scenarios). Causal determination is performed on each strong association pair: the rule engine matches the preset causal determination rule base (including three types of rules: normative violation → vulnerability triggering → normative violation third-party factors causing co-occurrence of the two), and the causal direction is determined by combining the contextual semantics of the code snippet (such as function call order and variable passing relationship). For example, an array index not validated (standard violation) → buffer overflow (vulnerability risk) is determined to be a standard violation leading to vulnerability triggering. The causal direction, correlation strength value, and risk / compliance level are integrated into a correlation label (format: Vulnerability Feature ID - Standard Feature ID - Causal Direction - Correlation Strength), which is then appended to the corresponding feature entry in the scan results to generate scan results containing correlation labels. This scan result directly serves as the data source for extracting vulnerability-standard correlation pairs in step 41, ensuring that subsequent remediation processes can accurately locate correlation features.

[0090] Optionally, step 32, triggering the confidence propagation of the vulnerability feature confidence propagation network based on the feature matching mapping table, to calculate the joint confidence value of feature matching through the mutual information gain between nodes in the vulnerability feature confidence propagation network, specifically includes:

[0091] Step 321: Starting from each successfully matched feature node, initiate the confidence diffusion process of the vulnerability feature confidence propagation network to propagate the joint confidence value to adjacent nodes based on edge weights;

[0092] Step 322: Based on the mutual information gain between nodes in the vulnerability feature confidence propagation network, dynamically adjust the joint confidence value in the propagation process to generate the propagation confidence value, and perform a weighted summation of the propagation confidence values ​​corresponding to all associated nodes to obtain the joint confidence value of feature matching.

[0093] Preferably, the specific implementation process of step 321 is as follows: Obtain the feature matching mapping table generated in step 31 (containing records of feature entropy ID, node ID, and matching degree value), filter out records with matching degree values ​​higher than the scenario-based propagation threshold (set to 0.6 for financial scenarios and 0.5 for internet scenarios), and mark the vulnerability feature nodes corresponding to these records as initial activated nodes. Assign an initial joint confidence value to each initial activated node: Initial joint confidence value = matching degree value × node base confidence (node ​​base confidence is the vulnerability association confidence calculated in step 23). For example, for an initial activated node with a matching degree of 0.85 and a node base confidence of 0.92, its initial joint confidence value is 0.85 × 0.92 = 0.782. Start the confidence diffusion process of the vulnerability feature confidence propagation network: Starting from the initial activated node, propagate the joint confidence value to adjacent nodes in the order of directly adjacent nodes → indirectly adjacent nodes (directly adjacent refers to nodes connected by one edge, and indirectly adjacent refers to nodes connected by two or more edges) based on the mutual information gain between nodes (edge ​​weights calculated in step 24). Set a propagation depth threshold (default 3 layers, expandable to 4 layers in financial scenarios to capture deep correlations). When the propagation reaches the threshold layer or the node has no unpropagated adjacent nodes, stop the diffusion process of the initially activated node and generate a confidence propagation path table containing source node-target node-propagation direction-initial propagation value. This path table is directly used as the input basis for dynamic adjustment in step 322.

[0094] Preferably, in the specific technical implementation of step 322: based on the confidence propagation path table generated in step 321, the dynamic adjustment engine is called to correct the initial propagation value of each path. The correction logic introduces a distance attenuation coefficient and a scenario association weight: the distance attenuation coefficient decreases as the number of propagation layers increases (1.0 for layer 1, 0.8 for layer 2, 0.6 for layer 3, and 0.4 for layer 4), used to weaken the propagation impact of distant nodes; the scenario association weight is assigned according to the relevance of node characteristics to the business scenario (e.g., in a payment scenario, the weight of a node related to fund verification is 1.2, and the weight of a node related to log printing is 0.8). The propagation confidence value of a single path is obtained through the logic of propagation confidence value = initial propagation value × distance attenuation coefficient × scenario association weight (textual description calculation logic). A weighted summation is performed on all propagation confidence values ​​pointing to the same target node: the weight is the proportion of mutual information gain of the corresponding path (mutual information gain of a certain path ÷ sum of mutual information gains of all incoming paths of that node), to obtain the cumulative confidence value of the target node. If the same feature entropy matches multiple initial activation nodes, the cumulative confidence values ​​of all relevant target nodes are summed again to generate a joint confidence value for the feature match (values ​​range from 0 to 1, with higher values ​​indicating higher overall confidence in the feature match). For example, if a feature entropy matches two initial activation nodes, after propagation, the cumulative confidence values ​​obtained are 0.65 and 0.32, and the joint confidence value is 0.65 + 0.32 = 0.97. This joint confidence value is directly used as the input data for the dual-channel verification in step 33.

[0095] Optionally, step 4, calculating the specification-vulnerability co-verification factor, is used to correct for missed and false positives in the scan results, specifically including:

[0096] Step 41: Extract vulnerability-canonical association pairs from the scan results, call the historical collaborative verification database, retrieve historical verification records of the same vulnerability-canonical association pairs, and generate association pair verification feature vectors;

[0097] Step 42: Calculate the specification-vulnerability co-verification factor based on the correlation verification feature vector. This specification-vulnerability co-verification factor is obtained by fusing vulnerability detection accuracy, specification verification accuracy, and correlation matching rate, and is used to quantify the credibility of the scan results.

[0098] Step 43: For the association pairs whose specification-vulnerability co-verification factor is lower than the preset trust threshold, start the dynamic sandbox simulation mechanism to build a virtual execution environment for the code snippet and simulate the code behavior under different input scenarios to generate sandbox simulation results.

[0099] Step 44: Based on the sandbox simulation results, complete and mark the missing features in the scanning results, and perform noise reduction on the misjudged features to generate corrected results.

[0100] Preferably, the specific implementation process of step 41 is as follows: Obtain the scanning results generated in step 34 (including vulnerability risk features, specification violation features, and association tags), and extract vulnerability-specification association pairs from them: each association pair consists of a vulnerability feature ID-specification feature ID-causal direction triplet (e.g., V001-C002-specification violation leading to vulnerability). Call the historical collaborative verification database, which stores historical records of the same association pairs for the past 3 years (configurable). Each record contains a verification timestamp-vulnerability detection result-specification verification result-association determination result-final confirmation result field. Perform time decay weighting on the retrieved historical records according to the following weights: 1.0 for records of the past 6 months, 0.8 for records of 6-12 months, and 0.5 for records of 1-3 years, to generate an association pair verification feature vector: the vector dimensions include historical occurrence frequency (after weighting), vulnerability detection consistency rate (the proportion of historical results matching the final confirmation result), specification verification consistency rate, association matching rate, and average verification time. Each dimension value is normalized to the [0,1] range. For example, if a certain association pair appears 12 times in the past 6 months and the vulnerability detection consistency rate is 85%, then the corresponding vector components are 0.12 (frequency normalization) and 0.85. The verification feature vector of this association pair is directly used as the input data for calculating the co-verification factor in step 42.

[0101] Preferably, in the specific technical implementation of step 42: using the correlation verification feature vector generated in step 41 as the basic data, the three components of vulnerability detection consistency rate, specification verification consistency rate, and correlation relationship matching rate are extracted as core parameters. Scenario-specific weight coefficients are introduced: in the financial scenario, the correlation relationship matching rate weight is set to 0.4 (due to high compliance requirements), the vulnerability detection consistency rate weight is 0.35, and the specification verification consistency rate weight is 0.25; in the internet scenario, the vulnerability detection consistency rate weight is increased to 0.45, and the other two are 0.3 and 0.25 respectively. The final factor value (ranging from 0 to 1) is obtained through the logic of specification-vulnerability collaborative verification factor = vulnerability detection consistency rate × weight 1 + specification verification consistency rate × weight 2 + correlation relationship matching rate × weight 3 (textual description of the calculation logic). Simultaneously, a dynamic correction item is set: if the historical frequency of an association pair is less than 5 times (low-frequency association pair), the factor value is multiplied by a low-frequency correction coefficient of 0.9 (due to insufficient sample size reducing credibility); if the historical frequency of an association pair exceeds 100 times (high-frequency association pair), the factor value is multiplied by a high-frequency enhancement coefficient of 1.05 (due to sufficient sample size improving credibility). For example, in a financial scenario, the three consistency rates of a high-frequency association pair are 0.9, 0.85, and 0.88, respectively. Its co-validation factor is 0.9×0.35+0.85×0.25+0.88×0.4=0.315+0.2125+0.352=0.8795, which is directly used for threshold judgment in step 43.

[0102] Preferably, in a scenario, step 44 is specifically implemented as follows: Obtain the sandbox simulation results generated in step 43 (including vulnerability trigger points, specification violation points, and time-series execution trajectories) and the original scan results generated in step 34, and start the feature correction engine. Complete and mark missed features: Vulnerabilities / specification features confirmed to exist in the sandbox simulation results but not recorded in the original scan results are marked as missed features and labeled with a sandbox verification-trigger path (time-series trajectory fragment) tag (e.g., V003-Missing-Sandbox Verification: Buffer overflow is triggered when input value = 100). Reduce noise for misjudged features: Compare the sandbox results with the original scan results. If the originally marked vulnerability / specification feature does not appear in the sandbox simulation and there is no indirect correlation evidence, it is marked as a misjudged feature, and the basis for noise reduction is recorded (no matching item in the sandbox execution trajectory). Construct a correction result matrix: The matrix's row dimension is the code fragment ID, and the column dimension is the vulnerability feature correction set, specification feature correction set, and correlation correction set. The intersection of rows and columns records the corrected feature ID and correction type (missing feature completion / misjudgment deletion). For example, the matrix cells of code snippet S001 record the vulnerability feature correction set: {V003 (complete), V005 (delete)}; the standard feature correction set: {C001 (retain)}; and the association correction set: {V003-C002 (add)}. This correction result matrix directly serves as the data source for extracting deviation data in step 51, ensuring that the iterative update process can accurately locate the feature associations that need to be adjusted.

[0103] Optionally, step 43, for association pairs where the specification-vulnerability co-verification factor is lower than a preset trust threshold, initiates a dynamic sandbox simulation mechanism to construct a virtual execution environment for the code snippet and simulate code behavior under different input scenarios to generate sandbox simulation results, specifically including:

[0104] Step 431: Parse the parameter constraint boundaries of the code snippet based on the feature entropy of the compound syntax tree to construct a multi-dimensional test case set. This multi-dimensional test case set includes boundary value scenarios, outlier scenarios, and normal value scenarios. Each test case in the multi-dimensional test case set is labeled with the corresponding input scenario type and the associated specification-vulnerability association pair identifier.

[0105] Step 432: Call the containerized lightweight virtualization engine, build a virtual execution environment with resource isolation and network isolation based on the original development environment information of the code snippet, and restore the dependency library version, compilation parameters and environment variables of the code snippet in the virtual execution environment to build a dynamic sandbox;

[0106] Step 433: According to the priority order of test cases corresponding to outlier scenarios → test cases corresponding to boundary value scenarios → test cases corresponding to normal value scenarios, execute the code snippets of the test cases in the dynamic sandbox and capture the execution process of the code snippets in real time to record variable state changes, memory operation trajectories, and function call sequences, thereby generating a time-sequential execution trajectory;

[0107] Step 434: Determine the vulnerability trigger point and the violation point based on the time-series execution trajectory to generate sandbox simulation results.

[0108] Preferably, the specific implementation process of step 431 is as follows: Obtain the feature entropy of the compound syntax tree generated in step 15 (including syntax relation entropy, type dependency entropy, and execution path entropy), and parse the parameter constraint boundaries of the code segment based on the feature entropy of the compound syntax tree. During the parsing process, extract the variable type constraints (such as the value range of integer variables and the length limit of string variables) from the type dependency entropy and the branch condition constraints (such as the judgment threshold of if statements and the upper limit of the iteration number of loop statements) from the execution path entropy, and integrate them to form a set of parameter constraint boundaries (each parameter contains name-type-value range-associated branch condition fields). Based on the parameter constraint boundary set, a multi-dimensional test case set is constructed: boundary value scenario test cases take the critical points of the parameter value range (e.g., when the integer variable value range is [1,100], take 1, 100, 0, 101); outlier scenario test cases include null values, special characters (e.g., SQL injection characters 'or'1'='1'), and type mismatch values ​​(e.g., passing the string 'abc' to an integer parameter); normal value scenario test cases take the middle value of the parameter value range (e.g., taking 50 in [1,100]). Each test case is labeled with the corresponding input scenario type (boundary value / outlier value / normal value) and the associated specification-vulnerability association pair identifier (e.g., association pair V001-C002), generating an labeled multi-dimensional test case set, which is directly used as the input data for step 433.

[0109] Preferably, in the specific technical implementation of step 432: the original development environment information of the code snippet (including programming language version, dependency library list and version number, compilation tool parameters, and system environment variable configuration) is obtained, and a containerized lightweight virtualization engine (such as a custom engine based on Docker) is invoked. The engine first creates a basic isolated container instance, uses namespace technology to achieve resource isolation of processes, networks, and file systems, and uses cgroups to limit the upper limit of CPU, memory, and IO resource usage of the container to ensure resource isolation between the virtual execution environment and the host environment. Inside the container, the corresponding version of the dependency package is automatically pulled according to the dependency library list (preferably obtained from the private image repository to ensure version consistency), and the compilation parameters (such as the -g debugging parameter for C language and the -Xmx memory parameter for Java) and environment variables (such as PATH and LD_LIBRARY_PATH) are configured according to the original development environment information. For code snippets involving network operations, a virtual network interface is additionally configured and restricted to accessing only the preset image service address to achieve network isolation. The finally constructed dynamic sandbox contains three elements: container instance, environment configuration list, and resource isolation strategy. This dynamic sandbox is directly used for the execution of test cases in step 433.

[0110] Preferably, in a scenario, step 433 is specifically implemented as follows: The multi-dimensional test case set with identifiers generated in step 431 and the dynamic sandbox constructed in step 432 are obtained and executed in the priority order of outlier scenario test cases → boundary value scenario test cases → normal value scenario test cases. Before execution, a unique tracking identifier (consisting of test case ID, associated identifier, and timestamp) is bound to each test case for subsequent trajectory association. When executing test cases in the dynamic sandbox, key nodes of the code snippet (function entry / exit, variable assignment point, branch decision point) are captured in real time using instrumentation tools (such as LLVM instrumentation, JavaAgent): variable state changes (variable name - old value - new value - change location), memory operation trajectory (memory address - operation type (read / write) - operation value - call stack), and function call sequence (function name - parameter list - return value - call time). The captured information is sorted by timestamp and combined with the tracking identifier of the test case to generate a time-sequential execution trajectory containing timestamp, tracking identifier, variable state, memory operation, and function call fields. For example, the time-series execution trajectory of outlier test case T001 (associated with V001-C002) will record the changes in the assignment of variable sql_str after passing in 'or'1'='1, the call sequence of database query functions, etc. This time-series execution trajectory is directly used as the input basis for the analysis in step 434.

[0111] Preferably, the specific implementation process of step 434 is as follows: Obtain the time-series execution trajectory generated in step 433, and call the feature matching engine to analyze the trajectory. First, extract abnormal features from the trajectory: out-of-bounds values ​​appearing in variable state changes (e.g., integer variable value is -1 but constraint is ≥0), illegal access in memory operation trajectory (e.g., writing to a freed memory address), and abnormal returns in function call sequence (e.g., encryption function returns null). Match these abnormal features with the vulnerability feature gene library in step 21 to determine the vulnerability trigger point (including vulnerability feature ID, trigger timestamp, and associated test case identifier). Second, extract the specification deviation features from the trajectory: function call order violates timing constraints (e.g., logging function is called after business function), and variable naming does not conform to syntax constraints (e.g., using keywords as variable names). Match these features with the specification feature rule chain in step 22 to determine the specification violation point (including specification feature ID, violation location, and associated test case identifier). Finally, the vulnerability trigger points and specification violation points are associated with the corresponding test case identifiers and time-sequential execution trajectory fragments to generate sandbox simulation results (format: vulnerability trigger point set - specification violation point set - associated trajectory mapping table). These sandbox simulation results are directly used as the basis for correcting the scan results in step 44.

[0112] Optionally, step 5, iteratively updating the vulnerability feature confidence propagation network based on the correction results to calibrate and eliminate biases in the scan results, generates vulnerability risk classification and specification violation classification outputs, specifically including:

[0113] Step 51: Extract vulnerability deviation data and specification deviation data for feature matching from the correction results;

[0114] Step 52: Calculate the correction coefficient of the edge weights based on the vulnerability bias data, so as to calibrate and eliminate the bias in the joint confidence value of the vulnerability and obtain the corrected joint confidence value of the vulnerability;

[0115] Step 53: Convert the corrected vulnerability joint confidence value into a multi-dimensional vulnerability risk classification that includes technical risk, business impact risk, and compliance risk, as the vulnerability risk classification.

[0116] Step 54: Calculate the adjustment factor of the node confidence based on the normative deviation data, so as to calibrate and eliminate the deviation of the normative joint confidence value to obtain the corrected normative joint confidence value;

[0117] Step 55: Convert the revised joint confidence value of the specification into a multi-dimensional specification risk rating that includes coding specification fit, business logic compliance, and security baseline compliance as a specification violation rating.

[0118] Preferably, in the specific technical implementation of step 52: using the vulnerability deviation data list generated in step 51 as input, the correction coefficient of the edge weight is calculated by focusing on the two core fields of confidence deviation value and edge weight in the list. First, the vulnerability deviation data is grouped according to the vulnerability type and the business scenario to which the code snippet belongs (e.g., SQL injection vulnerability - financial payment scenario buffer overflow vulnerability - industrial control scenario). Since different scenarios have different sensitivities to vulnerabilities, a scenario weight coefficient is assigned to each group (the weight of financial payment scenario is set to 1.2, industrial control scenario is set to 1.1, and ordinary Internet scenario is set to 1.0). The local correction coefficient of a single deviation data is calculated: if the deviation type is a missed judgment (the original confidence value is lower than the actual value that should be taken), the local correction coefficient = 1 + (confidence deviation value × scenario weight coefficient); if the deviation type is a misjudgment (the original confidence value is higher than the actual value that should be taken), the local correction coefficient = 1 - (confidence deviation value × scenario weight coefficient), ensuring that the correction coefficient value is within the range of [0.5, 1.5] (if it exceeds this range, it is truncated according to the boundary value to avoid over-correction). The average of all local correction coefficients corresponding to the same associated edge (the edge between two nodes in the vulnerability feature confidence propagation network) is taken to obtain the final edge weight correction coefficient for that edge. The original edge weight (the mutual information gain calculated in step 24) is multiplied by the final edge weight correction coefficient to obtain the corrected edge weight; then the joint vulnerability confidence value is recalculated using the corrected edge weight (reusing the weighted summation logic in step 32) to obtain the corrected joint vulnerability confidence value, which is directly used as the input data for risk classification in step 53.

[0119] Preferably, in a specific implementation of step 53 in a given scenario: Based on the corrected vulnerability joint confidence value generated in step 52, a multi-dimensional vulnerability risk grading model is constructed. The model includes three dimensions: technical risk, business impact risk, and compliance risk. The evaluation indicators and weights for each dimension are set according to the business scenario. Technical risk dimension: Based on the impact of the vulnerability on code execution stability (e.g., the probability of a crash due to memory overflow), the evaluation indicators include vulnerability trigger probability (derived from the corrected vulnerability joint confidence value) and vulnerability repair difficulty (based on historical repair time statistics). The weight for the financial scenario is set to 0.35, and for the industrial scenario, it is set to 0.4. Business impact risk dimension: Based on the impact of the vulnerability on core business (e.g., the possibility of financial losses due to payment vulnerabilities), the evaluation indicators include business relevance (the correlation coefficient between the module containing the vulnerability and the core business) and loss estimation level (classified according to industry loss standards). The weight for the financial scenario is set to 0.45, and for the industrial scenario, it is set to 0.35. Compliance risk dimension: Based on the degree to which the vulnerability violates industry compliance standards, the evaluation indicators include compliance clause matching degree (the number of associations between the vulnerability and compliance clauses) and violation penalty level (classified according to regulatory penalty cases). The weight for all scenarios is uniformly set to 0.2. For each dimension, the evaluation index score (0-100 points) is multiplied by its corresponding weight and summed to obtain the dimension risk value. Then, the risk values ​​of the three dimensions are summed with equal weights to obtain the comprehensive risk value. Based on the comprehensive risk value, the risk is categorized as follows: 80-100 points are high risk, 50-79 points are medium risk, and 0-49 points are low risk. A multi-dimensional vulnerability risk classification is generated, including vulnerability feature ID, risk value of each dimension, comprehensive risk classification, and classification basis. This classification serves as the final vulnerability risk output.

[0120] Preferably, in the specific technical implementation of step 54: using the list of specification deviation data generated in step 51 as input, the adjustment factor of the node confidence level is calculated for the node confidence level field associated with the specification confidence deviation value in the list. First, the specification deviation data is grouped according to specification type - code snippet development language (e.g., coding specification - Java language security baseline - Python language). Because the specification execution strictness of different languages ​​is different, a language weight coefficient is assigned to each group (Java language weight is set to 1.1 due to its strong typing characteristics, Python language weight is set to 1.05 due to its weak typing characteristics, and C++ language weight is set to 1.15 due to its low-level development characteristics). The local adjustment factor of a single deviation data is calculated: if the deviation type is a missed judgment (the original specification confidence value is lower than the actual value that should be taken), the local adjustment factor = 1 + (specification confidence deviation value × language weight coefficient); if the deviation type is a misjudgment (the original specification confidence value is higher than the actual value that should be taken), the local adjustment factor = 1 - (specification confidence deviation value × language weight coefficient). The adjustment factor value range is controlled between [0.6, 1.4] (to avoid extreme values ​​that may cause confidence level distortion). For the same node (a specification-related node in the vulnerability feature confidence propagation network), take a weighted average of all local adjustment factors (the weight is the priority of the specification feature of that node in the rule chain) to obtain the final node confidence adjustment factor for that node. Multiply the original node confidence (the compliance verification confidence calculated in step 23) by the final adjustment factor to obtain the corrected node confidence; then recalculate the specification joint confidence value using the corrected node confidence (reusing the specification verification channel logic in step 33) to obtain the corrected specification joint confidence value, which is directly used as the input data for specification classification in step 55.

[0121] Preferably, the specific implementation process of step 55 is as follows: taking the corrected joint confidence value of the specifications generated in step 54 as the core, a multi-dimensional specification risk classification model is constructed. The model includes three dimensions: coding specification fit, business logic compliance, and security baseline compliance. The evaluation indicators and weights of each dimension are set in accordance with industry specification requirements. The coding standard compliance dimension evaluates the degree to which the code follows general language standards. Indicators include naming convention compliance rate (derived from the revised joint confidence value of the standards) and code format uniformity rate (verified by formatting tools). The weight is set to 0.3 for all scenarios. The business logic compliance dimension evaluates the degree to which the code follows business-specific standards (e.g., dual verification standards for fund transfers in financial scenarios). Indicators include business rule matching degree (the number of instances where standard clauses match the code logic) and anomaly scenario coverage (the proportion of business anomalies handled by the code). The weight is set to 0.4 for financial scenarios and 0.35 for general scenarios. The security baseline compliance dimension evaluates the degree to which the code follows basic security standards (e.g., sensitive data encryption input verification). Indicators include security clause compliance rate (derived from the revised joint confidence value of the standards) and vulnerability prevention effectiveness (the proportion of associated vulnerabilities reduced). The weight is set to 0.35 for all scenarios. For each dimension, the indicator score (0-100 points) is multiplied by its weight and summed to obtain the dimension compliance value. The compliance values ​​of the three dimensions are then summed to obtain the overall compliance value. The compliance score is used to classify the compliance level: 90-100 points are fully compliant, 70-89 points are basically compliant, 40-69 points are partially compliant, and 0-39 points are non-compliant. A multi-dimensional compliance risk classification is generated, which includes the compliance feature ID, compliance scores of each dimension, comprehensive compliance classification, and classification basis. This classification is the final compliance violation output.

[0122] Figure 2 This is a schematic diagram of a multilingual code specification and security vulnerability synchronous scanning device according to an embodiment of this application. Figure 2 As shown, it includes:

[0123] Feature extraction unit: Performs cross-language syntax adaptation and syntax tree feature entropy extraction on the multilingual code set to generate a multilingual code syntax tree feature set;

[0124] Network building unit: Based on known vulnerability samples and code style libraries, construct a vulnerability feature belief propagation network;

[0125] Synchronous Detection Unit: Inputs the feature set of multi-language code syntax tree into the vulnerability feature confidence propagation network to simultaneously perform code standard compliance verification and security vulnerability detection, thereby generating scan results;

[0126] Result Correction Unit: Calculates the specification-vulnerability collaborative verification factor to correct missed scans and misjudgments in the scan results and obtain the correction result;

[0127] Hierarchical output unit: Based on the correction results, iteratively update the vulnerability feature confidence propagation network to calibrate and eliminate biases in the scan results, thereby generating vulnerability risk classification and standard violation classification output.

[0128] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for simultaneously scanning multilingual code standards and security vulnerabilities, characterized in that, include: Step 1: Perform cross-language syntax adaptation and syntax tree feature entropy extraction on the multilingual code set to generate a multilingual code syntax tree feature set; Step 2: Based on known vulnerability samples and code style libraries, construct a vulnerability feature belief propagation network; Step 3: Input the multi-language code syntax tree feature set into the vulnerability feature belief propagation network to simultaneously perform code style compliance verification and security vulnerability detection, thereby generating scan results; Step 4: Calculate the specification-vulnerability co-verification factor to correct for missed and false positives in the scan results. Step 5: Iteratively update the vulnerability feature belief propagation network based on the correction results to calibrate and eliminate biases in the scan results, thereby generating vulnerability risk classification and specification violation classification outputs; Step 3 specifically includes: Step 31: Perform semantic similarity matching between the composite syntax tree feature entropy in the multilingual code syntax tree feature set and the node features of the vulnerability feature belief propagation network to generate a feature matching mapping table; Step 32: Trigger the confidence propagation of the vulnerability feature confidence propagation network based on the feature matching mapping table, so as to calculate the joint confidence value of feature matching through the mutual information gain between nodes in the vulnerability feature confidence propagation network; Step 33: Perform dual-channel verification on the joint confidence value: In the vulnerability detection channel, the vulnerability risk level of the code segment is determined based on the vulnerability association confidence level to obtain the joint confidence level of vulnerability risk; in the specification verification channel, the specification compliance degree of the code segment is determined based on the compliance verification confidence level to obtain the joint confidence level of specification risk. Step 34: Based on the joint confidence of vulnerability risk and the joint confidence of regulatory risk, the feature association parsing module is used to identify the causal mapping relationship between vulnerability risk and regulatory violation, so as to generate scanning results containing the association labels between vulnerability risk features and regulatory violation features; Step 4, calculating the specification-vulnerability co-verification factor, is used to correct missed and false positives in the scan results. This includes: Step 41: Extract vulnerability-canonical association pairs from the scan results, call the historical collaborative verification database, retrieve historical verification records of the same vulnerability-canonical association pairs, and generate association pair verification feature vectors; Step 42: Calculate the specification-vulnerability co-verification factor based on the correlation verification feature vector. This specification-vulnerability co-verification factor is obtained by fusing vulnerability detection accuracy, specification verification accuracy, and correlation matching rate, and is used to quantify the credibility of the scan results. Step 43: For the association pairs whose specification-vulnerability co-verification factor is lower than the preset trust threshold, start the dynamic sandbox simulation mechanism to build a virtual execution environment for the code snippet and simulate the code behavior under different input scenarios to generate sandbox simulation results. Step 44: Based on the sandbox simulation results, complete and mark the missing features in the scanning results, and perform noise reduction on the misjudged features to generate corrected results.

2. The method according to claim 1, characterized in that, Step 1: Perform cross-language syntax adaptation and syntax tree feature entropy extraction on the multilingual code set to generate a multilingual code syntax tree feature set, specifically including: Step 11: Call the cross-language syntax deconstruction module to perform syntactic gene sequencing on the multi-language code set to identify the differences in syntactic representations between different programming languages; Step 12: Construct a language adaptation rule graph based on grammatical representation differences, and transform the adaptation graph into executable dynamic adaptation logic through rule distillation. Step 13: Based on dynamic adaptation logic, generate a unified abstract syntax tree containing syntax gene tags, where syntax gene tags are used to record the original language features of code snippets; Step 14: Perform hierarchical deconstruction of node features on the unified abstract syntax tree to extract the syntactic relation entropy, type dependency entropy and execution path entropy of the nodes, and generate composite syntax tree feature entropy accordingly; Step 15: Associate and map the feature entropy of the composite syntax tree with the syntax gene markers to construct a multilingual code syntax tree feature set.

3. The method according to claim 1, characterized in that, Step 2: Based on known vulnerability samples and code style libraries, construct a vulnerability feature belief propagation network, specifically including: Step 21: Call the vulnerability feature distillation module to perform code slicing and parsing on known vulnerability samples to extract the syntax pattern features, execution path features and data flow features that trigger the vulnerability, and generate a vulnerability feature gene library accordingly; Step 22: The code specification library is parsed through the specification feature extraction module, and the specification requirements described in natural language are transformed into computable syntactic constraint features, semantic constraint features and temporal constraint features to construct a specification feature rule chain; Step 23: Calculate the vulnerability association confidence of each vulnerability feature in the vulnerability feature gene library and the compliance verification confidence of each normative feature in the normative feature rule chain; Step 24: Analyze the collaborative association patterns of vulnerability features and specification features to obtain the cross-modal feature association strength, and calculate the mutual information gain between vulnerability features and specification features based on the cross-modal feature association strength, so as to construct a vulnerability feature belief propagation network topology with vulnerability features as nodes and mutual information gain as edge weights; Step 25: Inject the vulnerability association confidence and compliance verification confidence into the vulnerability feature confidence propagation network topology to obtain the constructed vulnerability feature confidence propagation network.

4. The method according to claim 1, characterized in that, Step 5: Iteratively update the vulnerability feature belief propagation network based on the correction results to calibrate and eliminate biases in the scan results, thereby generating vulnerability risk classification and specification violation classification outputs. Specifically, this includes: Step 51: Extract vulnerability deviation data and specification deviation data for feature matching from the correction results; Step 52: Calculate the correction coefficient of the edge weights based on the vulnerability bias data, so as to calibrate and eliminate the bias in the joint confidence value of the vulnerability and obtain the corrected joint confidence value of the vulnerability; Step 53: Convert the corrected vulnerability joint confidence value into a multi-dimensional vulnerability risk classification that includes technical risk, business impact risk, and compliance risk, as the vulnerability risk classification. Step 54: Calculate the adjustment factor of the node confidence based on the normative deviation data, so as to calibrate and eliminate the deviation of the normative joint confidence value to obtain the corrected normative joint confidence value; Step 55: Convert the revised joint confidence value of the specification into a multi-dimensional specification risk rating that includes coding specification fit, business logic compliance, and security baseline compliance as a specification violation rating.

5. The method according to claim 2, characterized in that, Step 14: Perform hierarchical deconstruction of node features on the unified abstract syntax tree to extract the syntactic relation entropy, type dependency entropy, and execution path entropy of the nodes, and generate composite syntax tree feature entropy accordingly. Specifically, this includes: Step 141: Using the nodes of the unified abstract syntax tree as the center, construct the grammatical neighborhood network of the nodes and count the frequency and distribution pattern of different grammatical relations in the grammatical neighborhood network, and use the distribution entropy value of the grammatical relations as the grammatical relation entropy. Step 142: Perform hierarchical destructuring of the type dependency layer on the nodes of the unified abstract syntax tree to parse the variable types, function return value types and parameter types involved in the nodes and construct type dependency chains accordingly. Calculate the distribution entropy value of type dependency as type dependency entropy by statistically analyzing the conversion probability distribution between different types on the type dependency chain. Step 143: Perform hierarchical deconstruction of the execution path layer of the nodes of the unified abstract syntax tree to extract the execution path set of the nodes under different branch conditions and calculate the path length distribution entropy and the branch trigger probability distribution entropy respectively. Then, fuse the path length distribution entropy and the branch trigger probability distribution entropy to generate the execution path entropy. Step 144: Weight the distribution of syntactic relation entropy, type dependency entropy, and execution path entropy, and then normalize the sum to generate the feature entropy of the composite syntax tree.

6. The method according to claim 3, characterized in that, Step 24: Analyze the collaborative association patterns between vulnerability features and canonical features to obtain the cross-modal feature association strength, and calculate the mutual information gain between vulnerability features and canonical features based on the cross-modal feature association strength, in order to construct a vulnerability feature belief propagation network topology with vulnerability features as nodes and mutual information gain as edge weights, specifically including: Step 241: Modal attribute annotation is performed on vulnerability features and specification features to construct a cross-modal feature co-occurrence matrix; Step 242: Calculate the original mutual information values ​​between features based on the cross-modal feature co-occurrence matrix, and normalize the original mutual information values ​​to obtain the cross-modal feature association strength; Step 243: Perform cluster analysis on the cross-modal feature association strength to obtain multiple feature clusters, and extract the association paths between features within each feature cluster to construct a cross-modal feature association subgraph with modal attribute annotation; Step 244: Perform topology fusion on the cross-modal feature association subgraph to calculate the mutual information gain between the vulnerability features when they are nodes and assign it as the edge weight between the nodes to obtain the vulnerability feature belief propagation network topology.

7. The method according to claim 1, characterized in that, Step 32: Trigger the confidence propagation of the vulnerability feature confidence propagation network based on the feature matching mapping table, so as to calculate the joint confidence value of feature matching through the mutual information gain between nodes in the vulnerability feature confidence propagation network, specifically including: Step 321: Starting from each successfully matched feature node, initiate the confidence diffusion process of the vulnerability feature confidence propagation network to transmit the joint confidence value to adjacent nodes based on the edge weight; Step 322: Based on the mutual information gain between nodes in the vulnerability feature confidence propagation network, dynamically adjust the joint confidence value in the propagation process to generate the propagation confidence value, and perform a weighted summation of the propagation confidence values ​​corresponding to all associated nodes to obtain the joint confidence value of feature matching.

8. The method according to claim 7, characterized in that, Step 43: For association pairs where the specification-vulnerability co-verification factor is lower than a preset trust threshold, initiate a dynamic sandbox simulation mechanism to construct a virtual execution environment for the code snippet and simulate code behavior under different input scenarios to generate sandbox simulation results. Specifically, this includes: Step 431: Parse the parameter constraint boundaries of the code snippet based on the feature entropy of the compound syntax tree to construct a multi-dimensional test case set. This multi-dimensional test case set includes boundary value scenarios, outlier scenarios, and normal value scenarios. Each test case in the multi-dimensional test case set is labeled with the corresponding input scenario type and the associated specification-vulnerability association pair identifier. Step 432: Call the containerized lightweight virtualization engine, build a virtual execution environment with resource isolation and network isolation based on the original development environment information of the code snippet, and restore the dependency library version, compilation parameters and environment variables of the code snippet in the virtual execution environment to build a dynamic sandbox; Step 433: Execute the code snippets of the test cases in the dynamic sandbox according to the priority order of test cases corresponding to outlier scenarios → test cases corresponding to boundary value scenarios → test cases corresponding to normal value scenarios, and capture the execution process of the code snippets in real time to record variable state changes, memory operation trajectories, and function call sequences, thereby generating a time-sequential execution trajectory. Step 434: Determine the vulnerability trigger point and the violation point based on the time-series execution trajectory to generate sandbox simulation results.

Images