Automated vulnerability processing method and system

Abstract

The present application provides an automated vulnerability handling method and system, wherein the method includes: obtaining multi-source heterogeneous data and temperature field distribution of the target system, semantically associating the vulnerability data with historical repair records, and combining the dynamic dependency chain to generate vulnerability propagation path characteristics; by matching the temperature field distribution with the thermodynamic pattern of known vulnerability attacks, identifying hardware load abnormality areas. Based on the dynamic graph attention mechanism, the vulnerability propagation path characteristics and hardware abnormality data are collaboratively analyzed to generate a patch deployment strategy that comprehensively considers repair priority and resource allocation. During execution, the topological order and data throughput of the patch distribution path are dynamically adjusted, and the resource occupancy ratio is optimized to ensure that the duration of cross-system service interruptions is controlled within the safety window. The present application improves the accuracy of vulnerability repair and system stability.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to an automated vulnerability processing method and system. Background Art

[0002] In cloud computing and distributed systems, vulnerability remediation must consider both the propagation impact at the software level and the abnormal load at the hardware level. Traditional methods struggle to assess the impact of vulnerability remediation across system components in real time, especially when faced with complex dependencies and dynamic load changes. This can easily lead to irrational remediation sequencing or unbalanced resource allocation, potentially causing cascading failures or service interruptions.

[0003] Existing solutions utilize a vulnerability prioritization method based on system call chain analysis. This method constructs a component dependency graph and combines vulnerability threat scores and dependency strength to calculate the remediation order. This method uses historical vulnerability data to train a graph neural network model, predicting the impact of different remediation paths on system stability and generating a static remediation plan. During the deployment phase, the patch distribution rate is fine-tuned based on real-time system load, with hardware status factored into the calculation only as a resource constraint.

[0004] The component dependency graph this solution relies on fails to incorporate the spatial distribution characteristics of hardware load anomalies, making the repair strategy insensitive to hidden faults caused by temperature field changes. Furthermore, the graph neural network model only models dependencies at the software level. When there is a temporal and spatial misalignment between the hardware anomaly area and the vulnerability propagation path, the rationality of the repair sequence decreases. Furthermore, static repair plans struggle to adapt to real-time changes in the dynamic dependency chain, especially in scenarios where sudden capacity expansion occurs in high-temperature load areas, which can lead to patch deployment delays caused by resource contention. Summary of the Invention

[0005] The present application provides an automated vulnerability handling method and system to address the problems of poor vulnerability repair accuracy and low system stability in the prior art.

[0006] In a first aspect, the present application provides an automated vulnerability handling method, comprising:

[0007] Acquire multi-source heterogeneous data and the temperature field distribution of the target system during operation;

[0008] Semantically associating the multi-source heterogeneous data with historical repair records in a preset vulnerability database, and combining them with the dynamic dependency chain of the target system to generate vulnerability propagation path features;

[0009] Performing spatiotemporal correlation matching between the temperature field distribution and the thermodynamic pattern of known vulnerability attack behaviors to identify hardware load anomaly areas in the target system triggered by the vulnerability;

[0010] Generate a patch deployment strategy by collaboratively processing the vulnerability propagation path characteristics and the hardware load abnormality area through a dynamic graph attention mechanism;

[0011] During the execution of the patch deployment strategy, the topological order and data throughput of the patch distribution path in the patch deployment strategy are adjusted in real time, and the resource occupancy ratio during the patch deployment process is dynamically optimized to keep the cross-system service interruption duration within the preset safety window.

[0012] Optionally, the collaborative processing of the vulnerability propagation path features and the hardware load abnormality area by a dynamic graph attention mechanism to generate a patch deployment strategy includes:

[0013] Through the dynamic graph attention mechanism, a dynamic graph structure is constructed according to the vulnerability propagation path characteristics and the hardware load abnormality area;

[0014] Calculating cross-domain correlation of attributes of each node in the dynamic graph structure;

[0015] The cross-domain correlation calculation result is input into a trained dynamic weight allocation model, which calculates the repair correlation strength between different nodes by traversing the connection paths of each node in the dynamic graph structure;

[0016] generating a node repair priority sequence according to the repair association strength;

[0017] Calculating the resource allocation ratio required for patch deployment based on the dynamic graph structure and the current hardware load abnormality area;

[0018] The node repair priority sequence and the resource allocation ratio are combined into a patch deployment strategy.

[0019] Optionally, the cross-domain correlation calculation result is input into a trained dynamic weight allocation model, and the dynamic weight allocation model calculates the repair correlation strength between different nodes by traversing the connection path of each node in the dynamic graph structure, including:

[0020] Inputting the cross-domain correlation calculation result into a trained dynamic weight allocation model, and traversing the connection paths of each node in the dynamic graph structure through the traversal module of the dynamic weight allocation model;

[0021] determining a path length attenuation coefficient according to a topological level of the connection path;

[0022] Extracting the vulnerability propagation intensity factor and the load anomaly intensity factor from the cross-domain correlation calculation result for each node on each connection path through the extraction module of the dynamic weight allocation model;

[0023] Multiplying the vulnerability propagation intensity factor by the corresponding path length attenuation coefficient to obtain a dynamic propagation correction value at the software level;

[0024] Multiplying the load anomaly intensity factor by the spatial overlap ratio of the hardware load anomaly regions of the nodes at both ends of the connection path to obtain an anomaly superposition correction value at the hardware level;

[0025] Linearly superimposing the dynamic propagation correction value and the abnormal superposition correction value according to a preset weight ratio to generate a repair impact value of the connection path;

[0026] The repair association strength is generated according to the repair impact values ​​of all connection paths in the dynamic graph structure.

[0027] Optionally, generating the repair association strength according to the repair impact values ​​of all connection paths in the dynamic graph structure includes:

[0028] According to all connection paths connected to the current node in the dynamic graph structure, a repair impact value of each connection path is directionally corrected according to the path length attenuation coefficient;

[0029] For each connection path, the repair impact value after directionality correction is added with the weight coefficient corresponding to the spatial overlap ratio of the hardware load abnormality areas of the nodes at both ends of the connection path to generate a path contribution value.

[0030] Accumulate the path contribution values ​​of the current node on all connection paths according to the topological order of all connection paths;

[0031] According to the accumulated results, the repair association strength of the current node is generated.

[0032] Optionally, generating a node repair priority sequence according to the repair association strength includes:

[0033] Sorting the repair association strengths of all nodes in the dynamic graph structure by numerical value to generate an initial priority queue;

[0034] Checking the component interaction topology relationship corresponding to each node in the initial priority queue, and when detecting a node pair with a direct dependency relationship, adjusting the priority order of each node in the node pair to generate an intermediate priority queue;

[0035] According to the temperature field distribution interval of the hardware load abnormality area, the nodes at the same dependency level in the intermediate priority queue are secondary sorted to generate a target priority queue;

[0036] Matching and checking the node order of the target priority queue with the patch compatibility parameters of each node in the dynamic graph structure;

[0037] Based on the matching verification results, a node repair priority sequence is generated.

[0038] Optionally, semantically associating the multi-source heterogeneous data with historical repair records in a preset vulnerability database and combining the dynamic dependency chain of the target system to generate vulnerability propagation path features includes:

[0039] Extracting vulnerability attribute fields and patch compatibility parameters from the multi-source heterogeneous data, and matching them with historical repair records in a preset vulnerability database;

[0040] Extract vulnerability propagation path patterns recorded in historical repair records that have successfully matched;

[0041] Mapping the vulnerability propagation path pattern to the dynamic dependency chain of the target system, and adjusting the component sequence in the vulnerability propagation path pattern according to the real-time interaction relationship between components in the dynamic dependency chain;

[0042] Generate vulnerability propagation path features based on the adjusted component sequence.

[0043] Optionally, performing spatiotemporal correlation matching on the temperature field distribution and a thermodynamic pattern of a known vulnerability attack behavior to identify an abnormal hardware load area in the target system triggered by the vulnerability includes:

[0044] Dividing the temperature field distribution into continuous monitoring segments according to time windows;

[0045] For each monitoring segment, extract the temperature change curve characteristics of the monitoring segment, and compare the shape similarity of the temperature change curve characteristics with the temperature change curves of each vulnerability type in the thermodynamic pattern library of known vulnerability attack behaviors to screen candidate vulnerability types whose similarity exceeds a first threshold;

[0046] Extracting the spatial temperature gradient characteristics of the monitoring segment and comparing the regional overlap with the spatial distribution characteristics corresponding to the candidate vulnerability types to screen specific vulnerability types whose overlap exceeds a second threshold;

[0047] When the monitoring segment matches the specific vulnerability type, the spatial area in which the temperature value in the monitoring segment continuously exceeds the alarm threshold corresponding to the specific vulnerability type in the thermodynamic pattern library is marked as a hardware load abnormality area triggered by the vulnerability.

[0048] In a second aspect, the present application provides an automated vulnerability handling system, comprising:

[0049] Acquisition module, used to obtain multi-source heterogeneous data and the temperature field distribution of the target system during operation;

[0050] An association module is used to semantically associate the multi-source heterogeneous data with historical repair records in a preset vulnerability database, and generate vulnerability propagation path features in combination with the dynamic dependency chain of the target system;

