A method and system for full lifecycle management of network vulnerabilities

Abstract

This invention discloses a method and system for full lifecycle management of network vulnerabilities. The method involves extracting entity relationships from raw vulnerability data to construct a vulnerability knowledge graph and identify key vulnerability nodes. Dependency conflict detection and mutation analysis are performed on these key nodes to extract core vulnerability attributes and construct key assessment and enhancement regions. Blind spot identification is performed on the raw vulnerability data to generate a blind spot distribution map. Coverage and missing features are extracted from the blind spot distribution map, and compensation and remediation strategy groups are constructed to generate hybrid remediation processing regions. Reliability analysis is performed on the hybrid remediation processing regions to determine high-reliability and low-reliability areas, assigning corresponding weights and constructing hierarchical remediation verification regions. The hierarchical remediation verification regions are merged with the key assessment and enhancement regions to generate a remediation synergy coefficient. Execution conflict prediction is performed on the compensation and remediation strategy groups, and a conflict avoidance sequence is constructed to complete the full lifecycle management of network vulnerabilities. This method can accurately identify key threats, optimize remediation strategies, and avoid execution conflicts.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method and system for managing the entire lifecycle of network vulnerabilities. Background Technology

[0002] As enterprises deepen their digital transformation, the network environment is becoming increasingly complex, encompassing various heterogeneous platforms such as virtualized infrastructure, cloud-native architecture, container clusters, and edge computing nodes. Network vulnerabilities serve as a primary entry point for attackers, and their management effectiveness directly impacts an enterprise's information security protection level.

[0003] Current vulnerability management technologies primarily employ periodic automated scanning combined with vulnerability database comparisons for threat identification, prioritizing detected vulnerabilities using a general scoring system. However, this approach fails to consider the actual exposure of assets within the enterprise and their business relationships, leading to discrepancies between threat assessments and actual risks. Furthermore, scanning tools lack adaptability to new architectures, exhibiting limited detection capabilities when facing service mesh communication, two-way authentication interfaces, and isolated network partitions, creating numerous detection gaps. In addition, the feasibility analysis of vulnerability remediation solutions is insufficient, failing to adequately assess the impact of patch deployment on business continuity and the constraints between different remediation tasks, resulting in frequent service interruptions and rollbacks during the remediation process. More critically, the lack of a continuous tracking mechanism for remediated vulnerabilities makes it impossible to identify situations where patches become ineffective or vulnerabilities reappear in new versions, hindering the establishment of a systematic and automated end-to-end management capability. Summary of the Invention

[0004] This invention provides a method and system for full lifecycle management of network vulnerabilities. It identifies key risk points on the threat propagation path by constructing a vulnerability association map, extracts the essential exploitation characteristics of vulnerabilities by using mutation patterns, makes up for scanning omissions by using coverage gap detection and targeted compensation schemes, distinguishes the reliability of remediation measures based on trusted quantification technology, and realizes the orderly execution of remediation tasks through dependency analysis and conflict prediction mechanisms, ultimately forming a closed-loop management system from threat discovery to protection verification.

[0005] The first aspect of this invention proposes a method for full lifecycle management of network vulnerabilities, comprising the following steps:

[0006] Obtain raw data on network vulnerabilities, construct a vulnerability knowledge graph based on the raw vulnerability data, and perform vulnerability association mining and analysis through the vulnerability knowledge graph to generate key vulnerability nodes;

[0007] At the critical nodes of the vulnerability, dependency conflict detection is performed to generate evaluation guidance indicators. The evaluation guidance indicators are then used to perform vulnerability mutation analysis to extract the core attributes of the vulnerability. Based on the core attributes of the vulnerability, a key evaluation and enhancement area is constructed.

[0008] The process involves scanning the raw vulnerability data to identify blind spots and generate a blind spot distribution map. Coverage and missing features are extracted from the blind spot distribution map to generate a missing feature set. A compensation strategy is then applied to the missing feature set to construct a compensation and repair strategy group. Vulnerability priorities are adjusted using the compensation and repair strategy group to generate a hybrid repair processing area. The construction of the compensation and repair strategy group from the missing feature set includes: performing compensation target location on the missing feature set to generate a compensation anchor set; identifying compensation conflict patterns from the compensation anchor set to generate conflict avoidance rules; extending the applicable boundaries of the conflict avoidance rules to generate extended compensation rules; and integrating the extended compensation rules to generate the compensation and repair strategy group.

[0009] Reliability analysis is performed on the hybrid repair processing area to determine high reliability area and low reliability area. A preset risk weight is set for the high reliability area and a compensation enhancement weight is set for the low reliability area. The graded repair verification area is constructed using the compensation enhancement weight and the preset risk weight.

[0010] The hierarchical repair verification area and the key evaluation enhancement area are merged to generate a repair synergy coefficient. The repair synergy coefficient is used to predict execution conflicts in the compensation repair strategy group and identify potential execution conflict points. A conflict avoidance sequence is constructed based on the potential execution conflict points, and the full lifecycle management of network vulnerabilities is completed based on the conflict avoidance sequence.

[0011] Optionally, the step of generating vulnerability key nodes through vulnerability association mining and analysis using the vulnerability knowledge graph includes: extracting propagation intensity features from the vulnerability knowledge graph; identifying low propagation areas and extracting hidden propagation paths based on the propagation intensity features; performing dependency tracing on the hidden propagation paths to generate high-risk propagation points; and determining vulnerability key nodes based on the high-risk propagation points.

[0012] Optionally, the step of using the assessment guidance indicators to perform vulnerability mutation analysis and extract core vulnerability attributes includes: constructing a vulnerability evolution tracking view based on the assessment guidance indicators; performing reverse mutation identification on the vulnerability evolution tracking view to extract reproducible patterns after repair; generating a stable attribute set by measuring attribute stability from the reproducible patterns after repair; and performing key screening on the stable attribute set to extract core vulnerability attributes.

[0013] Optionally, the step of extracting coverage missing features from the blind zone distribution map to generate a missing feature set includes: scanning the blind zone distribution map to identify blind zones and establish a gap identifier set; performing a missing intensity assessment on the gap identifier set to obtain a blind zone feature spectrum; performing missing range delimitation based on the blind zone feature spectrum to determine the coverage blind zone boundary; and extracting missing features based on the coverage blind zone boundary to generate a missing feature set.

[0014] Optionally, the step of performing reliability analysis on the hybrid repair processing area to determine high-reliability and low-reliability areas includes: using the hybrid repair processing area to perform trust propagation estimation to obtain a trust propagation strength table; performing volatility detection on the trust propagation strength table to identify trust-unstable areas; performing anomaly analysis in the trust-unstable areas to determine potential risk indicators; and classifying the potential risk indicators to identify high-reliability and low-reliability areas.

[0015] Optionally, the step of predicting and identifying potential execution conflict points for the compensation and repair strategy group using the repair coordination coefficient includes: constructing an execution dependency monitoring network based on the repair coordination coefficient; mapping the compensation and repair strategy group to the execution dependency monitoring network to obtain dependency offset points; performing conflict analysis on the dependency offset points to determine execution interference clusters; and identifying potential execution conflict points based on the execution interference clusters.

[0016] Optionally, the step of identifying low-propagation areas and extracting hidden propagation paths based on the propagation intensity features includes: dividing and identifying low-propagation areas according to the intensity threshold based on the propagation intensity features; detecting abnormal propagation fluctuations within the low-propagation areas to generate a fluctuation marker set; extracting unconventional connection channels based on the fluctuation marker set; and combining the low-propagation areas and the unconventional connection channels to determine hidden propagation paths.

[0017] Optionally, the step of performing a missing intensity assessment on the gap identifier set to obtain a blind zone feature spectrum includes: measuring the gap density based on the gap identifier set to obtain a density distribution; performing low-density area anomaly detection on the density distribution to identify anomalous clustering points; extracting missing intensity attributes from the anomalous clustering points to generate an intensity attribute set; and performing feature extraction on the intensity attribute set to obtain a blind zone feature spectrum.

[0018] A second aspect of this invention proposes a network vulnerability lifecycle management system, comprising:

[0019] The data acquisition module is used to acquire raw data of network vulnerabilities, construct a vulnerability knowledge graph based on the raw vulnerability data, and perform vulnerability association mining and analysis through the vulnerability knowledge graph to generate key vulnerability nodes.

[0020] The correlation analysis module is used to perform dependency conflict detection at the critical nodes of the vulnerability to generate evaluation guidance indicators, use the evaluation guidance indicators to perform vulnerability mutation analysis to extract the core attributes of the vulnerability, and construct key evaluation enhancement areas based on the core attributes of the vulnerability.

[0021] The blind spot compensation module is used to scan the original vulnerability data to identify blind spots and generate a blind spot distribution map, extract missing features from the blind spot distribution map to generate a missing feature set, construct a compensation and repair strategy group from the missing feature set using compensation strategies, and adjust vulnerability priorities using the compensation and repair strategy group to generate a hybrid repair processing area. The step of constructing the compensation and repair strategy group from the missing feature set includes: performing compensation target positioning on the missing feature set to generate a compensation anchor set; identifying compensation conflict patterns from the compensation anchor set to generate conflict avoidance rules; expanding the applicable boundaries of the conflict avoidance rules to generate extended compensation rules; and integrating the rules based on the extended compensation rules to generate the compensation and repair strategy group.

[0022] The reliability verification module is used to perform reliability analysis on the hybrid repair processing area to determine the high reliability area and the low reliability area, set a preset risk weight for the high reliability area, set a compensation enhancement weight for the low reliability area, and construct a graded repair verification area using the compensation enhancement weight and the preset risk weight.

[0023] The conflict avoidance module is used to merge the graded repair verification area with the key evaluation enhancement area to generate a repair coordination coefficient. The repair coordination coefficient is used to predict execution conflicts of the compensation repair strategy group and identify potential execution conflict points. A conflict avoidance sequence is constructed based on the potential execution conflict points, and the full life cycle management of network vulnerabilities is completed based on the conflict avoidance sequence.

