A vulnerability closed-loop management method based on a multi-dimensional knowledge graph and a code large model

Abstract

The application discloses a vulnerability closed-loop management method based on a multi-dimensional knowledge graph and a code large model, and belongs to the field of network and information security.The method comprises the following steps: collecting multi-source heterogeneous data to construct a multi-dimensional vulnerability knowledge graph; for candidate alarms of target software code, multi-modal features are extracted based on the graph and fused to determine confidence, and real vulnerabilities are identified; for real vulnerabilities, historical patches are retrieved from the graph and atomic repair operations are extracted as general expressions, a pre-trained code large model is used, combined with the context constraints of target code, to perform variable name mapping and syntax reconstruction on the atomic repair operations to generate candidate repair strategies; the candidate repair strategies are automatically verified in an isolated environment, feedback samples are generated according to the verification results, and are used for vulnerability confidence determination and / or incremental optimization of the code large model.The application improves the vulnerability detection accuracy, generates context-adapted repair patches, reduces the risk of patch regression, and realizes the closed-loop management of vulnerabilities.

Description

Technical Field

[0001] This invention relates to the field of network and information security technology, specifically to automated detection of software vulnerabilities, comprehensive risk assessment, intelligent generation of patch strategies, and closed-loop verification technology, and particularly to a closed-loop vulnerability governance method based on multidimensional knowledge graphs and large code models. Background Technology

[0002] With the acceleration of digitalization, software systems have become the core infrastructure of society. However, the exponential growth in software scale has also brought unprecedented challenges to its security. The traditional software vulnerability governance lifecycle typically relies on a combination of static tool scanning and manual review and auditing. This model has the following significant drawbacks:

[0003] 1. Isolated detection leads to an extremely high false alarm rate, and manual verification is very costly.

[0004] Existing vulnerability scanning tools employ black-box / white-box testing methods such as static analysis, typically enabling only single-point detection. Due to the failure to effectively integrate heterogeneous data such as code semantics, runtime logs, network traffic, and historical support tickets, severe data fragmentation and loss of contextual information occur. This makes it difficult to selectively filter potential vulnerabilities, resulting in a massive number of false alarms. Security engineers are forced to spend a significant amount of time troubleshooting invalid alerts.

[0005] 2. The repair strategy is passive and relies on personal experience, resulting in a long repair cycle.

[0006] Most existing solutions only focus on locating vulnerabilities, lacking global optimization for vulnerability remediation. Vulnerability remediation heavily relies on the personal experience of security personnel, resulting in long average remediation cycles, providing attackers with ample window of opportunity, and making it difficult to effectively reuse past vulnerability remediation experience at the organizational level.

[0007] 3. The lack of context-aware automatic verification loop makes it easy for patches to introduce regression risks.

[0008] Existing big data or machine learning security tools often overlook the contextual constraints, API usage patterns, and compatibility issues of the affected code when generating remediation suggestions. Simple code replacement or template-based fixes, lacking consideration of contextual dependencies and automated testing and global verification mechanisms in isolated environments, are highly susceptible to breaking existing functionality or introducing new security vulnerabilities. Directly applying the generated patches can easily introduce new logical flaws or break existing functionality, failing to provide a closed-loop guarantee for system stability and security.

[0009] Therefore, how to provide a closed-loop vulnerability management method that can improve the accuracy of identifying real vulnerabilities while reducing the regression risk caused by remediation is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0010] In view of the above problems, this invention is proposed to provide a closed-loop vulnerability governance method based on multidimensional knowledge graph and large code model to overcome or at least partially solve the above problems. It not only effectively improves the accuracy of identifying real vulnerabilities, but also realizes the intelligent generation and automated verification of context-aware remediation strategies, thereby significantly shortening the vulnerability response cycle, reducing the risk of patch regression, and providing reliable security assurance for complex software systems throughout their entire lifecycle.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] This invention provides a closed-loop vulnerability management method based on multidimensional knowledge graphs and large code models, comprising the following steps:

[0013] S1: Collect multi-source heterogeneous security data and construct a multi-dimensional vulnerability knowledge graph by extracting entity relationships;

[0014] S2: For candidate alarm points in the target software code, extract multimodal features based on the multidimensional vulnerability knowledge graph, fuse and determine the vulnerability confidence of each candidate alarm point, and identify the real vulnerability based on the vulnerability confidence.