[0051] a matching module, configured to perform spatiotemporal correlation matching of the temperature field distribution with thermodynamic patterns of known vulnerability attack behaviors, and identify hardware load anomaly areas in the target system triggered by the vulnerability;

[0052] A generation module is used to generate a patch deployment strategy by collaboratively processing the vulnerability propagation path characteristics and the hardware load abnormality area through a dynamic graph attention mechanism;

[0053] The adjustment module is used to adjust the topological order and data throughput of the patch distribution path in the patch deployment strategy in real time during the execution of the patch deployment strategy, and dynamically optimize the resource occupancy ratio during the patch deployment process so that the service interruption duration across the system is maintained within a preset safety window.

[0054] In a third aspect, the present application provides a computing device comprising a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute an automated vulnerability handling method as described in any one of the first aspects.

[0055] In a fourth aspect, the present application provides a computer storage medium having computer program instructions stored thereon, wherein the computer program instructions, when executed by a processor, implement an automated vulnerability handling method as described in any one of the first aspects.

[0056] In the present application, an automated vulnerability processing method is provided, which includes: obtaining multi-source heterogeneous data and the temperature field distribution of the target system during operation; semantically associating the multi-source heterogeneous data with historical repair records in a preset vulnerability database, and combining the dynamic dependency chain of the target system to generate vulnerability propagation path characteristics; performing spatiotemporal correlation matching on the temperature field distribution and the thermodynamic pattern of known vulnerability attack behavior to identify hardware load anomaly areas triggered by the vulnerability in the target system; collaboratively processing the vulnerability propagation path characteristics and the hardware load anomaly areas through a dynamic graph attention mechanism to generate a patch deployment strategy; in the process of executing the patch deployment strategy, adjusting the topological order and data throughput of the patch distribution path in the patch deployment strategy in real time, and dynamically optimizing the resource occupancy ratio during the patch deployment process, so that the service interruption duration across the system is maintained within a preset safety window.

[0057] The technical solution provided by this application has the following beneficial effects:

[0058] This application enables comprehensive data collection of software vulnerability characteristics and hardware operating status. It quantifies the risk of vulnerability propagation across system components and identifies critical impact paths. It also establishes a visual correlation between vulnerability attack behavior and physical hardware status. By integrating software and hardware data for decision-making, it develops a dynamic solution that balances remediation efficiency and system stability. It also adaptively optimizes the patch distribution process to keep service interruptions within safe thresholds.

[0059] Furthermore, this application also constructs a dynamic graph structure that integrates vulnerability propagation characteristics and hardware anomaly data, calculates the cross-domain correlation between nodes and inputs the pre-trained weight distribution model to generate a priority sequence based on the repair association strength; at the same time, it combines the real-time hardware anomaly area to calculate the resource allocation ratio, and finally outputs a patch deployment strategy that integrates the software repair urgency and hardware resource constraints.

[0060] Furthermore, it breaks through the limitations of software / hardware separation analysis in traditional vulnerability repair and implements cross-domain risk collaborative assessment through a dynamic graph attention mechanism, thereby improving the accuracy of repair priority sorting. The real-time linkage mechanism between resource allocation ratio and hardware load reduces the probability of resource conflicts during patch deployment, ensuring the continuity of critical business.

[0061] These and other aspects of the present application will become more readily apparent from the description of the following embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0063] Figure 1 A flowchart of an automated vulnerability handling method provided in an embodiment of the present application;

[0064] Figure 2 A schematic diagram of the structure of an automated vulnerability processing system provided in an embodiment of the present application;

[0065] Figure 3 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0066] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0067] In some of the processes described in the specification and claims of this application and the above-mentioned figures, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this document or may be executed in parallel. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish between different operations, and the serial numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to being different types.

[0068] Researchers have found that existing vulnerability repair solutions are difficult to take into account the synergistic effects of software vulnerability propagation characteristics and hardware abnormal loads at the same time, resulting in a disconnect between the repair strategy and the actual operating status of the system, often leading to cascading failures or resource contention problems. Based on this, an embodiment of the present application provides an automated vulnerability processing method, which can fuse vulnerability propagation path characteristics with hardware load abnormality data through a dynamic graph attention mechanism, generate a patch deployment strategy that matches the real-time status of the system, and dynamically optimize resource allocation during execution, controlling cross-system service interruptions within a safe threshold. The technical solution of this application can be applied to key business scenarios such as cloud computing platforms and distributed systems that require high availability.

[0069] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making creative efforts are within the scope of protection of this application.

[0070] Figure 1 A flowchart of an automated vulnerability handling method provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the method includes:

[0071] Step 101: Acquire multi-source heterogeneous data and the temperature field distribution of the target system during operation.

[0072] In this step, multi-source heterogeneous data includes vulnerability attributes of the target system (e.g., vulnerability type, impact scope), patch compatibility parameters (e.g., patch applicable versions, dependency conditions), and component interaction topology (e.g., service call relationships, data flow paths). This data comes from system logs, configuration files, and vulnerability scanning tools. The temperature field distribution represents hardware runtime temperature data collected by an optical sensor array deployed in the server cluster, reflecting the thermal load status of different hardware components (e.g., CPU, memory, and hard disk).

[0073] In this embodiment, vulnerability attributes, patch compatibility parameters, and component interaction relationships are first extracted from various data sources (vulnerability databases, system logs, and network topology diagrams) on the target system to form a structured data set. Simultaneously, an optical sensor array collects temperature data from various hardware areas on the server at a fixed sampling frequency to generate a two-dimensional temperature distribution map. After normalization, these two types of data are stored in a vulnerability signature database and a temperature field database, respectively, for subsequent use.

[0074] For example, a cloud computing platform detects a vulnerability in a Web service node. First, it collects the vulnerability type of the node (such as SQL injection), the version constraints of the required patch (such as only supporting Linux kernel 5.4 and above), and the calling relationship between the node and the database node and cache node; at the same time, it uses an infrared sensor to obtain the CPU temperature distribution of the physical server where the node is located (such as 70°C in the core area and 50°C in the edge area) to form an initial data set.

[0075] Step 102: semantically associate the multi-source heterogeneous data with historical repair records in a preset vulnerability database, and combine them with the dynamic dependency chain of the target system to generate vulnerability propagation path features.

[0076] In this step, the historical patch records in the pre-set vulnerability database refer to a collection of pre-stored vulnerability patch cases related to the target system. These records contain data such as vulnerability type, affected components, successfully applied patch versions, patch duration, and post-patch system stability metrics. These records are matched with current vulnerability features using semantic association techniques (such as natural language processing) to predict vulnerability propagation paths and optimize the remediation sequence. For example, if a historically similar vulnerability requires a web service restart after remediation on a database node, the current policy prioritizes the database node. A dynamic dependency chain refers to a network of interdependencies between components in the target system that changes in real time. These dependencies adjust dynamically based on system operating status, resource allocation, or external requests. Specifically, these include temporary connections established when component A calls component B's functionality, dependencies formed when sharing memory resources, and upstream and downstream connections in the service call chain that dynamically increase and decrease with load. Vulnerability propagation path features quantify the risk path of vulnerability propagation between components, including propagation direction (e.g., from web node to database node) and impact intensity (e.g., the deeper the dependency hierarchy, the more pronounced the impact attenuation).

[0077] In an embodiment of the present application, vulnerability attributes in multi-source heterogeneous data are semantically matched with historical repair records (e.g., repair records of the same vulnerability type are preferentially associated), and the topological structure of the dynamic dependency chain (e.g., the edge weights of the component call graph) are combined to calculate the probability of vulnerability propagation along each dependency path; the propagation probability is attenuated and corrected according to the dependency chain hierarchy (e.g., attenuated by a certain proportion each time a level is crossed), and finally a weighted directed propagation path graph is generated, in which the nodes represent system components and the edge weights represent the vulnerability propagation intensity.

[0078] For example, based on acquired data, we analyze that a Web (World Wide Web) node vulnerability may propagate to a database node through the API (Application Programming Interface) call chain (dependency level 1, propagation strength 0.9). Database node vulnerabilities may further affect log service nodes (dependency level 2, propagation strength 0.6). Combined with historical data on patching similar vulnerabilities (e.g., prioritizing database node patch deployment), we generate a propagation path feature map.

[0079] Step 103: Performing spatiotemporal correlation matching between the temperature field distribution and the thermodynamic pattern of known vulnerability attack behaviors to identify hardware load anomaly areas in the target system triggered by the vulnerability.

[0080] In this step, thermodynamic patterns represent typical temperature characteristics of hardware that are characteristic of known vulnerability attack behaviors (e.g., denial of service attacks), such as sudden CPU temperature rises and concentrated memory hotspots. These patterns include, but are not limited to, hotspot patterns with abnormally high local processor temperatures, load oscillation patterns with periodic temperature fluctuations in memory modules, read-write intensive patterns with abnormal temperature gradients in hard disk arrays, and overload patterns with uneven temperature distribution in power modules. These patterns match the hardware load characteristics triggered by specific vulnerability attack behaviors. Hardware load anomaly regions represent abnormally high temperature areas in the temperature field distribution that match vulnerability attack behaviors, such as CPU core temperatures that consistently exceed safety thresholds.