[0024] The beneficial effects of this invention are reflected in the following points: 1. By constructing a vulnerability knowledge graph and combining it with propagation strength analysis technology, the propagation path of vulnerabilities in asset-dependent networks is revealed, and vulnerability nodes located at key positions in the attack chain are identified. This fully considers the actual exposure surface and business impact of vulnerabilities in specific environments, avoiding the problems of over-patching of high-scoring, low-risk vulnerabilities and omission of low-scoring, high-risk vulnerabilities caused by relying solely on general scoring. Simultaneously, by employing vulnerability evolution tracking and post-patching reproduction pattern analysis, core attributes that remain stable across different versions and environments are extracted, and key assessment and enhancement areas are established. This ensures that protective measures focus on the fundamental exploitation mechanism rather than superficial triggering conditions, so that even if new variants of vulnerabilities emerge, protection based on core attributes remains effective.

[0025] 2. Traditional scanning tools have limited detection capabilities when dealing with service mesh communication, two-way authentication interfaces, and isolated network partitions, resulting in numerous detection blind spots. This invention systematically locates hard-to-cover areas such as container environments, encrypted communication, and isolated regions through scanning blind spot identification and compensation strategy construction technology. It designs targeted compensation schemes to fill coverage blind spots, ensuring that all asset types receive sufficient vulnerability detection. Combined with vulnerability priority adjustment and hybrid remediation processing area generation technology, it reassesses the true risk level of vulnerabilities based on the coverage capability of the compensation strategy, classifying vulnerabilities into three levels: immediate remediation, planned remediation, and compensatory protection, achieving differentiated remediation resource allocation. 3. Trust propagation and reliability analysis technologies are used to quantify the credibility of different remediation measures, identifying high-reliability and low-reliability areas and assigning weights to them. This avoids resource waste in high-reliability areas while ensuring sufficient compensatory protection for low-reliability areas. During the remediation execution phase, an execution dependency monitoring network is built to identify dependency offset points and execution interference clusters, predicting potential resource competition, dependency conflicts, and time window conflicts, and generating conflict avoidance sequences, effectively preventing patch deployment failures and business interruptions. By embedding conflict avoidance mechanisms into the entire lifecycle management process, closed-loop automated management from discovery to verification is achieved, shortening the vulnerability remediation cycle and improving the overall security operation efficiency. Attached Figure Description

[0026] The accompanying drawings illustrate specific examples of the technical solutions described in this invention and, together with the detailed embodiments, form part of the specification, serving to explain the technical solutions, principles, and effects of this invention.

[0027] Unless otherwise specified or defined, the same reference numerals in different figures represent the same or similar technical features, and different reference numerals may be used to represent the same or similar technical features.

[0028] Figure 1 This is a flowchart illustrating a method for managing the entire lifecycle of network vulnerabilities according to the present invention.

[0029] Figure 2 This is a structural block diagram of a network vulnerability lifecycle management system according to the present invention. Detailed Implementation

[0030] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0031] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0032] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0033] The technical solutions of the embodiments of this application will be described below.

[0034] like Figure 1 As shown, this embodiment of the invention provides a method for full lifecycle management of network vulnerabilities, including the following steps S110-S150:

[0035] Step S110: Obtain the original data of network vulnerabilities, construct a vulnerability knowledge graph based on the original vulnerability data, and generate key vulnerability nodes through vulnerability association mining and analysis using the vulnerability knowledge graph.

[0036] Specifically, this involves acquiring raw network vulnerability data. Raw network vulnerability data is collected from national vulnerability databases, security bulletin platforms, open-source community disclosures, and internal enterprise security scanning systems. This raw data includes fields such as vulnerability identifier, severity score, affected component version, vulnerability type, and attack vector. The collected raw data undergoes format standardization, unifying CVE numbering formats, standardizing CVSS scoring representations, and standardizing component version numbers. The vulnerability description text in the raw data is parsed to extract key information such as vulnerability triggering conditions, exploitation methods, and impact scope. For example, a company's security team discovered an SQL injection vulnerability in a web application during routine scans and also detected a remote code execution vulnerability in the open-source component Apache Struts. This data from different sources needs to be uniformly collected into the raw network vulnerability database. The raw data is then correlated with the company's asset inventory to establish a correspondence between vulnerabilities and affected servers, application systems, and network devices. The temporal attributes of the raw data are analyzed, recording the vulnerability disclosure time, patch release time, and internal discovery time. After a zero-day vulnerability is publicly disclosed, the security team needs to quickly confirm from the raw data whether the affected component version is being used internally.

[0037] A vulnerability knowledge graph is constructed based on raw vulnerability data. Entities and relationships are extracted from the raw network vulnerability data to establish the basic structure of the vulnerability knowledge graph. Each vulnerability in the raw vulnerability data is converted into a vulnerability node in the graph, with node attributes including vulnerability identifier, severity, vulnerability type, and affected components. Software packages, libraries, frameworks, and services in the raw vulnerability data are converted into component nodes. Servers, application systems, and network devices recorded in the raw vulnerability data are converted into asset nodes. Relationship edges between nodes are constructed based on the association information in the raw vulnerability data. For example, if a web application depends on the Spring framework, and the Spring framework depends on the Commons-Collections component, when a deserialization vulnerability is discovered in Commons-Collections from the raw vulnerability data, an "impact relationship" edge is established in the vulnerability knowledge graph from the vulnerability node to the Commons-Collections component node, and a "dependency relationship" edge is established from the Spring component node to the Commons-Collections component node. The association patterns between vulnerabilities in the raw vulnerability data are analyzed, and "exploitation chain relationship" edges are established between vulnerability nodes in the vulnerability knowledge graph. Some attackers combine privilege escalation vulnerabilities and file read vulnerabilities to achieve a complete attack chain. This combined exploitation relationship is represented in the vulnerability knowledge graph as collaborative exploitation edges between multiple vulnerability nodes. The vulnerability knowledge graph is constructed by integrating all entities and relationships from the original vulnerability data.

[0038] In some embodiments, generating critical vulnerability nodes through vulnerability association mining and analysis using the vulnerability knowledge graph includes: extracting propagation intensity features from the vulnerability knowledge graph; identifying low-propagation areas and extracting hidden propagation paths based on the propagation intensity features; performing dependency tracing on the hidden propagation paths to generate high-risk propagation points; and determining critical vulnerability nodes based on the high-risk propagation points.

[0039] Propagation intensity features are extracted from the vulnerability knowledge graph. The propagation probability of each vulnerability propagation path in the vulnerability knowledge graph is evaluated. The propagation probability is jointly determined by vulnerability exploitability, component dependency strength, and asset exposure level, and is calculated using the formula P = w1 × E + w2 × D + w3 × X, where P is the propagation probability, E is the exploitability score, D is the dependency strength coefficient, X is the exposure level coefficient, and w1, w2, and w3 are weighting coefficients. Vulnerabilities with high exploitability and publicly available exploit code have a higher propagation probability in the vulnerability knowledge graph. For tightly dependent component chains, the propagation probability decays slowly along the dependency chain in the vulnerability knowledge graph. The spread speed of vulnerabilities in the vulnerability knowledge graph is statistically analyzed, and the spread speed is measured by the growth rate of the number of affected nodes per unit time. Some worm-like vulnerabilities can be automatically exploited and propagated, exhibiting extremely rapid spread speeds in the vulnerability knowledge graph, infecting a large number of host nodes within hours. The directional characteristics of vulnerability propagation in the vulnerability knowledge graph are analyzed to identify intrusion paths from the external network to the internal network and data transfer paths from the internal network to the external network. The propagation strength index in the vulnerability knowledge graph is evaluated. Propagation strength comprehensively considers propagation probability, diffusion speed, and propagation direction, reflecting the activity level of the vulnerability in the graph. The propagation probability, diffusion speed, and propagation directionality of each vulnerability node are integrated into a propagation strength feature, which provides a data foundation for subsequent identification of low-propagation areas.

[0040] For example, identifying low-propagation areas and extracting hidden propagation paths based on the propagation intensity features includes: dividing and identifying low-propagation areas according to the propagation intensity features using an intensity threshold; detecting abnormal propagation fluctuations within the low-propagation areas to generate a fluctuation marker set; extracting unconventional connection channels based on the fluctuation marker set; and combining the low-propagation areas and the unconventional connection channels to determine hidden propagation paths.

[0041] Low-propagation areas are identified by using intensity thresholds based on propagation intensity characteristics. The distribution of propagation intensity characteristics for all nodes in the statistical knowledge graph is analyzed, and histograms and cumulative distribution curves of propagation intensity are plotted. The statistical properties of the propagation intensity characteristics are analyzed, and the mean, median, and standard deviation are calculated. A propagation intensity threshold is set, and nodes with propagation intensity below the threshold are classified as low-propagation areas. The threshold setting needs to balance coverage and identification accuracy. One company classified nodes with propagation intensity below the mean into low-propagation areas; these nodes include inconspicuous devices such as internal network print servers, testing environments, and developer workstations. Low-propagation areas are then divided and labeled, completing the identification of low-propagation areas. The identification of low-propagation areas provides an analytical scope for subsequent anomaly fluctuation detection.

[0042] Detect abnormal propagation fluctuations within low-propagation areas to generate a fluctuation tag set. Monitor the temporal changes in propagation intensity of nodes within low-propagation areas, and assess the amplitude and frequency of propagation intensity fluctuations. Under normal circumstances, the propagation intensity in low-propagation areas should remain stable. If the propagation intensity of a node in a low-propagation area suddenly increases or exhibits periodic fluctuations, it may indicate that the node is being exploited by attackers or exhibiting abnormal activity. An idle test server on a company's intranet normally has extremely low propagation intensity, but its propagation intensity suddenly increased over a period of time. Investigation revealed that attackers were using this server as a C2 control terminal to communicate with compromised intranet hosts. Identify abnormal patterns of propagation intensity fluctuations in low-propagation areas, including sudden increases, sudden decreases, and periodic fluctuations. Sudden increases may correspond to the occurrence of attacks, while sudden decreases may correspond to the activation of protective measures or the shutdown of nodes. Mark the detected abnormal fluctuations to generate a fluctuation tag set. Analyze the geographical location and network topology of the nodes in the fluctuation tag set to identify potential lateral movement attack paths. A company discovered that multiple nodes in low-propagation areas located in different departments simultaneously exhibited propagation intensity fluctuations, indicating that attackers were attempting lateral spread within the intranet.