[0015] S3: For the identified real vulnerabilities, retrieve the associated historical patches from the multi-dimensional vulnerability knowledge graph, perform semantic parsing on the historical patches, and extract several atomic repair operations. The atomic repair operations serve as a general expression for the repair logic of the historical patches. Input the several atomic repair operations into the pre-trained code model, and combine the context constraint information of the target software code corresponding to the real vulnerabilities to perform variable name mapping and syntax reconstruction on the atomic repair operations to generate candidate repair strategies.

[0016] S4: Automatically verify the candidate remediation strategies in an isolated environment, generate feedback samples based on the verification results, and use the feedback samples to incrementally optimize the vulnerability confidence determination process in S2 and / or the large code model in S3.

[0017] Preferably, the multi-source heterogeneous security data includes at least one of the following: open-source vulnerability databases, version commit records in code hosting platforms, code repositories to which the target software code belongs, and code execution logs.

[0018] Preferably, the multimodal features include:

[0019] The semantic similarity features between candidate alert point codes and known vulnerability codes in the multidimensional vulnerability knowledge graph;

[0020] Risk statistical characteristics of historical vulnerability patterns corresponding to candidate alert points;

[0021] Contextual deviation characteristics between the code context corresponding to the candidate alarm point and the normal code mode corresponding to the candidate alarm point.

[0022] Preferably, the step of fusing and determining the confidence level of a vulnerability in step S2 includes: calculating the confidence level value by weighted summation and Sigmoid mapping.

[0023]

[0024] In the formula, Code for candidate alarm points The code semantic similarity between the code and the known vulnerable code in the Multidimensional Vulnerability Knowledge Graph (VKG). Code for candidate alarm points Corresponding to the risk value of historical vulnerability patterns, Candidate alarm points Corresponding code context and candidate alert points The corresponding contextual deviation characteristics between normal code modes For trainable feature weights, For bias terms, For the Sigmoid function;

[0025] When the confidence value exceeds a preset threshold, the corresponding candidate alarm point is determined to be a real vulnerability.

[0026] Preferably, step S3, which involves extracting the atomic repair operation, includes:

[0027] Retrieve several historical vulnerability nodes from the multidimensional vulnerability knowledge graph that have a similarity to the current real vulnerability that is higher than a preset value, and obtain the patch that is directly associated with the historical vulnerability node.

[0028] The patch is semantically parsed, and the business variables and encoding information that are adapted to the business scenario of the historical vulnerability node are stripped out to obtain general repair logic code that does not depend on the business scenario, which is used as the atomic repair operation.

[0029] Preferably, the step of stripping the business variables and encoding information in the patch that are adapted to the business scenario of the historical vulnerability node includes at least one of the following: input filtering operation, boundary check addition operation, and application programming interface parameter rule replacement operation.

[0030] Preferably, the context constraint information in step S3 includes at least one of the following: the application programming interface declaration of the target software code, the version of the dependent library, and the code style.

[0031] Preferably, step S3 further includes: calculating a comprehensive score for the generated candidate repair strategies, and sorting and outputting the candidate repair strategies according to the comprehensive score; the comprehensive score includes: strategy effectiveness score, strategy security score, and strategy execution overhead score;

[0032] The effectiveness score of the strategy is obtained based on the success rate statistics of the corresponding historical patches in the multidimensional vulnerability knowledge graph.

[0033] The security score of the strategy is obtained based on the degree of matching between the changes in code attributes after the candidate repair strategy is repaired and the known poor code function patterns;

[0034] The strategy execution overhead score is estimated based on the change in lines of code and the number of affected modules after the candidate repair strategy is repaired.

[0035] Preferably, the feedback samples include: candidate repair strategies that pass verification as positive samples, and candidate repair strategies that fail verification as negative samples.

[0036] Preferably, the incremental optimization in step S4 includes:

[0037] The model parameters used for vulnerability confidence determination in step S2 are updated using the feedback samples.

[0038] The feedback samples are used to perform incremental fine-tuning training on the large code model in step S3. The incremental fine-tuning training updates the model parameters by adding the feedback samples based on the current model parameters of the large code model.

[0039] This invention addresses the challenges of high false positive rates in current vulnerability discovery tools, long traditional remediation cycles, and the ease with which manual remediation can introduce new vulnerabilities. It also aims to provide security analysis platforms with a more holistic perspective and targeted intelligence when dealing with large and complex software systems, focusing on the deep fusion of multi-source heterogeneous data and context-aware patch generation strategies. The beneficial effects of the above-mentioned technical solution provided by the embodiments of this invention include at least the following:

[0040] This invention improves the automated system's understanding of vulnerability root causes and project context by introducing a Vulnerability Knowledge Graph (VKG) and a large code model. This enables accurate filtering of false positives and allows for deeper investigation of real vulnerabilities. It significantly improves the accuracy and overall performance of vulnerability detection. Furthermore, by leveraging the target code context and combining the large code model, it generates security patches that balance compatibility and performance, which is of great significance for reducing enterprise security operation and maintenance costs and enhancing overall system stability. This invention does not involve modifying the underlying probes of specific vulnerability scanners; instead, it utilizes the natural language processing capabilities of the large model to achieve efficient closed-loop vulnerability management, thereby significantly shortening the vulnerability response cycle and reducing the regression risk associated with patching.

[0041] This invention ensures the security of software systems throughout their entire lifecycle, effectively preventing the risk of vulnerability exploitation, and has been extensively verified in real-world open-source projects and enterprise applications. By fusing multi-dimensional features, it effectively eliminates false positives caused by shallow rules while maintaining high recall. Furthermore, by reconstructing historical patches using a large-scale code model, it achieves high-adoption-rate automatic repair while ensuring the integrity of the code logic, effectively avoiding the problem of introducing new defects that is common with traditional manual repair methods. Attached Figure Description

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

[0043] Figure 1 The overall process architecture diagram of vulnerability closed-loop governance based on multidimensional knowledge graph and large code model provided in the embodiments of the present invention;

[0044] Figure 2 A flowchart of a vulnerability confidence determination method based on multimodal feature fusion provided in an embodiment of the present invention;

[0045] Figure 3 A flowchart for generating repair strategies based on Patch Policy Graph (PSG) and context-awareness, provided for embodiments of the present invention;

[0046] Figure 4 A flowchart for model parameter optimization based on isolated environment verification and online closed-loop feedback provided in an embodiment of the present invention;

[0047] Figure 5 A schematic diagram of the modular deployment structure of the vulnerability closed-loop management system provided in this embodiment of the invention;

[0048] Figure 6A schematic diagram comparing the vulnerability repair time of the conventional method flow and the method flow of the present invention for embodiments of the present invention. Detailed Implementation

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

[0050] This invention discloses a closed-loop vulnerability management method based on a multi-dimensional knowledge graph and a large code model. It consists of two core engines: a vulnerability determination engine based on multi-modal feature fusion, and a remediation strategy generation engine based on a patch policy graph (PSG) and a large code model. Specifically, it includes the following steps:

[0051] S1: Collect multi-source heterogeneous security data and construct a multi-dimensional vulnerability knowledge graph by extracting entity relationships.

[0052] Specifically, the steps for constructing a multidimensional vulnerability knowledge graph (VKG), as well as the resulting graph entity structure and edge structure, are as follows:

[0053] The specific steps for constructing the map are as follows:

[0054] The first step is multi-source data cleaning and preprocessing: Natural language segmentation and noise reduction are performed on the collected unstructured data (such as vulnerability description text and operation logs); Syntax Tree (AST) parsing and field alignment are performed on the structured / semi-structured data (such as NVD database, GitHub commit records, and source code differences).

[0055] The second step is multimodal entity and relation extraction: using Named Entity Recognition (NER) technology to extract vulnerability features and component information from the text; using static code analysis technology to extract code blocks, function calls, and version dependencies; and simultaneously, based on work order association and commit tracing, extracting the inherent association rules between vulnerabilities, code, and patches.