[0081] In an embodiment of the present application, the temperature field distribution is divided into continuous segments according to the time window, and the temperature change curve (such as the rising rate and fluctuation frequency) and spatial gradient (such as the area of ​​the high-temperature region) of each segment are extracted; similarity matching is performed with the temperature characteristics of known vulnerability attacks in the thermodynamic pattern library (such as SQL injection attacks that cause periodic high CPU load); if the temperature curve and spatial distribution of a segment both match a specific vulnerability type, the physical area corresponding to the segment is marked as an abnormal area.

[0082] For example, when the core temperature of the Web node's CPU (Central Processing Unit) rises from 60°C to 85°C within 10 seconds, and the fluctuation pattern is consistent with historical SQL injection attack records, and the spatial distribution shows concentrated heat in the core area (accounting for more than 80% of the area), the CPU core area is determined to be the abnormal load area triggered by the vulnerability.

[0083] Step 104: Generate a patch deployment strategy by collaboratively processing the vulnerability propagation path features and the hardware load abnormality area through a dynamic graph attention mechanism.

[0084] In this step, the dynamic graph attention mechanism, a graph processing technique that dynamically adjusts the weights of associations between nodes, is used to integrate software vulnerability characteristics with hardware anomaly data. The patch deployment strategy is a remediation action plan generated by analyzing the vulnerability propagation path characteristics and the areas of hardware load anomalies. It includes a node repair priority sequence (e.g., repairing database nodes before web nodes) and resource allocation ratios (e.g., allocating additional bandwidth to high-temperature nodes). This strategy uses the dynamic graph attention mechanism to quantify the urgency of each node's repair and constrain resource usage. For example, nodes with both high propagation risk and high temperature anomalies are assigned the highest priority and the most computing resources.

[0085] In an embodiment of the present application, a dynamic graph structure is constructed, in which nodes are system components, node attributes include vulnerability propagation strength and hardware anomaly values, and edge weights are determined by component dependency strength and temperature field overlap ratio; the influence weight of each node on neighboring nodes is calculated through an attention mechanism (such as the increase in the propagation weight of high-temperature anomaly nodes); all paths are traversed and the repair association strength is accumulated to generate a priority sequence; and the real-time occupancy rate of hardware resources (such as the remaining computing power of the CPU) is combined to allocate the patch deployment resource ratio.