[0043] Unconventional connection channels are extracted based on fluctuation marker sets. The connection relationships between nodes in the fluctuation marker set are analyzed to identify the connection patterns between these nodes and other nodes. Frequent communication or data exchange exists between nodes in certain fluctuation marker sets; these connections should not exist in normal business logic and are considered unconventional connections. For example, a company discovered an abnormal SSH connection between an employee's computer in the office area and a web server in the DMZ zone. In normal business operations, employee computers should not directly access the DMZ server; this connection was identified as an unconventional channel. The protocol type and port number of unconventional connections are checked to identify connections using non-standard protocols or ports. Attackers often use tunneling techniques to disguise malicious traffic as normal HTTP or DNS traffic in order to bypass firewall rules. The traffic characteristics of unconventional connections are analyzed to identify connections with abnormal data transmission direction and volume. Some connections used for data theft exhibit continuous large-volume data transmission from the internal network to the external network, with a clear unidirectional and continuous traffic pattern. The duration and activity level of unconventional connections are evaluated; long-lasting and frequently active connections may be stable channels established by attackers. The identified irregular connections are then integrated into unconventional connection channels.

[0044] Hidden propagation paths are identified by combining low-propagation areas and unconventional connection channels. A complete path is constructed from the external attack entry point to internal critical assets, consisting of jumper nodes in low-propagation areas and unconventional connection channels connected in series. In a certain APT attack, attackers first compromised employee computers via phishing emails, then used unconventional connections between employee computers and the test environment to enter the low-propagation area, and finally entered the core node through the weak isolation between the test and production environments. The entire attack path bypassed the main external network protection measures. The exploitability of the hidden propagation path is assessed, determined by the strength of the weakest link in the path. The threat level of the hidden propagation path is assessed by comprehensively considering the characteristics of the low-propagation area and the attributes of the unconventional connection channels, taking into account exploitability, the value of the endpoint asset, and the concealment of the path. Paths with high threat levels are identified as key hidden propagation paths for focus. Critical nodes and weaknesses on the hidden propagation path are analyzed to provide a basis for subsequent security hardening. A company discovered a highly threatening hidden propagation path with three unpatched vulnerable nodes and two improperly configured permissions. An emergency response process should be initiated immediately for remediation.

[0045] Dependency tracing is performed along hidden propagation paths to generate high-risk propagation points. Forward dependency tracing follows the hidden propagation path, starting from the vulnerability node and tracing back to all directly and indirectly dependent component nodes. A vulnerability in a low-level network library may be indirectly depended upon by dozens of upper-layer applications; forward tracing can fully identify the scope of affected applications. Reverse dependency tracing follows the hidden propagation path, starting from critical asset nodes and tracing back to all potential vulnerability sources affecting that asset. An enterprise's core database server may be threatened by multiple indirect vulnerabilities; reverse tracing can identify all potential attack entry points. Vulnerable links in the dependency chain along the hidden propagation path are analyzed to identify nodes lacking effective protection and easily breached. Some dependent components, while not inherently vulnerable, can become weak points due to improper configuration or excessive privileges. Key transit nodes are identified during dependency tracing and marked as high-risk propagation points. These points are located at the intersection of multiple hidden propagation paths; controlling these nodes can affect a large number of downstream assets.

[0046] Identify critical vulnerability nodes based on high-risk propagation points. Assess the strategic value of each high-risk propagation point, determined by the importance of the assets controlled by that point and its scope of impact. A web gateway located in the DMZ area connects to both the external network and the core internal network, making it extremely valuable; any vulnerability affecting this gateway should be considered critical. Analyze the correlation between high-risk propagation points and known attack events. If a high-risk propagation point has been frequently exploited in historical attacks, it indicates that attackers have mastered the penetration methods through that point. Considering the strategic value, historical attack frequency, and current protection strength of high-risk propagation points, rank them by threat level. Mark the vulnerabilities corresponding to the highest-threat propagation points as critical vulnerability nodes. These critical vulnerability nodes require priority remediation and intensive protection. Identifying critical vulnerability nodes provides priority guidance for vulnerability remediation and security hardening, ensuring that limited security resources are invested in the most critical risk points.

[0047] Step S120: Implement dependency conflict detection at critical vulnerability nodes to generate assessment guidance indicators, use the assessment guidance indicators to perform vulnerability mutation analysis and extract core vulnerability attributes, and construct key assessment enhancement areas based on the core vulnerability attributes.

[0048] Specifically, dependency conflict detection is implemented at critical vulnerability nodes to generate assessment guidance indicators. For components affected by critical vulnerability nodes, their dependency structures are extracted, including all levels of direct and indirect dependencies. For example, a web application depends on Spring framework version 5.2.8, which in turn depends on Commons-BeanUtils version 1.9.3, demonstrating this multi-level nested dependency structure. Version conflicts and compatibility issues are detected in the dependencies at critical vulnerability nodes. Conflicts occur when different versions of the same component are referenced by multiple dependents simultaneously, leading to runtime loading uncertainty. In an enterprise application, module A depends on Jackson version 2.9.8, and module B depends on Jackson version 2.11.2; a dependency conflict occurs when both modules run simultaneously. Changes in dependency compatibility after security patch application are also detected. Some vulnerability fixes force upgrades of dependent library versions, potentially introducing new incompatibility issues. For instance, an enterprise upgraded its Log4j version after fixing a vulnerability, resulting in a dependency conflict with an older version of Elasticsearch. The impact of dependency conflicts at critical vulnerability nodes on vulnerability exploitation is assessed, and the conflict impact factor C = Σ(s_i × d_i) is calculated, where C is the total conflict impact score, s_i is the severity of the i-th conflict, and d_i is the propagation depth of the conflict. A certain deserialization vulnerability can only be triggered under a specific version combination; version conflicts prevent this combination from forming, reducing the vulnerability risk. The impact degree, severity level, scope of involved components, and security impact assessment of dependency conflicts are integrated into assessment guidance indicators. These indicators provide guidance on detection priorities and focus areas for subsequent vulnerability mutation analysis.

[0049] In some embodiments, the step of using the assessment guidance indicators to perform vulnerability mutation analysis and extract core vulnerability attributes includes: constructing a vulnerability evolution tracking view based on the assessment guidance indicators; performing reverse mutation identification on the vulnerability evolution tracking view to extract reproducible patterns after remediation; generating a stable attribute set by measuring attribute stability from the reproducible patterns after remediation; and performing key screening on the stable attribute set to extract core vulnerability attributes.

[0050] A vulnerability evolution tracking view is constructed based on assessment guidance metrics. Utilizing dependency conflict information and version relationships from these metrics, the evolution path of a vulnerability across different versions is plotted. The vulnerability evolution tracking view uses time as the horizontal axis and component version as the vertical axis, marking the existence status and characteristic changes of the vulnerability in each version. The evolution tracking view for an Apache Struts vulnerability shows that it was introduced in version 2.3.5, fixed in version 2.3.20, but reappeared in a different form in version 2.5.0 due to code refactoring. The vulnerability evolution tracking view marks the release dates and fix status of security patches, with patch nodes dividing the evolution path into pre-fix and post-fix stages. An enterprise analyzed the fixing process of an XSS vulnerability and found that the initial patch added HTML escaping functions to the output points but failed to handle JSON output scenarios, resulting in an incomplete fix. The vulnerability evolution tracking view marks nodes where the vulnerability reappears, indicating that the vulnerability appeared in a new version after being fixed. A kernel privilege escalation vulnerability was patched in version 3.10, but a similar vulnerability was reintroduced in version 4.4 due to a kernel module refactoring. The vulnerability evolution tracking view was analyzed to determine the vulnerability distribution density across versions, identifying version ranges with high vulnerability concentration. Priority information from evaluation boot metrics was integrated to highlight high-risk versions and key evolution paths in the vulnerability evolution tracking view, thus completing the construction of the vulnerability evolution tracking view.

[0051] Reverse mutation identification is performed on the vulnerability evolution tracking view to extract recurring patterns after patching. Version nodes that reappear after patching are identified from the vulnerability evolution tracking view; these nodes indicate that the vulnerability reappeared in the same or similar form after being patched. Based on the vulnerability evolution tracking view, the code characteristics of the recurring vulnerability are compared with the original vulnerability to identify common code patterns and logical flaws. An authentication bypass vulnerability reappeared after being patched; comparison revealed that both versions had insufficient validation of user-input session tokens. Code pattern characteristics of the recurring vulnerability after patching were extracted; these patterns included insecure API calls, missing input validation, and incorrect permission checks. An SQL injection vulnerability reappeared multiple times; the pattern characteristic was the use of string concatenation to construct SQL queries, with typical code being "SELECT * FROM users WHERE id="+userId". The recurring pattern characteristic of a CSRF vulnerability was the lack of token verification when adding new API interfaces. The recurring pattern of a path traversal vulnerability was the failure to call the path normalization function before file operations, allowing attackers to access parent directories using the ".. / " symbol. The reproduction pattern of a certain command injection vulnerability is that user input is directly passed to `Runtime.exec()` without any filtering or escaping. The identified reproducible code pattern characteristics are integrated into a post-repair reproduction pattern, which reflects the types of security flaws that are easily and repeatedly introduced during development.