[0056] The third step is knowledge fusion and alignment: through entity disambiguation technology, entities pointing to the same object from different data sources (such as CVE numbers in NVD and specific bug IDs in the enterprise's internal code repository) are mapped and merged to eliminate redundant data.

[0057] The fourth step is graph storage and dynamic updates: The extracted and merged entities and edge relationships are persistently stored in the graph database in the form of triples (head entity, relation, tail entity), and a streaming data interface is established to support incremental real-time updates for new vulnerabilities and code submissions.

[0058] The resulting graph entity structure (Node) is described below:

[0059] In the Multidimensional Vulnerability Knowledge Graph (VKG), the entity structure is mainly divided into the following four dimensions as shown in Table 1:

[0060] Table 1. Entity Structure Category Table

[0061]

[0062] The resulting graph edge structure is explained below:

[0063] The entities in the graph are topologically connected by rich semantic edges. The main edge structures are shown in Table 2.

[0064] Table 2. Side Structure Category Table

[0065]

[0066] S2: For candidate alarm points in the target software code, extract multimodal features based on a multidimensional vulnerability knowledge graph, fuse and determine the vulnerability confidence of each candidate alarm point, and identify the real vulnerability based on the vulnerability confidence.

[0067] S3: For the identified real vulnerabilities, construct a Patch Policy Graph (PSG) and generate candidate remediation strategies by combining it with the large model. This includes the following sub-steps:

[0068] S31: Build Patch Strategy Graph (PSG):

[0069] After identifying the actual vulnerability node v in the target software code in step S2, and before inputting the large code model, a patch strategy graph (PSG) is generated.

[0070] The data structure of PSG is a structured directed attribute graph. The node set N includes: the target vulnerability node, the retrieved similar historical vulnerability nodes, the corresponding historical patch nodes, and the "atomic operation nodes" (such as boundary check additions, input filtering, etc.) abstracted from the historical patches through semantic parsing. The edge set E includes: the "similarity relationship" between the target vulnerability and historical vulnerabilities, the "remediation relationship" between vulnerabilities and patches, and the "inclusion relationship" between historical patches and atomic operations.

[0071] The generation of PSG is essentially based on the current real vulnerability v as the anchor point, and is formed by extracting relevant local networks from the multidimensional vulnerability knowledge graph (VKG). At this point, the current vulnerability v is treated as a new entity and connected to the original historical vulnerability nodes in the VKG through "similar relationship" edges. This dynamically expands the transient PSG as a subgraph and integrates it into the global VKG structure, achieving real-time expansion of knowledge.

[0072] S32: PSG is specifically applied in the feature retrieval and logical routing steps before inputting large-scale code models. Through graph traversal algorithms, PSG searches and calculates weights along connected paths from the target vulnerability to similar vulnerabilities, historical patches, and atomic operations, thereby selecting a series of atomic remediation operations that best match the current vulnerability.

[0073] Subsequently, these atomic remediation operations, precisely selected by PSG, are combined with contextual constraints of the target software code corresponding to real vulnerabilities (such as API usage patterns and dependency library versions) to construct structured prompts, which are then input into a pre-trained code model. Based on this input, the model performs variable name mapping and syntax reconstruction, ultimately generating context-adapted candidate remediation strategies.

[0074] S4: Automatedly verify candidate remediation strategies in an isolated environment, generate feedback samples based on the verification results, and use the feedback samples to incrementally optimize the vulnerability confidence determination process in S2 and / or the large code model in S3.

[0075] It should be noted that the code big model is based on the big language model (Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled).

[0076] In one embodiment, multi-source heterogeneous security data includes at least one of the following: open-source vulnerability databases, version commit records in code hosting platforms, code repositories containing the target software code, code execution logs, and other structured and unstructured data. Figure 1 As shown, the multi-source heterogeneous security data includes open-source vulnerability libraries such as NVD and Exploit-DB, code hosting platforms such as GitHub / GitLab, and internal enterprise code repositories and runtime logs. Through data cleaning, noise reduction, and entity relationship extraction, historical vulnerability patterns are extracted while preserving the semantic features of vulnerabilities, achieving deep integration of heterogeneous data such as code differences, dependencies, and runtime environments.

[0077] In one embodiment, as software complexity increases, the massive alarms generated by traditional static analysis are not only extremely inefficient but also lack contextual judgment. This embodiment first extracts features from the original massive alarms. Therefore, the candidate alarm points in step S2 are obtained by automatically scanning the target system using static code analysis and dynamic taint tracking techniques to acquire potential original alarms of the system.

[0078] In one embodiment, the multimodal features include:

[0079] Semantic similarity features between candidate alert point codes and known vulnerability codes in a multidimensional vulnerability knowledge graph;

[0080] Risk statistical characteristics of historical vulnerability patterns corresponding to candidate alert points;

[0081] Contextual deviation characteristics between the code context corresponding to the candidate alarm point and the normal code mode corresponding to the candidate alarm point.

[0082] In this embodiment, the code attribute graph (CPG), historical vulnerability patterns, and project-specific context in the multidimensional vulnerability knowledge graph are integrated. The cosine similarity of the code is calculated using a graph neural network (GNN), and the context reconstruction error is calculated using an autoencoder, thereby constructing a lightweight discriminative model to accurately filter false positives.

[0083] The specific steps for calculating code cosine similarity using a graph neural network (GNN) are as follows:

[0084] Input data is the target candidate alarm points. The data includes code snippets and code snippets of several known vulnerabilities from a multidimensional vulnerability knowledge graph (VKG). The data format is an extracted code attribute graph (CPG), whose mathematical representation is... ,in It is a collection of nodes representing the abstract syntax tree, control flow, and data flow. Let be the set of edges. This is the initial high-dimensional feature matrix generated by embedding techniques such as Word2Vec from the node text.

[0085] Candidate alarm points Code attribute diagram Code attribute diagram of known vulnerabilities in VKG The inputs are fed into a graph neural network (Gated Graph Neural Network, GGNN). Through information transfer across multiple layers and feature aggregation from neighboring nodes, the hidden state of each node is updated. Subsequently, a global pooling layer aggregates the local features of all nodes in the graph, mapping the output to a fixed-dimensional graph-level dense feature vector, denoted as […]. and .

[0086] The generated graph-level feature vector and They are mapped to the same vector space, and the structural semantic similarity of the code is measured by calculating the cosine of the angle between the two vectors. The calculation formula is as follows:

[0087] .

[0088] The specific steps for calculating the context reconstruction error using an autoencoder are as follows:

[0089] The training and inference inputs of the autoencoder are feature vectors of the code context, which are derived from the historical normal code of the target software project and code snippets around the alarm points to be determined.

[0090] During the training phase, all normal code from the target software project's code repository is input as input. For each function, method, or code block, its contextual features are extracted, such as: code lexical sequence, API call sequence, path embedding of the control flow graph (CFG), and path features of the abstract syntax tree (AST). A fixed-length feature vector is output, with one vector corresponding to each training sample.

[0091] The inference phase inputs the code snippets containing candidate alarm points generated by static scanning, typically taking several lines before and after the alarm line or the entire function body. A feature vector is obtained using the same feature extraction method as in the training phase.

[0092] In one embodiment, the step S2 of fusing and determining the vulnerability confidence level includes: calculating the confidence level value by weighted summation and Sigmoid mapping.

[0093]

[0094] In the formula, Code for candidate alarm points Code semantic similarity with known vulnerable code in the VKG (Multidimensional Vulnerability Knowledge Graph). Code for candidate alarm points Corresponding to the risk value of historical vulnerability patterns, Candidate alarm points The corresponding code context (including the execution environment and logical dependency sequence of the code surrounding the candidate alert point, such as API call patterns and sequences, dependent components and version constraints, etc.) and candidate alert points. The corresponding contextual deviation characteristics between normal code modes For trainable feature weights, For bias terms, This is the Sigmoid function, used to map scores to confidence levels in the (0,1) interval;

[0095] like Figure 2 As shown, when the confidence value exceeds the preset threshold, the corresponding candidate alarm point is determined to be a real vulnerability and enters the patch generation process.

[0096] It should be noted that, It is obtained by extracting the code attribute graph (CPG), embedding it into a graph neural network, and calculating cosine similarity. It is a weighted value of the activity level and severity level of the corresponding vulnerability pattern in historical data. The reconstruction error is calculated from the autoencoder trained on the project's historical code. It was trained using real vulnerabilities and false positive labeled data.

[0097] This embodiment combines historical risks with a comprehensive weighted average and Sigmoid mapping to ensure that the system can accurately filter out a large number of false alarms caused by simple rule matching, and focus attention on high-risk and highly reliable real vulnerabilities.

[0098] In one embodiment, step S3, which involves extracting the atomic repair operation, includes:

[0099] Retrieve several historical vulnerability nodes from the multidimensional vulnerability knowledge graph that have a similarity to the current real vulnerability that is higher than a preset value, and obtain the patch that is directly associated with the historical vulnerability node.

[0100] Semantic parsing is performed on the patch to remove business variables and encoding information that are adapted to the business scenarios of the historical vulnerability nodes, resulting in general patching logic code that is independent of the business scenarios, which serves as the atomic patching operation.

[0101] In one embodiment, the step of stripping business variables and coding information from the patch that are adapted to the business scenario of the historical vulnerability node includes at least one of the following: input filtering operation, boundary check addition operation, and application programming interface parameter rule replacement operation. These operations abstract the historical patch into a series of atomic operations representing pure patching logic. The purpose of this step is to generalize specific historical patching experience into transferable logical units.

[0102] The specific steps for stripping are explained below:

[0103] The abstraction steps for input filtering operations are as follows: Through Abstract Syntax Tree (AST) parsing, the statement nodes newly added in historical patches that perform data cleaning, escaping, or regular expression matching are located. The specific business input parameter variable names bound to these statements (such as specific form field names) are extracted and replaced with unified, generalized data input placeholders, while retaining the core filtering function type, cleaning rules, or matching expressions, forming a generic input filtering logic representation independent of business variables.

[0104] The abstraction steps for adding boundary check operations are as follows: Based on the change analysis of the control flow graph (CFG), identify the new conditional judgment branches added in historical patches. Extract the relational operators in the conditional expression, and strip away the specific business threshold variables and hard-coded constants involved in the comparison, replacing them with symbolic boundary placeholders. At the same time, retain the control flow blocking logic when the check fails (such as exception throwing or direct return), forming a general boundary check logic unit.

[0105] The abstraction steps for replacing API parameter rules are as follows: By comparing the Data Dependency Graph (DDG) and function call chain before and after the patch, the target API call where the configuration change occurred is located. The specific business context instance object calling the API is stripped and replaced with a generalized entity. Only the core security parameter key-value pairs (including authentication flags, encryption algorithm version parameters, etc.) that were added, deleted, or modified in the patch are extracted as abstract parameter replacement rules, thereby stripping away other business parameters that are unrelated to security fixes.

[0106] In one embodiment, step S3 not only extracts the local code segment of the target vulnerability point v, but also extracts the context constraint information of the project in which it is located, including at least one of the following: the application programming interface declaration of the target software code, the version of the dependent library, and the code style.

[0107] The pre-trained large code model receives the above input and, without changing the original business logic, performs variable name mapping and syntax-level refactoring on atomic operations based on the target system's current API usage patterns, dependency library versions, and compatibility constraints. It then outputs multiple sets of candidate remediation strategies that can directly adapt to the target project environment. .

[0108] In one embodiment, step S3 further includes: Figure 3 As shown, a comprehensive score is calculated for the generated candidate repair strategies, and the candidate repair strategies are sorted and output according to the comprehensive score; the comprehensive score includes: strategy effectiveness score, strategy security score, and strategy execution overhead score;

[0109] The strategy effectiveness score is obtained based on the success rate statistics of corresponding historical patches in a multi-dimensional vulnerability knowledge graph;

[0110] The policy security score is obtained based on the degree of matching between the changes in code attributes after the candidate remediation policy is applied and the known poor functionality patterns of the code.

[0111] The strategy execution overhead score is estimated based on the change in lines of code and the number of affected modules after the candidate repair strategy is repaired.

[0112] The comprehensive scoring formula is as follows:

[0113]

[0114]

[0115]

[0116] In the formula, The success rate of this strategy in historical applications (calculated by VKG statistics); Introduce a reverse assessment value for new risks to the strategy (the lower the value, the safer it is, calculated by the degree of matching between code attribute changes and known bad patterns); The estimated cost of strategy execution includes performance loss and compatibility impact (estimated through static metrics such as changes in lines of code and the number of affected modules). This is a balance coefficient that can be dynamically adjusted based on the project's safety and stability preferences;

[0117] The number of atomic repair operations successfully applied. This represents the total number of atomic repair operations. The number of atomic repair operations, To prevent extremely small constants with a denominator of zero;

[0118] Changes in cyclomatic complexity Number of matches with bad patterns The preset penalty weight coefficient.

[0119] The system sorts the results based on the overall score and outputs the top 1-3 repair strategies to generate code patches.

[0120] In one embodiment, such as Figure 4 As shown, the automated verification steps in step S4 include at least one of the following: compilation check, unit test, integration test, and targeted security test.

[0121] In one embodiment, the feedback samples include: patches corresponding to candidate repair strategies that have passed verification and patches corresponding to candidate repair strategies that have been actually adopted online by humans as positive samples, and patches corresponding to candidate repair strategies that introduce regression defects or fail verification as negative samples.

[0122] In this embodiment, the repair strategy that has been automatically verified and has the highest comprehensive score is output as the recommended patch, and the manual adoption results of the recommended patch are recorded. The adoption results are then used as feedback samples and injected back into the training set.

[0123] In one embodiment, the incremental optimization in step S4 includes:

[0124] Update the model parameters used in step S2 for vulnerability confidence determination using feedback samples;

[0125] The large code model in step S3 is incrementally fine-tuned using feedback samples. The incremental fine-tuning training updates the model parameters based on the current large code model parameters by adding new feedback samples.

[0126] It should be noted that this training step does not involve basic pre-training from scratch. Instead, it continuously enhances the accuracy of the large code model's understanding of specific business contexts and security specifications by constantly introducing project-specific feedback data.

[0127] like Figure 5 The deployment structure shown represents a modular deployment scheme for the entire closed-loop vulnerability management approach, deployed in a production network environment. The system acquires data sources from the production network, including code repositories, log sources, and traffic sources, which provide raw security data. After collection and initial processing by data access nodes, this data is sent to a VKG graph service node. This node extracts entity relationships to construct a multi-dimensional vulnerability knowledge graph, providing knowledge support for subsequent analysis. The security analysis platform integrates the system's main functional modules, internally integrating a vulnerability determination model service and a patch generation model service. The former utilizes knowledge from VKG to perform multi-modal feature fusion and confidence assessment on candidate alerts, thereby identifying real vulnerabilities; the latter, based on a large code model, combines historical patch information and the contextual constraints of the target code to generate candidate remediation strategies. The generated patches are sent to an automated verification execution node, where compilation checks, various tests, and security tests are performed in an isolated environment. The verification results are then fed back to the feedback learning service. The feedback learning service generates positive and negative samples based on the verification results, used for incremental optimization of the determination model and patch generation model. The operations and maintenance console is responsible for displaying the system's operating status, supporting manual review and intervention, and also feeding back the results of manual adoption into the feedback and learning service, thus forming a complete closed loop of data collection, knowledge building, vulnerability identification, patch generation, automated verification, and model optimization.

[0128] The effectiveness of the method of the present invention will be explained below with reference to specific experimental data:

[0129] As shown in Table 3, experiments were conducted on a mixed dataset (Juliet / SARD and 3 real Apache open-source projects, totaling 500 real vulnerabilities) to compare the method of this invention with other related works (rule-based traditional methods, Coverity static analysis, and Semgrep pattern matching tool). It can be seen that the method of this invention can filter out a large number of false positives based on an efficient understanding of code structure and contextual biases, improving the F1-Score of vulnerability detection to 0.810 and reducing the false positive rate to 14.4%.

[0130] Table 3 Performance Comparison of Different Vulnerability Detection Methods

[0131]

[0132] Meanwhile, as shown in Table 4, the generated remediation strategies have an overall adoption rate of up to 90.4% for common web vulnerabilities (such as SQL injection, XSS, etc.).

[0133] Table 4. Statistics of Repair Strategy Generation Results

[0134]

[0135] like Figure 6 As shown, in a practical comparison with the traditional manual vulnerability management process, the method of this invention significantly reduces the mean time to repair (MTTR) from 14.5 days to 8.2 hours and reduces the patch regression defect rate from approximately 5% in the past to 1.6%, demonstrating extremely high industrial application and practical value.

[0136] This invention fills a gap in existing technologies for automated vulnerability repair and closed-loop verification, providing a new solution for intelligent security governance in big data environments. It demonstrates significant effectiveness in ensuring software system security, improving vulnerability response efficiency, and controlling patch quality, providing robust technical support for enterprise-level security operations and maintenance.

[0137] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0138] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A closed-loop vulnerability management method based on multidimensional knowledge graphs and large code models, characterized in that, Includes the following steps: S1: Collect multi-source heterogeneous security data and construct a multi-dimensional vulnerability knowledge graph by extracting entity relationships; S2: For candidate alarm points in the target software code, extract multimodal features based on the multidimensional vulnerability knowledge graph, fuse and determine the vulnerability confidence of each candidate alarm point, and identify the real vulnerability based on the vulnerability confidence. S3: For the identified real vulnerabilities, retrieve the associated historical patches from the multi-dimensional vulnerability knowledge graph, perform semantic parsing on the historical patches, and extract several atomic repair operations. The atomic repair operations serve as a general expression for the repair logic of the historical patches. Input the several atomic repair operations into the pre-trained code model, and combine the context constraint information of the target software code corresponding to the real vulnerabilities to perform variable name mapping and syntax reconstruction on the atomic repair operations to generate candidate repair strategies. S4: Automatically verify the candidate remediation strategies in an isolated environment, generate feedback samples based on the verification results, and use the feedback samples to incrementally optimize the vulnerability confidence determination process in S2 and / or the large code model in S3.