[0086] For example, the dynamic graph shows that the database node has both a high transmission intensity (0.9) and an abnormally high temperature (85°C), resulting in the highest calculated repair correlation strength. Meanwhile, the web node, despite having a high transmission intensity (0.95) and a normal temperature, has a lower priority than the database node. Based on the current cluster CPU utilization (for example, if the database node's server utilization reaches 90%), more bandwidth resources are allocated to prioritize database node repairs.

[0087] Step 105: During the execution of the patch deployment strategy, the topological order and data throughput of the patch distribution path in the patch deployment strategy are adjusted in real time, and the resource occupancy ratio during the patch deployment process is dynamically optimized to keep the cross-system service interruption duration within a preset safety window.

[0088] In this step, the topological order represents the patch distribution order based on dependency relationships. This order is derived from the generated node repair priority sequence, such as prioritizing repairs for dependent components. Data throughput refers to the percentage of network bandwidth allowed to be used during patch transmission. This is dynamically adjusted by real-time monitoring of the target node's hardware load (such as CPU temperature). For example, when the target node's temperature exceeds a threshold, throughput is reduced to 50% of the standard value. This is calculated by the resource allocation ratio module. The resource utilization ratio indicates the upper limit of resources such as CPU and bandwidth that can be used during patch deployment to avoid impacting business operations.

[0089] In an embodiment of the present application, when executing the patch deployment strategy, the topological order and data throughput of the patch distribution path are adjusted in real time according to the correlation between the change rate of the vulnerability propagation path characteristics and the dynamic offset of the hardware load abnormality area, and through the collaborative feedback of the vulnerability propagation path characteristics and the hardware load abnormality area, the resource occupancy ratio in the patch deployment process is dynamically optimized, so that the duration of cross-system service interruption is maintained within the preset safety window.

[0090] For example, when deploying a database node patch, if the CPU temperature is detected to have risen to 90°C, the patch transmission rate will be immediately reduced to 50% of the standard value, and the deployment of the web node patch will be delayed. After the temperature drops back to 80°C, the original rate will be restored to ensure that the order query service is not affected.

[0091] This approach collaboratively analyzes software vulnerability characteristics and hardware load data to generate a remediation strategy that matches the system's real-time status, ensuring critical business continuity. This dynamic adjustment mechanism effectively avoids secondary failures caused by traditional solutions due to resource contention or improper remediation sequencing, improving the security and maintenance efficiency of complex systems.

[0092] To address the problem that existing vulnerability repair solutions are unable to collaboratively handle software vulnerability propagation characteristics and hardware abnormal load, and to further improve the matching degree between repair strategies and real-time system status, in some embodiments, step 104: collaboratively processing the vulnerability propagation path characteristics and the hardware load abnormality area through a dynamic graph attention mechanism to generate a patch deployment strategy includes:

[0093] Step 201: Using a dynamic graph attention mechanism, a dynamic graph structure is constructed based on the vulnerability propagation path characteristics and the hardware load abnormality area.

[0094] In step 201, the dynamic graph structure refers to a graph model constructed with system components as nodes and dependencies between components as edges. Node attributes include vulnerability propagation intensity and hardware anomaly values, and edge weights are determined by dependency call frequency and temperature field spatial overlap.

[0095] In this embodiment, each hardware / software component in the target system is first mapped to a graph node. Node attributes include vulnerability propagation path characteristics (e.g., vulnerability impact range and propagation direction) and corresponding hardware load anomaly data (e.g., temperature anomaly value and area). Edge connections are then established based on the actual interactions between components (e.g., data flows and call chains). The edge weights are determined by the strength of the dependencies between the components and the degree of correlation between the hardware anomaly areas. Finally, a dynamic graph attention mechanism is used to adjust the influence weights between nodes in real time, enabling the graph structure to simultaneously reflect the software vulnerability propagation trend and hardware anomaly changes. For example, suppose a server cluster contains a web service node (temperature anomaly +80°C), a database node (temperature anomaly +50°C), and a cache node (temperature normal). These nodes are first converted into graph nodes and labeled with their vulnerability characteristics. Based on the web node's frequent database calls, a high-weight edge (weight 0.9) is created, while the cache node's low-frequency interactions with the database node form a low-weight edge (weight 0.2). When the database node's temperature anomaly intensifies, the dynamic graph attention mechanism automatically increases the weight of its related edges (e.g., the web-to-database edge is adjusted to 0.95). This ultimately generates a dynamic graph that simultaneously reflects both vulnerability propagation risk and real-time hardware status.

[0096] Step 202: Calculate the cross-domain correlation of the attributes of each node in the dynamic graph structure.

[0097] In step 202, cross-domain correlation calculation refers to a comprehensive score that quantifies the correlation between the software vulnerability propagation risk and hardware anomaly between nodes, including a propagation intensity factor (calculated based on the vulnerability impact range) and a load anomaly factor (calculated based on the temperature deviation degree).

[0098] In an embodiment of the present application, a vulnerability propagation intensity factor at the software level is determined based on the hierarchical depth of cross-component dependencies in the vulnerability propagation path characteristics. Simultaneously, a load anomaly intensity factor at the hardware level is determined based on the degree of deviation between the temperature field distribution interval of the hardware load anomaly region and a preset thermodynamic threshold. For each node in the graph, its vulnerability propagation intensity (e.g., a node affects three downstream components) and hardware anomaly value (e.g., the temperature of the CPU region corresponding to the node exceeds the standard) are extracted, and both are normalized into a score of uniform dimension according to preset rules. All adjacent edges of the node are traversed, and the scores of adjacent nodes are weighted and aggregated according to edge weights to generate a correlation matrix reflecting the cross-component risk transmission capability. For each node in the graph, its vulnerability propagation intensity (e.g., a node affects three downstream components) and hardware anomaly value (e.g., the temperature of the CPU region corresponding to the node exceeds the standard) are extracted, and both are normalized into a score of uniform dimension according to preset rules. All adjacent edges of the node are traversed, and the scores of adjacent nodes are weighted and aggregated according to edge weights to generate a correlation matrix reflecting the cross-component risk transmission capability.

[0099] Step 203: Input the cross-domain correlation calculation result into the trained dynamic weight allocation model. The dynamic weight allocation model calculates the repair correlation strength between different nodes by traversing the connection path of each node in the dynamic graph structure.

[0100] In step 203, the connection path of each node refers to the sequence of component nodes interconnected by dependency edges in the dynamic graph structure, reflecting the potential propagation path of the vulnerability between system components. Specifically, these paths include direct connection paths (e.g., a first-level dependency from a web node to a database node) and indirect connection paths (e.g., a multi-level dependency from a web node to a database node to a log node). Path weights are determined by the frequency of inter-component calls, the intensity of data flow, and the overlap of temperature anomalies in shared hardware areas. These weights are used to quantify the risk of vulnerability propagation along different paths. The dynamic weight allocation model is a pre-trained graph neural network model that analyzes the inter-node remediation interactions and outputs a remediation association strength (a score indicating the priority of the node to be repaired). This remediation association strength is a node remediation priority score output by the dynamic weight allocation model. It comprehensively considers the node's vulnerability propagation impact (e.g., the number of downstream components affected), the degree of hardware load anomalies (e.g., the magnitude of temperature excursions), and its criticality in the dependency topology (e.g., whether it is dependent on multiple components). A higher remediation strength value indicates a more urgent node repair. For example, a node with a high remediation risk, high temperature anomalies, and located at the intersection of multiple dependency paths will receive the highest remediation strength value and require priority treatment to avoid systemic failure. The calculation of the repair association strength includes: attenuating and correcting the vulnerability propagation intensity factor according to the topological order of the dependency chain between nodes, and weighted fusion based on the spatial overlap ratio of the temperature field distribution intervals in the hardware load abnormality areas between nodes.

[0101] In an embodiment of the present application, after the correlation matrix is ​​input into the model, the model first attenuates the propagation impact according to the topological depth of the dependency path (such as halving the impact of nodes across two levels of dependency), and then calculates the intensity of each node affected by the vulnerability of other nodes based on the superposition effect of temperature anomalies of adjacent nodes (such as the mutual influence of two high-temperature nodes is enhanced when they are adjacent); and finally outputs the repair correlation strength of each node, where the higher the value, the greater the urgency of the repair.

[0102] Step 204: Generate a node repair priority sequence according to the repair association strength.

[0103] In step 204 , the node repair priority sequence refers to the component processing order sorted from high to low by repair association strength, and must satisfy dependency constraints (eg, a dependent component takes precedence over a component that depends on it).

[0104] In an embodiment of the present application, the repair association strength is first sorted in descending order, and then a check is made to see whether there is an inversion of the dependency relationship in the sort (such as a database node is ranked lower than the Web node that depends on it); if so, the priority of the dependent component is forcibly increased to ensure that the basic service is repaired before the upper-layer application, and the final priority execution queue is generated.

[0105] Step 205: Calculate the resource allocation ratio required for patch deployment based on the dynamic graph structure and the current hardware load abnormality area.

[0106] In step 205, the current hardware load anomaly region refers to the abnormal temperature distribution area associated with vulnerability attack behavior, detected in real time through optical sensing during the patch deployment strategy. The resource allocation ratio refers to the upper limit of computing resources that each node can occupy during patch deployment, determined by the node's current hardware load and repair priority. The resource allocation ratio is generated by constraining the matching relationship between the node repair priority sequence in the dynamic graph structure and the upper limit of hardware resource consumption.

[0107] In an embodiment of the present application, an initial resource quota is allocated to each node according to a priority sequence (e.g., high-priority nodes obtain more bandwidth), and then the temperature field changes of the target node are detected in real time: if the temperature of a node continues to rise, its resource occupancy ratio is dynamically lowered (e.g., down one level), and the remaining resources are reallocated to subsequent nodes to avoid local overheating and hardware failure.

[0108] Step 206: Combine the node repair priority sequence and the resource allocation ratio into a patch deployment strategy.

[0109] In an embodiment of the present application, the adjusted priority sequence is bound to the dynamic resource allocation table to generate a repair instruction set with execution constraints, such as "repair the database node at the standard rate first, reduce the speed if its CPU temperature exceeds the threshold, and transfer the remaining bandwidth to the web node."

[0110] Here's a specific example:

[0111] In a cloud computing platform vulnerability remediation scenario, after detecting a SQL injection vulnerability in a web service node, the system first constructs a dynamic graph structure: web nodes, database nodes, and log nodes are used as graph nodes. Edge weights between nodes are calculated based on call relationship strength (web: high database call frequency, weight set to 0.9; database: medium log call frequency, weight set to 0.6) and temperature field overlap (web and database nodes share the same physical server, the temperature overlap area accounts for 60%, and the weight is increased by 0.1). When traversing the connection path using the dynamic weight allocation model, the repair association strength of the database node is calculated as follows: propagation strength factor (0.9) × path attenuation coefficient (dependency level 1 is 1.0) + load anomaly factor (temperature 85°C corresponds to strength 1.2) × spatial overlap ratio (60%) = 1.62. This is higher than the web node's 1.14 (0.95 × 1.0 + 0.8 × 0.6, where 0.8 is the load intensity corresponding to 70°C). Therefore, the database node is ranked first when generating the priority sequence. When allocating resources, the resource ratio is adjusted based on the current CPU utilization (90%) of the server where the database node resides, according to the preset rule of "double bandwidth allocation when utilization > 85%." In actual deployment, when the database node temperature rises to 90°C (exceeding the safety threshold of 88°C), the patch transmission rate is adjusted linearly to the standard value × (1-(90-88) / 10) = 80% of the standard value according to the speed reduction formula. After the temperature drops to 85°C, full transmission speed is restored. The patch distribution schedule for web nodes is also dynamically adjusted.

[0112] In an embodiment of the present application, the method dynamically integrates software vulnerability characteristics with the real-time status of the hardware to generate a repair strategy that actually matches the system operation, thereby completing vulnerability repair while ensuring the continuity of critical business, and effectively avoiding secondary failures caused by resource conflicts or improper repair sequence in traditional solutions.

[0113] In order to solve the problem of difficulty in accurately quantifying vulnerability repair priorities in the prior art and further improve the scientific nature of the repair strategy, in some embodiments, step 203: inputting the cross-domain correlation calculation result into a trained dynamic weight allocation model, the dynamic weight allocation model calculates the repair association strength between different nodes by traversing the connection path of each node in the dynamic graph structure, including:

[0114] Step 301: Input the cross-domain correlation calculation result into a trained dynamic weight allocation model, and traverse the connection path of each node in the dynamic graph structure through the traversal module of the dynamic weight allocation model.

[0115] In an embodiment of the present application, the dynamic weight distribution model first starts from the entry node of the dynamic graph structure, visits each node in turn in the direction of the dependency edge, and records all possible propagation paths, including direct connection paths and indirect connection paths across multiple components.

[0116] Step 302: Determine a path length attenuation coefficient according to the topological level of the connection path.

[0117] In step 302, the topological level of the connection path refers to the relative depth of the vulnerability propagation path within the system's dependencies. This level is determined by analyzing the number of dependency hops between nodes in the dynamic graph structure. The specific calculation method is: starting with the source node containing the vulnerability (denoted as level 0), its directly dependent adjacent nodes are the first level (level 1), the dependent nodes of the dependent nodes are the second level (level 2), and so on. For example, the path from a web node to a database node is a first level (level 1), and the path from a web node to a database node to a log node is a second level (level 2). A larger number of levels indicates a more indirect vulnerability propagation and a smaller corresponding path length decay coefficient. This level data is derived from the explicit dependencies between components recorded in the dynamic graph structure constructed in step 201. The path length decay coefficient is a weight parameter that decreases with increasing dependency levels and is used to adjust for the impact of long-distance propagation on remediation priority.

[0118] In an embodiment of the present application, the attenuation coefficient is determined based on the number of dependency levels that the connection path passes through. The more levels there are, the smaller the coefficient is, reflecting the characteristic that the influence of vulnerability propagation decays with distance.

[0119] Step 303: extracting the vulnerability propagation intensity factor and the load anomaly intensity factor from the cross-domain correlation calculation result for each node on each connection path through the extraction module of the dynamic weight allocation model.

[0120] In step 303, the vulnerability propagation intensity factor reflects the propagation capability of the node's own vulnerability. The load anomaly intensity factor reflects the impact of the node hardware anomaly on the system.

[0121] In an embodiment of the present application, the extraction module obtains these two factors from the cross-domain correlation calculation results, where the propagation intensity factor is calculated based on the vulnerability impact range and component importance, and the load anomaly factor is calculated based on the temperature anomaly degree and duration.

[0122] Step 304: Multiply the vulnerability propagation intensity factor by the corresponding path length attenuation coefficient to obtain a dynamic propagation correction value at the software level.

[0123] In step 304 , the dynamic propagation correction value refers to the software vulnerability propagation impact score after path attenuation adjustment.

[0124] In an embodiment of the present application, the vulnerability propagation intensity factor is multiplied by the attenuation coefficient of the corresponding path to obtain a modified score that takes the propagation distance into account, and the propagation impact of distant nodes will be reduced accordingly.

[0125] Step 305: Multiply the load anomaly intensity factor by the spatial overlap ratio of the hardware load anomaly regions of the nodes at both ends of the connection path to obtain an anomaly superposition correction value at the hardware level.

[0126] In step 305, the hardware load anomaly regions at the nodes at both ends of the connection path specifically refer to the hardware anomaly regions corresponding to the two nodes associated with the specific connection path currently being traversed when calculating the repair association strength. This is used to calculate the path repair impact value at the micro level. The "current hardware load anomaly region" refers to the set of all hardware anomaly regions that exist globally in the target system when generating the patch deployment strategy. This is used to calculate the resource allocation ratio at the macro level. The two represent the relationship between the local and the global, and between the intermediate calculation quantity and the final decision basis. The anomaly overlap correction value refers to the hardware impact score after taking into account the overlap of hardware anomaly regions.

[0127] In the embodiment of the present application, the load anomaly intensity factor is multiplied by the spatial overlap ratio of the temperature anomaly regions of the nodes at both ends of the path to reflect the mutual influence of the hardware anomalies of adjacent nodes.

[0128] Step 306: linearly superimpose the dynamic propagation correction value and the abnormal superposition correction value according to a preset weight ratio to generate a repair impact value of the connection path.

[0129] In step 306, the repair impact value refers to the comprehensive impact score of a single path on the node repair priority.

[0130] In the embodiment of the present application, the dynamic propagation correction value and the abnormal superposition correction value are added according to the software weight and the hardware weight to obtain the final impact value of the path.

[0131] Step 307: Generate repair association strength according to the repair impact values ​​of all connection paths in the dynamic graph structure.

[0132] In an embodiment of the present application, the repair impact values ​​of all paths involved in a node are weighted and accumulated to obtain the final repair association strength of the node.

[0133] Here's a specific example:

[0134] In a financial system vulnerability mitigation scenario, for a vulnerability discovered in a trading engine node, the dynamic weight allocation model first traverses the connection paths: the first-level path (level 1, attenuation coefficient 1.0) from the trading engine to the risk control node, and the second-level path (level 2, attenuation coefficient 0.7) from the trading engine to the clearing node to the risk control node. The model extracts the vulnerability propagation intensity factor (1.1, calculated based on the impact on five downstream components) and the load anomaly intensity factor (1.3, corresponding to a CPU temperature of 90°C) for the trading engine node, and calculates the dynamic propagation correction value for the first-level path as 1.1 × 1.0 = 1.1. The temperature anomaly regions at both ends of this path overlap by 70%, resulting in an anomaly superposition correction value of 1.3 × 0.7 = 0.91. Linearly superimposing the software weight of 0.6 and the hardware weight of 0.4 yields a remediation impact value of 1.1 × 0.6 + 0.91 × 0.4 = 1.024. Due to hierarchical attenuation, the dynamic propagation correction value for the secondary path is 1.1 × 0.7 = 0.77, the anomaly superposition correction value is 1.3 × 0.5 = 0.65 (50% overlap area), and the repair impact value is 0.77 × 0.6 + 0.65 × 0.4 = 0.722. The final repair correlation strength of the trading engine node is the sum of the impact values ​​of each path: 1.024 + 0.722 = 1.746.

[0135] In the embodiment of the present application, the method dynamically quantifies the repair correlation strength of each node, thereby achieving scientific priority sorting that comprehensively considers the software vulnerability propagation characteristics and hardware abnormal status, effectively improving the accuracy and reliability of complex system vulnerability repair.

[0136] To address the problem of inaccurate node repair priority assessment in the prior art and further improve the rationality of the repair strategy, in some embodiments, step 307: generating the repair association strength based on the repair impact values ​​of all connection paths in the dynamic graph structure includes:

[0137] Step 401: Based on all connection paths connected to the current node in the dynamic graph structure, a repair impact value of each connection path is directionally corrected according to the path length attenuation coefficient.

[0138] In step 401, directional correction refers to adjusting the repair impact value according to the dependency direction of the connection path, reflecting the directional characteristics of vulnerability propagation.

[0139] In an embodiment of the present application, the repair impact value is weighted according to the directionality of the dependency relationship. The impact value of the upstream node on the downstream node remains unchanged, while the impact value of the downstream node on the upstream node is attenuated according to a preset ratio, reflecting the characteristic that the vulnerability mainly propagates along the dependency direction.

[0140] Step 402: For each connection path, the repair impact value after directionality correction is added with weight coefficients corresponding to the spatial overlap ratios of the hardware load abnormality regions of the nodes at both ends of the connection path to generate a path contribution value.

[0141] In step 402, the weight coefficient is an amplification factor set based on the degree of overlap between hardware load anomaly regions, used to enhance the mutual influence between physically adjacent nodes. The weight coefficient corresponding to the spatial overlap ratio is directly correlated with the load anomaly intensity factor: the weight coefficient is a scaling parameter dynamically adjusted based on the magnitude of the load anomaly intensity factor. When the load anomaly intensity factor is larger, the corresponding weight coefficient increases accordingly, increasing the impact of hardware anomaly region overlap on the path contribution value. Together, these two factors constitute a quantitative assessment system for the impact of hardware anomaly at the hardware level. The path contribution value is the final impact score of a single connection path on the node repair priority. It is generated by first applying a directional correction to the repair impact value (reflecting the directional characteristics of vulnerability propagation) and then adding the weight coefficients corresponding to the spatial overlap ratio of the hardware load anomaly regions at the nodes at both ends of the path (reflecting the degree of anomaly correlation between physically adjacent nodes). This value comprehensively considers the vulnerability propagation impact at the software level and the correlation between hardware anomaly states. For example, when the temperature anomaly regions of two nodes overlap significantly, their path contribution value increases, indicating a strong correlation between the repair priorities of the two nodes.

[0142] In an embodiment of the present application, for each connection path, the spatial overlap ratio of the temperature anomaly areas of the nodes at both ends is queried, and the weight coefficient is calculated according to the ratio of the overlapping area to the total area. The coefficient is multiplied by the repair impact value after directionality correction to obtain the path contribution value considering the hardware anomaly association.

[0143] Step 403: Accumulate the path contribution values ​​of the current node on all connection paths according to the topological order of all connection paths.

[0144] In step 403, topological order accumulation refers to aggregating path contribution values ​​step by step from bottom-level nodes to upper-level nodes according to the hierarchical order of dependencies.

[0145] In an embodiment of the present application, the path contribution values ​​of the current node and all directly dependent nodes are first accumulated, and then the contribution values ​​of the indirectly dependent nodes are accumulated, where the contribution values ​​of the indirectly dependent nodes need to be attenuated according to their dependency levels, and finally the total contribution value of the node is obtained.

[0146] Step 404: Generate the repair association strength of the current node according to the accumulation result.

[0147] In step 404, the current node indicates that each node is to be used as the current node.

[0148] In an embodiment of the present application, the total contribution value of the node is input into a preset strength mapping function to generate a standardized repair association strength value for subsequent priority sorting.

[0149] Here's a specific example:

[0150] In the financial trading system vulnerability remediation scenario, the vulnerability handling process for the trading engine node is as follows: First, the first-level path from the trading engine to the risk control node undergoes a directional correction, with the remediation impact value of 1.024. Due to the positive dependency, the original value remains unchanged. Then, based on the 70% overlap between the temperature anomaly areas of the two nodes, a weighting factor of 1.3 is applied (calculated as: base factor 1.0 + 70% overlap × 0.5 = 1.35, rounded to 1.3), resulting in a path contribution value of 1.024 × 1.3 = 1.331. The second-level path from the trading engine to the clearing node to the risk control node undergoes a directional correction, with the remediation impact value of 0.722. Due to the reverse dependency, the path is corrected using a hierarchical attenuation factor of 0.7 and a directional attenuation factor of 0.8, resulting in a value of 0.722 × 0.7 × 0.8 = 0.404. Based on the 50% overlap between the temperature anomaly areas, a weighting factor of 1.2 is applied, resulting in a final path contribution value of 0.404 × 1.2 = 0.485. The contribution values ​​of the two paths are accumulated in topological order. The direct path contribution value of 1.331 is fully weighted, and the indirect path contribution value of 0.485 is converted to 0.340 based on the secondary path weight of 0.7. The total of 1.671 is used as the repair association strength of the transaction engine node.

[0151] In an embodiment of the present application, the method achieves accurate quantification of node repair priority through dual optimization of directional correction and hardware anomaly superposition, ensuring that key nodes can be repaired in a timely manner while avoiding resource waste and excessive repair.

[0152] To address the problem in the prior art that the node repair order may violate system dependencies and further improve the rationality of the repair strategy, in some embodiments, step 204: generating a node repair priority sequence based on the repair association strength includes:

[0153] Step 501: sorting the repair association strengths of all nodes in the dynamic graph structure by numerical values ​​to generate an initial priority queue.

[0154] In step 501, the initial priority queue refers to a node sequence list arranged only by the repair association strength value from high to low.

[0155] In an embodiment of the present application, the repair association strengths of all nodes in the dynamic graph structure are first collected, and these strength values ​​are arranged in descending order to generate a preliminary repair order list, at which time only the repair urgency of the nodes is considered.

[0156] Step 502: Check the component interaction topology relationship corresponding to each node in the initial priority queue. When a node pair with a direct dependency relationship is detected, adjust the priority order of each node in the node pair to generate an intermediate priority queue.

[0157] In step 502, the component interaction topology corresponding to each node refers to the inter-component call dependency relationships recorded in the dynamic graph structure. This is derived from the system runtime data analyzed during the construction of the dynamic graph structure, including actual interaction relationships such as service call chains and data flow paths. For example, a web node calls a database node's API interface, or a microservice message queue subscription relationship exists. These relationships are stored in the dynamic graph structure as directed edges and are used to determine direct dependencies between nodes. A node pair with a direct dependency relationship refers to a direct dependency relationship between two component nodes during system operation, characterized by real-time data interaction or service calls. This manifests as node A requiring node B to complete a specific operation before executing its own function. For example, a "web node and database node" dependency pair is formed when a web service node directly calls a database node to perform a query. For example, if the database node (repair association strength 85) is ranked higher than the web node (strength 90) in the initial priority queue, but it is detected that the web node directly depends on the database node's service response (the component interaction topology shows a strong dependency edge between the web and database nodes), the database node's priority is adjusted to a higher level than the web node's. This ensures that the dependent database node is repaired first, preventing the web node from malfunctioning after repair due to an unrepaired database node. The intermediate priority queue is a transitional sorted list generated after dependency adjustments are made to the initial priority queue. This queue maintains the original repair association strength order while ensuring that dependent nodes are always sorted before the nodes that depend on them. For example, if the initial queue contains "Service A to Service B" but the actual topology is "Service B depends on Service A," Service A will be re-adjusted to be ahead of Service B.

[0158] In this embodiment, the dependencies of adjacent nodes in the initial queue are checked. If a node is found to depend on a node ranked after it, the dependent node is forced to be brought forward to the dependent node, ensuring that the basic service is repaired first. The adjusted queue retains the original strength ranking and only swaps the order of node pairs that violate the dependency relationship.

[0159] Step 503: performing secondary sorting on the nodes at the same dependency level in the intermediate priority queue according to the temperature field distribution interval of the hardware load abnormality area to generate a target priority queue.

[0160] In step 503, the temperature field distribution intervals of the hardware load anomaly areas refer to the identified temperature data of the hardware high-temperature areas associated with the vulnerability, including characteristic parameters such as the maximum temperature value and temperature fluctuation range of each anomaly area. This data is derived from server temperature field information collected in real time by optical sensors. After matching the vulnerability's thermodynamic model, it is marked as an anomaly area and used to assess the real-time load status of the physical device where the node is located. The same dependency level refers to nodes with the same topological depth in the dynamic graph structure, where the topological depth is determined by the node's position in the component interaction topology. Specifically, if the shortest connection path from two nodes to the topmost dependency node in the dynamic graph structure contains the same number of hops, the two nodes are considered to be at the same dependency level. During the secondary sorting, only the degree of deviation of the temperature field distribution intervals of the hardware load anomaly areas between nodes that meet this condition is compared, without changing the relative order of nodes at different dependency levels determined by the initial priority queue. Nodes at the same dependency level refer to component nodes at the same relative depth in the system dependency topology. The target priority queue is a priority list generated after dependency adjustment and temperature sorting of peer nodes. This queue satisfies three conditions: descending order of repair association strength, system dependency constraints, and prioritizing hot nodes among peer nodes. For example, in a queue, the original strength order of three peer nodes is A>B>C, but because node B has the highest temperature, the final order is adjusted to B>A>C.

[0161] In an embodiment of the present application, for the queue after dependency adjustment, the nodes at the same dependency level are extracted, the temperature peaks of their corresponding hardware load abnormality areas are compared, and these nodes at the same level are rearranged in order of temperature from high to low to ensure that high-temperature nodes receive higher priority.

[0162] Step 504: Match and verify the node order of the target priority queue with the patch compatibility parameter of each node in the dynamic graph structure.

[0163] In step 504, the node order of the target priority queue refers to the finalized repair execution order, which is generated by the following process: first sorting by repair association strength, then forcing dependent nodes to precede, and finally reordering peer nodes by temperature value. For example, from the initial queue [payment service 3.2, risk control service 2.9, account service 2.5], after dependency adjustment, it becomes [payment service 3.2, account service 2.5, risk control service 2.9], and then finally determined to be [payment service 3.2, account service 2.5, risk control service 2.9] because the account service temperature is higher. This order serves as the core execution basis of the patch deployment strategy. Patch compatibility parameters refer to deployment restrictions such as version constraints and dependency conditions of the patches required by the nodes.

[0164] In the embodiment of the present application, the target priority queue is compared with the patch installation requirements of each node to check whether there is a situation where patch conflicts prevent the deployment in order. If conflicts are found, the node order is fine-tuned under the premise of meeting the dependency constraints.

[0165] Step 505: Generate a node repair priority sequence based on the matching verification result.

[0166] In step 505, the position of each node in the node repair priority sequence is determined by its repair association strength, dependency constraints, hardware load abnormality degree and patch compatibility.

[0167] In the embodiment of the present application, all adjustment results of the preceding steps are integrated to generate a final repair order list that takes into account the urgency of repair and complies with the actual operation constraints of the system.

[0168] Here's a specific example:

[0169] In an e-commerce platform vulnerability remediation scenario, the system detected vulnerabilities in the order service node (with a remediation correlation strength of 1.8), the payment service node (1.6), and the inventory service node (1.5). An initial priority queue was generated: [Order Service 1.8, Payment Service 1.6, Inventory Service 1.5]. Inspection of the component interaction topology revealed that the payment service depended on the inventory service (the payment service called the inventory API to check inventory). Adjustments were made to generate an intermediate queue: [Order Service 1.8, Inventory Service 1.5, Payment Service 1.6]. Hardware analysis revealed that the order service and inventory service were both first-level dependent nodes, but the server hosting the order service had a higher temperature (core temperature of 88°C vs. 82°C for the inventory service), maintaining its priority. Verifying patch compatibility revealed that the payment service patch required the inventory service to be upgraded to version 2.3 (currently V2.2). This ultimately resulted in a priority sequence: [Order Service 1.8, Inventory Service 1.5, Payment Service 1.6].

[0170] In an embodiment of the present application, the method uses a multi-level priority adjustment mechanism to ensure that the generated repair order not only meets the system dependency constraints but also can promptly handle high-load abnormal nodes, effectively avoiding system service interruptions or secondary failures caused by improper repair order.

[0171] To address the problem of insufficient vulnerability propagation path prediction accuracy in the prior art and further improve the reliability of vulnerability feature analysis, in some embodiments, step 102: semantically associating the multi-source heterogeneous data with historical repair records in a preset vulnerability database and combining the dynamic dependency chain of the target system to generate vulnerability propagation path features includes:

[0172] Step 601: extract vulnerability attribute fields and patch compatibility parameters from the multi-source heterogeneous data, and perform field matching with historical repair records in a preset vulnerability database.

[0173] In step 601, the vulnerability attribute field refers to a data set describing the basic characteristics of the vulnerability, including parameters such as vulnerability type (e.g., SQL injection, buffer overflow), severity level (e.g., high, medium), and affected components. These fields are derived from vulnerability scanning tool detection reports, system security logs, and related queries of third-party vulnerability databases. These fields are extracted through standardized processing to form structured data. For example, a SQL (Structured Query Language) injection vulnerability can be identified by analyzing web application error logs, and detailed attribute information of the vulnerability can be obtained by matching it with the vulnerability database. Patch compatibility parameters refer to the system environment constraints imposed by the patch package required to fix the vulnerability, including supported operating system versions, dependent software versions, and hardware architecture requirements. These parameters are derived from metadata provided by the patch publisher and compatibility experience data accumulated from historical deployment records. For example, if a vulnerability patch document explicitly states "only applicable to Linux kernel version 3.10 and above," this condition will be extracted as a key compatibility parameter. Field matching is the process of comparing the attribute parameters of the current vulnerability with the corresponding fields in historical records for similarity. The specific matching process includes: comparing the attribute fields of the current vulnerability with the vulnerability features recorded in the historical repair records for similarity, and verifying the compatibility parameters of the current patch with the compatibility conditions of the successful repair cases recorded in the historical repair records.

[0174] In an embodiment of the present application, key attributes such as vulnerability type and impact scope in multi-source heterogeneous data are first parsed and compared item by item with the fields recorded in the vulnerability database. When the vulnerability type is the same and the overlap of the impact scope reaches a preset threshold, it is determined to be a historical repair record that has been successfully matched.

[0175] Step 602: Extract the vulnerability propagation path pattern recorded in the historical repair record of successful matching.

[0176] In step 602, a successful match indicates that both the similarity comparison and the consistency verification are successful. The vulnerability propagation path pattern refers to the typical path characteristics of the vulnerability propagation in the system recorded in the historical records.

[0177] In an embodiment of the present application, the recorded vulnerability propagation process is extracted from the successfully matched historical records, including characteristic parameters such as the affected component sequence and the propagation time interval, to form a standardized propagation pattern template.

[0178] Step 603: Map the vulnerability propagation path pattern to the dynamic dependency chain of the target system, and adjust the component sequence in the vulnerability propagation path pattern according to the real-time interaction relationship between components in the dynamic dependency chain.

[0179] In step 603, the real-time interaction relationships between components refer to the actual call dependencies and data flows between functional modules in the target system's current operating state, including dynamic information such as API call frequency, message queue subscription relationships, and shared memory access. These relationships are derived from real-time system monitoring data, service grid traffic records, and communication statistics between components in the resource monitoring system. Mapping adjustment is the process of adapting the historical propagation model to the actual architecture of the current system. Specifically, this adjustment process involves removing path nodes corresponding to components that no longer exist in the target system and inserting corresponding path connections at locations where new dependencies exist in the dynamic dependency chain. The component sequence is the ordered arrangement of components along the path a vulnerability passes through in the system, reflecting the vulnerability's spread from the point of intrusion to the affected area. This sequence is adjusted based on the component order in the historical vulnerability propagation model and the current system's real-time interaction relationships. For example, the sequence "A to B to C" in the historical record is adjusted to "A to B to D to C" based on the newly added call relationship B to D in the current system, ensuring that the sequence reflects the actual architecture.

[0180] In an embodiment of the present application, the extracted historical propagation pattern is compared with the real-time dependency chain of the target system. According to the actual calling relationship and data flow between the current components, the component sequence in the historical pattern is added, deleted or adjusted in order to ensure that the propagation path conforms to the current system status.

[0181] Step 604: Generate vulnerability propagation path features based on the adjusted component sequence.

[0182] In an embodiment of the present application, based on the adjusted component sequence, combined with the dependency strength and data flow frequency between components, a weighted directed propagation path graph is generated, where the nodes represent system components and the edge weights represent the possibility of vulnerability propagation.

[0183] Here's a specific example:

[0184] After detecting a vulnerability in a file service node on a cloud platform, the system first extracted the node's vulnerability attributes and patch compatibility parameters. By matching the vulnerability database, three historical records were found. Record A (85% match) indicated that a similar vulnerability had propagated along the path from "file service to data verification to archiving service." Based on real-time dependency chain analysis of the current system, it was discovered that the data verification service had added calls to the virus scanning service (approximately 500 calls per day). The historical path was adjusted to "file service to data verification to virus scanning to archiving service." The propagation strength of each path was calculated: 0.95 for file service to data verification (base value 0.9 × call frequency coefficient 1.05), 0.85 for data verification to virus scanning (base value 0.8 × call frequency coefficient 1.06), and 0.7 for virus scanning to archiving service (base value 0.7 × 1.0). Furthermore, the CPU temperature of the server hosting the file service node rose from 65°C to 82°C (safety threshold 80°C) within 5 minutes, matching the historical attack temperature curve by 90%, indicating that this was the abnormal load region triggering the vulnerability. In the final propagation path feature graph, file service nodes are marked in red (highest risk), data verification and virus scanning nodes are marked in orange (medium risk), and the edge weights are 0.95, 0.85, and 0.7, respectively.

[0185] In the embodiment of the present application, this method dynamically matches historical data with real-time system status to generate vulnerability propagation path characteristics that are more consistent with the actual system architecture, providing a reliable basis for accurately formulating repair strategies, and effectively avoiding the problems of incomplete or excessive repairs caused by path prediction deviations in traditional solutions.

[0186] To address the difficulty in accurately identifying vulnerability-related hardware anomalies in the prior art and further improve the accuracy of anomaly detection, in some embodiments, step 103: performing spatiotemporal correlation matching of the temperature field distribution with the thermodynamic pattern of known vulnerability attack behaviors to identify hardware load anomaly areas in the target system triggered by the vulnerability, includes:

[0187] Step 701: Divide the temperature field distribution into continuous monitoring segments according to time windows.

[0188] In step 701, continuous refers to adjacent monitoring segments without any gaps in time. Each segment is connected to the previous and next segments on the time axis, covering the entire monitoring period. Monitoring segments refer to time units of continuously collected temperature field data divided into fixed time periods.

[0189] In an embodiment of the present application, the temperature field data is divided into time windows containing several sampling points according to the system sampling frequency and vulnerability attack characteristics. Each window covers a complete temperature change cycle, which facilitates capturing the complete thermodynamic characteristics of the attack behavior.

[0190] Step 702: For each monitoring segment, extract the temperature change curve characteristics of the monitoring segment, and compare the shape similarity of the temperature change curve characteristics with the temperature change curves of each vulnerability type in the thermodynamic pattern library of known vulnerability attack behaviors to screen candidate vulnerability types whose similarity exceeds a first threshold.

[0191] In step 702, the temperature change curve features refer to the morphological characteristic parameters of the temperature fluctuations over time within the monitoring segment. The thermodynamic pattern library contains typical temperature change curves and spatial distribution features corresponding to different vulnerability types. The temperature change curve records the temperature fluctuation amplitude and periodicity of the processor core during a vulnerability attack, while the spatial distribution features record the temperature gradient distribution of the memory modules and storage devices during a vulnerability attack. Candidate vulnerability types are a set of possible vulnerability attack types selected through preliminary matching of temperature change curve features. These types of thermodynamic time characteristics (such as heating rate and fluctuation period) are highly similar to the temperature curve morphology of the current monitoring segment. For example, if a monitoring segment shows a sharp increase in CPU temperature within a short period of time accompanied by periodic fluctuations, "denial of service attack" and "buffer overflow attack" may be matched as candidate types for subsequent spatial feature verification.

[0192] In an embodiment of the present application, the rising slope, fluctuation frequency, peak duration and other characteristics of the temperature curve are extracted for each monitoring segment, and the morphology is compared with the standard curves of various vulnerability attacks in the thermodynamic pattern library to screen out candidate vulnerability types whose curve similarity meets the set standards.

[0193] Step 703: extracting the spatial temperature gradient characteristics of the monitoring segment and comparing the regional overlap with the spatial distribution characteristics corresponding to the candidate vulnerability types to screen specific vulnerability types whose overlap exceeds a second threshold.

[0194] In step 703 , the spatial temperature gradient feature refers to the difference characteristic parameters of the hardware surface temperature distribution.

[0195] In an embodiment of the present application, spatial features such as the temperature difference rate and the expansion speed of high-temperature areas in different physical regions within a monitoring segment are calculated. Regional overlap analysis is performed with typical distribution patterns corresponding to candidate vulnerability types (such as concentrated heat in the CPU core and high-temperature memory stripes), further narrowing the scope of vulnerability types. A specific vulnerability type refers to the vulnerability attack type ultimately determined after secondary verification of spatial temperature gradient characteristics. Not only does its temperature change curve in the time dimension match, but its temperature distribution characteristics in the spatial dimension (such as the shape of the high-temperature area and the gradient change rate) are also highly consistent with the current system state. For example, when a monitoring segment simultaneously meets the spatial characteristics of "concentrated high heat in the core area" and "steep gradient drop in the edge area," it can be determined to be a specific type of "SQL injection attack," distinguishing it from other candidate types.

[0196] Step 704: When the monitoring segment matches the specific vulnerability type, the spatial area where the temperature value in the monitoring segment continuously exceeds the alarm threshold corresponding to the specific vulnerability type in the thermodynamic pattern library is marked as a hardware load abnormality area triggered by the vulnerability.

[0197] In step 704, "duration" refers to the duration of the monitoring segment's time window. Specifically, it refers to the entire period from the time the temperature value first exceeds the alarm threshold until the end of the monitoring segment (i.e., the beginning of the next time window). During this period, the temperature value remains uninterrupted above the alarm threshold. This entire time span is the duration of the hardware load abnormality zone. The alarm threshold refers to the temperature danger threshold preset in the thermodynamic model library for various vulnerabilities.

[0198] In an embodiment of the present application, when the monitoring segment satisfies both the time curve matching and the spatial distribution matching, the physical area that continuously exceeds the corresponding vulnerability type alarm threshold is marked as an abnormal area, and the boundary of the area is dynamically adjusted according to the temperature gradient change rate.

[0199] Here's a specific example:

[0200] During a security incident involving an online payment system, infrared sensors detected an abnormal temperature distribution on the server hosting the transaction engine node. The system first divided the temperature data from the last 15 seconds into three monitoring segments (one segment every 5 seconds). In the second segment (seconds 6-10), the CPU temperature spiked from 65°C to 88°C (at a rate of 4.6°C / second). This spike showed a 92% similarity with the temperature curve for a "distributed denial of service attack" in the thermodynamics pattern library (calculated using a dynamic time warping algorithm), exceeding the 90% threshold for matching. Therefore, this attack type was identified as a candidate. Further analysis of the spatial characteristics of this segment revealed that the high temperature region was concentrated in the third core of the CPU (occupying 85% of the area). This overlapped 94% with the typical distribution of this attack type in the pattern library (80-90% of the core area), exceeding the 90% threshold for matching. This ultimately led to the identification of this attack type as a "distributed denial of service attack." According to the pattern library, the temperature alarm threshold for this attack type is 85°C. Since the temperature of the third core in the monitoring segment exceeded the threshold for 8 seconds (reaching a maximum of 88°C), this core area was marked as an abnormally loaded region triggering the vulnerability.

[0201] In the embodiment of the present application, the method can accurately distinguish abnormal loads caused by vulnerability attacks from normal business loads through thermodynamic feature matching in the dual dimensions of time and space, reduce the false alarm rate, and provide a reliable hardware status basis for timely blocking the spread of attacks.

[0202] Figure 2A schematic diagram of the structure of an automated vulnerability processing system provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, the system includes:

[0203] The acquisition module 21 is used to acquire multi-source heterogeneous data and the temperature field distribution when the target system is running.

[0204] The association module 22 is used to semantically associate the multi-source heterogeneous data with the historical repair records in the preset vulnerability database, and generate vulnerability propagation path characteristics in combination with the dynamic dependency chain of the target system.

[0205] The matching module 23 is used to perform spatiotemporal correlation matching between the temperature field distribution and the thermodynamic pattern of known vulnerability attack behaviors, and identify hardware load abnormality areas triggered by the vulnerability in the target system.

[0206] The generation module 24 is used to generate a patch deployment strategy by collaboratively processing the vulnerability propagation path characteristics and the hardware load abnormality area through a dynamic graph attention mechanism.

[0207] The adjustment module 25 is used to adjust the topological order and data throughput of the patch distribution path in the patch deployment strategy in real time during the execution of the patch deployment strategy, and dynamically optimize the resource occupancy ratio during the patch deployment process so that the service interruption duration across the system is maintained within a preset safety window.

[0208] Figure 2 The automated vulnerability processing system can execute Figure 1 The implementation principle and technical effects of the automated vulnerability handling method described in the illustrated embodiment will not be elaborated on here. The specific manner in which each module and unit performs operations in the automated vulnerability handling system in the above embodiment has been described in detail in the embodiment of the method and will not be elaborated on here.

[0209] In one possible design, Figure 2 An automated vulnerability handling system of the embodiment shown can be implemented as a computing device, such as Figure 3 As shown, the computing device may include a storage component 31 and a processing component 32;

[0210] The storage component 31 stores one or more computer instructions, wherein the one or more computer instructions are called and executed by the processing component 32 .

[0211] The processing component 32 is as follows Figure 1 The embodiment provides an automated vulnerability processing method.

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

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

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

[0215] The input / output interface provides an interface between the processing component and the peripheral interface module, which can be an output device, an input device, etc.

[0216] The communication component is configured to facilitate, among other things, wired or wireless communications between the computing device and other devices.

[0217] Among them, the computing device can be a physical device or an elastic computing host provided by a cloud computing platform, etc. In this case, the computing device can refer to a cloud server, and the above-mentioned processing components, storage components, etc. can be basic server resources rented or purchased from the cloud computing platform.

[0218] The present application also provides a computer storage medium storing a computer program, wherein the computer program can achieve the above-mentioned Figure 1 An automated vulnerability handling method according to the illustrated embodiment.

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

[0220] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0221] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the essence of the above technical solution, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for causing a computer device (such as a personal computer, server, or network device) to execute the methods described in each embodiment or certain portions of the embodiments.