[0052] A stable attribute set is generated by measuring attribute stability in the reproducible patterns after patching. The attribute characteristics in the reproducible patterns are analyzed, including triggering conditions, exploitation methods, impact scope, and patching difficulty. The reproducible patterns of a command injection vulnerability show that, regardless of the version, the triggering condition is unfiltered user input directly passed to the system command execution interface. A metric for attribute stability is defined, assessed by the retention rate of the attribute across different reproducible versions, calculated as S = N_c / N_t, where S is the stability score, N_c is the number of versions where the attribute remains consistent, and N_t is the total number of reproducible versions. Stability is measured for each attribute characteristic in the reproducible patterns, and the occurrence of the attribute across all reproducible versions is statistically analyzed. The "XML external entity parsing" attribute of a certain XXE vulnerability exists in all reproducible versions, with a stability score close to perfect. Attributes with stability scores above a threshold are selected; this threshold is typically set high to ensure the persistence of the selected attributes. The prevalence of high-stability attributes is verified by checking whether these attributes remain stable across different types of vulnerability mutations. A certain type of buffer overflow vulnerability exhibits a stable characteristic across various variants, including stack overflows and heap overflows, where the requirement to "construct excessively long inputs" remains consistent. Attributes with high stability metrics are extracted into a stable attribute set, which contains the core features that persist throughout the vulnerability's evolution.

[0053] The stable attribute set is critically screened to extract core vulnerability attributes. The criticality of each attribute in the stable attribute set for vulnerability exploitation is evaluated; criticality is determined by the strength of the causal relationship between the attribute and vulnerability triggering and exploitation. An attribute is considered highly critical if its absence renders the vulnerability completely unexploitable. For example, a deserialization vulnerability requires a specific class to exist in the classpath for exploitation; this "class dependency" attribute is highly critical. The dependencies between attributes in the stable attribute set are analyzed to identify core and derived attributes. Core attributes are the essential characteristics of the vulnerability, while derived attributes are the manifestations of core attributes in specific environments. For example, the core attribute of a file upload vulnerability is "server-side unverified file content," while derived attributes include "allowing upload of executable files" and "uploaded files can be accessed and executed." The detectability and defensibility of attributes in the stable attribute set are evaluated; highly critical and detectable attributes are ideal candidates for core attributes. For example, the "unescaped output point" attribute of an XSS vulnerability is both highly critical and easily detected through static analysis. The stable attribute set is ranked by criticality based on a comprehensive assessment of stability score, criticality, core-derived relationships, and detectability. The ranking calculation formula is K = w1 × S + w2 × C + w3 × D, where K is the criticality score, S is the stability score, C is the criticality score, D is the detectability score, and w1, w2, and w3 are the corresponding weighting coefficients. The top few attributes with the highest criticality scores are selected as the core vulnerability attributes to ensure that the set of core attributes is concise and representative.

[0054] Based on the core attributes of the vulnerabilities, key assessment and enhancement areas are constructed. The system components and configuration items requiring key assessment are identified based on the core attributes of the vulnerabilities, as these components and configuration items are directly related to the core exploitation mechanism of the vulnerability. For example, the core attribute of a deserialization vulnerability is its reliance on specific class loader behavior; therefore, the key assessment and enhancement areas should focus on the application's class loading configuration and deserialization call points. Deep detection mechanisms are deployed within these key assessment and enhancement areas, including code auditing rules, runtime monitoring probes, and penetration test cases. For example, targeting the core attribute of an SQL injection vulnerability (user input directly concatenating SQL statements), an enterprise deployed parameterized query detection rules at all database query code locations. Enhanced security policies are configured for these key assessment and enhancement areas, including stricter input validation, finer-grained access control, and more sensitive anomaly alerts. For example, targeting the core attribute of a file upload vulnerability in a web application (insufficient file type validation), whitelist verification and magic number detection mechanisms are configured at the file upload interface.

[0055] Step S130: Scan the original vulnerability data to identify blind spots and generate a blind spot distribution map. Extract the missing features from the blind spot distribution map to generate a missing feature set. Construct a compensation and repair strategy group by applying a compensation and repair strategy group to adjust the vulnerability priority and generate a hybrid repair processing area.

[0056] Specifically, the process involves identifying blind spots in the raw vulnerability data to generate a blind spot distribution map. The source and scanning coverage of the raw vulnerability data are analyzed to identify which assets, components, and network areas are not covered by the scanning tools. For example, one company's vulnerability scanning tool primarily covers externally exposed web servers and databases, but has low coverage for containerized microservices, IoT devices, and isolated internal network areas. Data integrity issues in the raw vulnerability data are detected, including assets that failed to scan, unidentified component versions, and missing configuration information. For some services using non-standard ports or applications using custom protocols, conventional scanning tools cannot correctly identify their component information. The scanning coverage rate for different asset types is calculated using the formula R = N_s / N_t, where R is the coverage rate, N_s is the number of scanned assets, and N_t is the total number of assets. One company found that the scanning coverage rate for virtual machine assets was 85%, but the coverage rate for container assets was only 40%. Technical blind spots of the scanning tools are identified, including encrypted communication scenarios, agentless deployment environments, and application layers requiring authentication. The blind spot distribution map, organized by asset type, network region, and component category, compiles coverage statistics, technical blind spot distribution information, and scan failure area markers for various assets.

[0057] In some embodiments, the step of extracting coverage missing features from the blind zone distribution map to generate a missing feature set includes: scanning the blind zone distribution map to identify blind zones and establish a gap identifier set; performing a missing intensity assessment on the gap identifier set to obtain a blind zone feature spectrum; performing missing range delimitation based on the blind zone feature spectrum to determine the coverage blind zone boundary; and extracting missing features based on the coverage blind zone boundary to generate a missing feature set.

[0058] The blind spot distribution map is scanned to identify blind spots and establish a gap identifier set. Areas with abnormal scanning coverage are located within the blind spot distribution map; these areas represent gaps that are completely untouched by vulnerability scanning tools or where scanning results are poor. For example, a company's blind spot distribution map shows that a subnet segment in its development and testing environment has zero scan coverage, indicating the deployment of numerous temporary test servers in this area. Areas with abnormally low scanning frequency are identified based on the blind spot distribution map; these areas have scan records, but the scan intervals far exceed security policy requirements. Abnormal scanning results are detected in the blind spot distribution map; anomalies include high scan failure rates, low component identification rates, and abnormal vulnerability detection rates. For instance, the component identification rate of an application cluster is only 30%, with many dependent libraries not correctly identified. High-value asset blind spots are marked in the blind spot distribution map; high-value assets include core business systems, sensitive data storage, and critical network nodes. For example, a company's payment gateway server, due to its special security hardening measures, is undetectable by scanning tools. The gap identifier set records blind spots in core systems such as development and testing environment subnets that are completely unreachable, low-frequency areas with scan intervals that have exceeded the deadline, application clusters with a component recognition rate of only 30%, and payment gateways where detection is hindered due to security hardening.

[0059] For example, the step of performing a missing intensity assessment on the gap identifier set to obtain a blind zone feature spectrum includes: measuring the gap density based on the gap identifier set to obtain a density distribution; performing low-density area anomaly detection on the density distribution to identify anomalous clustering points; extracting missing intensity attributes from the anomalous clustering points to generate an intensity attribute set; and performing feature extraction on the intensity attribute set to obtain a blind zone feature spectrum.

[0060] The density distribution is obtained by measuring the density of blind spots based on the gap identifier set. The blind spots in the gap identifier set are spatially mapped according to the network topology, and the location and extent of each blind spot are marked on the network topology map. A company's network topology is divided into a DMZ zone, office network, production network, and development network. Marking on the topology map reveals a large number of blind spots in the production and development networks. The number of blind spots within each network area in the gap identifier set is counted, and the blind spot density is calculated. The density calculation formula is D=N_b / A, where D is the density, N_b is the number of blind spots in the area, and A is the area (measured by the number of IP address ranges or subnets). A certain / 24 subnet has 8 blind spots, while an adjacent subnet of the same size has only 1 blind spot; the former has a significantly higher density. A spatial distribution map of the blind spot density is drawn to identify high-density and low-density areas. The company's development environment has the highest density, the DMZ zone has the lowest density, and the office and production networks are at a medium level. The spatial clustering characteristics of the density distribution are analyzed to identify whether the blind spots are randomly distributed or exhibit a clear clustering pattern. Some enterprises exhibit highly concentrated blind spots in their container clusters, while the blind spots in virtual machine areas are more dispersed. Through spatial mapping and density calculation, the density distribution reveals the degree of blind spot concentration in each network area. The development environment has the highest density, while the DMZ area has the lowest density. Container clusters show a clear spatial distribution pattern, while virtual machine areas are relatively dispersed.

[0061] Anomaly detection is performed on low-density areas within the density distribution to identify anomalous clusters. These areas are located within the density distribution, potentially representing well-covered sample areas or overlooked, neglected corners. For example, a subnet of a company had zero density; investigation revealed this area contained a newly built edge computing node cluster not yet under centralized management. Isolated blind spots are searched within low-density areas of the density distribution, contrasting sharply with the surrounding high-coverage environment. A single blind spot host within a well-covered production network was identified as an industrial control device using a special operating system. Abnormal clustering patterns in low-density areas of the density distribution are identified; although the overall density is low, a few blind spots exhibit non-random clustering. For instance, a company's DMZ had high overall scan coverage, but three adjacent load balancers were found to have blind spots, indicating scanning difficulties for specific device types. The causes of these anomalous clusters are analyzed, including management oversights, technical obstacles, business specificity, and security policy restrictions. Some anomalies arose because new equipment was purchased but the scanning tools were not yet compatible, while others were due to unclear responsibilities caused by organizational restructuring. These anomalies encompassed management oversights in newly built edge computing node clusters, isolated blind spots in industrial control equipment with special operating systems in the production network, and difficulties in scanning three adjacent load balancers in the DMZ. These anomalies reflect blind spot formation patterns caused by management oversights, technical obstacles, and the unique characteristics of the equipment.