2. The vulnerability closed-loop governance method based on multidimensional knowledge graph and large code model according to claim 1, characterized in that, The multi-source heterogeneous security data includes at least one of the following: open-source vulnerability databases, version commit records in code hosting platforms, the code repository to which the target software code belongs, and code execution logs.

3. The vulnerability closed-loop governance method based on multidimensional knowledge graph and large code model according to claim 1, characterized in that, The multimodal features include: The semantic similarity features between candidate alert point codes and known vulnerability codes in the multidimensional vulnerability knowledge graph; Risk statistical characteristics of historical vulnerability patterns corresponding to candidate alert points; Contextual deviation characteristics between the code context corresponding to the candidate alarm point and the normal code mode corresponding to the candidate alarm point.

4. The vulnerability closed-loop governance method based on multidimensional knowledge graph and large code model according to claim 1, characterized in that, The step S2, which involves fusing and determining the confidence level of a vulnerability, includes: calculating the confidence value through a weighted summation and Sigmoid mapping. ； In the formula, Code for candidate alarm points The code semantic similarity between the code and the known vulnerable code in the Multidimensional Vulnerability Knowledge Graph (VKG). Code for candidate alarm points Corresponding to the risk value of historical vulnerability patterns, Candidate alarm points Corresponding code context and candidate alert points The corresponding contextual deviation characteristics between normal code modes For trainable feature weights, For bias terms, For the Sigmoid function; When the confidence value exceeds a preset threshold, the corresponding candidate alarm point is determined to be a real vulnerability.