[0222] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. An automated vulnerability handling method, characterized in that: include: Acquire multi-source heterogeneous data and the temperature field distribution of the target system during operation; Semantically associating the multi-source heterogeneous data with historical repair records in a preset vulnerability database, and combining them with the dynamic dependency chain of the target system to generate vulnerability propagation path features; Performing spatiotemporal correlation matching between the temperature field distribution and the thermodynamic pattern of known vulnerability attack behaviors to identify hardware load anomaly areas in the target system triggered by the vulnerability; Generate a patch deployment strategy by collaboratively processing the vulnerability propagation path characteristics and the hardware load abnormality area through a dynamic graph attention mechanism; During the execution of the patch deployment strategy, the topological order and data throughput of the patch distribution path in the patch deployment strategy are adjusted in real time, and the resource usage ratio during the patch deployment process is dynamically optimized to keep the service interruption duration across the system within the preset safety window; The collaborative processing of the vulnerability propagation path features and the hardware load abnormality area by the dynamic graph attention mechanism to generate a patch deployment strategy includes: Through the dynamic graph attention mechanism, a dynamic graph structure is constructed according to the vulnerability propagation path characteristics and the hardware load abnormality area; Calculating cross-domain correlation of attributes of each node in the dynamic graph structure; The cross-domain correlation calculation result is input into a trained dynamic weight allocation model, which calculates the repair correlation strength between different nodes by traversing the connection paths of each node in the dynamic graph structure; generating a node repair priority sequence according to the repair association strength; Calculating the resource allocation ratio required for patch deployment based on the dynamic graph structure and the current hardware load abnormality area; The node repair priority sequence and the resource allocation ratio are combined into a patch deployment strategy.