[0062] A set of strength attributes is generated by extracting missing strength attributes from anomaly clusters. The importance, exposure level, and historical risk of assets within the anomaly clusters are comprehensively assessed to calculate the missing strength of the anomaly clusters. One anomaly cluster is located in the database cluster of a payment system. Although the number of blind spots is small, the exploitation of any one of these blind spot vulnerabilities could lead to a major security incident. The attack exposure surface of the blind spots within the anomaly clusters is assessed, including whether they are directly exposed to the internet, whether they connect to sensitive data, and whether they are located on attack paths. Some anomaly clusters, although located deep within the internal network, can be accessed externally via VPNs or jump servers, and their exposure surface is assessed as moderate. Historical security event records for the blind spots within the anomaly clusters are statistically analyzed, including past vulnerability exploits, intrusion attempts, and configuration errors. Two security incidents have occurred in the area where a certain anomaly cluster is located in the past year, indicating that this area does indeed have value for attackers. The strength attribute set integrates the missing strength calculation results, attack exposure surface assessment data, and historical security event statistics for each anomalous cluster point, quantifying the extremely high risk of blind spots in the payment system database cluster, the medium exposure surface of VPN-reachable internal network nodes, and the actual threat level of areas where two security incidents have occurred.

[0063] Feature extraction is performed on the intensity attribute set to obtain a blind spot feature spectrum. Multi-dimensional features of blind spots are extracted from the intensity attribute set, including risk level, technology type, and evolution trend. High-risk blind spots typically feature high asset value, high exposure, and low protection strength. Technical features of blind spots are extracted from the intensity attribute set; some blind spots are due to the use of encrypted communication protocols, while others are due to deployment in container or serverless environments. Management features are extracted from the intensity attribute set; the root cause of some blind spots is the unclear asset management responsibility after organizational restructuring. Evolutionary features are extracted from the intensity attribute set; some blind spots continue to expand with cloud-native transformation, while others gradually shrink with the improvement of scanning tool capabilities. Through multi-dimensional feature extraction, the blind spot feature spectrum covers the superposition of high asset value and high exposure at the risk level, the scanning barriers formed by encrypted protocols and container environments at the technical level, the unclear responsibility caused by organizational restructuring at the management level, and the dynamic trend of blind spot expansion driven by cloud-native transformation and shrinkage promoted by improved tool capabilities at the evolution level.

[0064] The blind zone boundary is determined by performing a missing range delineation based on the blind zone feature spectrum. A threshold for defining the blind zone boundary is set according to the intensity distribution in the blind zone feature spectrum. Areas with intensity above the threshold are defined as core blind zones, requiring priority compensation coverage; areas with intensity below the threshold are defined as secondary blind zones, which can be compensated using simplified schemes. Based on the risk characteristic distribution of the blind zone feature spectrum, blind zone boundary lines are drawn on the blind zone distribution map, clearly distinguishing the fully scanned areas from the blind zones. An enterprise demarcates production networks from development networks, cloud assets from traditional data center assets, and container environments from virtual machine environments based on the boundaries determined by the blind zone feature spectrum. The evolutionary characteristics in the blind zone feature spectrum are analyzed to identify whether the boundaries expand or shrink over time. For some enterprises, containerization transformation has led to a continuous expansion of container blind zone boundaries, while the coverage boundaries of traditional virtual machines have correspondingly shrunk. Combining the technical characteristics of the blind zone feature spectrum, assets and traffic crossing the blind zone boundary are assessed; these cross-boundary elements may become springboards for attackers to penetrate from covered areas into blind zones. A springboard machine connecting both the production and development networks becomes a key node crossing the blind zone boundary. Based on intensity threshold classification and risk characteristic analysis, the coverage blind zone boundary clearly delineates the production network from the development network, cloud assets from traditional data centers, and container environments from virtual machine environments, and identifies key nodes that cross the boundary, such as jump servers that connect to both the production network and the development network.

[0065] Missing features are extracted from the coverage blind zone boundary to generate a missing feature set. Features leading to uneven scan coverage are extracted along the coverage blind zone boundary. One side of a company's coverage blind zone boundary consists of standardized virtual machines, while the other side consists of microservices orchestrated using containers. This difference in deployment methods results in varying applicability of scanning tools. Feature samples of typical assets are extracted from within the coverage blind zone boundary, and their common technical and business characteristics are analyzed. All applications within a certain blind zone use the gRPC protocol for inter-service communication, a key feature causing conventional HTTP scanning tools to fail. Connection features are extracted from cross-boundary nodes at the coverage blind zone boundary. These connection features describe the network topology and access relationships between the blind zone and the covered area. A cross-boundary node uses an SSH tunnel to connect assets within the blind zone; this connection method can be used to deploy blind zone scanning probes. The missing feature set combines features such as the differences in virtual machine and container deployment methods on both sides of the boundary, the gRPC protocol causing HTTP scanning failure within the blind zone, and SSH tunnel connections at cross-boundary nodes, revealing the impact mechanism of deployment technology, communication protocols, and access paths on scan coverage.

[0066] In some embodiments, constructing a compensation and repair strategy group by compensating the missing feature set includes: performing compensation target positioning on the missing feature set to generate a compensation anchor set; identifying compensation conflict patterns from the compensation anchor set to generate conflict avoidance rules; extending the applicable boundaries of the conflict avoidance rules to generate extended compensation rules; and performing rule integration based on the extended compensation rules to generate a compensation and repair strategy group.

[0067] The process involves identifying compensation targets and generating a compensation anchor set for the missing feature set. Based on the technical characteristics of the missing feature set, specific target objects requiring compensation coverage are determined. For containerized application blind spots, compensation targets include container images, runtime environments, and orchestration platforms; for encrypted traffic blind spots, compensation targets include SSL / TLS endpoints and application layer protocols. The priority and time window for compensation coverage are determined based on the business characteristics of the missing feature set. For core business system blind spots, compensation scanning should be performed during off-peak hours or maintenance windows; for test environment blind spots, coverage can be performed at any time. The network location and deployment method for compensation implementation are determined based on the environmental characteristics of the missing feature set. For network isolation areas, scanning probes need to be deployed within the isolation area; for areas with strict firewalls, temporary policy changes or proxy penetration need to be applied for. Anchor points are set for each compensation target; these anchor points are the starting point and control point for the compensation policy implementation. For a specific container environment, the compensation anchor points are set to the image repository and the Kubernetes API server. The compensation anchor set clarifies the implementation path for container environments using image repositories and Kubernetes APIs as anchor points, encrypted traffic using SSL / TLS endpoints as entry points, and isolated areas requiring the deployment of scanning probes internally. It also sets time windows for compensation during off-peak periods for core businesses and coverage at any time for test environments.

[0068] This process involves identifying compensation conflict patterns from the compensation anchor set and generating conflict avoidance rules. It analyzes potential conflicts between different compensation measures within the anchor set, including scenarios such as resource contention, policy confrontation, and business impact. Some compensation scanning tools require access to the same set of API interfaces, and concurrent execution may exceed interface rate limits. The process also analyzes conflicts between compensation measures in the anchor set and existing security policies, identifying potential security alerts or access denials triggered by compensation implementation. A compensation scanning probe's network behavior characteristics match intrusion detection rules, leading to its blocking by the IDS. Furthermore, it analyzes the potential impact of compensation measures in the anchor set on business operations, identifying risks of performance degradation or service interruption. Some intrusive compensation scans may increase application response latency, impacting user experience. Conflict patterns are extracted from the conflict scenarios identified in the anchor set, and avoidance rules are formulated for these scenarios, including time-shifting, resource isolation, and policy whitelisting. For resource contention scenarios, a time-shifting strategy is adopted; for policy confrontation scenarios, compensation tools are added to the security policy whitelist. For the three types of conflict scenarios identified—resource competition, strategy confrontation, and business impact—the conflict avoidance rule set includes measures such as staggered timing to deal with excessive concurrent access, whitelist exemption to avoid IDS blocking, and execution during off-peak hours to prevent response delays.

[0069] Extending the application boundaries of conflict avoidance rules to generate extended compensation rules. Evaluating the applicability and limitations of conflict avoidance rules, and identifying their effectiveness in different scenarios. A conflict avoidance rule designed for container environments may not be applicable to virtual machine environments. Expanding the application boundaries of conflict avoidance rules allows them to cover more compensation scenarios. Generalizing rules originally applicable to a single technology stack to universal rules applicable to multiple technology stacks. A rate limiting rule originally only applicable to Docker is extended to support Docker, Containerd, and Podman simultaneously. Adding conditional judgment logic during rule extension to dynamically adjust rule parameters based on the actual environment. An extended rule dynamically adjusts scan concurrency based on network bandwidth and system load. Verifying the effectiveness and security of extended rules to ensure that the extended rules do not introduce new conflicts or risks. An enterprise verified the extended rules in a test environment, confirming that the rules can correctly handle various boundary conditions. Extended compensation rules expand the original rate limiting rules for Docker to support Containerd and Podman, adding conditional judgment logic for dynamically adjusting scan concurrency based on network bandwidth and system load.

[0070] Compensation and remediation strategy groups are generated based on the integration of extended compensation rules and implementation rules. These extended compensation rules are categorized and integrated according to technical fields, forming strategies for container compensation, network compensation, and application compensation. Furthermore, they are chronologically integrated according to implementation phases, forming a comprehensive strategy covering the preparation, implementation, and verification phases. A company's compensation strategy includes early-stage network connectivity testing, mid-stage scan execution, and late-stage result verification. Implementation conditions and success criteria are configured for each compensation strategy. Some compensation strategies are set to automatically trigger image scans when a new container deployment is detected. The compensation and remediation strategy groups are divided into container compensation, network compensation, and application compensation strategies by technical field, and cover network connectivity testing, scan execution, and result verification in the preparation, implementation, and verification phases by process phase, with implementation trigger conditions such as automatically triggering image scans when a new container deployment is detected.