5. The vulnerability closed-loop management method based on multidimensional knowledge graph and large code model according to claim 1, characterized in that, Step S3 involves extracting the atomic repair operation steps, including: Retrieve several historical vulnerability nodes from the multidimensional vulnerability knowledge graph that have a similarity to the current real vulnerability that is higher than a preset value, and obtain the patch that is directly associated with the historical vulnerability node. The patch is semantically parsed, and the business variables and encoding information that are adapted to the business scenario of the historical vulnerability node are stripped out to obtain general repair logic code that does not depend on the business scenario, which is used as the atomic repair operation.

6. The vulnerability closed-loop management method based on multidimensional knowledge graph and large code model according to claim 5, characterized in that, The steps of stripping business variables and encoding information from the patch that are adapted to the business scenario of the historical vulnerability node include at least one of the following: input filtering operation, boundary check addition operation, and application programming interface parameter rule replacement operation.

7. The vulnerability closed-loop governance method based on multidimensional knowledge graph and large code model according to claim 1, characterized in that, The context constraint information in step S3 includes at least one of the following: the application programming interface declaration of the target software code, the version of the dependent library, and the code style.

8. The vulnerability closed-loop governance method based on multidimensional knowledge graph and large code model according to claim 1, characterized in that, Step S3 further includes: calculating a comprehensive score for the generated candidate repair strategies, and sorting and outputting the candidate repair strategies according to the comprehensive score; the comprehensive score includes: strategy effectiveness score, strategy security score, and strategy execution overhead score; The effectiveness score of the strategy is obtained based on the success rate statistics of corresponding historical patches in the multidimensional vulnerability knowledge graph. The security score of the strategy is obtained based on the degree of matching between the changes in code attributes after the candidate repair strategy is repaired and the known poor code function patterns; The strategy execution overhead score is estimated based on the change in lines of code and the number of affected modules after the candidate repair strategy is repaired.

9. The vulnerability closed-loop management method based on multidimensional knowledge graph and large code model according to claim 1, characterized in that, The feedback samples include: candidate repair strategies that pass verification as positive samples, and candidate repair strategies that fail verification as negative samples.

10. The vulnerability closed-loop governance method based on multidimensional knowledge graph and large code model according to claim 1, characterized in that, The incremental optimization described in step S4 includes: The model parameters used for vulnerability confidence determination in step S2 are updated using the feedback samples. The feedback samples are used to perform incremental fine-tuning training on the large code model in step S3. The incremental fine-tuning training updates the model parameters by adding the feedback samples based on the current model parameters of the large code model.

Images