2. The method according to claim 1, characterized in that The cross-domain correlation calculation result is input into a trained dynamic weight allocation model. The dynamic weight allocation model calculates the repair correlation strength between different nodes by traversing the connection path of each node in the dynamic graph structure, including: Inputting the cross-domain correlation calculation result into a trained dynamic weight allocation model, and traversing the connection paths of each node in the dynamic graph structure through the traversal module of the dynamic weight allocation model; determining a path length attenuation coefficient according to a topological level of the connection path; Extracting the vulnerability propagation intensity factor and the load anomaly intensity factor from the cross-domain correlation calculation result for each node on each connection path through the extraction module of the dynamic weight allocation model; Multiplying the vulnerability propagation intensity factor by the corresponding path length attenuation coefficient to obtain a dynamic propagation correction value at the software level; Multiplying the load anomaly intensity factor by the spatial overlap ratio of the hardware load anomaly regions of the nodes at both ends of the connection path to obtain an anomaly superposition correction value at the hardware level; Linearly superimposing the dynamic propagation correction value and the abnormal superposition correction value according to a preset weight ratio to generate a repair impact value of the connection path; The repair association strength is generated according to the repair impact values ​​of all connection paths in the dynamic graph structure.

3. The method according to claim 2, characterized in that Generating the repair association strength according to the repair impact values ​​of all connection paths in the dynamic graph structure includes: According to all connection paths connected to the current node in the dynamic graph structure, a repair impact value of each connection path is directionally corrected according to the path length attenuation coefficient; For each connection path, the repair impact value after directionality correction is added with the weight coefficient corresponding to the spatial overlap ratio of the hardware load abnormality areas of the nodes at both ends of the connection path to generate a path contribution value. Accumulate the path contribution values ​​of the current node on all connection paths according to the topological order of all connection paths; According to the accumulated results, the repair association strength of the current node is generated.