[0071] A hybrid remediation processing area is generated by adjusting vulnerability priorities through compensation and remediation strategy groups. The vulnerability risk level is reassessed based on the coverage capabilities of the compensation and remediation strategy groups. Some vulnerabilities initially marked as high-risk are downgraded in risk after compensation coverage reveals limited exposure. Priority is adjusted based on the implementation cost and timeframe of each strategy, calculated using the formula P = w1 × R + w2 × E - w3 × C, where P is the priority score, R is the risk level, E is the urgency of remediation, C is the remediation cost, and w1, w2, and w3 are weighting coefficients. A vulnerability requiring downtime for remediation, despite its high risk, is postponed to off-peak hours due to significant costs. Vulnerability scenarios suitable for hybrid remediation are identified, combining automated patching, virtual patching, configuration hardening, and manual remediation. In the hybrid remediation processing area, the risk level of vulnerabilities with limited exposure is downgraded, vulnerabilities with high downtime costs are postponed to off-peak hours, and production systems that cannot be patched immediately are protected using a combination of temporary WAF virtual patching and official updates via maintenance windows.

[0072] Step S140: Perform reliability analysis on the hybrid repair processing area to determine high reliability area and low reliability area, set a preset risk weight for the high reliability area, set a compensation enhancement weight for the low reliability area, and construct a graded repair verification area using the compensation enhancement weight and the preset risk weight.

[0073] In some embodiments, the step of performing reliability analysis on the hybrid repair processing area to determine high-reliability and low-reliability areas includes: performing trust propagation estimation on the hybrid repair processing area to obtain a trust propagation strength table; performing volatility detection on the trust propagation strength table to identify trust-unstable areas; performing anomaly analysis on the trust-unstable areas to determine potential risk indicators; and classifying the potential risk indicators to identify high-reliability and low-reliability areas.

[0074] A trust propagation strength table is obtained by estimating trust propagation in a hybrid remediation processing area. The dependencies of remediation measures in the hybrid remediation processing area are analyzed. For example, the vulnerability remediation of a web application depends on the underlying operating system and middleware patch status; unpatched dependent components will affect the reliability of application-layer remediation. A trust propagation model is established, where trust propagates from verified reliable remediation nodes to dependent nodes. After a database patch undergoes complete testing, its trust propagates to all application services connected to that database. The attenuation coefficient during propagation is calculated, determined by dependency strength and the reliability of intermediate links; trust decays step-by-step in the propagation chain. The propagation process of trust throughout the entire area is simulated, and the cumulative trust value of each node is calculated. A microservice node receives propagation from three basic services; the cumulative trust reflects the overall reliability of its remediation. The strength of propagation paths is statistically analyzed; strong paths indicate stable reliability transmission, while weak paths indicate obstructed transmission. The trust propagation strength table records the cumulative trust value and path strength of each node, quantifying the strong path propagation of the database patch, the cumulative trust of multiple dependency sources in the microservice, and the step-by-step attenuation pattern in the chain.

[0075] Volatility detection is performed on the trust propagation strength table to identify areas of trust instability. The temporal changes in trust levels for each node in the table are analyzed to identify nodes with abnormal trust fluctuations. A significant drop in trust levels for some nodes within a short period may indicate a failure of the fix or environmental changes. The amplitude and frequency of trust fluctuations in the table are calculated; amplitude reflects the drastic nature of the change, while frequency reflects its stability. A node's trust level dropped from 85% to 60% and then rebounded to 80% within a week, demonstrating high volatility. An abnormal threshold for trust fluctuations is set; nodes exceeding this threshold are marked as unstable nodes. In an application cluster, the front-end service has a trust level of 90%, while the back-end API service it calls has a trust level of only 45%, forming a clear trust cliff. The distribution characteristics of unstable nodes are analyzed to determine whether the instability is an isolated phenomenon or a systemic problem. An enterprise discovered that all services based on a certain open-source framework exhibited trust fluctuations, indicating a systemic reliability issue with the framework's fix. The area of ​​unstable trust includes abnormal nodes with significant fluctuations in trust levels within a week, call chains where trust cliffs are formed between front-end and back-end APIs, and systemic reliability fluctuations of a certain open-source framework service group.

[0076] Anomaly analysis is performed in unstable trust zones to identify potential risk indicators. This includes analyzing the anomalous characteristics of remediation measures in these zones, including remediation failure modes, protection bypass cases, and verification deficiencies. For example, remediation measures in a particular unstable trust zone frequently fail due to dependency conflicts, and the failure modes are repeatable. Historical security events in the unstable trust zone are examined to identify records of attacks or protection failures after remediation. For instance, two similar vulnerability exploits occurred in an unstable zone within one month of remediation, indicating that the remediation measures were not truly effective. Verification coverage in unstable trust zones is assessed to identify which remediation measures lack sufficient verification. Some remediation measures only underwent basic functional testing, without security regression testing and attack simulation verification. Environmental variables in unstable trust zones are analyzed to identify external factors that may affect remediation reliability. For example, a patch for a certain zone is effective in the test environment but fails in the production environment due to configuration differences. Potential risk indicators are extracted from anomaly characteristics, security events, verification deficiencies, and environmental factors, including a 25% remediation failure probability due to dependency conflicts, the residual attack risk from two vulnerability exploits within one month of remediation, coverage deficiencies due to only basic testing and lack of regression verification, and protection attenuation due to configuration differences between the test and production environments.

[0077] Potential risk indicators are used to classify and identify high-reliability and low-reliability zones. Based on the probability of patch failure, residual attack risk, and protection decay rate among the potential risk indicators, patch reliability levels are determined. Zones with a patch failure probability below 10% are designated as high-reliability candidate zones, while those above 30% are designated as low-reliability candidate zones. Some zones, although their main attack paths are blocked, still have variant attacks or bypass methods, resulting in insufficient protection integrity. The protective effect of some virtual patches or configuration hardening measures decays rapidly over time, requiring frequent updates and maintenance. A comprehensive reliability score for each zone is calculated based on these three indicators using the formula C = α × (1-P) + β × (1-R) ​​+ γ × E, where C is the reliability score, P is the failure probability, R is the residual risk, E is the continued effectiveness, and α, β, and γ are weighting coefficients. Classification thresholds are set based on the reliability scores: high-reliability zones include areas with sufficient patch repairs, complete verification, and continuous monitoring; low-reliability zones include areas with temporary protection, insufficient verification, or environmental constraints. Based on the comprehensive reliability score calculation, areas with a failure probability of less than 10%, no attack residue, and sufficient patches that provide continuous and effective protection are classified as high reliability areas, while areas with a failure probability of more than 30% and temporary protection that can be bypassed or decays rapidly are classified as low reliability areas.

[0078] Set preset risk weights for high-reliability zones. Identify potential risks still existing in high-reliability zones, comprehensively considering the completeness of remediation coverage, asset importance, and the impact of environmental changes. Although a core payment system has been fully patched, it still requires a high risk weight to ensure continuous monitoring due to its handling of sensitive transaction data. Assess the completeness of remediation coverage in high-reliability zones to identify any omissions or unaddressed boundary conditions. A company patched an application-layer SQL injection vulnerability, but stored procedure injection at the database layer was not covered. Analyze the importance level and attack value of assets in high-reliability zones; even if the patch is reliable, high-value assets still require a higher risk weight. Assess the impact of environmental changes in high-reliability zones; system updates, configuration changes, or network topology adjustments may affect the effectiveness of remediation measures. After a load balancer upgrade in a company's production environment, some of the original security configurations became invalid. Based on the assessment of remediation coverage completeness, asset importance analysis, and the impact of environmental changes, preset risk weights are used to assign a high weight to the core payment system for continuous monitoring, supplementary verification is added to areas not covered by stored procedure injection, and the detection frequency is increased for areas affected by environmental changes such as load balancer upgrades.

[0079] Assign compensation enhancement weights to low-reliability zones. Analyze the weaknesses in the remediation measures within low-reliability zones to identify the root causes of insufficient reliability. Some low-reliability zones are due to technical limitations preventing the implementation of standard remediation, while others are due to business constraints preventing downtime for patching. Assess the required compensation intensity for low-reliability zones, which is determined by both the size of the reliability gap and the risk of asset exposure. For a vulnerability in an industrial control system that cannot be patched, compensation is provided through network isolation and whitelisted access control, with the compensation intensity needing to achieve an equivalent protective effect to a patch. Design multi-layered compensation schemes for low-reliability zones, as a single compensation measure may be insufficient to fill the reliability gap, requiring a combination of multiple methods. A company uses a three-layered compensation approach for an SQL injection vulnerability in a legacy system: WAF protection, database least privilege, and anomaly monitoring. Assign weights to each layer of compensation measures in low-reliability zones, with the weight reflecting the measure's contribution to overall reliability. In one compensation scheme, WAF protection has a weight of 40%, access control has a weight of 30%, and monitoring and detection have a weight of 30%, with the weight allocation based on the protective effectiveness assessment of each measure. The compensation enhancement weight is based on the reliability gap and compensation scheme configuration. For industrial control systems that cannot be patched, the equivalent compensation strength of network isolation and whitelist control is set. For legacy systems with SQL injection, a three-layer weight allocation is set: 40% WAF protection, 30% access control, and 30% anomaly monitoring.

[0080] A tiered remediation and verification zone system is constructed using compensation-enhanced weights and preset risk weights. The preset risk weights of the high-reliability zone and the compensation-enhanced weights of the low-reliability zone are integrated to establish a unified risk assessment system. In a certain enterprise's risk assessment system, the high-reliability zone has a base score of 90 points, adjusted according to preset risk weights; the low-reliability zone has a base score of 60 points, adjusted according to compensation-enhanced weights. Based on the comprehensive risk score, the hybrid remediation processing zones are tiered into Level 1, Level 2, and Level 3 verification zones. Level 1 verification zones correspond to the highest risk or lowest reliability areas, requiring the most frequent verification and the most stringent monitoring. Differentiated verification strategies are configured for each verification zone, including verification frequency, verification depth, and verification methods. Level 1 verification zones are verified daily and undergo deep penetration testing; Level 2 verification zones undergo weekly routine testing; and Level 3 verification zones undergo monthly basic verification. A dynamic adjustment mechanism for verification zones is established, adjusting the zone tier in real time based on verification results and risk changes. An asset originally in the Level 2 verification zone is automatically promoted to the Level 1 verification zone if a new vulnerability is discovered or a remediation fails during verification. The graded remediation and verification areas are divided into Level 1, Level 2, and Level 3 verification areas based on risk scores. Differentiated strategies are configured for Level 1 daily deep penetration testing, Level 2 weekly routine testing, and Level 3 monthly basic verification. A dynamic adjustment mechanism is also established to automatically upgrade the verification level when new vulnerabilities are discovered.

[0081] Step S150: The hierarchical repair verification area and the key evaluation enhancement area are merged to generate a repair coordination coefficient. The repair coordination coefficient is used to predict execution conflicts of the compensation repair strategy group and identify potential execution conflict points. A conflict avoidance sequence is constructed based on the potential execution conflict points. The full lifecycle management of network vulnerabilities is completed based on the conflict avoidance sequence.

[0082] Specifically, a remediation synergy coefficient is generated by merging the tiered remediation and verification area with the key assessment and enhancement area. The overlapping areas between these areas are identified; these overlapping areas are critical regions requiring both remediation and verification, and key assessment simultaneously. For example, a company's core database server is located within both the tiered remediation and verification area and the key assessment and enhancement area for SQL injection vulnerabilities. The consistency and differences between the two areas in terms of asset coverage, vulnerability types, and protection strategies are analyzed. The tiered remediation and verification area focuses on reliability verification, while the key assessment and enhancement area focuses on in-depth protection. The enhancement effect and potential conflicts when the two areas work together are evaluated. The synergy effect manifests as complementary protection, while the potential conflict manifests as resource competition. A web application requires both remediation and verification scanning and continuous behavior monitoring; traffic aggregation may impact performance. The synergy strength between the two areas is calculated using the formula M = θ × O + φ × C - ψ × I, where M is the remediation synergy coefficient, O is the area overlap, C is the strategy consistency, and I is the resource interference. Based on the synergy strength, a collaborative working mode is configured: parallel protection is used for high-synergy areas, and time-sharing isolation is used for low-synergy areas. The repair coordination coefficient quantifies the coordination strength of overlapping assets such as core database servers, the complementarity of reliability verification and deep protection strategies, and the resource interference caused by the superposition of scanning and monitoring. Based on this, parallel protection for high coordination areas and time-sharing isolation mode for low coordination areas are configured.

[0083] In some embodiments, the step of predicting and identifying potential execution conflict points by using the repair coordination coefficient to assess the compensation repair strategy group includes: constructing an execution dependency monitoring network based on the repair coordination coefficient; mapping the compensation repair strategy group to the execution dependency monitoring network to obtain dependency offset points; performing conflict analysis on the dependency offset points to determine execution interference clusters; and identifying potential execution conflict points based on the execution interference clusters.

[0084] An execution dependency monitoring network is constructed based on the remediation synergy coefficient. A dependency topology between strategies is established based on the synergy strength information in the remediation synergy coefficient. The execution dependency monitoring network uses strategies as nodes and dependencies as directed edges, with edge weights representing dependency strength. A database patch strategy points to all application update strategies that depend on that database; edge weights are set according to dependency tightness. Execution constraints are labeled for each node in the execution dependency monitoring network, including prerequisite dependencies, resource requirements, and time windows. Constraints for a patch deployment strategy include the operating system version must be higher than a certain version, 4GB of memory is required, and execution must be performed within a maintenance window. Resource competition edges are established in the execution dependency monitoring network to identify strategy nodes that need to compete for the same resources. A vulnerability scanning strategy and a traffic monitoring strategy both require mirroring network traffic; a resource competition edge is established between them. Status monitoring points are configured in the execution dependency monitoring network to collect the execution status and resource usage of each strategy node in real time. The execution dependency monitoring network consists of policy nodes and directed edges of dependency relationships. It includes execution constraints such as the dependency topology of database patch pointing to application update, operating system version and memory requirements, resource conflict edges that scan and monitor competing network traffic, and status monitoring points that collect task start time and resource consumption.

[0085] The compensation and repair strategy group is mapped to the execution dependency monitoring network to obtain dependency offset points. Each strategy in the compensation and repair strategy group is mapped as a node to the execution dependency monitoring network, establishing a correspondence between strategies and network nodes. A certain WAF rule update strategy is mapped to an independent node in the network, with its dependency edge pointing to the vulnerability identification strategy of the web application. The actual dependency relationships of each strategy node after mapping are analyzed to see if they are consistent with the theoretical dependency relationships, identifying dependency offset phenomena. Dependency offsets include types such as inconsistent dependency relationships, implicit dependency transitivity, and circular dependencies. A certain application patching strategy theoretically only depends on operating system patches, but in actual execution, it is found that it also depends on a specific version of the runtime library, resulting in dependency offset. Implicit transitivity of dependency relationships is detected; some indirect dependencies are ignored in theoretical analysis. A certain microservice A depends on service B, and service B depends on service C. When the vulnerability repair of C fails, the repair of A is also affected, but the initial dependency analysis did not consider the transitive dependency from A to C. Circular dependencies and deadlock risks are identified; some strategies form a closed loop of mutual dependencies, causing execution failure. Dependency offsets include inconsistencies in dependencies where application patches actually depend on runtime libraries but are not theoretically included, implicit transitive dependencies from microservices A to C, and circular loops and deadlock risks formed by inter-strategy dependencies.

[0086] Conflict analysis is performed on dependency offsets to identify execution interference clusters. The severity of the conflict at each dependency offset is assessed, determined by the probability of execution failure and the scope of impact caused by the offset. An unresolved offset in a circular dependency will prevent both critical strategies from executing, thus its severity is assessed as high. The correlation between dependency offsets is analyzed to identify which offsets influence each other or cascade amplify the effect. A dependency offset causing resource allocation delays triggers time window conflicts for multiple downstream strategies, creating a cascading effect. Spatial clustering characteristics of dependency offsets are identified, showing a dense concentration of offsets in certain regions or systems. In a company's microservice architecture, all ServiceMesh-based services have dependency offsets because there is a complex dependency between patching vulnerabilities in the Mesh control plane and updating data plane services. Based on conflict severity, correlation, and spatial clustering characteristics, related dependency offsets are categorized into execution interference clusters. One interference cluster contains five interconnected dependency offsets, all involving upgrades to the container orchestration platform and patch deployments for containerized applications. The execution interference clusters are categorized by the severity of the conflict, their correlation, and spatial clustering characteristics. They include high-risk offset points of circular dependencies that prevent the execution of both key strategies, cascading time window conflicts caused by resource allocation delays, and five interrelated offset points in the ServiceMesh architecture that involve container orchestration upgrades.

[0087] Identify potential execution conflict points based on the execution interference cluster. Identify the conflict triggering conditions and critical states within the execution interference cluster to determine under what circumstances a conflict will actually occur. For example, a network bandwidth conflict is triggered when a certain interference cluster executes more than three tasks in parallel; this concurrency level is the conflict triggering condition. Identify key conflict nodes within the execution interference cluster; these nodes are the core links in the conflict propagation chain. For example, the patch deployment of a certain API gateway is a key node in the interference cluster; the execution delay of this node will affect the updates of all subsequent dependent services. Assess the avoidability of potential execution conflict points. Some conflicts can be avoided by adjusting the execution order or resource configuration, while others are systemic constraints that are difficult to avoid. A maintenance window conflict can be avoided by requesting an additional time window, but an architectural dependency conflict requires a redesigned fix. Calculate the risk priority for each potential execution conflict point using the formula Q = λ × S + μ × F + ν × U, where Q is the conflict risk score, S is the conflict severity, F is the frequency of occurrence, U is the unavoidability, and λ, μ, and ν are weighting coefficients. Potential execution conflict points include critical conditions for bandwidth conflicts triggered by more than 3 parallel tasks, critical propagation nodes where API gateway patch delays affect all dependent services, conflict types that can be avoided by maintenance windows but are difficult to avoid by architectural dependencies, and risk priority ranking based on severity and frequency of occurrence.

[0088] A conflict avoidance sequence is constructed based on potential execution conflict points. Avoidance strategies are designed for each potential execution conflict point, including time-shifting, resource isolation, strategy adjustment, and priority ranking. For network bandwidth conflicts among potential execution conflict points, a time-shifting execution strategy is adopted, scheduling vulnerability scanning during off-peak business hours; for maintenance window conflicts, high-risk vulnerabilities are prioritized based on risk level. Conflict avoidance decision rules are established, defining automated handling methods under different potential execution conflict point scenarios. When resource utilization exceeds a threshold, low-priority tasks are automatically suspended; when dependency conditions are not met, the execution of dependent tasks is automatically postponed. A dynamic adjustment mechanism for the conflict avoidance sequence is designed to adjust the avoidance strategy based on real-time feedback during execution. A patch task originally scheduled for execution in the early morning is automatically postponed to the same time the following day due to delays in preceding tasks. Monitoring and alarm mechanisms are configured for the conflict avoidance sequence to ensure that avoidance measures are effective and do not introduce new problems. An enterprise configures automatic monitoring; when the avoidance strategy causes a task delay exceeding 24 hours, an alarm is triggered to notify the administrator for intervention. The conflict avoidance sequence is configured to stagger execution during off-peak hours for network bandwidth conflicts, prioritize high-risk vulnerabilities for maintenance window conflicts, establish decision rules for automatically suspending low-priority tasks when resources exceed thresholds, and have a dynamic adjustment mechanism for automatically postponing the execution of pre-tasks when they are delayed, as well as alarm triggering conditions for delays exceeding 24 hours.