4. The method according to claim 1, wherein Generating a node repair priority sequence according to the repair association strength includes: Sorting the repair association strengths of all nodes in the dynamic graph structure by numerical value to generate an initial priority queue; Checking the component interaction topology relationship corresponding to each node in the initial priority queue, and when detecting a node pair with a direct dependency relationship, adjusting the priority order of each node in the node pair to generate an intermediate priority queue; According to the temperature field distribution interval of the hardware load abnormality area, the nodes at the same dependency level in the intermediate priority queue are secondary sorted to generate a target priority queue; Matching and checking the node order of the target priority queue with the patch compatibility parameters of each node in the dynamic graph structure; Based on the matching verification results, a node repair priority sequence is generated.

5. The method according to claim 1, wherein The semantic association of the multi-source heterogeneous data with the historical repair records in the preset vulnerability database and the generation of vulnerability propagation path features in combination with the dynamic dependency chain of the target system include: Extracting vulnerability attribute fields and patch compatibility parameters from the multi-source heterogeneous data, and matching them with historical repair records in a preset vulnerability database; Extract vulnerability propagation path patterns recorded in historical repair records that have successfully matched; Mapping the vulnerability propagation path pattern to the dynamic dependency chain of the target system, and adjusting the component sequence in the vulnerability propagation path pattern according to the real-time interaction relationship between components in the dynamic dependency chain; Generate vulnerability propagation path features based on the adjusted component sequence.