[0089] This system manages the entire lifecycle of network vulnerabilities based on conflict avoidance sequences. It integrates all management elements from vulnerability discovery to remediation and verification, including vulnerability identification, risk assessment, remediation implementation, effectiveness verification, and continuous monitoring. One enterprise's vulnerability lifecycle management covers the entire process from automated vulnerability scanning and discovery to developing remediation plans based on risk levels, patch deployment, and penetration testing verification. Conflict avoidance sequences are embedded in the execution phase of the vulnerability lifecycle to ensure that remediation plans automatically avoid conflicts during implementation. Before execution, a remediation task automatically checks dependencies and resource availability; if conditions are not met, the execution time is automatically adjusted according to the avoidance sequence. A closed-loop feedback mechanism is established for the vulnerability lifecycle, feeding verification results back to risk assessment and remediation strategy adjustment. If, after remediation, verification reveals insufficient protection effectiveness, the feedback mechanism automatically triggers the strengthening of compensation strategies or a reassessment of the remediation plan. Continuous optimization of the vulnerability lifecycle is implemented, with management processes constantly improved based on historical data and effectiveness evaluations. The network vulnerability lifecycle management covers the entire process from automated scanning and discovery to patch deployment and penetration testing verification. It embeds conflict avoidance sequences to implement pre-execution dependency and resource checks, establishes a closed-loop feedback mechanism that automatically triggers compensation and reinforcement when the protection effect is not up to standard, and continuously optimizes the management process based on historical data.

[0090] To implement the network vulnerability lifecycle management method corresponding to the above method embodiments, and to achieve the corresponding functions and technical effects. See also Figure 2 , Figure 2 This diagram illustrates a structural block diagram of a network vulnerability lifecycle management system 200 provided in an embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. The network vulnerability lifecycle management system 200 provided in this embodiment includes:

[0091] Data acquisition module 201 is used to acquire raw data of network vulnerabilities, construct a vulnerability knowledge graph based on the raw vulnerability data, and perform vulnerability association mining and analysis through the vulnerability knowledge graph to generate key vulnerability nodes.

[0092] The correlation analysis module 202 is used to perform dependency conflict detection at the critical nodes of the vulnerability to generate evaluation guidance indicators, use the evaluation guidance indicators to perform vulnerability mutation analysis to extract the core attributes of the vulnerability, and construct key evaluation enhancement areas based on the core attributes of the vulnerability.

[0093] The blind spot compensation module 203 is used to scan the original vulnerability data to identify blind spots and generate a blind spot distribution map, extract the missing features from the blind spot distribution map to generate a missing feature set, construct a compensation and repair strategy group based on the missing feature set, and adjust the vulnerability priority through the compensation and repair strategy group to generate a hybrid repair processing area.

[0094] The reliability verification module 204 is used to perform reliability analysis on the hybrid repair processing area to determine the high reliability area and the low reliability area, set a preset risk weight for the high reliability area, set a compensation enhancement weight for the low reliability area, and construct a graded repair verification area using the compensation enhancement weight and the preset risk weight.

[0095] The conflict avoidance module 205 is used to merge the graded repair verification area with the key evaluation enhancement area to generate a repair coordination coefficient, use the repair coordination coefficient to predict execution conflicts of the compensation repair strategy group and identify potential execution conflict points, construct a conflict avoidance sequence based on the potential execution conflict points, and complete the full life cycle management of network vulnerabilities based on the conflict avoidance sequence.

[0096] The aforementioned network vulnerability lifecycle management system 200 can implement a network vulnerability lifecycle management method according to the above method embodiments. The options in the above method embodiments are also applicable to this embodiment, and will not be detailed here. The remaining content of this application embodiment can be referred to the content of the above method embodiments, and will not be repeated in this embodiment.

[0097] The purpose of the above embodiments is to reproduce and derive the technical solution of the present invention by way of example, and to fully describe the technical solution, purpose and effect of the present invention. The purpose is to enable the public to have a more thorough and comprehensive understanding of the disclosure of the present invention, and not to limit the scope of protection of the present invention.

Claims

1. A network vulnerability life cycle management method, characterized by, The method comprises the following steps: acquiring network vulnerability raw data, constructing a vulnerability knowledge graph based on the vulnerability raw data, and generating a vulnerability key node through vulnerability correlation mining analysis based on the vulnerability knowledge graph; implementing dependency conflict detection at the vulnerability key node to generate evaluation guide indicators, using the evaluation guide indicators to perform vulnerability variation analysis and processing to extract vulnerability core attributes, and constructing a key evaluation enhancement region based on the vulnerability core attributes; identifying a scanning blind area from the vulnerability raw data to generate a blind area distribution map, extracting a coverage missing feature from the blind area distribution map to generate a missing feature set, constructing a compensation repair strategy group by compensating the missing feature set, and generating a hybrid repair processing region through the compensation repair strategy group; the step of constructing a compensation repair strategy group by compensating the missing feature set comprises the following steps: locating a compensation target from the missing feature set to generate a compensation anchor set; identifying a compensation conflict mode from the compensation anchor set to generate a conflict avoidance rule; expanding the applicable boundary of the conflict avoidance rule to generate an expanded compensation rule; and generating a compensation repair strategy group based on the expanded compensation rule; performing reliability analysis on the hybrid repair processing region to determine a high-reliability region and a low-reliability region, setting a preset risk weight for the high-reliability region, setting a compensation enhancement weight for the low-reliability region, and constructing a hierarchical repair verification region using the compensation enhancement weight and the preset risk weight; fusing the hierarchical repair verification region and the key evaluation enhancement region to generate a repair coordination coefficient, identifying potential execution conflict points through execution conflict prediction of the compensation repair strategy group based on the repair coordination coefficient, constructing a conflict avoidance sequence based on the potential execution conflict points, and completing network vulnerability life cycle management based on the conflict avoidance sequence.

2. The method of claim 1, wherein, The method comprises the following steps: extracting a propagation intensity feature from the vulnerability knowledge graph; identifying a low propagation region based on the propagation intensity feature and extracting a hidden propagation path; performing dependency tracking on the hidden propagation path to generate a high-risk propagation point; determining a vulnerability key node based on the high-risk propagation point.

3. The method of claim 1, wherein, The method comprises the following steps: constructing a vulnerability evolution tracking view based on the evaluation guide indicators; extracting a post-repair reproduction mode through reverse variation identification of the vulnerability evolution tracking view; generating a stable attribute set through attribute stability measurement from the post-repair reproduction mode; extracting a vulnerability core attribute through key selection of the stable attribute set.

4. The method of claim 1, wherein, The method comprises the following steps: identifying a scanning blind area from the blind area distribution map to establish a gap identification set; performing missing intensity evaluation on the gap identification set to obtain a blind area feature spectrum; determining a coverage blind area boundary based on the blind area feature spectrum; extracting a missing feature set based on the coverage blind area boundary.

5. The method of claim 1, wherein, The reliability analysis on the mixed repair processing area determines a high reliability area and a low reliability area, comprising: The trust propagation estimation on the mixed repair processing area obtains a trust propagation intensity table; The volatility detection on the trust propagation intensity table identifies a trust instability area; The anomaly analysis in the trust instability area determines a potential risk indicator; The grading on the potential risk indicator identifies a high reliability area and a low reliability area.

6. The method of claim 1, wherein, The execution conflict pre-judgment on the compensation repair strategy group through the repair coordination coefficient identifies a potential execution conflict point, comprising: The execution dependency monitoring network is constructed based on the repair coordination coefficient; The dependency offset points are obtained by mapping the compensation repair strategy group to the execution dependency monitoring network; The conflict analysis on the dependency offset points determines an execution interference cluster; The potential execution conflict point is identified according to the execution interference cluster.

7. The method of claim 2, wherein, The low propagation area is identified according to the propagation intensity feature and the hidden propagation path is extracted, comprising: The low propagation area is identified according to the intensity threshold division of the propagation intensity feature; The fluctuation marker set is generated by detecting the propagation anomaly wave in the low propagation area; The unconventional connection channel is extracted based on the fluctuation marker set; The hidden propagation path is determined by combining the low propagation area and the unconventional connection channel.

8. The method of claim 4, wherein, The missing intensity evaluation on the empty slot identification set obtains a blind area feature spectrum, comprising: The empty slot density measurement is performed based on the empty slot identification set to obtain a density distribution; The abnormal aggregation point is identified by performing low-density area anomaly detection on the density distribution; The intensity attribute set is generated by extracting the missing intensity attribute from the abnormal aggregation point; The blind area feature spectrum is obtained by performing feature extraction on the intensity attribute set.

9. A network vulnerability life cycle management system, characterized by, Comprise: The data acquisition module is used for acquiring network vulnerability original data, constructing a vulnerability knowledge graph based on the vulnerability original data, and generating a vulnerability key node through vulnerability correlation mining analysis of the vulnerability knowledge graph; The correlation analysis module is used for implementing dependency conflict detection at the vulnerability key node to generate an evaluation guide index, and extracting a vulnerability core attribute by using the evaluation guide index for vulnerability variation analysis processing; The blind area compensation module is used for identifying a blind area distribution map by scanning the vulnerability original data, extracting a missing feature set from the blind area distribution map, generating a compensation repair strategy group by constructing a compensation strategy for the missing feature set, and generating a mixed repair processing area by adjusting the priority of the vulnerability through the compensation repair strategy group; the compensation repair strategy group is generated by constructing a compensation strategy for the missing feature set, comprising: a compensation anchor set is generated by implementing compensation target positioning on the missing feature set; a conflict avoidance rule is generated by identifying a compensation conflict mode from the compensation anchor set; an extended compensation rule is generated by expanding the applicable boundary of the conflict avoidance rule; and the compensation repair strategy group is generated by implementing rule integration based on the extended compensation rule. A reliability verification module is configured to perform reliability analysis on the mixed repair processing area to determine a high-reliability area and a low-reliability area, set a preset risk weight for the high-reliability area, set a compensation enhancement weight for the low-reliability area, and construct a hierarchical repair verification area by using the compensation enhancement weight and the preset risk weight. A conflict avoidance module is configured to fuse the hierarchical repair verification area and the key evaluation enhancement area to generate a repair coordination coefficient, perform conflict prediction on the compensation repair strategy group through the repair coordination coefficient to identify potential execution conflict points, construct a conflict avoidance sequence according to the potential execution conflict points, and complete network vulnerability life cycle management based on the conflict avoidance sequence.

Images