6. The method according to claim 1, characterized in that The step of performing spatiotemporal correlation matching between the temperature field distribution and the thermodynamic pattern of known vulnerability attack behaviors to identify hardware load anomaly areas in the target system triggered by the vulnerability includes: Dividing the temperature field distribution into continuous monitoring segments according to time windows; For each monitoring segment, extract the temperature change curve characteristics of the monitoring segment, and compare the shape similarity of the temperature change curve characteristics with the temperature change curves of each vulnerability type in the thermodynamic pattern library of known vulnerability attack behaviors to screen candidate vulnerability types whose similarity exceeds a first threshold; Extracting the spatial temperature gradient characteristics of the monitoring segment and comparing the regional overlap with the spatial distribution characteristics corresponding to the candidate vulnerability types to screen specific vulnerability types whose overlap exceeds a second threshold; When the monitoring segment matches the specific vulnerability type, the spatial area in which the temperature value in the monitoring segment continuously exceeds the alarm threshold corresponding to the specific vulnerability type in the thermodynamic pattern library is marked as a hardware load abnormality area triggered by the vulnerability.

7. An automated vulnerability handling system, characterized in that: include: Acquisition module, used to obtain multi-source heterogeneous data and the temperature field distribution of the target system during operation; An association module is used to semantically associate the multi-source heterogeneous data with historical repair records in a preset vulnerability database, and generate vulnerability propagation path features in combination with the dynamic dependency chain of the target system; a matching module, configured to perform spatiotemporal correlation matching of the temperature field distribution with thermodynamic patterns of known vulnerability attack behaviors, and identify hardware load anomaly areas in the target system triggered by the vulnerability; A generation module is used to generate a patch deployment strategy by collaboratively processing the vulnerability propagation path characteristics and the hardware load abnormality area through a dynamic graph attention mechanism; An adjustment module is used to adjust the topological order and data throughput of the patch distribution path in the patch deployment strategy in real time during the execution of the patch deployment strategy, and dynamically optimize the resource usage ratio during the patch deployment process so that the service interruption duration across the system is maintained within a preset safety window; The collaborative processing of the vulnerability propagation path features and the hardware load abnormality area by the dynamic graph attention mechanism to generate a patch deployment strategy includes: Through the dynamic graph attention mechanism, a dynamic graph structure is constructed according to the vulnerability propagation path characteristics and the hardware load abnormality area; Calculating cross-domain correlation of attributes of each node in the dynamic graph structure; The cross-domain correlation calculation result is input into a trained dynamic weight allocation model, which calculates the repair correlation strength between different nodes by traversing the connection paths of each node in the dynamic graph structure; generating a node repair priority sequence according to the repair association strength; Calculating the resource allocation ratio required for patch deployment based on the dynamic graph structure and the current hardware load abnormality area; The node repair priority sequence and the resource allocation ratio are combined into a patch deployment strategy.

8. A computing device, characterized in that It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are used to be called and executed by the processing component to implement an automated vulnerability processing method as described in any one of claims 1 to 6.

9. A computer storage medium, characterized in that A computer program is stored, and when the computer program is executed by a computer, an automated vulnerability processing method according to any one of claims 1 to 6 is implemented.

Images